Chapter 3.5 follows chapter 3.4, Differences between the variant trees, and precedes chapter 3.6, The control build and its history, within part 3, the project library.
3.5.1 Build harness of the experimental codebases
The build harness, the machinery that constructs and instruments the documented codebase, uses the Harnessed Agentic Software Programming build and instrumentation method (HASP) to record commands, artifacts, phase results, and handoffs. It is separate from the measurement harness, which runs maintenance tasks against frozen variants. The build harness spends from a generation ledger, while the measurement harness spends from a run ledger.
A freeze is a recorded lock on a tree’s contents and hashes. A replay hash is the hash produced when the same build action is run again. A gate is a required pass with an attached evidence record before a freeze can stand. These terms keep construction evidence distinct from measurement evidence.
The build harness operates on the specification through the files under the build folder, including build state, transcripts, handoffs, prompts, scripts, spikes, and profile references. The earlier pre-rebuild state remains available for comparison. The native control process uses its own freeze scripts and does not inherit the build harness evidence.
Figure D-P0-1. One specification, one documented build, one strip, seven re-documentations, and one independent control
%% figure D-P0-1 flowchart TB subgraph documented["Documented build"] n1_1["2. Requirements/"] --> n1_2["project_manifest.json"] n1_2 --> n1_3["spec_version"] n1_3 --> n1_4["HASP Build/build_state.json"] n2_1["completed"] --> n2_2["phase-0"] n2_2 --> n2_3["phase-8"] n2_3 --> n2_4["HASP Build/scripts/build_h.py"] n3_1["gate_checks.py"] --> n3_2["deploy_gate.py"] n3_2 --> n3_3["H-LAP-L5P"] n3_3 --> n3_4["H-STR"] n4_1["1. Harness/scripts/strip_lap.py"] --> n4_2["strip_python_source()"] n4_2 --> n4_3["step"] n4_3 --> n4_4["step"] n5_1["lap_files"] --> n5_2["inline_markers"] n5_2 --> n5_3["# Trace:"] n5_3 --> n5_4["# Decision:"] end subgraph variants["Variant trees"] n6_1["H-LAP-L1"] --> n6_2["H-LAP-L4P"] n6_2 --> n6_3["3. LAP Profile Library/HASP Instrumentation/application_order.md"] n6_3 --> n6_4["1. Harness/scripts/instrument_profile.py"] n7_1["copy_clean_tree()"] --> n7_2["check_code_identical()"] n7_2 --> n7_3["H-NON"] n7_3 --> n7_4["step"] n8_1["variant_manifest.json"] --> n8_2["1. Harness/scripts/freeze_non_parity_repair.py"] n8_2 --> n8_3["step"] n8_3 --> n8_4["step"] n9_1["step"] --> n9_2["deploy.manifest.json"] n9_2 --> n9_3["entrypoint"] n9_3 --> n9_4["one_command"] n10_1["public_port"] --> n10_2["performance_reference"] n1_4 --> n2_1 n2_4 --> n3_1 n3_4 --> n4_1 n4_4 --> n5_1 n5_4 --> n6_1 n6_4 --> n7_1 n7_4 --> n8_1 n8_4 --> n9_1 n9_4 --> n10_1 n4_3 -- "load_lap_files()" --> n4_3_reference["reference"] n4_4 -- "variants/H-LAP-L5P/lap_artifact_manifest.json" --> n4_4_reference["reference"] n7_4 -- "variants/H-NON/README.md" --> n7_4_reference["reference"] n8_3 -- "H-NON-2026-07-retired" --> n8_3_reference["reference"] n8_4 -- "H-NON-2026-08-11-interim-delivery-1" --> n8_4_reference["reference"] n9_1 -- "H-NON-2026-08-18-pre-parity-repair" --> n9_1_reference["reference"] end
source: operations/site-ia/A3-diagram-specification.md
source: operations/site-ia/A6-page-briefs.md line 530
Shared derivation of the build variants and the separate control path.
3.5.2 Reproducibility gates of the experimental codebases
The nine gates are the specification gate, the runnable-project gate, a gate that checks the user journey in a real browser, the test-and-hidden-scoring gate, the documentation-quality gate, the strip-validity gate, the retrofit gate, the task pre-registration gate, the reproducibility gate, and the deployability gate. Each gate produces a pass or fail record before the relevant freeze. source: Appendix K lines 30 to 38
That gate checks the user journey, meaning the steps a person takes through the product, before release. The deployability gate checks a clean machine, meaning a machine without preinstalled project dependencies, with one command and its declared smoke checks, quick checks that confirm basic operation. These gates address failures that a green unit suite can leave undiscovered. The gate records also identify inherited, inapplicable, pending, and re-run evidence for each variant.
The ordered gates and their blocking evidence.
3.5.3 Execution contexts of the experimental codebases
An execution context, meaning the setting in which code is constructed or measured, contains the build harness for the documented tree, the native harness, meaning the harness that runs the unguided control under its ordinary Claude Code behavior, or the measurement harness for maintenance tasks in frozen variants. Their tool versions and provenance fields remain recorded, and their ledgers remain separate.
Separate execution contexts for construction, control generation, and measurement.
Green test results alongside a broken product path.
3.5.4 Build phases of the experimental codebases
The build harness records nine phases, from phase-0 through phase-8, with their completion dates in the build state. The recorded sequence runs from 2026-07-16 through 2026-07-20. The state also records a timestamp and fix-round count for each phase. source: 5. Experiment/2. Project Library/Project H - Evidenceline Compliance Platform/HASP Build/build_state.json key completed and log
Figure D-P4-5. A phase-loop figure generated from build state, showing phase-0 through phase-8 with their recorded completion dates and fix-round evidence.
%% figure D-P4-5 stateDiagram-v2 state "A phase-loop figure generated from build state / phase-0" as s1 state "phase-8 with their recorded completion dates and fix-round evidence" as s2 s1 --> s2
source: operations/site-ia/A3-diagram-specification.md
source: operations/site-ia/A6-page-briefs.md line 532
The recorded build phases and completion dates.
3.5.5 Generation ledger and handoffs
A generation ledger is the record of construction spending and phase-level generation evidence. The build method preserves raw generation transcripts, command logs, artifact hashes, and handoff notes. A handoff carries the accepted state and unresolved work from one phase to the next. The ledger makes each build action traceable without mixing construction spending with run spending.
3.5.6 Control build of the experimental codebases
The unguided control follows a separate native process. A goal-only session receives the specification, and an audit returns missing requirements for repair. The control’s freeze evidence is held in the native build notes and freeze scripts. Its status remains distinct from the gates applied to the documented build.
The separate native control process and its freeze record.
3.5.7 Byte identity of the experimental codebases
The documented variants are derived from one stripped tree, with profile documentation applied without changing executable code. The byte-identity check covers 297 tracked Python files and 2,376 file comparisons, all matching. source: 3. The LAP Profiles.md line 287
The byte-identity comparison across the documented variants.
3.5.8 Freeze repair of the experimental codebases
A freeze fixes the tree that measurement will use by its recorded hashes. A re-freeze re-derives evidence from the existing trees after an evidence-affecting file change. It updates strip records, hashes, and identity checks without rebuilding the variants. The earlier state file, transcripts, handoffs, and freeze scripts preserve the trail from the prior state to the current record.
source: operations/site-ia/A6-page-briefs.md line 520