Skip to content

The ledger is readable back as operational history, filtered by task, event and time

Majordomus has always appended events to state/ledger.jsonl. majordomus history is the command that reads them back: what happened, when, for which task, at which commit, what verification ran, and what outcome was accepted.

declared statusdeclared status: guaranteed Declared deterministic and blocking, implemented, and naming the behavioural test that is to prove it. Whether a recorded run supports it is the evidence verdict, shown beside it.

recorded evidencerecorded evidence: not run Declared guaranteed, and not supported by a recorded run: the test is named, and no passing run of the current inputs is recorded. how evidence is recorded

What happened, when, for which task, at which head, and what outcome was accepted. Never what anyone said.

What it means

Majordomus has always appended events to state/ledger.jsonl. majordomus history is the command that reads them back: what happened, when, for which task, at which commit, what verification ran, and what outcome was accepted.

It is operational reconstruction, not a conversation. Nothing in the ledger records what anyone said, because nothing writes that.

How it works

Filters are --task, --event, --since (a duration like 90m, 2h, 7d, or an ISO timestamp), and --limit (default 20, newest) or --all. Output is oldest line first, so a filtered run reads as a narrative rather than in reverse.

Each event renders a detail column suited to its kind: a started task shows its profile and scope, a finished task its outcome and the verify command's exit code, a checkpoint or handover its record's filename, a resolved question its answer.

--json emits the matching ledger lines verbatim — the same bytes, not a re-serialisation, so a consumer sees exactly what was written.

The reader skips a malformed line rather than crashing on it, so a corrupted ledger stays readable while it is being reported.

How to see it

majordomus history --task t-20260903193012-a4f1
# 2026-09-03T19:30:12Z  task.started       t-20260903193012-a4f1  3f2a9c1  profile=debugging scope=lib/auth
# 2026-09-03T19:45:00Z  task.checkpoint    t-20260903193012-a4f1  3f2a9c1  20260903T194500Z--main--3f2a9c1--8c1d0e4a.md
# 2026-09-03T19:52:31Z  decision.recorded  t-20260903193012-a4f1  3f2a9c1  Normalise the callback URI before comparing state
# 2026-09-03T20:14:08Z  task.finished      t-20260903193012-a4f1  b71e0c9  outcome=completed verify_exit=0

majordomus history --event task.finished --all --json | jq -r '.outcome'

What it does not cover

It reports what was recorded, not what happened. A worker that never checkpoints leaves a sparse history, and the ledger cannot know that.

It does not aggregate. There is no report of tasks per week or average duration, because nothing yet needs one and a statistic in a tool that cannot measure cost invites the reader to infer cost.

It is one repository's ledger. Nothing merges histories across repositories or worktrees.

Why it exists

The events were being written from the first version and read by nothing but a grep inside watch. A write-only log is a cost with no benefit: it accumulates, it is capped, and it answers no question anyone can ask of it. Either something reads it or it should not be written.

Detail rendered from docs/claims/history-ledger-read.md.

From the statement to the proof

  1. 1 · the public statement

    The ledger is readable back as operational history, filtered by task, event and time

    Made on Knowledge, Provenance, Watch.

  2. 2 · the canonical claim

    history-ledger-readdeclared status: guaranteed in docs/CLAIMS.yaml

    Defined in read it on this site · docs/CLI.md

  3. 3 · the implementation

    lib/history.sh · majordomus history

  4. 4 · the test and the scenarios

    Test: test/cases/22_history.sh

    Executed in Read back what happened, and keep the ledger within its cap, Record a decision so the next worker can find it, Record what one worker did in one sitting.

  5. 5 · the recorded runs

    recorded evidence: not run how evidence is recorded

Verify it yourself

The test runs in a disposable temporary repository and asserts the behaviour, not a string in the source.

from a clone of the repository
bash test/run.sh 22_history

Where this claim is used

Related claims same implementation

The moments this answers

Searches the titles and descriptions of every page this site publishes.