Recipe, not skill. Cairntir’s core is three skills (crucible, quality, reason). Decision Replay chains them onto Cairntir’s own memory: load a past decision, walk its supersedes chain, run the reason loop against today’s evidence, write a new prediction-bound drawer that extends the chain. The longitudinal record of the decision keeps growing instead of being lost.
This is the recipe that demonstrates the v1.1 synergy stack — recipe runtime + temporal walk + production reason loop — working together.
You committed a prediction-bound drawer in the past (via Signal Reader, the
reason skill, or the cairntir reason CLI), the prediction window has
elapsed, and you want to ask: did that read still hold? What changed?
Should the belief mass move?
Trigger phrases:
Trigger contexts:
signals wing predictions.decision_drawer_id (required, integer) — the drawer id of the
decision you want to replay. The recipe walks the supersedes chain from
this id (using cairntir.memory.temporal.walk_supersedes), pulls the
leaf’s claim and predicted_outcome, and chains the new prediction
onto the leaf.current_evidence (required, string) — what you’ve observed since
the original prediction. One-to-three paragraphs. This is the ground
truth the original prediction is being tested against.horizon_months (optional, integer) — re-prediction horizon in
months. Defaults to the original window. Set explicitly to revisit on a
different cadence.The CLI looks up the drawer by id and walks its supersedes chain end to end. Output: a list of drawers, root → leaf, representing the full history of the original claim — first prediction, every revision, the current observation if any.
The leaf of that chain is the load-bearing input for the reason step. Its
claim and predicted_outcome become the proposer’s seed; the new
prediction the reason loop writes will carry supersedes_id pointing at
this leaf, extending the chain instead of starting a new one.
The reason loop runs one full predict → observe → update cycle, scoped
to the same wing and room as the original chain. The proposer is
seeded with the original leaf’s claim and predicted outcome; you supply
the observed outcome (what current_evidence showed) and a verdict
(--success if the original prediction still holds, --fail if it
broke).
The loop writes two drawers:
supersedes_id = original_leaf_id.
This is what makes Decision Replay structural rather than cosmetic —
the chain now has another link, and a future replay can walk it.supersedes_id = new_prediction_id,
carrying the observed outcome and any explicit surprise delta. Verdict and
surprise are independent: a prediction can hold through an unexpected path.Belief mass is reinforced (+1.0) on success, weakened (-1.0) on failure. The store clamps mass at zero, so a long string of failed replays drives the original drawer’s mass toward zero — but never deletes it.
Before the replay verdict commits, the recipe drops a Crucible marker drawer in the chain. The four stress-test questions apply unchanged:
Run those questions over your verdict before accepting the replay. If the Crucible reveals a fatal weakness, abort the replay and revise.
The Crucible drawer’s supersedes_id points at the seed drawer (per
the recipe runner’s standard wiring), so the replay’s full execution
arc is reconstructable via walk_supersedes from any node in the chain.
The recipe is invoked through the dedicated cairntir replay CLI command
(which auto-fills the leaf’s claim + predicted from the chain) or through
the generic cairntir recipe-run decision-replay.
cairntir replaycairntir replay 95 --evidence "fastembed default has held for four days,
no cold-start regressions, no manual config required for any new install."
The CLI:
--delta when
the route differed, including when the verdict still held.supersedes_id set to the leaf id.cairntir recipe-run decision-replaycairntir recipe-run decision-replay \
--input decision_drawer_id=95 \
--input current_evidence="fastembed default has held for four days..."
This path skips the auto-fill — provide --claim, --predicted, --observed,
and --success, or answer their interactive prompts. --delta is optional.
Use this path when you want to change the claim mid-replay, e.g. you realize
the original prediction was poorly formed and the replay is also a
re-statement.
For a single Decision Replay invocation against drawer N (chain leaf L):
replays, room =
decision-replay, kind = seed. No supersedes pointer.supersedes_id = L. Wing/room match the
recipe (replays/decision-replay). Carries the original claim +
predicted outcome.supersedes_id = new_prediction_id.
Carries the observed outcome and any explicit surprise delta.supersedes_id = seed_id. Embeds the
Crucible prompt for the calling LLM to run against.The original chain (rooted at whatever drawer N belongs to, leaf L) now
has the new prediction → observation pair grafted on at the leaf via
the supersedes pointer. walk_supersedes(N) after a replay returns one
chain that spans from the original root all the way through the latest
replay observation.
A drawer that has been replayed three times has six new entries in its chain (three prediction-observation pairs). Each replay’s belief mass adjustment compounds with the prior ones. After 6-12 months of monthly replays, the chain becomes a calibration record — a longitudinal dataset of “this is what we predicted, this is what happened, this is how the belief evolved.”
Pair this with the Signal Reader recipe and you get a closed loop: Signal Reader emits the original prediction; Decision Replay closes each prediction’s window and writes the verdict. The signals wing becomes a track record, not a notebook.
claim or predicted_outcome.
The CLI will refuse, but if you bypass it the reason step will work
with empty strings and the belief math will be meaningless. Replay only
prediction-bound drawers — drawers that committed to something
falsifiable in the first place.horizon_months field on the original drawer is the cue.| Component | Role in Decision Replay |
|---|---|
| Reason | The replay verdict is exactly one reason-loop step with supersedes_id set. Drives the predict→observe→update cycle. |
| Crucible | Marker drawer drops the four stress-test questions into the chain so the calling LLM can run them on the verdict before the user accepts the replay. |
| temporal.walk_supersedes | Loads the chain from the original drawer id. Pure query, no mutation. |
| Signal Reader | The most common upstream — Signal Reader writes the original prediction-bound drawer, Decision Replay closes its window. |
No 4th skill needed. Decision Replay is orchestration of the three existing skills plus the temporal walk, applied to the domain of “closing the prediction window on a past decision.”