docs: fold the fourth-reading findings into ADR 0018 and the roadmap

All six valve-actuator inspection reports and all four clean-water checklist
pages read at full render. Confirmed R8, R9, R10 and R15 with exact evidence;
sharpened R3 and R5; raised R20-R22.

Folded into the ADR:
- Section 4: a note is never an answer. The source answers several lines with a
  bare "see notes" and NO mark -- a cross-reference standing in place of an
  answer, one of which points at notes that never mention the line. R3 had
  modelled only the safer variant (mark AND pointer). A line with a note and no
  result is a blank and the gate treats it as one.
- Section 8: scope widened to final control elements, not only transmitters.
  Every valve report records fail position on loss of signal, function, and
  control/feedback signal types. Fail position is the clearest case for the
  whole collection. Fields added; collection name unchanged.
- Section 9: required signature roles come from the GC's template, never from
  the vendor's paper. Two failure modes in the source, not one -- a contractor
  block left blank on one vendor's form, and NO such block at all on another. A
  QC deriving who owes a signature from the attached document reports nothing
  missing for the worse case.

New, not folded:
- R20: a signed checklist's signature block sits on its own page carrying no
  identification of what was signed. Detached, it attests to nothing. A
  rationale finding for ADR 0010's signed_content_hash and a print-discipline
  bar for the free turnover view; recorded in ROADMAP M6.2.

Also recorded: the gate form handles its one conditional item by writing the
condition into the prompt text rather than branching the form -- an experienced
vendor, with no tooling constraint at all, independently choosing constraint
#5's answer. Cite it when conditional checklists are next proposed.

Secondary input to open question 12: actuator serial number reads N/A on all
six valve reports. Any asset-vs-position model must handle a position whose
occupant has no serial identity at all.

Author: mds08011

docs/ROADMAP.md

@@ -465,6 +465,12 @@ gate moves to where ambiguity becomes permanent (ADR 0018 §4).
   lines are unresolved, and the check lands `incomplete` as today. `sign.html`
   and the turnover build surface unresolved lines as the specific blocker,
   linking to the correction check that would clear them.
+- **A note is never an answer.** Result and note are separate fields; prose in
+  the response position is not a response. A line with a note and no result is a
+  **blank** and the gate treats it as one. The source answers several lines with
+  a bare "see notes" and no mark — a cross-reference standing in place of an
+  answer, one of which points at notes that never mention the line. The capture
+  UI structurally cannot produce this shape, which is the point.
 - **Validation.** `na_reason` is **required when `result = "na"`**,
   server-enforced on `check_items`. A check may **not be signed**, and a scope
   may **not be frozen**, while any included line carries a blank result — the
@@ -612,19 +618,30 @@ mid-startup with nothing prompting re-verification.
 **Goal.** Capture what the vendor PDFs took with them when they left, and make
 the package refuse to be compiled with the signature block empty.
 
-### M6.1 — Instrument configuration records (observation 6)
+### M6.1 — Instrument and final-control-element configuration records (observation 6)
 
 The 4–20 mA span, the transmitter range, the delay, the logging interval, the
 setpoints — configured at startup, captured inside a vendor's report, and
 unrecoverable by the time the instrument is replaced.
 
