Ledger

The tamper-evident record of everything that happened.

An append-only, hash-chained log. Each record carries the SHA-256 of its predecessor, so editing, reordering or deleting a record breaks verification from that point on.

Field	Meaning
seq, ts_ms	Position and time
run_id, step, actor, tool	What it concerns and who did it
payload_hash	SHA-256 of the canonical JSON of the arguments or result. The payload is never stored
reason	Why. Required and non-empty
event	run_started, intended, approved, blocked, would_block, succeeded, failed, uncertain, compensating, compensated, compensation_failed, unrecoverable, deferred
detail	Short free text: the violation, the approval trigger, who resolved a step
prev_hash, hash	The chain

Write-ahead: intended is journaled before the tool runs. If journaling fails, the call does not run. A dangling intended after a crash is exactly the list of effects to reconcile.

Credentials never reach it

reason, detail and error text are redacted for well-known credential shapes before they are written. Arguments and results are only hashed.

Verify

reversi verify ledger.jsonl                  # a file
reversi verify -d ./reversi-data --store sqlite   # whatever the store holds
python -m reversi_sdk verify ledger.jsonl    # Python standard library only

Or open viewer/index.html. For signed exports see evidence.

Stores

JSON Lines file, SQLite or PostgreSQL (storage). SQLite and PostgreSQL reject UPDATE and DELETE on the ledger table, and several processes can share one database: the seq primary key makes forking the chain impossible, and a writer that loses a race re-reads the tail and retries.

What it does not prove

A hash chain detects edits, deletions and reordering. It does not detect truncation of the tail, or a whole-file rewrite by someone who controls the file. Anchor the head somewhere they cannot reach (evidence).