Auditability

The audit chain

Every registration, approval, role change and policy change in ARC1 is a signed receipt, chained to the one before it, as The receipt describes. The application cannot edit or delete a receipt; the database refuses both when the application’s role attempts them. A full verification starts at the first receipt and walks to the head.

An export carries the receipts exactly as issued, the public keys and a signed manifest of the chain, and it verifies offline against an independently trusted public verification key. Verified means every signature and link holds, the organization and head are the expected ones, and every signer is a key the verifier already trusts. A fingerprint copied from ARC1’s own screen proves consistency, not independence; it has to arrive by another channel.

What a chain cannot stop

Two things are beyond any chain. Someone who controls the database can delete the newest receipts and move the head back, and the shorter chain still verifies. Someone who holds both the signing key and the database can re-sign everything, and only a fingerprint pinned beforehand exposes it. We state both, because an auditor should know where the protection ends.

Anchors outside the database LAB

An anchor copies the chain’s signed head, hourly or daily, into an Amazon S3 bucket the customer owns, under Object Lock in compliance mode, and accepts the copy only after reading it back and confirming its retention. A later truncation is then detectable up to the last anchor.

Restores are checked the same way. In a drill on 7 October 2026, the 2,760 receipts restored from a backup verified against the pinned key and the head recorded before the backup.

Decision records

Each AI spending decision is kept as one portable record: the model permission, the comparisons and the limits set before collection, forecasts, spend assignments, the policy publication, the record’s own limitations, and the receipts and keys behind them. It is kept, and downloadable as a decision packet. A verifier with no dependencies gives one plain verdict, and a packet without a signed export never reads as verified.

A decision record proves what was decided and approved. It does not prove that the change ran, that it saved money, or who held which role at the moment of approval.

Offline proof bundles LAB

A proof bundle seals what ARC1 signed in a window, such as the last 24 hours, 7 days or 30 days: the audit chain, each gateway’s receipt chain, key evidence and the signed policy packs, under a manifest. A standalone verifier checks it with no network, no dependencies and no access to ARC1, against the auditor’s own trusted keys, and answers verified, failed, untrusted signer or gap. Prompts, completions, raw identifiers, directory attribution and private keys are excluded by construction.

A verified bundle shows the records are intact and signed by trusted keys. It does not show that ARC1 saw all traffic, or that nothing happened outside the window.

Isolation between organizations

Every table of organization data carries row-level security, enabled and forced, and the application’s database role cannot bypass it. A coverage gate fails the build if any table, view or privileged function is uncovered; on the released schema it read 175 tables and found none uncovered. A cross-organization test then reads, updates, deletes and inserts as one organization against another’s rows on every table, and each attempt returned nothing or was refused.

Where it stands

LIVE: in the released product and running on our hosted production deployment, with synthetic data. LAB: built or being built, and run only in our lab or against a vendor’s documented interface. NEXT: designed, not yet built. How we use these words.