ADR 0016: SOP version binding, QMS authority and impact runs

Status: Accepted
Date: 2026-09-14
Deciders: Founder

Context

Phase 1 modelled an SOP as a local record with an integer version and an approve route, and a check bound to the SOP, not to a version. Controlled SOPs live in the QMS with major.minor versions, configurable lifecycle states and effective dates; inspection questions are “which version applied when the work was done” and “who accepted the requirement set the check used”.

Decision

sop_versions mirrors each QMS version (major, minor, lifecycle state mapped per connection, effective_at, effective_on_observed, superseded_at, rendition hash, document). The QMS is authoritative for content and state; Trovensa’s SOP approve route applies to local SOPs only (sop_external otherwise).
Requirement sets are agent-proposed ({code, text, page, paragraph, chunk_id, modality, role, evidence_expectation}) and become usable only after QA acceptance with a decision signature.
A check binds to the version effective at the target’s reference time by default (binding_rule = auto) or to a named version with a required binding_reason (manual); the binding, requirements hash, check-logic version and agent version are stored on the check, and a different triple creates a new check with supersedes_check_id.
A new effective version triggers review_extract_requirements and review_sop_impact, which lists bound open checks and drafts and targets modified inside the observation gap, and proposes a re-check batch.

Consequences

CheckCreate gains optional sop_version_id and binding_reason; CheckOut exposes the binding; checks.target_type gains eln_entry.
QMS polling uses ALLVERSIONS with a 15-minute delta and nightly reconciliation; lifecycle labels are read and mapped per connection, never hard-coded.

Alternatives considered

Trovensa approves SOPs: two approval systems for one document; rejected.
Bind checks to the SOP only: cannot answer which version applied; rejected.
Automatic requirement use without acceptance: agent-generated requirements would drive findings unreviewed; rejected.

Follow-ups

Training-record checks against QMS objects once object names are verified on a partner tenant.