Chapter 1.9 follows chapter 1.8, Threats to validity, and closes part 1, the reading path; part 2, the harness, begins with chapter 2.1, Execution of a cell.
The campaign has settled its exploratory status and the conditions for the next registered work. The remaining work concerns the frozen builds, the control, the task registry, the batch plan, the spending ceiling, and the report endpoints.
D-R8-1. Readiness gates for registered work.
source: operations/site-ia/A6-page-briefs.md, section R8
1.9.1 Settled decisions and outstanding registration work
All work recorded before the coming freeze remains exploratory and does not enter the confirmatory analysis. The task tracker, an index that gathers each open action and its status, records the blockers, control work, task order, and registration sequence. Its current order is the operative order for the first registered batch.
source: 5. Experiment/0. Plan/TASK_TRACKER.md section 1 at line 53 (blocking the first registered batch), section 2 at line 81, section 3 at line 136, and the suggested order at line 170
The task index records sixteen registered task units and one draft task. The draft remains outside the registered batch until its checks and status permit admission.
source: task_index.csv
The control has passed 430 of 430 backend tests and 151 of 151 frontend tests across 31 files on 2026-08-22. This verification supports the control’s place in the planned comparison, subject to the remaining freeze gates.
source: 5. Experiment/2. Project Library/Project H - Evidenceline Compliance Platform/variants/H-NON/variant_manifest.json key verification
The absence sweep found sixteen tasks with the requested behaviour absent from the frozen builds. Those records support the passability review before registration.
source: 5. Experiment/4. Task Library/Project H/_verification/README.md line 5
The freeze, a lock on the build, task, and analysis choices, must be completed before a confirmatory cell can be admitted. The first registered batch remains blocked by the unfinished tracker items.
1.9.2 First additive run blockers
The first additive run still requires the outstanding tracker actions, the control verification, the suggested task order, and the registration decision. The verification records are the material for that decision. A task is passable when its stated checks show the requested behaviour is absent in the untouched starting builds and the record permits measured use.
source: 5. Experiment/0. Plan/TASK_TRACKER.md section 1 at line 53 (blocking the first registered batch), section 2 at line 81, section 3 at line 136, and the suggested order at line 170; 5. Experiment/4. Task Library/Project H/_verification/README.md line 5 and the folder’s records dated 2026-09-01 to 2026-09-03
D-R8-3. The campaign road from settled work to reporting.
source: operations/site-ia/A6-page-briefs.md, section R8
D-R8-4. The registered run plan.
source: operations/site-ia/A6-page-briefs.md, section R8
1.9.3 Cost model of the documentation experiment
The cost model, a set of operator estimates for expected cell spending, assigns 0.70 dollars for a succeeding cell, 2.85 dollars for a failing cell, and 5.00 dollars at the worst case. The preflight script reads this model and prints the batch worst case before launch.
source: 5. Experiment/1. Harness/config/run_defaults.json lines 11 to 13 (key cost_model)
The basis field states that these figures are operator estimates from the haiku-class shakedowns and are not list prices.
source: 5. Experiment/1. Harness/config/run_defaults.json line 14 (basis field: operator estimates from the haiku-class shakedowns and not list prices)
Earlier cost descriptions use seventy cents for a successful cell, one dollar fifty for the next stated case, and twenty-one dollars thirty-seven for the stated batch total. Those figures remain tied to their page source and are separate from the current ceiling model.
source: page 12 at lines 176 to 198
Figure fig-extra-cost-model. A cost model diagram showing the succeeding-cell estimate, failing-cell estimate, worst-case ceiling, and the preflight check that reports the ceiling before launch.
%% figure fig-extra-cost-model flowchart LR n1["A cost model diagram showing the succeeding-cell estimate<br/>failing-cell estimate<br/>worst-case ceiling<br/>the preflight check that reports the ceiling before launch"]
source: operations/site-ia/A3-diagram-specification.md
D-R8-7. The cost model and its preflight ceiling.
source: operations/site-ia/A6-page-briefs.md, section R8
1.9.4 Final report endpoints of the documentation experiment
An endpoint, a measured outcome carried into the final report, is one of the two primary outcome measures. The reliability endpoint is success within the registered budget. The cost endpoint is tokens to success when both arms succeed.
A record must preserve the task, arm, run record, and scoring result. The two comparisons are the documented build against the control and the documented build against the stripped twin. The first comparison carries the primary treatment contrast. The second comparison isolates the documentation layer over shared executable code.
D-R8-5. The shape of the final answer.
source: operations/site-ia/A6-page-briefs.md, section R8
The final report will carry the reliability and cost endpoints with their eligibility decisions and witnesses. Status statements in this entry must be re-read at every update so that settled work, blockers, costs, and endpoints continue to match the owning records.
source: 5. Experiment/0. Plan folder, Appendix K, section K.2 at line 22; 5. Experiment/2. Project Library/Project H - Evidenceline Compliance Platform/variants/H-NON/variant_manifest.json key verification; 5. Experiment/1. Harness/scripts/preflight_batch.py