Chapter 1.3 follows chapter 1.2, The claim and its falsification conditions, and precedes chapter 1.4, The eight documentation doses, within part 1, the reading path.
1.3.1 Instrument composition of the documentation experiment
The measuring instrument has two halves. Evidenceline, the compliance-evidence platform built for this campaign, is the software product against which maintenance work runs. The maintenance suite supplies the maintenance work and its checks. The arrangement permits documentation to lose, because maintenance work can expose a failure in a documented path and a test can examine a boundary where documentation is expected to add little value.
1.3.2 Evidenceline product of the documentation experiment
The product manages evidence for functional-safety work. It turns the standards that apply to a machine into a fixed setup and the documents that follow from that setup. Its deterministic core reads the recorded choices and produces the same result each time. Its state is rebuilt from an append-only event record, and the resulting state can be checked by a hash. The specification in the concept and requirements files was frozen before implementation, so each build is measured against the same intended behaviour. The manifest status is frozen. source: 2. Project Library/Project H - Evidenceline Compliance Platform/project_manifest.json, key status
The complexity floor requires thirty-five sub-packages, 140 source files, 45 test files, 90 requirements, 60 rules that must remain true, 12 rule families and 12 distant boundaries. source: 2. Project Library/Project H - Evidenceline Compliance Platform/project_manifest.json, key complexity_floor
A seam, a boundary where a change in one part can violate a rule enforced elsewhere, is a deliberate place for maintenance work to reveal a distant cause. An invariant, a rule that must remain true, protects such behaviour. The manifest contains thirteen seam entries. source: 2. Project Library/Project H - Evidenceline Compliance Platform/project_manifest.json, key seams
The product has a deterministic core and a product shell. The core holds canonical state and rule execution. The shell presents that state through services and a browser interface. The maintenance suite can expose a symptom in the shell whose cause lies in the core, which makes the seam observable.
1.3.3 Project F evidence in the documentation experiment
Project F, the external-validity project, uses paperless-ngx, a mature document-management system maintained outside this campaign. A brownfield system, a codebase received after its original construction, supplies a setting where the documentation treatment meets code that was not written for this study. The pinned source is identified by commit d34ef75786fe806be9d521e9071ef92200fb3494.
source: 2. Project Library/Project F - Open Source/source_manifest.json, key commit_or_tag
The licence is the General Public License version 3.0 (GPL-3.0). source: 2. Project Library/Project F - Open Source/source_manifest.json, key license
The import date is 2026-07-19. source: 2. Project Library/Project F - Open Source/source_manifest.json, key imported_at
The source-tree screen contains 1,440 paths, of which 313 are Python and 414 are TypeScript files. source: 2. Project Library/Project F - Open Source/source_manifest.json, key source_tree_screen
1.3.4 Sequence structure of the documentation experiment
A task, a bounded maintenance job, gives an arm, one treatment version of a build, and a ticket, a written request with acceptance conditions. The substrate stays in place while the job is staged. A cell, one arm at one task assignment, records that pairing. The variant distinguishes the builds being compared. The dose names the treatment applied to a cell. A freeze, the recorded state held unchanged before work begins, fixes the starting point.
The task index contains seventeen Project H rows. Sixteen are registered and one, H-M025, is a draft. Eight rows are archived. source: 4. Task Library/task_index.csv columns project_id and status
A task may stand alone or belong to a chained sequence, an ordered run in which a later job depends on the preceding job. The predecessor tree, the record of those dependencies, shows which job must succeed before another can begin. A depth outcome, the furthest successful point in a sequence, records partial progress. Independent tasks and chained sequences let the suite measure both isolated maintenance work and accumulated work.
A visible tier, a level that presents the complete acceptance conditions and the checks available to the agent, states those conditions. A hidden tier, a level that tests those conditions with checks withheld from the agent, tests the same stated conditions. A probe, an edge-case check, exercises a condition at the edge of the stated behaviour. A witness, an honest implementation that demonstrates passability, shows that the check set can be satisfied. A cone, a calculator that locates consequences across a seam, helps locate those consequences.
1.3.5 Task evidence checks of the documentation experiment
The falsifier, a negative control intended to disprove a claim, marks a case where documentation is predicted to lose or make no difference. The ticket and visible checks give the agent the full stated job. Hidden checks may vary the inputs while preserving that job. Each check set is written from the ticket, audited against its wording, run against untouched starting trees, and tested with a witness implementation. These checks prevent a hidden tier from adding an unstated requirement.
The task package contains the request, acceptance conditions, agent-facing checks and hidden checks. Its purpose is to make a maintenance result attributable to the work performed against the frozen substrate. The package schema and task anatomy are maintained in the task library, while the plan defines the two task families and the boundary between what the agent receives and what it never sees.
1.3.6 Documentation loss conditions of the documentation experiment
The suite includes tasks designed to predict a tie or a loss for documentation. These cases matter because a suite in which documentation always wins cannot distinguish useful guidance from an advantage built into the tasks. Additive work gives each arm the same behavioural request against its own frozen tree. This avoids a patch written for one tree failing before the maintenance behaviour can be assessed.
1.3.7 Manifest discrepancy of the documentation experiment
An earlier page reported 126 requirements, 69 invariants and 14 seams. The manifest has no key planned_counts on 2026-09-12. Its seam list contains thirteen entries. The counts in this entry come from the complexity floor and the requirements files, with the seam count taken from the manifest. The discrepancy is retained in the plan record.
source: 2. Project Library/Project H - Evidenceline Compliance Platform/project_manifest.json, keys: complexity_floor and seams
1.3.8 Instrument figures of the documentation experiment
The two halves of the measuring instrument.
The product tiers and an observable seam.
The task suite map regenerated from the task index.
The frozen specification as the instrument basis.
The additive task model.