Chapter 3.6 follows chapter 3.5, Construction and freezing of the builds, and precedes chapter 3.7, The second codebase, paperless-ngx, within part 3, the project library.

The control, an unguided build made from the specification alone, is the unguided non-documented (H-NON) version of Evidenceline. One agent session received the specification without the build harness, phase gates, or documentation regime used for the other arms. The build history includes a lost transcript, an audited rebuild, a parity shortfall, a parity repair, a documentation-density comparison, and a re-freeze, a new frozen record after a change. source: operations/site-ia/A6-page-briefs.md line 540

3.6.1 Control build origin of the experimental codebases

The first control was an independent build. The agent received the locked specification and worked without harness instructions, phase structure, automated checks, independent review, or a documentation regime. The build therefore records an unguided construction process rather than a stripped copy of the documented build.

3.6.2 Retirement of the first control build

3.6.2.1 Lost transcript of the experimental codebases

The first transcript contained evidence needed to verify the build against the specification. Its loss removed that evidence. The operator retired the build rather than deleting it, preserving the prior tree beside the current control.

3.6.2.2 Mismatched model of the experimental codebases

The first control also carried a model mismatch in the historical record. The rebuilt control used the model class specified for its rebuild, while the retired transcript could no longer establish the model used by the first run. The folder sequence therefore distinguishes the retired tree from the audited rebuild.

3.6.3 Audited rebuild shortfall of the experimental codebases

The rebuild was made in a copy outside the repository. Its builder did not see the acceptance gate. The rebuild followed the control rebuild plan in Appendix L and stopped short of the full specification. Its shortfall concerned the runnable-project gate, the platform test and code-side scoring hooks gate, the task pre-registration gate, the reproducibility gate, and the deployability gate.

The control had therefore not completed the full sequence of gates passed by the documented build. Appendix L records the rebuild plan, the stopping point, and the addendum for the later repair.

3.6.4 Parity audit findings of the experimental codebases

A parity audit, a comparison of corresponding behaviour between builds, found four control-only defects. They were a lossy comma-separated-value round trip, an incomplete JSON export that omitted review comments and the committed setup record, an account-creation path with one shared password salt, and an impure dossier plan preview. source: operations/site-ia/A6-page-briefs.md line 540

The audit compared the control with the documented build. The first three defects concerned stored data or account behaviour. The final defect concerned preview behaviour. The audit supplied the basis for the repair recorded in the manifest and Appendix L.

3.6.5 Parity repair of the experimental codebases

A parity repair, a correction that brings a build into behavioural agreement with its comparison build, closed the four control-only defects. The repair date was 2026-08-22. source: variants/H-NON/variant_manifest.json keys repaired, predecessor and verification

The repaired tree was verified with 430 of 430 backend tests and 151 of 151 frontend tests across 31 files. source: variants/H-NON/variant_manifest.json keys repaired, predecessor and verification

The predecessor tree was the unguided non-documented (H-NON) tree variants/H-NON-2026-08-18-pre-parity-repair. source: variants/H-NON/variant_manifest.json keys repaired, predecessor and verification

The repair changed the status of the stripped-versus-control comparison. The comparison is now a structure component only because the control received the repair and the stripped twin did not. It cannot isolate the build process.

3.6.6 Requirement coverage shortfall of the experimental codebases

Requirement coverage was graded 220 of 225 before the repair. Amendment A7 records the parity repair and the demotion of the structure component. source: Appendix A line 79

3.6.7 Documentation density of the experimental codebases

The control contains ordinary in-code comments, while the documented build has a curated documentation layer and the stripped twin has no in-code documentation. No committed campaign census owns a comparable comment-line total, so this page makes no numerical density claim.

3.6.8 Control folder sequence of the experimental codebases

Figure D-P5-1. The four control trees and the event that retired each of the first three

%% figure D-P5-1
flowchart TB
  subgraph g1[" "]
    n1_1["variants/"] --> n1_2["H-NON"]
    n1_2 --> n1_3["0. Plan/Appendix L, Control Rebuild Plan.md"]
    n1_3 --> n1_4["step"]
  end
  n1_4 -- "variants/H-NON/variant_manifest.json" --> n1_4_reference["reference"]

source: operations/site-ia/A3-diagram-specification.md source: operations/site-ia/A6-page-briefs.md line 548 The control folder sequence from the retired tree to the repaired tree.

A comparison showing the control as an independent specification-led build and the stripped twin as a mechanically derived build, with a clear separation between the two origins. The independent origin of the control build.

A gate comparison showing the documented build completing its checks while the control remains short of the runnable-project, platform test and code-side scoring hooks, task pre-registration, reproducibility, and deployability gates. The control shortfall against the documented build.

A cyclic figure showing the control moving through agent work, specification checking, defect discovery, repair, and another specification check until the required behaviour is reached. The control iterate-to-spec loop.

A structure figure distinguishing the documented build, stripped twin, and independently built control without reporting an unsupported comment-line census. source: 0. The Website/assets/gen_site_figures.py lines 11 to 15 The structure figure identifies the three build histories; no numerical density comparison is claimed.

3.6.9 Re-freeze state of the experimental codebases

The manifest, a file listing the frozen build’s recorded state, records the re-freeze through the keys variant, rebuilt, frozen_utc, tree_sha256, file_count, builder_model, builder_session, coverage, spend, verification, predecessor, repaired, and repair. The repaired control is the current frozen control and the baseline for comparison with the other builds. source: .../variants/H-NON/variant_manifest.json keys variant, rebuilt, frozen_utc, tree_sha256, file_count, builder_model, builder_session, coverage, spend, verification, predecessor, repaired and repair

The repair report path was never present. This entry cites the manifest and Appendix L instead.

Previous: Construction and freezing of the builds | Next: The second codebase, paperless-ngx
source: `operations/site-ia/A6-page-briefs.md` section `### P5. The control build and its history`