Audit Log Service  ·  View 16 of 40  ·  4 · Data

Segment, Chain and Certificate

The entities that make a range provable, including the one that lets a disposed range still verify.

Editable source SVG draw.io All views
segment segment_id PK tenant_id FK event_class · date_partition blob_uri (immutable container) object_digest SHA-256 merkle_root prev_root (predecessor) record_count dek_id (HSM-wrapped) retention_until sealed_at chain_head head_id PK tenant_id FK sequence segment_id FK prev_head_hash head_hash checkpoint checkpoint_id PK checkpoint_root (all tenant heads) tenant_head_count hsm_key_version signature tsa_token RFC 3161 ledger_txn_id signed_at tombstone tombstone_id PK segment_id FK merkle_root (retained) certificate_id FK method crypto-shred disposed_at inclusion_proof proof_id PK event_id FK segment_id FK leaf_index audit_path checkpoint_id FK evidence_bundle bundle_id PK query_hash record_count manifest_digest signature watermark (role, caller) disposal_certificate certificate_id PK retention_class_id FK range_from · range_to record_count policy_ref signature event_id FK (written back in) 1 : 1 N : 1 1 : 0..1 1 : N N : M N : 1 N : 1 N : M Segment, Chain and Certificate — What Makes a Range Provable The tombstone is the reason a disposed range verifies as lawfully disposed rather than as tampering: the segment bytes go, the Merkle root and the certificate that authorised their going both stay in the chain. v 1.0 · owner Data & AI Global Practice · date 2026-09

Decisions

  • The tombstone is the load-bearing entity. It keeps the Merkle root and the certificate reference after the bytes are gone, so a disposed range verifies as lawfully disposed rather than as tampering.
  • The disposal certificate is written back into the log as an ordinary audit record with its own event_id. Deletion is a governed, evidenced act, and the evidence lives in the thing it deleted from.
  • An evidence bundle references checkpoints rather than containing the whole chain, which is what keeps a bundle for a thousand records measured in megabytes rather than gigabytes.

Model notes

  • object_digest binds the immutable blob's bytes to the merkle_root, so an altered object is detectable without recomputing every leaf.
  • prev_root in the segment header is what makes removal detectable: taking a segment out invalidates every hash after it.
  • Inclusion proofs are materialised on demand rather than stored — they are a function of the segment and the checkpoint, and storing them would be a third copy to keep consistent.

Omitted here

  • Proof of non-existence over a covered range is phase 3 and needs the absence filters shown on view 14; the model above supports it without change.