Skip to content

Seal

Audit trail

Tier: Record · Requirement module: Audit (BR-079) · Status: ⬜ Not started

Purpose

The requirement asks for a legally defensible audit trail for every submission, review, rejection, approval, directive, extension, and enforcement action. Seal provides it as a hash-chained, append-only log written in the same transaction as the state change it describes.

The distinction that matters: most systems produce a log, which is a record you are asked to trust. Seal produces evidence, which can demonstrate its own integrity.

Scope

Capability Status Notes
Append-only entries ⬜ No update or delete path exists
Hash chaining ⬜ Each entry contains its predecessor's hash
Transactional write ⬜ Same transaction as the state change, via the outbox pattern
Actor and reason capture ⬜ Who, when, what, why, and the prior state
Chain verification ⬜ On demand and on a schedule; a break is an incident
Trail rendering ✅ Version history and audit views on a return
Export pack ⬜ Sealed export with a hash manifest for legal use

Entry shape

{
  "sequence": 4812993,
  "tenantId": "seczim",
  "occurredAt": "2026-08-12T08:14:22.184Z",
  "actor": { "type": "USER", "id": "user:m.okonjo", "role": "SENIOR_SUPERVISOR" },
  "action": "RETURN_REJECTED",
  "subject": { "type": "SUBMISSION", "id": "OBL-873390-R02-2026Q2", "version": "1.0" },
  "reason": "Capital deficit reported without a board-approved restoration plan.",
  "citation": "Directive on Capital Adequacy for Securities Market Intermediaries",
  "priorStateHash": "sha256:a71f…",
  "newStateHash": "sha256:3d02…",
  "previousEntryHash": "sha256:8bc4…",
  "entryHash": "sha256:e559…"
}

entryHash covers the whole entry including previousEntryHash. Removing or altering any entry breaks every hash after it, which is detectable by walking the chain.

Why chained rather than merely append-only

An append-only table protects against accidental modification. It does not protect against a privileged actor with database access, which is exactly the scenario a firm's counsel will raise when contesting a rejection.

Chaining changes the question from do you trust the operator to can you produce a chain that verifies. Combined with periodic publication of the chain head — internally at minimum, and plausibly to a notary or a witness system — it makes retrospective alteration demonstrable rather than deniable.

Stated honestly: chaining alone does not prevent a sufficiently privileged actor from rewriting the entire chain from the point of alteration forward. That is why the chain head is published periodically. The published head is the anchor; without it the chain proves only internal consistency.

What gets sealed

Every state change in every engine. Non-exhaustively:

Engine Sealed actions
Registry Licence granted, varied, suspended, surrendered; officer appointed or removed
Return Studio Template version published; threshold changed; calendar amended
Cadence Obligation materialised; due date shifted; extension requested or granted
Strata Draft certified; submission filed; amendment filed; current pointer moved
Assay Validation run and its verdict set; re-validation against another version
Bench Assigned; checklist item cleared; query raised, answered, closed; outcome recorded
Prism Score computed; rating overridden
Docket Case opened, staged, evidenced, decided, closed; directive issued

Reads are not sealed by default. Access logging for sensitive reads — a supervisor opening a firm's file — is a separate concern and likely a requirement, but it is volume-dominant and does not belong in the evidential chain.

Owns

  • The audit chain and its entries
  • Chain verification and the published head
  • Export packs and their manifests

Does not own

  • Anything else. Seal never holds the only copy of a business fact; it holds the record that a fact changed, and the hashes that prove the record is intact.

Open questions

  • Head publication. Internal periodic publication is the minimum. Whether the head is witnessed externally is a governance decision with cost implications, and it is the difference between strong and very strong evidence.
  • Retention and volume. The chain never shrinks. Partitioning by tenant and period is straightforward; the constraint is that pruning is not available, so storage growth is linear and permanent by design.
  • Read access logging. Needed, but separate. Mixing high-volume read logs into the evidential chain would degrade both.