Upkeep

A harness can become convincing long after it stops being accurate. A command still prints green, a map still looks complete, and a routing index still has rows. None of those appearances tells you whether the checks still test what they claim or whether the generated views still agree with the sources they summarize.

Coldstart treats those as two different upkeep jobs. Verification asks a fixed, named roster of checks about the tree and preserves the difference between a represented defect and broken checking machinery. Regeneration rebuilds machine-owned views from authored sources and compares the result with the bytes on disk. One protects the meaning of a run; the other protects the direction of truth.

[Visual 7 — One wide frame split into two equal panels. Left panel: a box labelled "27 registered check classes at the pinned revision" enters a runner labelled "applicable roster for this tree". The runner has three equal exits: "0 — applicable checks passed", "1 — represented finding" and "2 — runner or check broke". A small note under exit 0 reads "only the predicates and environment represented by this run". Right panel: two authored-source stacks, "warehouse cards and structure" and "capability cards", enter two regenerate boxes. Their outputs, "warehouse maps" and "routing projections", meet a byte-compare gate with three exits: "current", "stale — report or rewrite" and "source unreadable — refuse partial output". A bracket under both panels reads "honest upkeep: name what was checked, and derive every generated view from its owner". Pages 7.1 and 7.2 enlarge the left and right panels without changing these counts or labels.]

The two pages

Green belongs to a roster

The verification entry point does not search for files that happen to look like checks. It imports an explicit, ordered roster. At the pinned revision that roster contains 27 check classes. Adding a class therefore requires a deliberate registration change; dropping one cannot be hidden by a missing file that nobody noticed.

The runner also asks which classes make sense for the tree in front of it. A Coldstart root carries the harness, its tools, its capability library and its own knowledge warehouse, so every registered class has a subject there. A mounted project exposes only the knowledge area Coldstart owns inside someone else's project. Checks whose subjects cannot exist there are skipped by name, and the run announces both the applicable count and the skipped classes.

That announcement matters as much as the final exit. “Green” without the roster could mean all 27 classes ran, a smaller mount-safe subset ran, or an operator deliberately selected one class. The same process code would hide those differences if the report did not name them.

The three exits preserve another boundary. Exit 1 means a check ran and found a defect represented by its rule. Exit 2 means the runner could not make a trustworthy judgment: the root could not be resolved, the roster was malformed, the requested class did not exist, or a check raised instead of returning findings. A broken gate is not a passing gate and not an ordinary red tree.

Exit 0 is deliberately narrower than “the project is correct.” It says that the applicable checks completed without an error under the mode and environment of that run. Non-strict mode may still report ratchet warnings. Strict mode promotes those warnings and runs the expensive matrix that proves each registered check's declared self-test goes red when the check is neutered. The output, not the colour alone, tells you which contract was exercised.

Generated views point back to authored sources

The right panel has the opposite shape. A warehouse map and a routing projection are useful because they make authored material easier to scan or query. They become dangerous if people edit them as independent records. The projection can then disagree with its source while both files continue to look plausible.

Coldstart avoids that second source of truth by rebuilding the whole view. The warehouse generator scans the authored cards and room structure, renders the expected top-level and room maps, and compares those rendered bytes with the files on disk. The routing generator scans authored capability cards and renders both its compact rows and its index from that same card set.

In ordinary write mode, a differing projection is replaced with the freshly rendered form. In check-only mode, the tools report which output is stale and write nothing. Both use byte comparison, so even line-ending drift remains visible instead of disappearing through text normalization.

Malformed source is not ordinary staleness. If a card or structure cannot be parsed, the generator refuses to write a partial view that silently omits it. That is the derived-state equivalent of a broken verification runner: the machinery cannot support a trustworthy result, so it stops instead of producing something that merely looks current.

The two jobs meet, but they do not collapse

Regeneration can repair stale machine-owned views. Verification can detect whether represented relationships, budgets, references, registrations and derived-state parity hold. Running both is a stronger maintenance routine than running either alone, but neither changes what the other means.

A current projection says its bytes equal a fresh rendering of the sources the generator could read. It does not say the authored sources are wise, complete or current. A green verification run says its applicable predicates passed. It does not say every possible defect has a registered predicate, that every skipped class was irrelevant in some wider context, or that the resulting product achieves its intended outcome.

This is why upkeep starts with nouns, not reassurance. Name the roster. Name the tree shape and mode. Name the authored source. Name the generated projection. Name whether the result is a finding, staleness, or broken machinery. Once those are separate, “green” and “current” become useful evidence rather than blanket conclusions.

When this matters

Use this upkeep discipline when the harness itself has changed, when authored cards or warehouse structure moved, before a close that relies on generated views, or when a previously clean run no longer explains which guarantees it exercised. A small prose-only edit may not change a projection, but the check-only comparison is cheap evidence of that fact.

Human judgment remains outside both mechanisms. A person still decides whether the roster covers the risks that matter, whether a warning should become a hard gate, whether an authored card tells the truth, and whether a change in generated output reflects an intended source change. The tools make drift and breakage legible; they do not make those decisions disappear.

What this section does not claim

This section does not claim that self-CI proves its own completeness. The strict falsifiability matrix tests whether each registered class can be made to fail through its declared self-test. It cannot prove that an absent class should have existed, that a test models every defect, or that the environment matches production.

It also does not claim that deterministic generation makes authored sources correct. Re-derivation prevents a generated view from becoming an independently maintained truth. If the source is wrong, the regenerated output can reproduce that wrongness exactly.

Next

Start with the meaning of a verification result: what green means.

How current this page is

Checked on 10 August 2026 against the pinned product revision's verification runner, check contract, self-test-integrity rule, maintenance instruction and two projection generators. The product has moved since that pin; sections 1 to 6 use the same revision, so this section keeps it rather than mixing source snapshots mid-handbook. To ask whether a claim here still holds, or to report one that does not, write to [email protected].