+**Scope widened after the full render of the valve reports**
+([review notes R21](adr/0018-review-notes.md#r21--configuration-data-lives-on-final-control-elements-not-only-instruments--folded-into-adr-0018-8)):
+this covers **final control elements too**, not just transmitters. Every valve
+report in the source records fail position on loss of input signal, function
+(on/off vs modulating), and control/feedback signal types. **Fail position is
+the clearest case for the whole collection** — configured once, recorded only in
+a vendor PDF, the first thing needed at replacement, and wrong answers have
+process consequences rather than paperwork ones.
+
 - **Data model.** New **append-only `instrument_settings`**: `project`, `tag`
   (required), `configured_at`, `configured_by`, `vendor_company` (nullable),
   `input_type`, `range_low` / `range_high` / `range_unit` (the engineering
   range: 0–500 gpm), `signal_low` / `signal_high` / `signal_unit` (the
   electrical span: 4–20 mA), `damping_seconds`, `delay_seconds`,
   `logging_interval`, `setpoints` (text), `firmware_version`, `notes`,
-  `superseded_by` (self-relation, nullable), `client_token`.
+  `superseded_by` (self-relation, nullable), `client_token`; and for final
+  control elements `fail_position`, `control_function`, `control_signal`,
+  `feedback_signal`.
   `updateRule: null`, `deleteRule: null`. **Not** folded into `calibrations`:
   "what is it set to" and "does it read true" are different facts on different
   cadences (ADR 0016 rejected the analogous flattening).
@@ -665,6 +682,21 @@ missing countersignatures before the package was compiled.
   minus roles signed against the current `content_hash`. No stored `signed`
   flag (already rejected by ADR 0010). The app records who signed in what
   capacity; it never adjudicates who was entitled to.
+- **Required roles come from the GC's template, never from the vendor's paper**
+  ([review notes R22](adr/0018-review-notes.md#r22--missing-countersignature-has-two-failure-modes-and-one-has-no-block-to-leave-blank--folded-into-adr-0018-9)).
+  The source has two failure modes: a contractor block **left blank** on one
+  vendor's form, and on another **no such block at all** — it ends at "inspected
+  by". A QC deriving who owes a signature from the attached document would report
+  nothing missing for the second and worse case. The list is computed against the
+  frozen `required_signature_roles`, independent of any attached document.
+- **Print discipline** ([R20](adr/0018-review-notes.md#r20--a-signature-can-sit-on-a-page-that-identifies-nothing--open)).
+  In the source, a signed checklist's signature block sits on **its own page**,
+  carrying a name, a wet signature, a date — and nothing identifying what was
+  signed. Detached from the preceding sheet it attests to nothing. Every page of
+  a printed turnover artifact must therefore carry enough identity (package id,
+  scope, content-hash prefix) that a separated page stays traceable. This is the
+  concrete field justification for ADR 0010's `signed_content_hash`, and it sets
+  a bar the free print view must not regress against.
 - **Turnover.** A **missing-countersignature QC block** computed before the
   freeze is allowed.
 

docs/adr/0018-multi-vendor-startup-evidence-model.md

@@ -14,11 +14,16 @@ No project, company, vendor, or person is identified anywhere in this record.
 **Provenance — read this before trusting the Context section.** This ADR was
 written from a **summary** of those observations. The source package was read
 directly afterwards, on 2026-08-04, and the reading is recorded in
-[`0018-review-notes.md`](0018-review-notes.md). Every observation was confirmed;
-comments **R2, R6, R7, R8 are folded in below**, **R1 reversed a recommendation**
-in this ADR's open questions, and **R3–R5 remain open** for the maintainer. The
-Context section below is left as originally written rather than retrofitted —
-what the ADR knew when, and from what, is itself part of the record.
+[`0018-review-notes.md`](0018-review-notes.md). Every observation was confirmed.
+Four readings have now happened — a summary, a text-layer pass, a corrected
+render pass, and a full render of the valve reports and clean-water checklists.
+Comments **R2, R6, R7, R8, R21 and R22 are folded in below**; **R9–R12 were
+decided** and appear as §§13–14 and §5; **R1 proposed reversing a recommendation
+and was decided against**; **R3–R5 and R13–R20 remain open** for the maintainer.
+The Context section below is left as originally written rather than retrofitted —
+what the ADR knew when, and from what, is itself part of the record. Three of
+its ten bullets are now known to be imprecise in detail while correct in
+substance; the review notes carry the corrections.
 
 ## Context
 
@@ -150,6 +155,16 @@ is to separate the two moments:
 - **`check_items.na_reason`** (text) is **required when `result = "na"`**,
   server-enforced by the `check_items` createRule. "N/A" with no reason is the
   second most ambiguous mark on a paper form.
+- **A note is never an answer**
+  ([R3](0018-review-notes.md#r3--pass-with-exception-is-a-real-answer-the-state-vocabulary-has-no-home-for--open)).
+  A line carries a `result`, and separately may carry a `note`; prose in the
+  response position is not a response. The source answers several lines with a
+  bare **"see notes" and no mark at all** — a cross-reference standing *in place
+  of* an answer, which reads as resolved and is not. Worse, one such pointer
+  **dangles**: the notes it refers to say nothing about that line. So a line with
+  a note and no `result` is a **blank**, and the gate below treats it as one. The
+  capture UI cannot produce this shape (result control and note field are
+  separate), which is the point — the failure is native to paper.
 - **`incomplete` survives, and keeps its meaning** at the check level: a run
   that was started and abandoned. Capture is never blocked — hard constraint #1
   means a laborer on a dead-zone phone must always be able to submit what they
@@ -334,13 +349,23 @@ which a naive numeric parse would read as a single value — a concrete case for
 the §7 rule that an unparseable reading derives nothing and the tech's explicit
 result stands.)
 
-### 8. Instrument configuration is its own append-only ledger
+### 8. Configuration is its own append-only ledger — instruments **and final control elements**
 
 Configured settings are neither a calibration nor a checklist. A calibration
 (ADR 0016) asks "does it read true?" — configuration asks "what is it set to?"
 They change on different schedules and for different reasons; folding settings
 into `calibration_points` would misrepresent both.
 
+**Scope covers final control elements, not only transmitters**
+([R21](0018-review-notes.md#r21--configuration-data-lives-on-final-control-elements-not-only-instruments--folded-into-adr-0018-8)).
+Every valve report in the source captures the same class of fact on an
+actuator — fail position on loss of input signal, function, control-signal type,
+feedback-signal type. **Fail position is the single clearest case for this whole
+collection**: configured once, recorded only in a vendor PDF, first thing anyone
+needs when the actuator is replaced, and getting it wrong has process
+consequences rather than paperwork ones. The collection keeps the name
+`instrument_settings` — a tag is a tag and the record shape does not differ.
+
 New append-only collection **`instrument_settings`**:
 
 `project` · `tag` (required) · `configured_at` · `configured_by` ·
@@ -350,7 +375,10 @@ New append-only collection **`instrument_settings`**:
 `signal_low` / `signal_high` / `signal_unit` (the electrical span: 4–20 mA) ·
 `damping_seconds` · `delay_seconds` · `logging_interval` ·
 `setpoints` (text: the human list) · `firmware_version` · `notes` ·
-`superseded_by` (self-relation, nullable) · `client_token` (idempotent retry).
+`superseded_by` (self-relation, nullable) · `client_token` (idempotent retry) ·
+and for final control elements: `fail_position` (e.g. `close` / `open` /
+`last`) · `control_function` (`on_off` / `modulating`) ·
+`control_signal` · `feedback_signal`.
 
 `updateRule: null`, `deleteRule: null`. A reconfiguration is a **new record**
 that the prior may point at via `superseded_by`; the **current settings are
@@ -376,6 +404,15 @@ answered.
   the check** at execution (`checks.required_signature_roles`), exactly like
   `witness_required` already does (ADR 0002). A template edited later must not
   change what a signed check required.
+- **Required roles come from the GC's template, never from the vendor's paper**
+  ([R22](0018-review-notes.md#r22--missing-countersignature-has-two-failure-modes-and-one-has-no-block-to-leave-blank--folded-into-adr-0018-9)).
+  The source shows two failure modes, not one: a contractor block **left blank**
+  on one vendor's form, and on another vendor's form **no such block at all** —
+  it ends at "inspected by" and never contemplated a countersignature. A QC that
+  derived "who still owes a signature" from what the attached document contains
+  would report nothing missing for the second case, which is the worse one. The
+  missing-countersignature list is therefore computed against the frozen
+  `required_signature_roles` **independently of any attached vendor document**.
 - `signatures.signer_role` gains `vendor_tech`, `subcontractor`,
   `gc_witness`, and `controls_integrator` alongside the existing vocabulary.
 - **Witnessing becomes a role, not a text field.** `checks.witnessed_by` stays