# How the Husky audit trail works **Audience:** custodian of records / counsel preparing a deposition. **Requirement:** REQ-107 **Related:** ADR-0003, REQ-100–REQ-106 ## Purpose Husky records what a broker knew and decided when they selected a carrier or issued a Subpart O document. The goal is business-records evidence: contemporaneous capture, regular practice, a documented process, and retention of original source artifacts. Cryptographic hash chaining is defensive depth. It is not what makes the record admissible. Retaining the original PDF and applying a consistent process is. ## What gets recorded Every material action writes an `audit_event` row: - Subpart O document created, versioned, terminated, or exported - Agreement sent for signature and completed - Nightly timestamp anchoring of the day’s event hashes Each event captures: - Organisation and actor (when known) - Event type - Server-clock timestamp (`occurred_at`) - Structured payload (criteria, document ids, versions) - SHA-256 of any source artifact retained with the event ## Immutability `audit_event` and `artifact` tables revoke UPDATE and DELETE from the application role. Database triggers raise on either operation. Correcting a mistake means appending a new event, never editing an old one. Source document bytes are stored once under a key that includes their SHA-256 and are never overwritten (REQ-101). ## Hash chain Within an organisation, each audit row stores `prev_hash` (the prior row’s `row_hash`, or a genesis value for the first row) and its own `row_hash` (SHA-256 over a canonical encoding of the row contents plus `prev_hash`). Verification recomputes the chain in order and fails if any row was altered (REQ-103). Postgres enforces `UNIQUE (org_id, prev_hash)` so two concurrent appends cannot both claim the same parent; the loser re-reads the tail and retries. ## Timestamp anchoring Nightly, Husky computes a Merkle root over that day’s `row_hash` values for the organisation and submits it to a free RFC 3161 timestamp authority (FreeTSA). The returned token is stored (REQ-104). Until live DER validation is enabled (`FREETSA_LIVE=true` and OpenSSL validation wired), development uses an explicit `dev-attestation` token labelled as such. ## Public verification Anyone with an organisation id can call the public verify endpoint. The response reports whether the chain is intact, whether an anchor is present, and whether the stored timestamp token validates against the Merkle root. It does not expose carrier names, document bodies, or other PII (REQ-105). ## Counsel export Brokers can download a timestamped PDF summarising the Subpart O / selection audit slice for a carrier, including verification status (REQ-106). Phase 1 labels this honestly as an STF audit slice; the full qualification entity arrives in Phase 2. ## Regular practice This process is the ordinary course of Husky’s operation for design partners and customers. Events are written at the time of the action by server code, not backfilled by operators.