Checkpoint timeline

A checkpoint (also called a gate — the two terms name the same event) is a point where the agent pauses its work, reviews what just happened against the active taxonomy of failure modes, and decides whether to repair something or continue. Each card in the ledger is one checkpoint.

A checkpoint where no failure mode is supported by the evidence is recorded as clean (“none apply”). Clean checkpoints are expected and count separately in the summary above.

The host integration (Codex or Claude Code) installs checkpoints at configured boundaries: session start, user-prompt submission, mid-task progress boundaries, and final submission before the agent stops. Custom hooks can also bind a checkpoint to a specific event, tool, or recurring command.

A single turn or prompt may trigger several checkpoints; they stay separate records that share the same host turn ID. Checkpoints fail open — if one errors or times out, the agent continues normally and that checkpoint silently does not fire.

The agent runs a four-step reflection: Observe concrete activity (or a missing expected step), Correlate only evidence-supported causes, Map that evidence to taxonomy codes, and Decide whether to repair or continue. Open any entry to see the full structure in the detail drawer.

The reflection is recorded compactly and privately — nothing is printed into the conversation. Most checkpoints are advisory; the final submission checkpoint can block completion until its required response passes or the retry policy is exhausted.

Codes come from the active taxonomy shown in the chip at the top of the page. During the Map step the agent cites a code only when the recorded evidence supports it, and each assignment stores that evidence alongside the code. One checkpoint can carry several codes, or none.

The monitor is read-only: it displays the decisions exactly as they were recorded at the checkpoint and never re-judges them.

Each conversation starts from the taxonomy selected at session start — a stored project taxonomy, the built-in MAST adaptation, or none. One completed assistant episode records one trace; once enough traces accumulate (five eligible traces by default), generation proposes a project-specific taxonomy from them.

The chip at the top of the page names the exact taxonomy version this conversation's checkpoints used.

Refinement is a periodic review of the active taxonomy against the traces that accumulated since it was adopted: the first review runs after ten completed traces, later reviews every twenty (both configurable). The learning job runs in the background and the current taxonomy stays active while it works.

Proposed changes are checked against exact trace evidence, and every replacement code must pass a separate support review before the result activates between episodes. An accepted change receives a new immutable taxonomy ID linked to its predecessor by lineage; a valid “no change” verdict simply advances the review cadence without replacing anything.

Both modes show the same checkpoint records, transposed. Failure modes → checkpoints groups entries under every failure mode that fired, which highlights recurring problems. Checkpoints → failure modes lists each gate in order with the codes considered there, which follows the conversation chronologically.