Case packet

Neutral case identifier: case-b5510a490b71bf

The possible directed relationship from Artifact A to Artifact B is under review.

Artifact A

A derived copy of recomputable truth must be checked or absent

Some artifacts carry a copy of information that is mechanically recomputable from a ground-truth source elsewhere in the system: a completeness [mark] (a frontmatter field caching a recomputable index property), a compiled cue (a memory system's derived retrieval hint), a hardcoded contract list inlined in a hot-path instruction, a duplicated file. Such a copy has exactly two valid states. Either it is checked — a validator re-derives it from the source and fails on mismatch — or it is absent: deleted, or replaced by reading the source live. There is no safe middle where the copy is maintained by hand and trusted by consumers.

The asymmetry that forces the rule

The two failure modes are not symmetric, and the rule rides entirely on that. An absent copy costs the consumer one bounded recomputation: run the query, read the source, do the work the copy would have saved. A false copy costs silent, unbounded wrongness — it tells consumers to stop looking, or to follow a snapshot of a world that has since moved, with no signal that anything is wrong. This is the [stale-indexes failure] in its sharpest form: a trusted-but-stale claim suppresses exactly the fallback that would have recovered the truth.

A bounded, recoverable downside on one side; a silent, unbounded one on the other — that is why hand-maintained-and-trusted is forbidden rather than merely risky. An unenforced copy is always one missed edit away from the catastrophic state, with nothing watching.

Where the rule applies: the deterministic end of derived knowledge

Any use-shaped artifact depends on its sources — whether its content is worked out from them (a derived copy) or generalizes beyond them (an abstracted rule, answerable to its sources as evidence). For dependent knowledge in general the KB runs managed staleness: [tracked lineage] names the downstream artifacts when a source changes, [make-like timestamp comparison] detects when review is due, and [holistic rework rather than patching] is the fix. The repair follows the regime: re-derive and compare where the content is recoverable from the source, re-examine the support where it exceeds it. That machinery stops at review because verification there is judgment. Deciding whether a revised source invalidates a downstream instruction is a Level B check in the [text testing pyramid] — an LLM reading both and judging fidelity or support — too costly to run always and too noisy to block on. In that regime the hand-maintained dependent artifact is not forbidden; it is unavoidable, and the design effort goes into making the lineage view surface the dependent artifact when the upstream change is recognized.

What flips the regime is the check price: mechanical derivation makes verification Level A — deterministic, near-zero cost, binary, runnable on every pass. Detection and verification then collapse into one free step, instead of needing a cheap detector plus an expensive judge. Two things change. Enforce-or-omit stops being aspirational and becomes the rule, since trusting an unchecked copy now saves nothing. And the interrupt-placement problem dissolves, since the validator is the edit-time surface — lineage only needs to sit where a machine can follow it, not where a human will see it.

What enforcement buys

[Frontloading spares execution context] wants a recomputable value inlined, since re-deriving it on every call is a hot-path cost; [an author should fix what the executor can't determine, not what it will] wants the same value left out, since anything the situation determines goes stale by drift or ignorance. Enforcement is the third class that lets both stand: between arbitrary (safe to pin) and situational (brittle to pin) sits recomputable-and-checked. Here a machine watches the situation on the author's behalf, converting staleness into a validation failure at check time instead of a silently wrong snapshot discovered mid-task.

What "checked" requires — and its limits

Enforcement is available only when four preconditions hold:

  1. A derivation rule. The copy must be mechanically re-derivable from the source. Extractable lists, set memberships, and file identity qualify; natural-language summaries and judgments do not — there is no comparison a machine can run, so they stay as live reads or are omitted.
  2. Machine-locatability. The copy must occupy a marked region that names its source — the [lineage] the validator follows to find the ground truth and re-derive it. Machine-followable suffices; human visibility is not required once the validator carries the interrupt.
  3. Ground truth that exists at validation time. Enforcement cannot help where execution itself produces the evidence: a plan's executor learns things no validator could pre-check, because the run generates them. When this precondition fails, the value was never a recomputable copy in the first place — that territory stays with the executor.
  4. A validator expected to bottom out, not recurse. The validator is itself a hand-authored artifact making an unchecked claim — that it correctly re-derives the copy. This looks like it reopens the regress, but it doesn't: a validator is centralized, versioned, reviewed on every change, and amortized across every copy it protects, so its unit cost of correctness-assurance is far lower than N independently hand-maintained instances would be. A derivation rule that is itself a judgment call rather than a strict mechanical extraction does not meet this precondition — it is the forbidden state, just relocated one layer down, with a stronger trust signal attached.

Consequences

  • Checked copies degrade gracefully. Dropping one costs consumers a recomputation, never correctness, so lifecycle exits stay cheap: a copy that outgrows its purpose is deleted and readers fall back to the source.
  • Never write the unenforced natural-language version of a checkable claim. "This list is complete" with no validator behind it is exactly the hand-maintained-and-trusted state the rule forbids. A checkable claim is enforced as a check or not asserted at all.
  • When a copy can't be checked, the resolution is omission. Either delete the copy ([ADR 025] deleted committed generated indexes) or read the source live (the 2026-06-10 skill edits — logged in kb/log.md — chose read-the-contract per invocation). Both are correct; both pay a build-time or hot-path cost that enforcement would have avoided. Omission is the fallback, not the optimum.

Instances across four surfaces

Four surfaces in the system instantiate the rule, each in a different state of application — already enforced, stated but unenforced, resolved by omission, and not yet applied. The spread is what shows it generalizes:

  • complete/covered_by marks on tag-READMEs (the curated per-tag index files) — enforced and shipped. A validator re-derives membership from the scoped rg sweep and fails on mismatch (the mark contract is in the [tag-readme type spec]). The sweep pattern is hand-authored, but it executes as a strict mechanical extraction — and precondition 4's amortization argument is what keeps the pattern's authorship acceptable instead of a quiet regress.
  • Compiled memory views and cues — the general source-of-truth requirement, stated for memory systems in [keep-compiled-views-aligned]: a derived surface needs provenance, regeneration rules, and staleness detection so it does not become an independent authority.
  • Hardcoded contract values in hot-path skills — currently resolved by omission (read the contract live). Enforcement — a marked frontloaded region whose extractable list a validator re-derives — would dominate, recovering the context economy without the drift.
  • Duplicated build artifacts — the two tracked AGENTS.md.template copies (root feeds wheel builds via pyproject force-include; src/commonplace/_data serves editable installs) must be byte-identical (the two-copy layout is designed in [ADR 027]). This is the trivially checkable case: file identity, one comparison.

It is the general form of "a cache must never be the only copy" — applied not only to caches but to every derived copy of recomputable truth.

Open Questions

  • Where else does an unenforced natural-language claim quietly stand in for a checkable one (the status: maturity field is a candidate trust mark with no validator)?
  • What is the cheapest general mechanism for marked, locatable, checkable frontloaded regions in instruction text?

Relevant Notes:

Artifact B

LLM recompute cost inverts the store-vs-recompute default

Ordinary software defaults against storing a value it can derive. Normalize the schema, keep one source of truth, recompute on read: compute is cheap and abundant, whereas a stored derived copy is a standing liability — it can go stale, it can disagree with its source, and every writer now has two places to keep in sync. Denormalization is the exception you reach for only under measured pressure, and reaching for it early is a named smell. The whole bias runs one way: prefer recompute, distrust the stored copy.

For an LLM consumer the cost profile flips, because the recompute step is the expensive one. "Recompute in context" is not a cheap arithmetic op; it is a tool call, a file load, a search, or a stretch of unreliable reasoning — each spending the scarce resource and each able to fail. This inverts the default: [context is the central scarce resource in agent systems], so the thing ordinary software treats as free is here the dominant cost, and the thing it treats as a liability — a materialized derived value the consumer just reads — becomes the cheap path. Materializing a derived value so the model reads it instead of recomputing it is worthwhile exactly where, judged as code, it would be premature denormalization: a derived value, cheap to recompute, stored anyway. The judgment reverses because the consumer changed, an instance of the general point that [human–LLM differences are load-bearing for knowledge-system design] — here the difference is the relative price of storage versus recompute.

The safety composition pushes materialization into symbolic form

The value theory alone says only materialize it. It does not say what the materialized copy must look like. That second constraint comes from composing this note with its safety half: once the value is recomputable from a live source, [a derived copy of recomputable truth must be checked or absent]. A materialized-and-trusted copy is one missed edit from silent, unbounded wrongness; a materialized-and-checked copy costs at most a bounded recomputation when dropped.

Requiring the check narrows how the value may be materialized. A validator can only re-derive and compare when the copy sits in a machine-parseable region that names its source — that is, when the materialized value is in symbolic rather than natural-language [representational form]. So the two halves divide cleanly: the value theory says materialize the derived value, and the safety constraint says materialize it in a form code can validate. Value pulls a computation out of the model's context; safety pushes the result into a symbolic slot with a derivation rule behind it. Neither half is sufficient alone — value without safety gives you the hand-maintained stale copy, safety without value gives you a validator guarding a copy no one needed.

Instances and one non-instance

This is the general value theory that two existing patterns instantiate:

  • The mark concept — complete/covered_by on tag-READMEs — is a validated symbolic cache consumed by agents. The membership query is recomputable but costs a scoped sweep on every read; the mark materializes the answer so the agent reads it, and a validator re-derives it so it can't silently rot (the mark contract is in the [tag-readme type spec]). Value plus safety, both halves present. The name mark fits this whole pattern — a validated cache read by an agent to spare a recompute — not just the tag-README fields. TODO: promote mark to its own definition note (./definitions/mark.md) once a second instance ships; with one example, the definition would just restate this bullet.
  • [Frontloading spares execution context] is the sibling application at the level of a whole instruction: precompute — or generate — the parts of a consuming call's context whose inputs are already known, and insert the result so the call reads instead of works. It is broader than this note along one axis (its inserted parts need not be a recomputed derived value; they can be generated content), and this note is sharper along another (it isolates the store-vs-recompute inversion that makes the insert pay).

A content-hash anchor looks superficially similar and is not an instance. It records a past state — a snapshot the current ground truth cannot regenerate, since its entire job is to detect divergence from that past — so it is load-bearing, not an accelerator over a recoverable query. And it is consumed by code, not read by the model to spare a recompute. It fails both halves at once: nothing about it trades the model's expensive recompute for a cheap read, and its value is the recorded past, not a re-derivable present. The pattern here is specifically a value the model would otherwise recompute, materialized for the model to read, checked because it is re-derivable — not every stored derived byte.

Scope

The inversion is about the consumer's recompute price, not about storage being free. A materialized value still costs to keep checked and still occupies context when read; the claim is only that the balance that makes recompute the default for a code reader makes materialization the default for a model reader. Where the derived value is consumed by code rather than read by the model, the ordinary software default applies unchanged — the flip rides entirely on who pays for the recompute.

Open Questions

  • What is the smallest general mechanism for a checked, machine-locatable materialized region inside natural-language instruction text, so the value half can be taken without hand-rolling a validator per case?
  • Are there derived values worth materializing for a model reader that are not cheaply re-derivable, where the safety half must fall back to managed staleness rather than a Level A check?

Relevant Notes:

Under-review context phrase

the value half — recompute being dear to a model is what makes a checked derived copy worth keeping in the first place