Hash-linked audit
Evidence model
Every material transition produces a signed, hash-linked event. The evidence chain records what happened, in what order, and under which authority.
Audit chain
Each AuditEvent carries event id, timestamp, node id, operation id, session id, key id, phase, status code, reason code, artifact references, a previous event hash, and a node signature. The previous event hash creates a tamper-evident chain: any insert, delete, or reorder breaks the hash linkage. Observability builds on this structure — metrics, backpressure, SIEM delivery, and presign-pool monitoring are driven by the structured event stream.
When a backend site fails mid-operation, the architecture commits Failed(evidence_cid) as an immutable terminal record before proceeding with abort or recovery. The failure is part of the audit chain. Post-incident review starts from the committed artifact.
Reason codes
Stable reason codes keep API status, detection point, runtime response, retry behavior, and operator notification aligned. A policy denial, a reused step permit, a remote timeout, a stale epoch, a conflicting slot, and a publication denial are recognizable across logs, receipts, SDK errors, and support tooling. Support can route an issue to the right boundary without interpreting raw state.
Evidence packages
The evidence package is the portable form of the audit story. It bundles policy binding, replay evidence, equivocation evidence, publication receipts, recovery material, redaction rules, a trace digest, and a package signature. Customer deployments use it to verify sensitive operations while raw secret material stays local.
Recovery is evidenced too
Recovery is a deterministic, evidenced transition. Terminal states are final; only non-terminal states — PendingApproval, PendingRemote, Rotating, Degraded, Recovered — allow idempotent replay. Recovery resumes from the last confirmed transition for an operation_id / session_id pair: recover_step(k, d) returns the committed effect when the key is fixed and the input digest matches, re-executes when the key is still pending, and yields a PoisonedSessionWitness when the key is fixed but the digest conflicts.
Any divergence between the external-runtime journal, the secret-kernel journal, and the local descriptors closes the session to Poisoned with conflict evidence. A conflict becomes a provable artifact; no heuristic merge is attempted.
SIEM export and EvidenceBundle assembly
The AuditEvent stream is the authoritative source for observability: metrics, alerts, and health signals are derived from structured events. Exportable signals divide by owner — the audit plane owns completeness, integrity, and delivery of evidence; the proposals-and-controls plane owns monitoring of compliance controls; the operational-risk plane handles latency, saturation, presign-pool exhaustion, backpressure, and safe-mode activation.
An EvidenceBundle assembles the portable form of an operation's audit story: policy binding (PolicyReceipt and AdmissionDecision hash), replay evidence (anti-replay marker and conflicting step descriptor if present), equivocation evidence (both message versions and sender if triggered), publication receipts (PublicationReceipt and ExternalExportGate binding), recovery material (PoisonedSessionWitness if the session closed to Poisoned), redaction rules, a trace root digest, and a bundle signature from the issuing node. A verifier with the public key, the policy root, and the bundle can check every material claim without access to the raw journal or secret state.
OTLP stream and critical alert metrics
The audit event stream is exported as an OTLP stream that connects directly to SIEM and SOC pipelines. Every signing attempt, policy denial, KMS authentication event, and protocol abort appears as a structured event with stable field names, so operators read fields directly.
Critical alert metrics are: signing failures (any operation that closes to Failed or Aborted), 5xx errors at the client API boundary, key unwrap failures (a node that cannot decrypt its DEK cannot participate — in cloud setups this surfaces as a KMS authentication failure; in on-prem setups as a Vault or HSM authorization rejection; either way it signals a credential or identity problem), local store or database connection errors, and permit reuse attempts (STEP_PERMIT_REUSED signals a replay or crash-recovery anomaly). Each metric maps to a reason code and an owning plane, so an alert routes to the owning operator.