ADR-0088: Verification Evidence Classes — Planned vs. Verified, Derived at the Read Layer¶
- Status: accepted (Nicolas 2026-07-21, design session D6 "tend to agree" + session close "sounds right"; the classifier refinement in §2 is a coordinator correction found while drafting — flagged to Nicolas the same day)
- Date: 2026-07-21
- Deciders: Nicolas Burri, design by Claude. Origin: his colleague's question ("a test plan is verifying only if it is actually executed") and the appointment-vs-event analysis.
- Refines: ADR-0077 §6 / its 2026-07-19 clarification §4 (coverage evidence), ADR-0086 (chains + report roll-ups), ADR-0079 (the risk verification hop). Rides the ADR-0085 consolidation wave.
Context¶
A verifies link is authored like an appointment ("this artifact is the designated
verification") but the word reads like an event ("this has been verified"). The derived views
conflated the two: a link from an approved plan counted identically to one from an executed
test report. "Planned but never executed" — the audit question — was invisible.
Decision¶
- Evidence classes are DERIVED at the read layer only. No link-type change, no migration of
links, no new authoring act. An inbound
verifieslink classifies as: - verified — its source document's type carries the
verification_evidenceflag (§2) AND the source version is RELEASED (a released report is the recorded event); - planned — every other
verifieslink (plan-type sources, and evidence-type sources not yet released: a draft report is not evidence). - The classifier is a per-document-type flag
verification_evidence(additive migration, default false).
Correction, 2026-08-19 (Nicolas). As accepted, this clause read "governed on the scope-config type surface exactly like
may_define_*", and it was implemented that way. The analogy was the defect: themay_define_*flags live on the per-(scope, type)type_activationrow, whileverification_evidenceis a column of the installation-widedocument_typerow. Gating an installation-wide write onACTIVATE_CATALOG_ENTRIESin the caller's scope — a permission the content role Quality Manager holds per project — therefore let one project change what counts as VERIFIED in every tenant's coverage matrix, GSPR view and exported audit PDF, with the audit row anchored in the caller's trail so the affected tenants recorded nothing (2026-08-18 review, module-arc register, catalog). The flag is now governed like every other global-catalog mutation:MANAGE_CATALOGeffective at GLOBAL, auditedVERIFICATION_EVIDENCE_SETat GLOBAL, written throughPUT /api/admin/document-types/{documentTypeId}/verification-evidence(the per-scope path is retired — a breaking wire change, permitted pre-1.0 by ADR-0090 §4). Nothing else in this ADR changes: the classifier, the derivation and the surfaces are exactly as decided; only WHO may set the flag, and where the act is recorded. The per-scope Document-types tab still SHOWS the flag. NOT the document CATEGORY: while drafting, the category shortcut proposed in the session was checked against the real corpus and found WRONG — PULSEMED'sVERPLANis category RECORD (every development artifact imported as a record) yet is semantically a plan; category-based classing would have called its links "verified". A type-level flag is one boolean at a variation point the corpus itself proves, with zero per-link burden. 3. Surfaces (uniform): coverage evidence labels split ("planned ×N · verified ×N" — thecoveredverdict itself is unchanged: any inbound verifies OR satisfies); the chain roll-upfullyVerifiednow requires ≥1 verified-class evidence per satisfying software requirement, and chains gain the intermediate flagVERIFICATION_PLANNED_ONLY(betweenSATISFIED_UNVERIFIEDand clean); the risk view's "control not verified" gap keeps firing on ZERO verifies links, and a planned-only verification renders as "planned" rather than a green verified; the ADR-0087 report digest counts the two classes separately. 4. Evidence dates join the read models: wherever verified-class evidence renders (chains, annex, report), the evidence record's release date rides along — a 2025 report backing a 2026 audit is visible at a glance. Freshness stays human judgment here. 5. Freshness as a RULE ("verified within N days") is deliberately NOT built — registered with its structural home: an ADR-0089 recurring obligation optionally tied to the verified item derives OVERDUE exactly like periodic review; a rule-kind variant converges with the registered "coverage as a configurable rule kind" follow-up. Re-entry trigger: the first real recurring-verification process (the backup rehearsals; October-audit prep).
Consequences¶
- Additive migration (the type flag) + read-layer derivation changes; DTOs additive (evidence class + date fields); seed/importer set the flag on genuinely report-like types.
- The seeded SAMPLE corpus currently verifies via its Verification Plan — with honest classing its full chain reads "planned only". The seed gains a small released Verification Report record so the teaching corpus keeps one genuinely green chain alongside the gap stories.
- Suspect semantics unchanged and orthogonal (change-triggered staleness is already covered).