Audit Trail

Directive signing

Every browser directive is signed before it leaves the operator session. The Ed25519 signature covers message kind, Theatre scope, payload hash, and a monotonic directiveSeq - a sequence number that makes both tamper and replay attacks detectable independently of wall-clock time.

The signing architecture targets migration to NIST post-quantum cryptography standards - ML-DSA for signing and ML-KEM for key encapsulation. Ed25519 is the compatibility baseline, not the end state.

• Tamper detection: signature covers the full payload hash - any field mutation breaks the signature
• Replay detection: monotonic directiveSeq makes replayed directives detectable without relying on timestamps
• Attribution: the signing key is bound to the operator session - every record has a responsible principal

Hash-chained intent ledger

Accepted, operator-signed directives are written to a hash-chained intent ledger. Planning suggestions do not write to the ledger - only directives that have been accepted and signed create durable records. This distinction is enforced at the type system, the runtime gate, and the IRONLAW ingest channel simultaneously.

• Crash-safe by construction:the audit sidecar is fsync'd before the primary line commits - no partial writes
• Encrypted at rest: AES-256 with keys managed in your infrastructure
• Governance posture on record: the active IRONLAW policy hash is recorded in every ledger entry so the governance posture at decision time is provable, not reconstructed
• Merkle checkpoints: intermediate checkpoints make range verification fast without reading the full chain

Offline chain verification

The intent ledger is offline-verifiable. A CLI tool verifies the full chain from file alone - no vendor connection, no live system required. This matters for legal holds and regulatory inquiries where you need to prove chain integrity to a third party who cannot connect to your infrastructure.

Verification confirms: hash-chain continuity, signature validity on every directive, Merkle checkpoint consistency, and that the policy hash recorded in each entry matches a known policy artifact. Evidence runbooks and pack tooling are shared under engagement.

IRONLAW policy refusal records

Every refused operation returns a structured PolicyRefusal with a ruleId and correlationId before any execution-facing system is touched. Refusals are written to a queryable SQLite audit store with rolling metrics surfaced live in the browser dashboard.

This means the audit trail includes not just what ran, but what was refused and why - a complete picture of governed operations, not just successful ones.

WebAuthn step-up for high-consequence actions

Actions above a defined consequence threshold require a WebAuthn step-up challenge before execution. The challenge is connection-bound with a per-action nonce, 5-minute deferred TTL, and 4-hour assertion expiry. Every step-up event is appended to the per-action audit trail.

Consequence thresholds and the action classes they apply to are defined in your IRONLAW policy - not hardcoded. Your legal or compliance team can define what counts as high-consequence for your regulatory environment.

What this means in practice

• Regulatory inquiry: produce a complete, verifiable evidence chain for any time window - not a reconstructed narrative assembled under deadline pressure
• Legal hold: hand counsel an offline-verifiable file with cryptographic proof of chain integrity - no live system access required
• Attribution:every record traces back to a specific operator session, signing key, and IRONLAW policy version - "the system did it" is not an answer the ledger accepts
• Governance drift detection: policy hash in every entry means you can identify exactly when governance posture changed and what actions ran under each version