The governed execution layer for accountable AI work.

01 | Serving pattern

What this site serves

iorch.net is the public Immaculate product surface. It serves JAWS Flight Deck download links, MCP/API docs, status, and the JAWS checkout lane while the shared Arobi API surface is published on Aura.

• iorch.net: Immaculate MCP/API docs, public status, JAWS downloads, and JAWS checkout.
• aura-genesis.org: Arobi Network, LaaS API, verifier API, and shared developer docs.
• qline.site: JAWS IDE, Qline product copy, downloads, and Qline customer flows.

02 | Governance

How a tool action is admitted

Agent work enters an admission step before shell commands, file edits, deploys, or network calls. Low-risk work proceeds. Higher-risk work asks for operator approval and records the reason.

• Policy gates run before action, not after damage is done.
• Approval holds are visible to the operator.
• Receipts keep the action, route, verdict, and summary together.

03 | Evidence

LaaS turns work into reviewable receipts

The Ledger-as-a-Service lane stores digests and summaries so customers can audit who requested work, which lane handled it, which policy applied, and what result came back.

• Receipts are designed for review, replay, billing, and incident analysis.
• Public pages expose safe summaries only.
• Private keys, prompts, and raw logs stay outside crawlable pages.

04 | Key lanes

Use the right key for the right surface

Arobi tenant routes and Immaculate trust-spine routes are intentionally separated so product access, model access, and evidence writes can be rotated independently.

Arobi API:       X-Arobi-Tenant-Key: <tenant-key>
Immaculate API:  Authorization: Bearer <immaculate-key>
Q Gateway:       Authorization: Bearer <q-key>