Agent Work Receipt v0.1 gives an agent's work a portable record: what it was asked to do, what authority it declared, what it produced, and what evidence supports its reported result. We introduced the Apache-2.0 contract on July 22, 2026.
A receipt helps another tool inspect the work without requiring an OrgX account or internal identifier. It does not make the producer's account true. The consumer still needs to check evidence, signer identity, and any required human acceptance.
Follow a receipt through review
Consider an illustrative code fix. The agent reports that it changed an artifact and ran a check. The reviewer needs the original request, the changed version, and the check result before deciding whether the fix is acceptable.
The receipt puts references to those items in one object. If the check result is missing, the reviewer should retain that gap rather than infer success from a completion message. If someone later changes the claimed outcome, an integrity check can detect that the signed content no longer matches. It cannot determine whether the original code fix solved the right problem.
The Codex fixture provides an actual example of the contract. The accompanying JSON Schema defines its structure. A schema-valid document has the expected shape; that is a different result from verified delivery.
The contract carries intent, actor and declared authority, actions, artifacts, evidence, claimed outcome, and verification. It also accommodates cost, lineage, human interventions, and timestamps. Producer-owned identifiers let the record move between runtimes without pretending that every consumer shares the same database.
A CI runner, coding client, or other agent runtime can emit the format. That is an interoperability contract, not a claim that every listed client already produces complete receipts automatically. The public repository contains the implementation and fixtures to inspect.
Three checks that must stay separate
The verifier answers three questions:
| Check | What it establishes |
|---|---|
| Content integrity | The record matches its declared hash, a fingerprint of its contents. |
| Signature validity | The signature is valid for the supplied key. |
| Trust policy | This consumer trusts that signer for this purpose. |
These are checks on the record and signer. None establishes task success or human acceptance.
A valid signature does not make a signer trusted. A trusted signer does not repair altered content. Neither establishes that the evidence proves the claimed business outcome.
A signer trusted for build attestations need not be authorized to accept a client's delivery.
For implementers, v0.1 hashes RFC 8785 canonical JSON with the root integrity member omitted. Its Ed25519 signature profile signs a domain-separated canonical payload binding the digest and signature metadata. Follow the conformance vectors rather than substituting another serialization or combining all results into one green badge.
Release status and hosted use
At the v0.1 launch, the TypeScript package was a repository preview. The announcement's statement that it is not published to npm yet referred to that release. An October 1, 2026 update recorded that @useorgx/agent-work-receipt 0.2.0 was available on npm. Use the matching version's contract when building an integration.
The schema, fixtures, and validator can be used without an OrgX account. Hosted import is optional: authenticated teams can bring a semantic receipt into a shared OrgX ledger while retaining producer-owned identifiers. Admission stores the account; independent checking and human review remain separate operations.
Inspect one example
Open the public validator and load a fixture. Locate the requested work, authority, artifact, and evidence. Inspect which checks were performed and which questions remain unanswered. The launch video illustrates those distinctions:
The launch video explains receipt checks; it is not a verification of a real delivery.
If you are implementing a producer, compare its output with the schema and published conformance cases. If you are reviewing work, open the artifact and its supporting evidence before recording acceptance. A portable account is useful precisely when it keeps those next checks visible.