Chapter 3.1 opens part 3, the project library, after part 2, the harness, and precedes chapter 3.2, The Evidenceline product.
source: the two folder listings
A codebase, a collection of project files, is the project material organized into a product tree and its variants.
3.1.1 Scope rule of the experimental codebases
The Project Library, the collection that holds project materials, holds products and variants. It never holds task prompts, scores, or run artifacts. The library stores the project material needed to maintain those products and variants.
A variant appears in the library as a product tree. Project H and Project F are the products represented by the library. The library keeps their source material, manifests, and variant trees.
3.1.2 Library contents of the experimental codebases
The owning files are the library readme and the project manifest schema. The folder listing includes _archive, Open Source Candidates, Project F - Open Source, Project H - Evidenceline Compliance Platform, and the listed owning files. The library also contains the Project H variants folder and the Project F variants folder.
The scope rule keeps task prompts, scores, and run artifacts outside the Project Library. Those materials belong to their corresponding task, measurement, and run locations.
3.1.3 Project H variant trees and their frozen builds and their frozen builds and their frozen builds
Project H has thirteen variant trees: eight documented rungs, the stripped twin, the frozen control, and three superseded controls. source: the two folder listings
The Project H variants folder is the tree collection for the Evidenceline product. Its listing records the documented rungs and control trees.
3.1.4 Project F variant trees
Project F has two variant trees: the literate assessment protocol tree and the non-literate tree. source: the two folder listings
The Project F variants folder is the tree collection for the open source product. Its listing records both trees.
3.1.5 Project J variant trees
Project J is changedetection.io, an open-source web-page change monitor imported on 2026-09-20 under amendment A15 as the first brownfield project, meaning a codebase received after its original construction rather than built for the study. It is pinned at upstream commit 9c5600087a6ca1fc3a57ce9dd961dd918c7b69f9 under the Apache-2.0 licence and holds three arms in its variants/ folder: J-NON, the untouched snapshot; J-LAP-MATCH, the same code with an orientation file, one package summary per top-level package, a test-to-code index and inline boundary markers; and J-LAP-FULL, which adds the relationship map of thirteen reviewed boundaries and writes each boundary’s rule into its marker. The two documented arms were generated by a deterministic program from frozen prompts, and an equivalence check proved the executable statements of all 320 Python files identical across the three arms once comments and docstrings are removed. No agent-instruction file was present in the upstream tree, so none was removed.
source: 5. Experiment/2. Project Library/Project J - changedetection.io/source_manifest.json; HASP Analysis/equivalence_check.md and HASP Analysis/relationship_map.json in the same folder
3.1.6 Folder map of the experimental codebases
A folder map, a diagram of the library’s folders and files, shows how the owning files, project folders, archive, candidate folder, and variant folders, folders that hold variant trees, are arranged.
The map connects the owning files, the project folders, the archive, the candidate folder, and the folders for each product’s trees. It shows the boundary around the Project Library and the location of the variant trees.
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 458
The arms scroll sequence and its added still show the progression shared with P3 and P4.
source: operations/site-ia/A6-page-briefs.md line 458
Figure D-P0-2. The projects, their variant folders, and what the library excludes
%% figure D-P0-2 flowchart TB subgraph g1[" "] n1_1["variants/"] --> n1_2["HASP Build/"] n1_2 --> n1_3["upstream_snapshot/"] n1_3 --> n1_4["selection/"] end subgraph g2[" "] n2_1["step"] --> n2_2["step"] n2_2 --> n2_3["HASP Analysis/"] n2_3 --> n2_4["Open Source Candidates/"] end subgraph g3[" "] n3_1["_archive/"] --> n3_2["2. Project Library/README.md"] end n1_4 --> n2_1 n2_4 --> n3_1 n2_1 -- "variants/F-LAP/" --> n2_1_reference["reference"] n2_2 -- "variants/F-NON/" --> n2_2_reference["reference"]
source: operations/site-ia/A3-diagram-specification.md
source: operations/site-ia/A6-page-briefs.md line 458
The folder map shows the Project Library contents and the locations of both variant folders.
3.1.7 Manifest schema of the experimental codebases
The project manifest schema is stored with the Project Library. It records the structured information used to identify a product, its conditions, and its tree. The schema file belongs to the owning files listed above.
3.1.8 Reverse index of the experimental codebases
The reverse index records 331 files in the Project Library. source: reverse index, re-derived by find with the date