Here's a question that comes up in more and more conversations we are having. An AI now helps decide things that actually matter to you: whether your loan gets approved or what your kid's tutor app teaches. So you ask the provider running it: how do I know this thing works the way you say it does? And the answer, today, almost everywhere, boils down to: because we say so. Trust us. They point to SOC 2 and ISO audits, internal control systems, audit logs. Think about that for a second. The people running the AI are also the people logging it and writing their own report card. If something breaks or a corner gets cut, the user can’t check. For a to-do app, fine, whatever. But for an AI a government runs for its citizens, or a bank runs on your accounts? "Trust us" can't be where the story ends. The watching itself needs to be provable.

I am thinking about observability in two ways: Operational observability answers whether the system is healthy: latency, failures, traces, metrics. That discipline is pretty mature, and this post isn’t redefining it. Verifiable observability asks whether a regulator, or government customer, or the public can check the operator’s word for them and without being handed the raw data. That property barely exists in today's AI stack.

Self started with one class of verifiable claims: facts about people, proven from their own documents, on their own devices, revealing nothing else. But once you think in terms of verifiable claims rather than trusted assertions, the same cryptographic tools extend naturally to the rest of the stack. 

1. Identity proofs: what can be established about the user

An identity proof establishes that a credential with certain properties authorized this session, not which specific person was holding the phone. That is exactly the right shape for observability, because it is the most you can prove while storing nothing about the person.

• Practical one-human-one-allocation. Free and subsidized access tiers, including the universal basic access schemes now discussed for national models, need sybil resistance. Proof of unique personhood, anchored to government-issued documents, delivers practical uniqueness. 

• Private eligibility gates. "Over 18" as a proof rather than a birthdate in a database, with the observability layer able to show a regulator that every gated session carried one.

• Agent accountability. With Agent ID, agents carry verifiable credentials rooted in an accountable authorization: a human, or an organization, with delegation depth, scope, and expiry expressed in the credential itself. The claim is narrower than one human per agent action. Every agent action maps to a checkable authorization chain, and as agents self-delegate and act under company authority, that chain is the object a court or auditor actually needs.

• Counting without tracking. The primitive here is the nullifier: each credential can derive exactly one unlinkable, application-specific pseudonym, so an operator can report, and an auditor can verify, true unique-user counts while learning nothing about who the users are.

2. Verifiable records: history that cannot be quietly rewritten

The machinery behind Self's identity registries (commitments, Merkle trees, publicly anchored digests) generalizes into record-keeping for AI systems:

• Tamper-evident audit logs. Evaluation results, model-version fingerprints, incidents, and certification artifacts written as signed, committed records that anyone can later verify existed and were never altered. The operator can no longer edit the history.

• Consent and rights provenance. A registry proof establishes that a given item carries a valid consent or license entry. It does not, by itself, establish that the training pipeline used only such items; that second guarantee comes from the attested pipeline of mechanism 3, which admits data to the corpus only with a valid proof attached. Composed, the two support a claim we would phrase carefully: every item admitted to this training corpus carries a verifiable consent or rights entry, and the admitting pipeline is attested. That is weaker than "we cryptographically proved the weights" and far stronger than any privacy policy in production today.

3. Attestation: the process that provably ran

We have written before about why AI inference belongs in private compute: TEEs provide confidentiality plus hardware-signed proof of which code processed the data, and Self already operates attested inference in production, with enclave measurements published to a transparency log and verified client-side. For observability, attestation adds what logs alone cannot, always within the hardware trust model (you are trusting the silicon vendor's root, a point we return to below):

• The serving stack is the certified stack. The attested measurement covers more than the weights. It covers the serving configuration, including system prompts, sampling parameters, and the surrounding pipeline, because identical weights behind a different wrapper are a different system. A silent swap of any measured component shows up in the measurement.

• Codified policy is attested code. Retention, redaction, and sampling rules that can be expressed as code run inside the measured pipeline, so "the policy executed" is a verified statement about software. Policies that live in human processes, such as escalation review and manual overrides, remain procedural.

Where the trust goes, and what it costs

Cryptography does not remove trust; it relocates it. Instead of trusting the operator, you trust document issuers, silicon vendors' attestation roots, protocol soundness, and registry governance. Different adversaries are answered by different mechanisms: attestation and logs constrain a dishonest or compromised operator; identity proofs constrain fraudulent users and sybil farms; confidential computing constrains the curious cloud provider; none of them constrain a malicious document issuer or a broken hardware root. The question becomes where trust resides and how it is diversified, not whether it exists. That is still a categorical improvement,.

The engineering costs are real but increasingly ordinary: attestation overhead on current-generation confidential GPUs is near zero, anonymous-credential verification is milliseconds, and the true costs are operational, in key management, reproducible builds, and log infrastructure. Verifiability is a property you budget for, like availability. It is no longer exotic.

None of the ingredients is novel on its own: confidential computing, transparency logs, and signed supply chains all exist. What does not exist is their composition with population-scale anonymous credentials into a single stack aimed at AI governance, where the claims that matter span users, data, and process at once. And two boundaries remain beyond the current state of the art: cryptographic proof-of-training is not yet practical, and no cryptography proves a model's values or knowledge are as intended. The latter is the province of rigorous, independent evaluation, which has its own verified-human problem upstream, as we covered previously: verified humans produce the ground truth, verifiable records carry the results, attestation ties them to the deployed system.

Why now

Three things changed. Confidential computing reached commodity AI hardware, making attested inference a deployment choice rather than a research project. Anonymous credentials reached population scale through government-issued documents, making verified access compatible with privacy for the first time. And regulators are shifting from policy documents to evidence: audit regimes that assume records mean something, aimed at exactly the gap between procedural trust and proof.

The deployments that win the next decade will be able to prove what they claim about their users, their data, and themselves. That is the stack Self is building: proofs about humans and agents at the front door, verifiable registries underneath, attested compute around the process.