A read-back gate, symmetric to the write-side gates #190

New issue

Closed

opened 2026-08-16 15:41:11 +00:00 by john · 0 comments

john commented

2026-08-16 15:41:11 +00:00

Owner

The problem

Every gate in Cadence asks whether something was written down. None asks whether
the record changed what was about to happen.

The project's stated Core Value is that what gets written down "must come back on
its own at the moment it matters". Recall exists as a BM25 subcommand and is
injected into cad-context, cad-planner and cad-debug (v1.1.0-rc.1). What is
missing is any check that it landed. A planner can receive twelve prior decisions
and produce a plan that cites none of them, and nothing anywhere notices.

So the central claim of the product is the one claim with no evidence behind it.

The proposal

A read-back check, symmetric to the write-side gates:

At plan time, count the prior decisions, deviations and captures the recall
pass surfaced for this phase.
Count how many the produced plan actually cites (D-NN references, CAPTURE
ids, prior SUMMARY open items).
A plan citing zero of a non-empty set is REPORTED, not refused. It may be
correct; it is also exactly the shape of a planner that ignored the corpus.

Advisory first. It becomes a gate only once there is data on how often the zero
case is legitimate.

Why this one matters most

It is the only guarantee in Cadence that no competing tool could copy without
first building the corpus. Everything else here (gates, routing, atomic commits)
is reproducible by anyone who wants to write the prompts. The corpus is not.

How you would know it worked

The metric is the interesting part: how often does a plan change because of a
prior phase's record? Today that number is unknown. After this it is a number in
trace.jsonl. If it is near zero, the Core Value line in PROJECT.md is wrong and
should be rewritten rather than defended.

Depends on nothing. Would be strengthened by, but does not require, the archived
corpus work from REC-01/REC-02.

## The problem Every gate in Cadence asks whether something was written down. None asks whether the record changed what was about to happen. The project's stated Core Value is that what gets written down "must come back on its own at the moment it matters". Recall exists as a BM25 subcommand and is injected into `cad-context`, `cad-planner` and `cad-debug` (v1.1.0-rc.1). What is missing is any check that it landed. A planner can receive twelve prior decisions and produce a plan that cites none of them, and nothing anywhere notices. So the central claim of the product is the one claim with no evidence behind it. ## The proposal A read-back check, symmetric to the write-side gates: - At plan time, count the prior decisions, deviations and captures the recall pass surfaced for this phase. - Count how many the produced plan actually cites (`D-NN` references, CAPTURE ids, prior SUMMARY open items). - A plan citing zero of a non-empty set is REPORTED, not refused. It may be correct; it is also exactly the shape of a planner that ignored the corpus. Advisory first. It becomes a gate only once there is data on how often the zero case is legitimate. ## Why this one matters most It is the only guarantee in Cadence that no competing tool could copy without first building the corpus. Everything else here (gates, routing, atomic commits) is reproducible by anyone who wants to write the prompts. The corpus is not. ## How you would know it worked The metric is the interesting part: how often does a plan change because of a prior phase's record? Today that number is unknown. After this it is a number in `trace.jsonl`. If it is near zero, the Core Value line in PROJECT.md is wrong and should be rewritten rather than defended. ## Related Depends on nothing. Would be strengthened by, but does not require, the archived corpus work from REC-01/REC-02.