Who does the operating work
AI colleagues operate the recurring, high-frequency work: issuing attestations against verified source facts, propagating revocations, running freshness and validity checks, and assembling the evidence records that accompany each reliance event. Relying-side agents query the exchange, verify proofs, and either proceed or escalate according to policy-as-code set by their governors.
The architecture is layered as a network-level utility. It sits above identity and credentialing primitives and beneath the application-level commerce, negotiation and settlement layers, so both the issuer and relying functions are shared infrastructure rather than bespoke per-integration plumbing. That placement is deliberate: the reliance decision belongs in one checkable place, not scattered across every downstream system your agents touch.
Where humans stay accountable
The design keeps the consequential decisions with people. Issuers' human governors define which claims the organisation will attest to and accept liability for. Relying-party governors define which issuers and attestation types are admissible, under what scope, value thresholds and expiry, and receive escalations on ambiguous or high-risk reliance. Agents act only inside those limits.
The audit trail exists to make that accountability practicable rather than nominal. When a decision is later questioned, a governor does not reconstruct scattered logs from memory; the reliance record shows which attestations were verified, under whose scope, and against which liable party. Liability terms are attached to each attestation before any reliance occurs, so who stands behind a claim is settled in advance of an agent acting on it — not argued after the fact.
What is enforced, and what is not yet built
Access is governed by policy-as-code with explicit scope and value thresholds. Attestations carry a revocation mechanism, and for EU adoption the work is aligned to eIDAS 2.0 electronic-attestation-of-attributes conformance. We are plain about the current state: this is early infrastructure proven against a narrow set of high-frequency common facts — licence validity, policy status, certification and granted permissions — with a small group of design-partner issuers and relying parties, not a finished ecosystem.
From there the direction is incremental. Early on, a working issuer-to-relying-party flow for one or two attestation types, with verification and revocation live and every reliance event recorded. Then multiple attestation types and a growing roster of issuers and relying parties, with the governance console supporting thresholds, scope, expiry and escalation routing. Later, a self-serve issuer onboarding path, standardised attestation schemas for common facts, and audit exports that feed external governance and dispute-resolution processes. These are the intended sequence, stated as direction rather than a promise of dates.