Fit and limits

The handbook ends with two decisions that no amount of structure can make for you.

The first is a fit decision. Does a recurring problem in your work justify the recurring cost of planning, filing, verification and closeout? The second is a claim decision. Does the available evidence support the sentence you want to say, or are you about to turn a mechanism into a promised outcome?

Those questions belong together because both resist wishful accounting. A useful work habit still has upkeep. A real mechanism still has a limit. Coldstart is a better fit when both sides stay visible.

[Visual 9 — One wide frame split into two readings by a solid vertical boundary. The left reading is labelled "fit decision". A balance compares "recurring pain" with "recurring operating cost"; below it, a hand labelled "human judgment" can choose "smaller method" or "keep what earns its upkeep". The right reading is labelled "claim boundary". Three boxes run left to right: "claim", "evidence", and a dashed "unsupported inference" box stopped by a vertical bar; below them are four boundary tags: "evaluation", "release", "platform", and "migration". A footer across both readings says "observed mechanism ≠ guaranteed outcome". Pages 9.1 and 9.2 enlarge the left and right readings without changing these labels.]

The two pages

Fit starts with witnessed pain

The left reading begins with something that happened more than once: a decision had to be reconstructed, a request expanded without a choice, a handoff hid what had been checked, or old guidance returned after the project had moved on.

That history belongs on one side of the balance. The other side carries the work of maintaining a bounded plan, a current pointer, owned records, useful checks and an honest close. If a smaller method addresses the repeated failure at lower continuing cost, the smaller method wins.

Coldstart cannot score this balance for you. A check can report whether a represented condition is present. It cannot decide how much that condition matters in your project, whether the same failure will recur, or whether the process used to catch it earns the attention it consumes.

Evidence stops before the outcome

The right reading begins with a narrower question: what was actually observed?

At the pinned review, the source contains mechanisms for session orientation, bounded work, project records, routed guidance, selected enforced boundaries, verification and re-derived views. Its evidence also includes authored evaluation sets and a partly walked smoke record. Those sources can support statements about the mechanisms they inspect and the exact cases they exercise.

They do not establish that a project becomes more productive, that its code becomes better, that drift disappears, or that every named host behaves alike. They also do not turn one-project activation into a verified way to reconcile an existing body of project knowledge.

The vertical bar in the visual is therefore part of the product story. A claim can travel from a mechanism to evidence. It stops before the unsupported inference.

Four boundaries move at different speeds

• Evaluation asks what a bounded authored set actually measured. A clean result on that set is not evidence about every task or about user outcomes.
• Release asks what state was reviewed on the date above. This handbook describes a pre-release source state; later work can invalidate a status sentence without changing the mechanism.
• Platform asks where an entry point or test was actually exercised. A declared host surface and selected launcher evidence do not establish the complete journey everywhere.
• Migration asks whether existing project material can be reconciled without loss. Mechanical activation is implemented; existing-corpus adoption has no verified path at the pinned review.

Keeping these boundaries separate prevents a result in one area from silently settling another. A locally exercised check says nothing by itself about a public release. A source-level mechanism says nothing by itself about a successful migration. A routing score says nothing by itself about the quality of the work produced after routing.

The handbook ends at judgment

The earlier sections explain commands, the work loop, memory, guidance, boundaries, change, upkeep and setup. They can show where an action enters the loop, which record owns a fact, when a check runs, or how a generated view is re-derived.

This section marks what remains yours. You decide whether the discipline fits the pattern of work. You decide whether the evidence is strong enough for the claim. The method can make those decisions more inspectable; it cannot take ownership of them.

Next

Start with the cost side of the boundary: is this worth it?

How current this page is

Checked on 10 August 2026 against the pinned lifecycle record, smoke evidence, release-boundary tests, scoring implementation, evaluation report and claim grammar. The product has moved since that pin; the handbook keeps one shared evidence boundary instead of mixing revisions. To ask whether a claim here still holds, or to report one that does not, write to [email protected].