Audit Chain

Audit chain principles

The audit chain is governed by five principles (audit_and_evidence_model.md §2):

AE-001: Evidence over logging.
AE-002: Append-only with tamper evidence.
AE-003: Causality preservation.
AE-004: No silent state.
AE-005: Evidence must be defensible.

Cryptographic chaining

Each event includes event_hash and previous_hash. previous_hash must equal the immediately preceding event's event_hash in sequence order (per persistence_and_storage_spec.md §4.3 and §4.4).

Hash algorithm is SHA-256 encoded as lowercase hex strings (per persistence_and_storage_spec.md §4.4).

Event-hash construction includes: event_type + session_id + turn_id + recorded_at + previous_hash + payload (per persistence_and_storage_spec.md §4.3).

Chain structure example:

Event 1 - genesis
  event_id:       evt_001
  event_type:     system.initialized
  previous_hash:  0000000000000000000000000000000000000000000000000000000000000000
  event_hash:     a3f2bc91...

Event 2
  event_id:       evt_002
  event_type:     session.created
  previous_hash:  a3f2bc91...   <- must equal Event 1 event_hash
  event_hash:     9bc1f3a2...

Event 3
  event_id:       evt_003
  event_type:     policy.version_activated
  previous_hash:  9bc1f3a2...   <- must equal Event 2 event_hash
  event_hash:     c4d8e2f1...

Core event structure

Minimum event fields include (audit_and_evidence_model.md §4):

event_id
session_id
turn_id
timestamp (RFC3339 UTC)
event_type
actor
policy_version
canonicalization_version
trust_state
previous_event_hash
event_hash

Genesis event

The genesis event is the first chain element with fixed previous_hash of 64 zeros (persistence_and_storage_spec.md §4.5):

0000000000000000000000000000000000000000000000000000000000000000

Session creation is only valid after durable session.created persistence (session_and_turn_model.md §4.1).

HMAC signing and verification

The chain uses hash-linking with HMAC-based tamper evidence in verification workflows. syndicate audit verify validates chain continuity and signature integrity before returning success.

# Verify chain integrity
syndicate audit verify

# Verbose verification details
syndicate audit verify --verbose

# Machine-readable verification output
syndicate audit verify --output json

Expected success shape:

audit chain: OK
  events:  47
  genesis: a3f2bc91... (previous_hash: 0000...0000)
  head:    c4d8e2f1...

Exit code 0 means clean chain; non-zero means integrity failure (per CLI-007, cli_command_reference.md §8.4).

Export

# Export all events as NDJSON
syndicate audit export <session-id> --format ndjson --out audit-export.ndjson

# Export as JSON array
syndicate audit export <session-id> --format json

Exports include hash-link fields for independent external verification.

v1 deployment note This page describes v1 local-embedded behavior. Team and enterprise deployments use syndicate-server and can differ in storage and key-management topology, while append-only chain integrity and verification invariants remain the same.

Non-guarantee callout Syndicate Code does not guarantee absence of hallucinations or correctness of model output. It does guarantee that decisions and executions are recorded as append-only evidence (per G4).