The receipt

What a receipt is

ARC1 writes a receipt for every governance event (a registration, a proposal, an approval, a role change, a policy change) and, on routes that run through the ARC1 Gateway, for every request decision. Each receipt is signed with Ed25519 and carries the digest of the receipt before it, so a sequence of receipts can be checked as a whole and a gap shows.

Governance receipts are signed by the deployment’s key, not by each person; the record names who acted. Gateway receipts are signed by the enrolled gateway’s own key and chained per gateway.

What it carries

Who

The actor by identifier: a person, a directory sync, a device, an operator, a gateway or an agent. Never a name, an email address or a device label; names are looked up in the directory when someone reads the record.

What

One action from a closed vocabulary, the object it touched, and details limited to identifiers, modes, reason codes and counts.

When and where

The time, the organization, the receipt’s position in its chain and the digest of the receipt before it.

Signed by

The fingerprint of the signing key, and whether that key is the deployment’s configured key.

A gateway decision receipt adds the request’s metadata: the person, agent or device; the model and connection; the decision and its effect; each rule that matched and in which mode; token usage by class; the upstream status and timings; and the version and digest of the policy pack in force. It never carries prompts, replies, headers, tool names, file names or keys.

What a verified chain proves

Checked against an independently trusted public verification key, a chain shows that each record is exactly what the key signed, that nothing between the first record and the head was removed or reordered, and that the head is the one the verifier expected. The check needs no connection to ARC1. The console runs the same verifier in the browser, and a signed export can be verified on a machine that has never seen the hub.

What it does not prove

• That a person signed it. The deployment’s key signs; the record names who acted.
• That an approved change was deployed, or that a request was allowed. A stored gateway receipt means the evidence arrived, not that the request went through.
• That ARC1 saw all traffic. Only routes through the ARC1 Gateway produce request receipts.
• That the newest records are all present. Someone who controls the database can remove the latest receipts and leave a shorter chain that still verifies. An anchor kept outside the database, described in Auditability, makes that detectable up to the last anchor.

Following one request LAB

The Trace explorer follows one request through its receipts: who asked, the edge that saw it, the policy version, the request-side verdict, the route, the response-side verdict, tokens, dollars and the work item it served. Each step is drawn as verified, unverified or missing, and a missing step shows its reason instead of a zero. The response-side step is empty today, because no response-side inspection exists on that path yet.

Trace a dollar works backwards from a cost to the verified receipts that make it up. The figure is gateway-measured at configured rates. It is shown beside provider-billed spend and never added to it, and it is called exact only when every receipt in scope is verified and priced.

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.