Announcement · 25 October 2026
The front gate is live.
One gate in front of the model, one gate afterward — both running.
The gate API now verifies intention at the door, before it judges output. A caller seals a signed attestation of standing intent — purpose and declared domains — into the chain at intake; a caller minted for the door gets no verdict without one. Every proposal is then checked against that signature, the caller’s sealed trajectory is tallied for drift and probing, and a revoked attestation refuses everything downstream. Specified in the morning, shipped the same day — the first attestation, intention escalation, and revocation are records 3 through 6 of the production chain.
What shipped
The door, in three parts
The checks are Tools 03 and 04, stated on the tools page and drawn on the architecture page. What shipped is the machinery that runs them.
POST /api/v1/attest seals the caller’s signed statement of intent — purpose plus declared domains — as a chain record, before entry. No attestation, no verdicts for a door-minted caller: the refusal is attestation_required, and it is answered, not negotiated.
Each proposal is checked against the domains the caller signed for — a mismatch escalates. The sealed history is tallied at the same moment: enough out-of-domain records in the trailing window, or enough escalations and vetoes in the trailing hour, escalates the current proposal too. Single asks are never judged in isolation, because assembly is the hazard, not vocabulary.
POST /api/v1/attest/revoke is an operator act, sealed as a REVOKE record. From that moment the caller is refused everywhere — verdicts and re-attestation alike. Restoration is an operator decision, never the caller’s.
Verify it yourself
Don’t take the announcement’s word for it
An attestation binds a caller to what it declared; it does not certify the declaration was honest — the trajectory check exists precisely because a signature is not a character reference. The architecture page states the scope in full.
POST https://api.verityverdict.com/api/v1/attest — under a caller key. Unauthenticated calls are refused; the endpoint’s existence and its refusal are both checkable from any terminal.
Records 3–6 of the production chain: an attestation, an in-domain ALLOW, an out-of-domain ESCALATE under D3, and a revocation. The chain then verified end to end — 8 records, 8 signatures.
GET /api/v1/chain under a caller key reads the ledger back, metadata only. ATTEST and REVOKE now appear in its counts beside ALLOW, ESCALATE, and VETO.