Announcement · 11 November 2026
The record now names who.
Identity, attested and sealed — every verdict can carry the enrolled subject who proposed it.
The gate has always sealed what was proposed and what the gate decided. It now seals who stood behind the proposal. Under a customer’s engagement letter, people and agents are enrolled as named subjects — every agent bound to a responsible human — and a verdict can carry that subject’s identity inside the signed record itself: not a label beside the record, but part of what the signature covers. Enrollment and revocation are chain records, like everything else here. This layer ships as one worker with the front gate, which has been restored and merged back into the gate’s single codebase — the door and the name now arrive together.
What shipped
The name, in four parts
Enrollment, assertions, attribution in the payload, and revocation that bites at the next verdict. The customer is the identity authority for its own people; Verity is the witness, not the guarantor.
POST /api/v1/identity/enroll — a customer enrolls its own subjects, human operators and agents, under its letter. Each enrollment is sealed as an ATTEST record carrying a commitment hash of the enrollment statement. The roster itself stays key-gated; the chain proves the binding existed, and when.
POST /api/v1/identity/assert — an enrolled subject acts under a short-lived signed assertion, ten minutes and single-use, issued under a dedicated assertion key that is separate from the chain key and published openly for anyone to verify against. The gate checks the assertion’s signature, expiry, replay status, and the subject’s standing before any verdict seals.
Chain records now seal in a second format that binds what the first format displayed but did not sign: the caller, the rules that fired, and — for attested callers — the subject, their enrollment, and the epoch anchor the record was written under. A record without an assertion seals that absence explicitly. It cannot be upgraded later to look attested.
POST /api/v1/identity/revoke — revoking a subject is one sealed act, effective at the next verdict. An assertion already issued stops working the moment the revocation seals, not when it expires.
The boundary, in full
What we guarantee
Enrollments, revocations, and verdicts are sealed in the chain at the time they happen, signed, and anchored to a third-party timestamp. What the chain says was enrolled, revoked, allowed, escalated, or vetoed — and when — is replayable and verifiable by anyone holding the public keys.
For an attested verdict, the subject who proposed, the enrollment they acted under, and the fact that the enrollment stood unrevoked at verdict time are inside the signed payload — not metadata that can be edited without breaking the seal.
A revoked subject is refused at the door from the moment the revocation seals, assertions notwithstanding.
Where a device checks a face or a finger, it does so on the device. Verity holds pseudonymous subject IDs, public keys, and hashes — nothing worth stealing, and no dossier to leak.
Signature, expiry, single-use, and subject status are verified before a verdict is written. A failed check is a refusal, answered and unsealed — never a record dressed up as attested.
The other half of the boundary
What we don’t guarantee
The customer attests its own people; Verity is the witness, not the guarantor. A customer who enrolls a fiction owns the fiction — and the chain will faithfully prove they enrolled it.
We are not an identity-proofing service and not a public identity provider. There is no “Login with Verity,” no consumer accounts, no self-enrollment. If a client needs its people proofed, the client proofs them; we seal the result.
Possession can be lent; enrollment cannot detect it. The remedy is revocation — instant, sealed, and attributable — not a promise we can’t keep.
The gate rules on proposals and keeps the record. An ALLOW is a statement about scope and rules, not a blessing, and the sealed record exists precisely so that question can be argued later with evidence.
Verify it yourself
Don’t take the announcement’s word for it
An enrollment binds a subject to what a customer declared; it does not certify the declaration was true — the guarantee lists above state the scope in full.
GET /api/v1/identity/pubkey serves the assertion verification key openly, beside the chain key at /api/v1/chain/pubkey. Any assertion can be checked against it without trusting us.
Records 270–274 of the production chain: two enrollments (ATTEST), the first attributed verdict — an ALLOW whose signed payload names its subject and the enrollment it acted under — an anchor (ANCHOR), and a subject revocation (REVOKE). Read them back under a caller key at GET /api/v1/chain, metadata only.
GET /api/v1/chain/verify under an admin key replays both record formats across the boundary and verifies every signature — old records under the format they were sealed in, new records under theirs. On the current chain, signatures checked equal records checked.
Take care of your people. Don’t build for everyone.