All four gate criteria met. False Adaptation Rate 0/7 with 12 of 13 mechanical mutations absorbed. 178 tests pass. TD-WP-0002 finished. Fitness loop closed via F-0003: actor isolation was a property of scenarios written to expose it, not of runs. Actors now carry an automatic private marker and the runner examines all of them on every scenario, with two permanent regressions behind it. Compression - six abstractions removed, each declared and never used: Verdict.SUSPICIOUS (a verdict no oracle could emit), Step.expect_refusal, ActorIsolationError, World.seed, EvidencePack.latest, Trajectory.method. F-0008: Temperature may be redundant. Crystallization was built without it ever being consulted; measured stability of realization did the work, and is observed rather than declared. Gated for removal alongside energy.py. INTENT_CHANGED and REALIZATION_FAILED had never run. Both now have purpose-built cases and a test that fails if a seventh outcome is added without one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 1629012@bnt-lap001 Assistant-Session: 78d4fb13-8a1e-474b-87a3-9b9261c49a39
2.6 KiB
| id | type | class | status | discovered | discovered_by | workplan | task | carried_to |
|---|---|---|---|---|---|---|---|---|
| F-0008 | framework-finding | UNNECESSARY_COMPLEXITY | open | 2026-08-23 | TD-WP-0002-T10 | TD-WP-0002 | TD-WP-0002-T10 | next workplan |
F-0008 — Temperature may be redundant; measured stability did the work
Observation
Temperature (HOT / WARM / COOL / COLD) is one of the more prominent
ideas in INTENT.md and the Concept Model. It is supposed to govern which
verification mode an asset uses, and it is the mechanism by which "tests
crystallize as software cools".
The spike built crystallization end to end. Temperature was never consulted, never implemented, and never missed.
What actually triggered freezing was assess_stability: the same realization
path observed across several consecutive runs. Nothing declared the surface cold;
the surface was observed to have stopped moving.
The argument for removal
The two mechanisms answer the same question, and only one of them can be wrong:
| Temperature | Measured stability | |
|---|---|---|
| source | declared by a human | observed from runs |
| upkeep | must be maintained and kept honest | none |
| failure mode | says COLD while the surface churns |
none — it is the churn |
| already built | no | yes |
A declared temperature is a claim about the system that nobody verifies. The project's own first heuristic — do not let a declaration substitute for evidence — argues against keeping it.
The argument for keeping it
Two cases measured stability cannot cover:
- Forward-looking scope. A team knows a rewrite lands next month.
Temperature can say
HOTbefore any run has observed instability, where measured stability would happily freeze an asset the day before it breaks. - Cheap prioritisation. Deciding where to spend effort across many capabilities may want a coarse label without running anything.
Neither case arose in the spike, and neither is evidenced.
Recommendation
Do not delete yet; do not build either. Carry Temperature as explicitly
unvalidated in the fitness map, and set a gate: if the next workplan completes
without any decision consulting it, remove it from the concept model.
Recorded now because the compression review's purpose is to catch concepts that survive on the strength of being attractive rather than useful, and Temperature is currently the clearest instance in the corpus.
Related
Confidence, Campaign, Metabolism and Retirement are in the same position —
declared, unimplemented, never consulted — but Temperature is the one with a
built alternative already doing its job, which makes it the decidable case.