Chapter 3.2 follows chapter 3.1, The codebases and their variant trees, and precedes chapter 3.3, The project manifest, within part 3, the project library.
Evidenceline is a compliance platform for functional-safety projects. The platform manages evidence for standards-driven work on industrial machines.
The setup flow turns the question of applicable standards and owed documents into a fixed process. A pre-check establishes the machine domain. A gated questionnaire then presents twenty-two questions, each exposed when earlier answers make it relevant.
source: page 03 line 20
The deterministic engine reads the answers, applies boolean logic, and produces the same result each time. It uses no language model and no guesswork. In the worked example, it loads the applicable standards and instantiates about fifteen core deliverable documents with specialist overlays.
source: page 03 line 52
The setup cascade converts machine information into linked compliance documents and controlled evidence.
The documents form a cascade. Upstream hazards seed safety requirements, and those requirements feed downstream calculations. A collaborative editor, change tracking, comments, and project work views sit above the compliance core.
3.2.1 Deterministic core of the experimental codebases
The product has a deterministic headless core beneath its collaborative interface. The core uses event-sourced state and rebuilds it by replaying an append-only record of changes. It reads no wall clock and no outside environment, so replaying the same record produces the same state hash.
The product shell provides the web service, browser interface, rich-text editor, and live collaborative editing. Canonical truth is committed back to the event-sourced core. The shell presents and edits information, while the core governs the state used for evidence and verification.
The deterministic core governs evidence and state beneath the collaborative product shell.
The core keeps an immutable, hash-chained record of evidence. Each record carries a fingerprint derived from the preceding record, so a changed earlier record makes later fingerprints fail. Approved states are frozen as baselines, and releases preserve the states intended for delivery. The system can therefore identify changed evidence, approvals, and stale downstream material.
source: 5. Experiment/0. Plan/Appendix O, Project H, the Instrument Application.md line 15
The concept and design folders define the boundary between the product shell and the deterministic core. The boundary makes documentation removable without changing executable behaviour and gives cross-module rules a place for explicit verification.
source: 5. Experiment/0. Plan/Appendix O, Project H, the Instrument Application.md line 43
3.2.2 Cross-module rules of the experimental codebases
An invariant is a rule the system must never violate. A seam is a place where a change in a module can break a rule enforced by another module. The specification records fourteen seams.
source: page 03 line 87
A word-level comparison illustrates the boundary. An inline trace marker can cause an editor to highlight a whole line when only a word changed. The visible symptom is in the editor, while the cause is in the core logic that divides text into comparable pieces. The cross-module rule requires word-level differences to survive inline markers.
The frozen specification connects product structure, cross-module rules, and the documentation boundary.
The frozen specification governs the product before implementation. It gives the build a stable source for the document cascade, evidence controls, and cross-module relationships. It also makes the documentation boundary testable when the documentation layer is removed.
source: 5. Experiment/0. Plan/Appendix O, Project H, the Instrument Application.md line 49
3.2.3 Impact controls of the experimental codebases
The impact-cone calculator follows the paths and relationships that may be affected by an accepted edit. It takes acceptable edits and returns affected paths. The cone_files() function in the aggregate metrics script strips symbols and documentation markers while calculating that set.
source: 1. Harness/scripts/aggregate_metrics.py line 81
Figure fig-i-impact-cone. A cone calculation showing accepted edits at the source, affected files expanding through connections between related records and document relationships, and the resulting impact set feeding coverage and release gates.
%% figure fig-i-impact-cone flowchart LR n1["A cone calculation showing accepted edits at the source<br/>affected files expanding<br/>connections between related records and document relationships<br/>the resulting impact set feeding coverage and release gates"]
source: operations/site-ia/A3-diagram-specification.md
The impact cone carries accepted edits through affected files and relationships into release checks.
The coverage gates check whether required relationships and evidence are represented. Release gates check whether the resulting state is eligible for delivery. The evidence hash chain, baselines, releases, and impact cone keep those decisions tied to the recorded product state.
3.2.4 Product scale of the experimental codebases
The product contains thirty-five sub-packages.
source: page 03 line 141
The core contains 196 source files.
source: page 03 line 141
The tracked product contains 1,440 files.
source: page 03 line 141
The product specification also describes builds of the application used to test the instrument. Each build carries a documentation dose, and the comparisons preserve the same application while changing that dose.
source: 5. Experiment/0. Plan/Appendix O, Project H, the Instrument Application.md line 55
The deterministic boundary separates evidence controls from changes that could alter executable behaviour.
The boundaries, limits around executable behaviour, are strict. Documentation must not alter executable behaviour. Links between hashed records, records joined by fingerprints that reveal changes, must remain valid. Baselines, fixed approved states, must remain fixed. The impact cone must account for affected relationships, and coverage gates, checks for required relationships, and release gates, checks for delivery eligibility, must enforce their checks. A variant can have a different set of documents and controls.