A granted waiver is never projected into an evaluated bundle, so an authored measure's exception path is shape-only

Start with fhir-bundle-builder.ts, measure-bindings.ts, admin/waivers.ts, and the evaluation path used by planCaseUpsert. Trace how active, unexpired waiver rows can become Conditions for the matching measure, then add tests for granted, expired, and measure-specific waivers; done means the next run changes only the intended outcome and the admin header is accurate.

Named in ADR-083 d2. The ADR's finding, filed so it is not mistaken for something that works.

What is true today

An authored measure reads its exception the right way round: the CQL asks for a coded FHIR Condition, and WorkWell supplies data rather than a verdict. audiogram.cql has

define "Has Active Waiver":
  exists([Condition] C where exists(C.code.coding x
    where x.system = 'urn:workwell:vs:audiogram-waiver' and x.code = 'audiogram-waiver'))

and measure-bindings.ts carries the per-measure waiver (and for mmr a separate refusal) code/value-set pair.

What is NOT true

Nothing turns a granted waiver into that Condition. The waivers table is record-keeping and admin/waivers.ts says so in its own header: "Granting a waiver is a record-keeping action here (the synthetic evaluation engine derives EXCLUDED from its seeded distribution, not from this table) — so a grant does not retroactively change outcomes." The only code that emits those codes is the synthetic fixture generator (fhir-bundle-builder.ts, from config.hasWaiver).

So: an admin grants a waiver, the ledger records WAIVER_GRANTED, and the next run scores the subject exactly as before. The shape is right; the wiring does not exist.

Why it is filed rather than built

ADR-083 d2: this is the one legitimately WorkWell-side exception — an authored measure whose own logic reads a WorkWell-supplied Condition — but it is TWH/occupational-content work, not pilot work. The six official pilot measures cannot use it at all: only a chart-documented exclusion counts for those, which is #565's write path.

What the fix needs

• The evaluated bundle for an authored measure includes a Condition per ACTIVE, unexpired waivers row for that subject and measure, carrying the binding's waiver.code / waiver.valueSet.
• Expiry is honoured at evaluation time, not at grant time: expires_at in the past must stop producing the Condition, so the case reopens on the next run (which is already what planCaseUpsert does for a system EXCLUDED closure whose waiver lapsed).
• A revoke path, or an explicit decision that a waiver is never revoked and a correction is a new row.
• Tests: a granted waiver flips the next run's outcome to EXCLUDED for that measure only; an expired one does not; a grant for measure A does not exclude measure B.

Definition of done

Granting a waiver changes the next run's outcome for that subject and measure, and admin/waivers.ts's header no longer has to say it does not.