Verify and interpret the Evidence Gateway audit chain

Evidence Gateway writes a keyed, append-only audit chain. The chain is useful for proving which governed operation was admitted, what concept was released, and whether retained records were modified. It does not repeat source values or automatically provide a citizen-facing access history.

Verify retained history

Run the integrity check with the deployment stopped when you need to prove both sealed history and the active segment:

evidence verify-audit --runtime /etc/registry-evidence/runtime.yaml

A successful stopped-deployment check reports only bounded metadata:

segments: 3
records: 1842
sealed-sequence: 1-2
head: <chain-head>
active-segment: verified

The runtime file supplies the audit directory and hash-key reference. The command accepts neither on the command line, which prevents an operator from accidentally verifying a different chain or key than the deployment uses.

If Evidence Gateway is still running, the writer keeps the active segment locked. Verification proves the sealed history and reports:

active-segment: not verified: a running writer holds it, so only sealed history was proven

Run this check before and after backup, restore, or audit transfer. A missing sealed segment and a broken keyed chain both fail, but only retained and discoverable history can be checked. This is not proof that an operator never deleted history before the check or that an off-host receiver accepted it.

Interpret one operation

For an admitted request, the native chain uses closed phases:

Phase	What it establishes	What it does not establish
access-attempt with authorized	Authentication and the complete authority path were accepted before source credentials or source data were touched.	The source returned a record or the assertion was released.
disclosure-release with released	The named concepts were serialized and durably recorded before the exact response bytes were released.	The source fact was true or the caller used the answer correctly.
denial with not-authorized	An authenticated authorization refusal was durably recorded before its generic 403 response.	The rejected requirement, purpose, subjects, unmatched authority, selector information, or response format.
denial or transient-failure after authorization	An admitted operation later failed in one closed, value-free class.	The protected selector, source value, or credential that triggered it.

Authentication, malformed-request, and invalid-selector failures happen before Evidence Gateway has enough privacy-safe context and do not fabricate a native event. Do not expect every HTTP request to produce two audit records.

Authorized-material native records can carry the governed requirement, purpose, bundle revision, requester pseudonym, subject role and selector-profile pseudonym, source and adapter identifiers, response protection, decision, safe failure class, disclosed concept IDs, evidence ID, and signing key ID. A standalone authorization-refusal record instead carries a requester pseudonym and closed denial reason without the rejected requirement, purpose, subjects, unmatched authority, selector information, or response format. Native records never carry the disclosed value, raw selector, source response, access token, or credential.

Inspect the last local tutorial operation

The local tutorials expose one intentionally small view after the services stop:

evidencectl audit show --last-operation

ACCESS AUTHORIZED age-bracket service-path-selection requester=<pseudonym>
DISCLOSURE RELEASED age_bracket

A standalone authorization refusal produces a one-event view:

ACCESS REFUSED requester=<pseudonym> reason=not_authorized

This command verifies the whole retained local chain, then renders the operation that owns the physically last verified chain record. Concurrent requests can complete in a different order from their admission order, so “last” does not mean the most recently admitted request. The command is not a production audit browser and has no --all, subject filter, or export mode. An access-only operation prints only the authorized line rather than claiming a release that did not occur.

Understand pseudonymous correlation

Requester and subject handles are deterministic keyed pseudonyms. They are protected correlators, not anonymous values and not encrypted copies of identifiers.

The subject handle binds the complete selector tuple together with the trust domain, purpose, audience, role, selector profile, and key version. The same tuple in the same scope can be correlated by protected tooling. A different purpose, audience, or key version produces a different handle. A composite selector cannot be reproduced from one field such as person_id alone.

Registry Stack V1 does not expose supported tooling to answer:

Show every access for person_id=person-123.

There is no subject-history query, citizen portal, pseudonym derivation command, requester-name resolver, or cross-system history assembly. Do not work around this by exposing the audit hash key or raw JSONL records. The native chain contains the privacy-preserving correlation primitive that future protected tooling would need, but a citizen access request currently requires a separately governed operator process.

Protect the chain

• Allow one Evidence Gateway writer per audit path.
• Put the path on durable storage and monitor capacity before a fail-closed write stops release.
• Back up every sealed segment and the active segment as one history.
• Retain the matching audit hash key for as long as the history must remain verifiable.
• Restrict event access separately from ordinary service operations.
• Record retention, deletion, recovery, and requester-identity mapping responsibilities outside the Evidence Gateway bundle.

Rotate an audit master as a new epoch

An audit master rotation never appends a new key to an existing chain. Treat it as a new audit epoch, with a fresh path and a new hashKeyVersion:

1. Drain traffic and stop Evidence Gateway.
2. Verify the old chain and record its head and the applicable configuration revisions.
3. Archive the old runtime, master key, sealed segments, active segment, and recorded head together.
4. Generate a fresh master, increment hashKeyVersion, choose a new audit path, and run the full deployment check.
5. Start the new revision and verify its new chain independently.

The matching master remains necessary to verify an archived epoch. Do not replace a retained master in place, merge segments from distinct epochs, or delete a chain to make a replacement key work.

Continue with Retention and persistent state and Backup and restore for the surrounding operator procedures.