Taleef7 · Taleef7 · Sep 20, 2026 · Sep 20, 2026 · Sep 20, 2026
@@ -127,19 +127,25 @@ retelling. Naming policy: repo documents say "Maui" and "the pilot group" only.
   real blood pressures profile-stamped at ingest before real data (issue #533's ingest half); cms137
   stays routed unless the final rule removes Quality ID 305. An out-of-population official outcome no
   longer opens a case (ADR-078 d2). Read `docs/JOURNAL.md` for the newest entries, not this line.
-- MM-2/3/4 are blocked on externals (ROADMAP §7). The milestones deliver a **sandbox**; the pilot's
-  production/PHI phase is a separate `PRODUCTION_READINESS`-gated decision nothing in M-M authorizes.
+- **MM-2's build is COMPLETE** (#550/#551/#555/#573/#574) and **MM-3's design half shipped** (#569,
+  ADR-083); MM-3's *wiring* and **MM-4** are blocked on externals (ROADMAP §7). This line said all three
+  were blocked until 2026-09-20, which was false for MM-2 from 2026-09-12 on. The milestones deliver a
+  **sandbox**; the pilot's production/PHI phase is a separate `PRODUCTION_READINESS`-gated decision
+  nothing in M-M authorizes.
 - M-C (packaging) is complete and published; M-E1 (occupational content) is deferred behind M-M, not
   cancelled (locked decision 6). Open threads live in the newest JOURNAL entry's "still owner-owned"
   line and in GitHub issues, not here.
 
 ## Standing corrections
 Each is a claim the project got wrong once and would otherwise repeat.
-1. **The CMS FHIR-reporting timeline is CMS-attributable but PROPOSED.** The CY2027 PFS proposed rule
-   (CMS-1848-P, July 2026) *seeks comment on* a two-year transition — FHIR reporting voluntary
-   PY2028–29, mandatory PY2030 for applicable APP Plus measures, MIPS CQMs sunsetting ~PY2030. Cite it
-   as proposed/under comment, **never as final** (final rule ~Nov 2026). The same rule proposes removing
-   Quality IDs 305 (CMS137) and 493 from APP Plus for PY2027.
+1. **The CMS FHIR-reporting timeline is CMS-attributable, and it is an RFI — weaker than a proposal.**
+   The CY2027 PFS rule (CMS-1848-P, July 2026) *seeks comment on* a two-year transition — FHIR reporting
+   voluntary PY2028–29, mandatory PY2030 for applicable APP Plus measures. Cite it as **sought comment
+   on**, never as proposed and never as final (final rule ~Nov 2026). **Two things this entry itself got
+   wrong, corrected 2026-09-20 from the 2026-09-07 review:** MIPS CQMs are proposed to be **EXTENDED**
+   for PY2027+, not "sunsetting ~PY2030" as this line read; and the separate proposal to sunset
+   **traditional MIPS as a reporting option** after PY2028 is a *different* policy — do not merge the
+   two. The same rule proposes removing Quality IDs 305 (CMS137) and 493 from APP Plus for PY2027.
 2. **"QI-Core STU7 = US Core 7 = WebChart's exact surface" is half right.** The equality holds, but
    **CMS's shipping content is authored on QI-Core 6**, and the direction of travel is US Quality Core
    0.5.0 over US Core 6.1.0.

@@ -22,9 +22,11 @@ it the surface where the non-negotiable rule matters most. Three consequences, a
 - **`systemActions` is never emitted.** In CDS Hooks it is the array a client auto-applies with no user
   interaction. Nothing WorkWell returns may change a chart without a human choosing it, which is the
   human-in-the-loop contract of §7 applied to an outbound integration.
-- **`critical` is never emitted**, and is unrepresentable in the card type. It means *the user must not
-  proceed*; WorkWell is supplementary to WebChart and is not entitled to say that about someone else's
-  encounter.
+- **`critical` is never emitted**, and is unrepresentable in the card type. **What the spec actually
+  says (corrected 2026-09-20):** CDS Hooks 2.0 defines `critical` only as the top of an urgency ordering
+  — `info` < `warning` < `critical` — **not** as "the user must not proceed", which is what this file
+  asserted until now. The refusal is unchanged and rests on its own ground: WorkWell is supplementary to
+  WebChart and is not entitled to raise the loudest available signal inside someone else's encounter.
 
 A card `suggestion` is a *proposal* — a `ServiceRequest` with `intent=proposal`, `status=draft`, offered only
 where the order code carries an APPROVED terminology mapping, and accepted only by a clinician's explicit

@@ -134,7 +134,12 @@ Deployment profile model: `WORKWELL_INSTANCE` selects which tenants are visible,
 1. Author updates CQL text in Studio.
 2. Compile API runs translator validation.
 3. Compile result persisted in `measure_versions.compile_status` + `compile_result`.
-4. Activation is blocked unless compile gate and test-fixture gate pass.
+4. Activation is blocked unless the compile gate and the test-fixture gate pass. **The test-fixture
+   gate is a STRUCTURAL check and does not execute the measure** — `validateTests`
+   (`backend-ts/src/measure/measure-read-models.ts`) asserts that fixtures exist and that each names a
+   fixture, a subject and an expected outcome. Studio's ✅ on that row therefore means *the fixtures are
+   well-formed*, not *the fixtures were run and passed*. This line read as if it executed them until
+   2026-09-20; the Studio label itself still overstates and is tracked separately.
 
 ### 5.3 CQL -> Run
 1. User triggers a scoped manual run (`/api/runs/manual`) or a case rerun using the shared CASE path.

@@ -327,7 +327,7 @@ Supports filters: `status`, `measureId`, `priority`, `assignee`, `site`, `caseId
 > reading by position keeps every column it had — the same rule ADR-079's `notInPopulation` followed.
 > Both are DIRECTORY facts resolved at export time, so both are EMPTY on a deployment whose roster
 > records none: the occupational directory has never carried a payer, and the live WebChart directory
-> discards Coverage until #533's ingest work lands. `payer` is a Source of Payment Typology code, the
+> discards Coverage until the WebChart ingest work lands (**#591**; #533 closed 2026-09-08 with that half unshipped). `payer` is a Source of Payment Typology code, the
 > same vocabulary the measures' `SDE Payer` reads.
 
 > **The payer filter is a SET, and that is not cosmetic.** `?payer=` accepts a repeated parameter or a

@@ -702,7 +702,8 @@ Eight days before the pilot group's quality lead was told the sandbox held her A
 showed two. cms2, cms130, cms165 and cms137 were vendored, MADiE-gated (36/36, 64/64, 68/68, 45/45),
 runnable under ADR-072, and unrouted, each waiting on a sequenced precondition: cms2's seven
 cross-engine disagreements (diagnosed 2026-09-07, #538), cms130's sweep (63/64, #539), cms137's flip
-after those two and after the final rule on Quality ID 305, and cms165's WebChart ingest half (#533).
+after those two and after the final rule on Quality ID 305, and cms165's WebChart ingest half (**#591**,
+formerly #533's).
 The owner's priority is every measure the pilot group sent us working and visible in the sandbox, and
 the sandbox evaluates a generated corpus, not WebChart data.
 
@@ -732,7 +733,7 @@ been the whole worklist.
    the sandbox unless the final rule removes 305, at which point it is un-routed by the same workflow
    edit. cms165 runs on the corpus's stamped profiles (ADR-076 d1, #539); before real data it needs
    every QI-Core profile it retrieves stamped at ingest and WebChart's BP status to arrive final
-   (#533). Neither is a sandbox blocker, and both are written into the PHI readiness gate.
+   (**#591**, formerly #533's). Neither is a sandbox blocker, and both are written into the PHI readiness gate.
 
 ### Consequences
 
@@ -926,7 +927,8 @@ in the store's own docstring so it is not attempted again.
 
 ### Consequences
 
-- cms165 still must NOT be routed (issue #533 stays open for the ingest-side stamping), and this is
+- cms165 still must NOT be routed over WebChart data (**#591** tracks the ingest-side stamping; #533 closed
+  2026-09-08 with that half unshipped), and this is
   now the reason rather than a blanket one: the measure is scoreable, our corpus can score it, real
   WebChart data cannot yet.
 - CMS2's seven cross-engine disagreements have a cause (`docs/evidence/CROSS_ENGINE_2026-09-07_CMS2.md`),

@@ -317,7 +317,7 @@ Per measure, per stack:
 > its retrieves name, and since #539 `prepareForQiCore` stamps `us-core-blood-pressure` from a
 > resource's own codes. That is what lets the sandbox route it (ADR-078). It is NOT sufficient for
 > WebChart data: the other QI-Core profiles must arrive stamped at ingest, and WebChart exports BP panels
-> with `status: "unknown"` (issue #533's open half). A green gate over the corpus says nothing about that.
+> with `status: "unknown"` (**#591**, formerly #533's open half). A green gate over the corpus says nothing about that.
 >
 > **The credentialed gate runs in CI:** `.github/workflows/flip-gate.yml` (manual) vendors the measure's
 > sidecar with the VSAC secret, sweeps the Maui roster, and uploads `.flip-gate/<id>-<date>.json`.

@@ -78,7 +78,7 @@ is **362 of 387 across eight measures**, CMS165 deliberately excluded.
 > `trustMetaProfile` is now decided PER MEASURE and cms165 is the only measure that sets it (ADR-076 d1);
 > the default stays false because trusting profiles globally empties cms122's and cms125's populations,
 > and those are routed. That is possible because the ADR-075 corpus stamps the profile each retrieve
-> names. **It does not make cms165 routable, and #533's ingest half is still open.** On 2026-09-07
+> names. **It does not make cms165 routable, and the ingest half is still open (#591; #533 closed 2026-09-08 with that half unshipped).** On 2026-09-07
 > `prepareForQiCore` began deriving `us-core-blood-pressure` from codes a resource already carries —
 > one necessary piece, and the one no other layer can supply, since only the codes say what a resource
 > IS. It is nowhere near sufficient: `trustMetaProfile: true` filters EVERY profile-typed retrieve on
@@ -92,7 +92,7 @@ is **362 of 387 across eight measures**, CMS165 deliberately excluded.
 > rerun-to-verify would quietly return MISSING_DATA. Better than a plausible wrong number, and not a
 > guarantee. **cms165 is routed on the SANDBOX since 2026-09-08 (ADR-078)** — it runs there because the
 > corpus stamps every profile it retrieves and #539 stamps a blood pressure from its own codes — and
-> **must not be routed over WebChart data** until the ingest half of #533 (every QI-Core profile stamped
+> **must not be routed over WebChart data** until the ingest half (#591, formerly #533's; every QI-Core profile stamped
 > at ingest, BP status arriving final) is closed. That condition now sits in the PHI readiness gate.
 
 **An officially routed measure is scored over the calendar year** containing the evaluation date, not a

@@ -46,8 +46,14 @@ report). Its EMR-reported clinical half, decoded from MIPS quality IDs to the eC
 > substance-use-disorder volume, so it is not a measure their workflow produces data for. That is
 > independent of CMS-1848-P: even if the final rule keeps 305 in APP Plus, the pilot has no existing
 > practice to compute it from. **MM-1a's expected outcome is therefore "cancelled, not deferred"** — the
-> ACO/final-rule confirmation is now a formality to record rather than a fork the plan waits on. Nothing
+> ACO/final-rule confirmation is a record to obtain rather than a fork the plan waits on. Nothing
 > is promised on CMS137 either way until it is confirmed (ADR-047's gate precondition is unchanged).
+>
+> **This paragraph called that confirmation "a formality"; corrected 2026-09-20** (the 2026-09-07
+> review's B-3, accepted then and not applied until now). It is not a formality: the sandbox ROUTES
+> CMS137 today (ADR-078), so the final rule decides whether the PHI phase inherits a measure the pilot
+> has little data to compute, or whether the routing comes out. The *plan* does not wait on it; the
+> *answer* is not foregone.
 
 > **Amendment (2026-08-31): MIPS is a SEPARATE reporting obligation, not a naming convention.** The pilot
 > must report MIPS **as a group, outside the ACO**, in addition to its APP Plus participation. Two
@@ -275,7 +281,8 @@ any config surface added; the standard idempotency/audit invariants on anything
   > **SINCE 2026-09-08 (ADR-078):** the owner routed all six measures on the sandbox, so MM-1c's
   > per-measure gating describes what was DONE for the sandbox flip and now governs the PHI phase
   > instead. cms2's mismatches were diagnosed, cms130 and cms165 were swept; what remains open is #532
-  > (cms165's 11/68 cross-engine disagreements, undiagnosed) and #533's ingest half.
+  > (cms165's 11/68 cross-engine disagreements, undiagnosed) and the ingest half, now **#591** (#533 closed
+  > 2026-09-08 with it unshipped).
 - **MM-1d (PY2027 — a QI-Core 6→7 MIGRATION, not a re-vendor):** every vendored artifact currently
   declares `effectivePeriod` 2026-01-01..2026-12-31 and the runtime does not check it (§1.1). **Re-checked
   2026-09-14 and re-sized: the FHIR content does not exist yet, and when it arrives it is a profile
@@ -417,7 +424,7 @@ it removes none. The MADiE gate remains the routing precondition for every measu
 | 4 | Exception/exclusion documentation guidance (which forms clinicians use) | Nicole consultation | MM-3 specifics |
 | 5 | ~~ACO answers: attribution basis, reporting mechanism, reporting cadence~~ — **ANSWERED at the 2026-09-09 ACO working session, recorded here 2026-09-15.** Reporting is at the **ACO level under APP Plus**; the pilot group becomes a **MIPS APM** through it; the workflows are **eCQM-only** (the claims-based and survey measures are computed for them, not by them); **PY2027 is reported in 2028**. The mechanic that matters to us: **the mechanism is chosen PER MEASURE and must be agreed by both participants** — the ACO computes each measure under every mechanism available to it, compares the results against the benchmarks, and takes the best. So eCQM numbers have to be available **early** and in a shape that supports a per-measure comparison, which is a product requirement and not just a reporting detail. **Still open from the same session:** the four #557 inputs (identifier format, cadence, non-match handling, whether Medicare Advantage is in or out) and the ACO's own prioritised report list, promised on the call and not received by 2026-09-15. | ACO | #557's semantics; reporting scope |
 | 6 | CY2027 **final** rule (~Nov 2026) — reconfirm APP Plus mechanics **and measure 305's fate** (CMS-1848-P proposes removing 305 and 493); same rule as the standing FHIR-timeline correction | CMS | MM-1a/MM-1e; reporting-mechanics claims |
-| 7 | ~~Pilot measure-set confirmation after the ACO finalizes~~ — **CONFIRMED at the 2026-09-09 session and against the pilot's PY2027 measure sheet.** The six ACO-reported measures reconcile **one for one** with what the sandbox routes: 001/CMS122, 134/CMS2, 236/CMS165, 112/CMS125, 113/CMS130, 305/CMS137 — all vendored, MADiE-gated and routed (ADR-078). The sheet's other three (479 HWR, 484 MCC, 321 CAHPS) are claims- or survey-calculated and correctly out of scope. The sheet carries **no targets, benchmarks, deadlines or mechanism**, so it confirms the set and nothing else. CMS137 still depends on 305 surviving the final rule (item 6) and cms165 is sandbox-only until #533's ingest half. | ~~Pilot group / ACO~~ | ~~MM-1 completeness~~ — nothing |
+| 7 | ~~Pilot measure-set confirmation after the ACO finalizes~~ — **CONFIRMED at the 2026-09-09 session and against the pilot's PY2027 measure sheet.** The six ACO-reported measures reconcile **one for one** with what the sandbox routes: 001/CMS122, 134/CMS2, 236/CMS165, 112/CMS125, 113/CMS130, 305/CMS137 — all vendored, MADiE-gated and routed (ADR-078). The sheet's other three (479 HWR, 484 MCC, 321 CAHPS) are claims- or survey-calculated and correctly out of scope. The sheet carries **no targets, benchmarks, deadlines or mechanism**, so it confirms the set and nothing else. CMS137 still depends on 305 surviving the final rule (item 6) and cms165 is sandbox-only until the ingest half (**#591**, formerly #533's). | ~~Pilot group / ACO~~ | ~~MM-1 completeness~~ — nothing |
 | 8 | CDS Hooks client auth answer: does WebChart act as a CDS Hooks client; its `iss` + JWKS URL (ADR-067's named gap) | MIE joint call | MM-4 |
 | 9 | **PY2027 official artifacts — and MM-1d is bigger than "re-vendor" (re-checked 2026-09-14).** Two different publications, and only one has happened. The PY2027 **QDM/HQMF** specifications WERE published by CMS on **2026-05-14** — that is what the pilot's measure sheet means when it says clinical measure specifications are available for 2027. The **FHIR** content WorkWell actually executes has **not** landed: `cqframework/dqm-content-qicore-2026` exists but holds only draft examples (a breast-cancer-screening draft, stratification examples), on **QI-Core 7.0.2**, with **no release tag**, **no `bundles/` directory**, and **none of the six measures** in `input/cql` or `input/resources/measure`. Consequences: the `effectivePeriod` 2026-only warning keeps firing through all of 2027, and when the content does land this is a **QI-Core 6 → 7 migration** (our shipping content is authored on QI-Core 6 — CLAUDE.md standing correction 2) with a full MADiE re-gate per measure, not the refresh this row used to imply. Re-check for a release tag before assuming it is still blocked. | CMS / eCQI publication | MM-1d |
 | 10 | **The payer-driven measures (added 2026-08-31).** Beyond the ACO's set, the pilot has measures individual health plans require — specific insurers want specific things worked — and those must be in the system too. Which measures, for which payers, and whether any is a published eCQM is entirely unknown. | Pilot group | scoping only — no milestone depends on it yet |

@@ -37,7 +37,13 @@ What WorkWell emits across the eCQM toolchain, and the conformance level of each
 
 > **This section exists to stop the verification language above from carrying over by association.**
 > Everything else in this document describes measures graded against somebody else's answer key.
-> Occupational measures have no answer key, and cannot acquire one.
+> Occupational measures **have** no answer key.
+>
+> **"and cannot acquire one" was removed 2026-09-20** — it was stronger than anything we can support.
+> A route exists and has been named on the record: a steward could publish specifications and expected
+> results (the NCQA process MIE's quality lead described on 2026-07-24), or an independent
+> implementation could be built for ours to disagree with. Neither exists today and neither is in
+> progress, which is the claim that actually holds: **nothing in this repo is graded by anyone but us.**
 
 | | Official CMS eCQMs (M-A) | CQL engine (M-C) | **Authored OSHA measures (M-E1)** |
 |---|---|---|---|