Validation documentation — the tool / instance rule¶
This folder holds the validation package described by ADR-0061 (realization plan: csv-validation-package.md). Everything here belongs to exactly one of two lanes, and the rule below decides which.
The rule¶
| Lane | Home | Content | May reference |
|---|---|---|---|
| Tool — LQMS itself, as shipped to any organisation | templates/, plus the per-tag supplier evidence in <tag>/ and requirements-<baseline>/ |
Statements true of any LQMS installation: the tool's mechanisms, its risk classes and mitigations, its inherent residuals, the supplier's evidence chain. Organisation-specific values appear only as declared template fields. | Other tool documents, ADRs, requirements, tests, CI evidence. Never an instance document. |
| Instance — one organisation's use of LQMS | drafts/ today; after C-V2 instantiation, controlled documents inside that organisation's LQMS |
One organisation's intended use, its recorded risk judgments, its deployment facts, its residuals and open items. | Its template (always), plus tool documents. |
The reference direction is one-way: instance → template, never template → instance. A tool document that cites an instance document has leaked and must be fixed, not worked around.
Why: LQMS is intended to be usable by organisations other than the first one, and the ownership question is open (implementation plan, D2 "Tool-vs-instance separation", 2026-07-26). Keeping the tool lane free of any single organisation's specifics is what makes the tool portable — and it is cheaper to hold the line per document than to de-specialise a package later.
Naming¶
- Template:
templates/<subject>.md— e.g.templates/tool-risk-assessment.md. - Instantiation:
drafts/<subject>-<instance>.md— e.g.drafts/tool-risk-assessment-meridian.md. Instantiations are INSTANCE data and do not live in this repository (tool-vs-instance, C-3): an installation keeps its filled-in copies in its own controlled storage. Only the tool-generic templates below are tracked here. - The instantiation names its template in its header block; the template names none of its instantiations.
Write LQMS for the tool. Do not elaborate product branding in these documents — a product rename is anticipated, and every branded phrase is a future edit.
How template fields work¶
Templates are written so they can be seeded as TEMPLATE-category documents in LQMS itself (ADR-0061 §2, C-V2a; mechanics in ADR-0049 §2):
- Instance-specific values are
{{key}}placeholders in the body, every one of them declared in a fenced```template-varsblock, one field per line:key | label | required(yes/no) | default. An undeclared placeholder blocks the template's submit; a missing required value blocks instantiation. (That is why the templates themselves describe the syntax in words rather than printing an undeclared example placeholder — a doc that explains the mechanic must not trip it. This README is not a seeded template, so it may.) - The block renders as a definition table in the preview (it is field documentation, not content), and is stripped from the instantiated document.
- Keys are camelCase without underscores: canonical markdown escapes
_({{audit\_date}}), which would break substitution — substitution matches the raw projection bytes. - Instantiating produces a RECORD draft with the values substituted, linked to the template
version by an
instantiated-fromprovenance edge. It then runs the ordinary life cycle (review, release), so the organisation's judgments and additions are reviewed like any other controlled content.
While a template still lives here as a repo document, the same field block is the contract: an instantiation records its filled values as a table, so template and instance stay mechanically comparable.
Contents¶
| Path | Lane | What it is |
|---|---|---|
| templates/intended-use.md | Tool | Intended-use specification skeleton (§4.1.6 "intended use" input). |
| templates/tool-risk-assessment.md | Tool | Tool-risk assessment: risk classes TR-001…TR-009, their mitigations and the tool's inherent residuals (§4.1.6 "proportionate to risk" input). |
| templates/ai-authorship-posture.md | Tool | How LQMS is authored, the gates that bound AI output, and why the validation evidence does not rest on trusting the authorship. |
| mock-audit-walkthrough.md | Tool (rehearsal aid) | The adversarial rehearsal script; disposable by design. |
<tag>/, requirements-<baseline>/ |
Tool | Generated per-release supplier evidence: validation report + archived CI evidence. |
| journeys/ | Tool | Promoted validation-journey bundles (ADR-0101), one per qualified release: the performance-qualification protocol, its screenshots and the records the walk produced. Promoted verbatim with scripts/promote-validation-journey.sh as part of the release ritual. |
The three drafts/ documents are working drafts for review, not controlled documents. On
acceptance they become the source content for controlled documents authored and released inside
LQMS through the ordinary life cycle (the C-V2 path, ADR-0061 §2/§3).