The framework: sign the diff, not the anecdote

0 · The loop, end to end

Contrast with Part 1's as-is loop: the eleven steps collapse to six; the manual translation step (a prose comment re-keyed into a tracker) becomes the agent's assessment; the writer's re-copying of numbers into in-text tables disappears entirely, because the bindings re-resolve mechanically; and the audit trail is not a reconciliation report bolted on afterwards — it is the version history.

1 · The change request is a versioned artifact

Part 1's central negative finding: in every incumbent tool the request lives in a comment thread that dies at “resolved.” Here it is a file, in the repo, with a lifecycle.

# requests/CR-012.yaml
id: CR-012
state: in_review              # derived — see §6
requested_by: "@medical-writer"
requested_at: 2026-08-14T15:02:00Z
context:                      # captured by the composer, not typed
  display: t-ae-overview
  iteration_at_request: v003
  e3_section: "12.2.1"
  binding: "t-ae-overview:any_ae:p;group=Xanomeline High Dose"
request_text: >
  Split the AE overview by baseline severity so the high-dose
  imbalance in severe events is visible in the main table.
assessment:                   # agent-written, human-checkable
  tier: A                     # P | A | N | D — verified by CI, §2
  reason: DATA DRIVEN         # ARS AnalysisReasonEnum vocabulary
  interpretation: add AESEV as a second grouping level to any_ae and by_soc_pt
  acceptance_criteria:
    - severity levels appear as nested rows under each arm column
    - subject denominators unchanged from v003
  assumptions:
    - AESEV is populated for all treatment-emergent AEs in adae
  sap_consistency: post-hoc   # triggers the E3 §9.8 note, §2
  provenance: { model: claude-fable-5, prompt_hash: "sha256:…" }
disposition:                  # filled as the loop advances
  pr: 41
  result_iteration: t-ae-overview/v004

Three properties do the work. The verbatim request is preserved — the writer's words, not the agent's paraphrase, are the record (the pattern GitHub's suggested-changes provenance uses: proposer and applier both credited). The context is captured, not typed — the composer knows which display, which iteration, which sentence the writer was looking at, which kills the “which table did they mean” ambiguity that plagues comment logs. The rationale is a merge precondition — a CR with an empty assessment cannot merge (GitBook's merge-rules pattern), which produces the change-control record regulators expect as a side effect of using the system. The iteration ledger already reserved a change-request field (D10); every display version now answers “why do you exist” with a CR id.

GitHub retains its audit log ~90 days — far short of record-retention needs. The CR record and ledger are the durable, committed export of the same facts; the platform's log is corroboration, never the system of record.

2 · The review tier is determined by the computed diff, not the request text

The industry already runs two-tier governance — a signed SAP for analysis semantics, unsigned shells for presentation (Part 1 §4). The framework makes that asymmetry mechanical, and machine-verifiable.

The agent claims the tier; CI verifies it. A PR labelled Tier P whose regenerated ARD hash moved fails the build — the same shape as Terraform's plan/apply discipline, where the reviewer approves the computed plan, and HCP Terraform's mandatory-vs-advisory check split: denominator and population changes block, formatting nits warn. The ITIL standard-change idea applies directly: Tier P is a pre-approved change class precisely because the system can prove nothing statistical happened.

The post-hoc rule is encoded, not remembered. EMA's reflection paper §2.3.3.3 states that after database lock, non-prespecified modifications make results post hoc, and model changes require a SAP amendment. The framework enforces this mechanically: every Tier A/N change carries an AnalysisReasonEnum value; a DATA DRIVEN change auto-drafts a generated-tier text block for E3 §9.8 (“Changes in the Planned Analyses”) — bound to the CR id, entering the same approval gate as every generated block (D8). ICH E3 reserved that section in 1995; the loop fills it as a build artifact instead of an end-of-study archaeology exercise. The CR's verbatim request, timestamps and reviewer identities are simultaneously the defense against the “changed the SAP because you saw the data” charge — the change is disclosed, attributed and signed at the moment it happens.

3 · Version or fork: the writer's intent, applied as a rule

D10 gives every display an iteration ledger. The only new question is when a change is a new version and when it is a new display.

• Version (vNNN+1) — same analytical question, revised answer or presentation. The draft replaces the current iteration on approval. This is the default.
• Fork (new slug) — a different or additional question, or the original must remain in the document: t-ae-overview--by-severity, directory of its own, forked_from: t-ae-overview@v003 in the manifest, its own assembly slot. Both render until an editorial decision retires one (open question D-CR3). Forks are for comparison and coexistence; versions are for succession — the Sanity/Figma lesson is that long-lived divergence is the failure mode, so fork sparingly and record lineage always.
• Not a fork: in-text vs post-text variants stay what they are — two renderings of one ARD (D6). A cross-display atomic change (one CR touching several displays plus prose) is a single branch/PR, not several forks.

