Developers / local alpha
Start with the local receipt example below. A separate private governance pilot now connects structured records, signed receipts and sponsored Base Sepolia batches; public developer onboarding is not yet available.
From a checkout of the source repository, install dependencies and run the maintained example. It writes a synthetic machine-event receipt, an issuer-signed presentation and private evidence openings to the ignored build directory. It does not broadcast a transaction.
FROM THE REPOSITORY ROOT
npm ci
node examples/verification-receipt.js
node sdk/typescript/verification-receipt-cli.js derive build/receipt-example/receipt.jsonThe Python reference CLI derives the same receipt format. TypeScript includes signature recovery and anchor helpers; Python does not yet provide signature recovery or an RPC client.
The implementation path
Create a commitment over exact evidence bytes. Keep the returned random salt, source material and access policy in your own private evidence store.
Pin the profile and its definition digest. Bind issuer, subject, event, evidence descriptors, chain destination and optional stream history.
Prepare the EIP-191 attestation message, collect the signature and retain the original receipt, evidence openings and any later batch manifest.
Use an individual anchor or a retained batch manifest. Anchoring is a separate action from evidence creation and application enforcement.
Check profile, opening, signature, authority, proof and canonical inclusion independently. Return the check you actually performed.
The envelope
The 0.4.0-alpha receipt schema accepts only documented envelope fields. Application-specific meaning belongs in exact-byte evidence and versioned profiles, so it cannot silently disappear from the commitment.
Useful failures
An anchor can remain available after source material is lost. It cannot recreate the file or complete a missing opening.
A general receipt may bind evidence but does not inherit historical authority or ZK policy-proof semantics from the authorised AVR flow.
A different file fails an integrity comparison. Treat a legitimate update as a new linked record and fresh decision.
Planned safety profile
The planned dedicated safety profile is designed for integrations that already have a policy gateway, sandbox or monitor. It will bind selected policy versions, tool requests, alerts and authorised interventions to a reviewable timeline.
The governance API can already accept structured control observations and incident records. A dedicated safety profile and gateway example remain planned; neither the portal nor an anchor provides a real-time safety controller or safety verdict.