Chapter 3.3 follows chapter 3.2, The Evidenceline product, and precedes chapter 3.4, Differences between the variant trees, within part 3, the project library.
3.3.1 Manifest schema of the experimental codebases
The artifact follows the schema in 5. Experiment/2. Project Library/project_manifest_schema.md. Its normative keys are schema_version, project_id, name, kind, language, status, conditions, complexity_floor, id_ranges, seams, spec_files, task_set_path, valid_for_measured_runs, valid_for_measured_runs_note, and extras. These keys record the project identity, operating conditions, structural constraints, identifier spaces, cross-module relationships, specification locations, task-set location, run eligibility, and project-specific data.
source: operations/site-ia/A6-page-briefs.md, section P2.
3.3.2 Complexity floor of the experimental codebases
A complexity floor is the minimum set of structural properties that a build must satisfy for the project instrument. The manifest stores these values in complexity_floor.
- The minimum subpackage count is 35. source: 2. Project Library/project_manifest.json, key complexity_floor
- The minimum source-file count is 140. source: 2. Project Library/project_manifest.json, key complexity_floor
- The minimum test-file count is 45. source: 2. Project Library/project_manifest.json, key complexity_floor
- The minimum requirement count is 90. source: 2. Project Library/project_manifest.json, key complexity_floor
- The minimum invariant count is 60. source: 2. Project Library/project_manifest.json, key complexity_floor
- The minimum invariant-family count is 12. source: 2. Project Library/project_manifest.json, key complexity_floor
- The minimum distant-seam count is 12. source: 2. Project Library/project_manifest.json, key complexity_floor
3.3.3 Seam definitions of the experimental codebases
A seam is a place where editing one module can break a rule enforced by another module. The seams key records each relationship with a symptom location, a cause location, an enforcing invariant, and a statement of the coupling. The seam list contains 13 entries.
source: 2. Project Library/project_manifest.json, key seams
3.3.4 Project manifest of the experimental codebases
A project manifest is the structured record that states a project’s identity, schema, conditions, structural constraints, identifier spaces, seams, specification files, task set, run status, and extensions. The Project H manifest is the worked example. It describes the Evidenceline Compliance Platform and provides the source keys for the values in this entry.
Figure D-P2-1. The declared sections of a project manifest and the complexity floor
%% figure D-P2-1 flowchart TB subgraph sections["Declared sections"] n1_1["subpackages"] --> n1_2["source_files"] n1_2 --> n1_3["test_files"] n1_3 --> n1_4["requirements"] n2_1["invariants"] --> n2_2["invariant_families"] n2_2 --> n2_3["step"] n2_3 --> n2_4["acceptance"] end subgraph manifest["project_manifest.json"] n3_1["seams"] --> n3_2["determinism_contract"] n3_2 --> n3_3["lap_surface"] n3_3 --> n3_4["profiles"] n4_1["project_manifest.json"] --> n4_2["project_manifest_schema.md"] n1_4 --> n2_1 n2_4 --> n3_1 n3_4 --> n4_1 n2_3 -- "distant_seams" --> n2_3_reference["reference"] end
source: operations/site-ia/A3-diagram-specification.md
source: operations/site-ia/A6-page-briefs.md, section P2.
Structure of the Project H manifest.
3.3.5 Identifier ranges of the experimental codebases
Related project versions that preserve a shared structure while differing in selected files or settings use the id_ranges key to reserve stable spaces for requirements, invariants, acceptance tests, seams, and defects. These ranges keep identifiers stable across builds. The manifest also names the specification files and the historical task-set path through spec_files and task_set_path.
3.3.6 Frozen status of the experimental codebases
The status key records the value frozen.
source: 2. Project Library/project_manifest.json, key status
Frozen status means that the concept, requirements, and design records govern the project before implementation changes are assessed. The manifest also records whether the project is valid for measured runs and explains that value in valid_for_measured_runs_note.
3.3.7 Requirement and invariant counts
An invariant is a rule that the system must never violate, such as preserving a frozen baseline when a later document version exists. The manifest has no planned_counts key. The requirement and invariant totals are therefore recounted from the files in 2. Project Library/Project H - Evidenceline Compliance Platform/2. Requirements/.
The requirements directory contains 126 requirement files. source: 2. Project Library/Project H - Evidenceline Compliance Platform/2. Requirements/
The requirements directory contains 69 invariant files. source: 2. Project Library/Project H - Evidenceline Compliance Platform/2. Requirements/
The manifest groups related project versions that share a structure.