4 · The draft lives in the document, honestly

Jeremy's requirement: the new draft display is inserted into the document for review. The three-tier Pages preview system shipped in v0.2 makes this nearly free.

• On the PR branch, assembly points the slot at the draft iteration; the pr/{N}/ preview renders the full document with the draft display in place, watermarked with version, CR id and pending-sign-off state. Root and dev tiers keep serving the approved document — tier semantics already established.
• The draft state lives in the artifact: the iteration manifest carries approval: {state: draft}, exactly parallel to text blocks (D8). The assembler's existing gate generalizes: an unapproved display iteration can render only watermarked, only in previews — the same “draft is a lifecycle state, not a failure” convention the text layer established.
• Staleness guard (Atlantis's undiverged): promotion re-verifies that the reviewed ARD reproduces — same spec hash, same data manifest — before current.json flips. If dev moved underneath (data prep changed, upstream spec merged), the approval is void and the pipeline re-plans. Approvals bind to {spec_hash, ard_hash} and die when either moves (GitLab's reset-approvals-by-patch-id, made value-aware).
• The Reader closes the discovery loop: displays with open CRs show a chip linking to the preview — a reviewer arriving from the document always finds the revision in flight.

5 · Dual sign-off: each role signs its own competency

Jeremy's flow ends “requests review/sign-off from the biostatistician.” The framework adds the symmetric half the closed loop makes possible — and the incumbents make impossible.

• The biostatistician signs the ARD diff — rows added, removed, changed; denominators and populations named; rendered before/after beside it. The diff engine is cards::compare_ard() (0.8.0, experimental — wrapped and pinned), presented Datafold-style: a summary comment on the PR, drill-down to the value-level diff page in the preview. Path-scoped review requirements make this non-optional: library/tfl/**/analysis.yaml and custom.R require statistical approval (CODEOWNERS + the ruleset required-reviewer rule, GA Feb 2026); display.yaml-only diffs route lighter.
• The medical writer signs the binding impact report — every sentence whose rendered value changed between iterations, listed with before/after. The fidelity gate (D7) already catches orphaned bindings loudly; the impact report catches the quieter case — a binding that still resolves but to a different number. The writer who asked for the change confirms the prose still says what the study shows. No incumbent can produce this list, because no incumbent knows which sentences quote which cells.
• Identity rules, borrowed from the systems that learned them the hard way: the requester cannot be the final approver; the agent proposes and never approves (the Copilot precedent — its review is always a comment, never an approval); bot identities do not satisfy review requirements. Two humans close every Tier A loop.
• Part 11 honesty. A GitHub PR approval is an audit trail, not an electronic signature — §11.50 requires the signed record to carry the signature's meaning, §11.200 requires re-authentication, and no GitHub-native mechanism provides either (GitLab's re-auth-to-approve is the only git-native precedent that explicitly cites Part 11). The framework's v1 posture is stated, not fudged: approvals are recorded, attributed, meaning-bearing entries in the committed ledger (“statistical review and approval of iteration v004 against CR-012”), synchronized from PR events; a validated e-signature layer is the study-level platform's job (§12 deferral), and the ledger is designed so that layer can adopt it without rework. This mirrors where sign-off actually lives today: QC checklists and tracker columns, now versioned and attributable.
• Regulatory placement, by construction. The agent edits specs and drafts prose; every number is computed by the deterministic, tested pipeline. That keeps the AI on the “operational efficiency” side of FDA's draft-guidance scope line — it never generates evidence — while the dual human sign-off implements EMA §2.3.5's “close human supervision” and “quality review mechanisms” as workflow, and human editorial review is precisely the EU AI Act Art. 50(4) discharging control.

6 · The lifecycle, derived — never parallel

Decap CMS's documented failure is the cautionary tale: an editorial state machine that can disagree with the VCS approval it mirrors. Here the CR's state is computed from git and PR facts, not stored beside them.

Every transition is a commit or a PR event; the audit trail is the version history (D9). A dashboard can render the CR queue — the open.csr equivalent of the reconciliation report, except it also knows what happened after each comment.

7 · Delivery increments

Five increments, each shippable and demonstrable on its own, ordered so the writer-facing surface lands first and the platform-dependent pieces land last.

Increment 2 is where a design question from §13 gets settled by adjacency: the browser editor deliberately did not attempt the regeneration round-trip for spec edits. The agent lane is that round-trip — run server-side by CI on a branch, where R exists — which is why the composer (increment 1) never needs webR to be honest: it produces a request, not a result.

8 · Credit where due: the borrowed mechanics

And one deliberate non-borrowing: no incumbent's in-app sign-off is imitated. The §12 deferral stands — status is data, surfaced in the UX; the study-level platform owns roles and e-signature when it exists. Nothing in this framework preempts it; everything in this framework feeds it.

9 · Open questions for review