Audit Trail

Hash Chain Integrity

Every audit log entry includes a SHA-256 hash that chains to the previous entry. This creates a tamper-evident sequence — if any entry is modified, inserted, or deleted, the hash chain breaks and the tampering is detectable.

Immutability is enforced at the application layer: SealDoc never issues UPDATE or DELETE statements on audit entries. The underlying Forge SQL database is managed by Atlassian. The hash chain and HMAC sealing provide detection (not prevention) of any tampering that might occur at the infrastructure level.

The hash is computed from a deterministic encoding of the entry fields, ensuring that the same data always produces the same hash.

Per-Entry Fields

Each audit log entry records:

Field	Description
Entry ID	Unique identifier for this audit entry.
Document	The Jira issue key or Confluence page ID that this entry relates to.
Action	The action performed: sign, approve, reject, submit_review, set_safety_class, settings_change, erasure, revert_on_edit.
User	The Jira account ID and display name of the user who performed the action.
Timestamp	UTC timestamp of when the action occurred.
Details	Action-specific metadata (signature meaning, rejection reason, old/new safety class, etc.).
Safety Class	The safety classification level at the time of this action (if applicable). Content hashes are stored on signature records, not audit entries.
Previous Hash	Hash of the previous audit entry in the chain, creating the tamper-evident sequence.
Entry Hash	SHA-256 hash of this entry's fields, used as the "previous hash" for the next entry.

Chain Sealing (HMAC)

In addition to the per-entry hash chain, SealDoc periodically seals the entire chain with an HMAC-SHA256 checkpoint. Sealing happens:

• After every write — each new audit entry triggers a seal update.
• Hourly — a scheduled Forge trigger creates a periodic seal checkpoint.

The HMAC key is managed by the app and stored in Forge storage. Chain sealing provides a second layer of tamper detection — even if an attacker could recompute the hash chain, they would need the HMAC key to forge a valid seal.

Export

The audit trail can be exported for external review:

• CSV — tabular export of all audit entries with all fields, suitable for spreadsheet analysis.
• PDF — formatted audit report with table layout, generated in your browser from the CSV data. Suitable for regulatory submissions.

Exports include the full hash chain data so that integrity can be independently verified.

Retention Policy

Audit log retention is configurable in Admin Settings. The retention period determines how long audit entries are preserved before they can be pruned. By default, all entries are retained indefinitely.

Entries within the retention period cannot be deleted — the audit trail is append-only by design. Once the retention period expires, entries may be soft-deleted (removed from active queries but preserved in the hash chain).

Chain Validation

SealDoc provides a built-in chain validation tool accessible from the project page. Validation checks:

• Hash continuity — each entry's previous_hash matches the preceding entry's entry_hash.
• Gap detection — no entries are missing from the sequence.
• HMAC verification — the chain seal matches the expected HMAC value.
• Entry integrity — each entry's hash matches its recomputed value from stored fields.

If any check fails, SealDoc reports the specific entry where the chain integrity was broken.