Florence AI — Knowledge: SBC coverage examples & CSR variants

Audience: Florence AI (via tool-call retrieval) + engineers wiring scenario / subsidy explanations. This is the canonical reference for what we display on the plan-detail Year Scenarios block and what Florence cites when a user asks "why is my CSR-94 baby cost $X?".
Status: Living. Updated 2026-05-22 (ENG-365 Option C). Verified against SelectHealth 2026 SBC + CMS Plan Attributes PUF.
One sentence: Florence never computes these numbers — she reads them via api_get_plan_detail (Phase E, #53) and explains them using this doc as the cite-able source.

1 · What the SBC coverage examples are

Federal regulation (45 CFR 147.200, the ACA "Summary of Benefits and Coverage" rule) requires every plan to publish three standardized hypothetical scenarios so consumers can compare apples-to-apples:

Scenario	What it models	2026 CMS standardized Total Example Cost
Having a Baby	9 months of in-network prenatal care + a hospital delivery	$12,700
Managing Type 2 Diabetes	A year of routine in-network care of a well-controlled condition	$5,600
Simple Fracture	In-network emergency room visit + follow-up care	$2,800

These totals are fixed by CMS (same across every plan for a plan year) — that's what makes the comparison meaningful. They are not in the PUF; we hardcode them in apps/web/src/lib/plan-detail-extras.ts → SCENARIO_TOTAL_COST, verified against SelectHealth's 2026 SBC (68781UT0200014 page 7). Re-verify on each PUF release.

The per-plan part — the patient's cost-share breakdown (deductible / copay / coinsurance / non-covered) — comes from the issuer's filed SBC and lives in puf.sbcScenarios per plan + puf.csrVariants[tier].sbcScenarios per CSR variant.

2 · Where the data lives in MongoDB

plans/{hiosId}                                        ← one doc per HIOS plan
  ├─ deductibleIndividual, moopIndividual             ← BASE variant
  ├─ puf.sbcScenarios.{havingABaby|havingDiabetes|havingSimpleFracture}
  │     ├─ deductible    ── patient's deductible share for this scenario
  │     ├─ copayment     ── patient's copays
  │     ├─ coinsurance   ── patient's coinsurance
  │     └─ limit         ── non-covered / limited services
  │     (sum = patient's total out-of-pocket; "Typically you pay" in the UI)
  │
  └─ puf.csrVariants                                  ← Silver plans only
        ├─ "94"  → 94% AV variant  (HIOS suffix -06; 100-150% FPL)
        ├─ "87"  → 87% AV variant  (HIOS suffix -05; 150-200% FPL)
        ├─ "73"  → 73% AV variant  (HIOS suffix -04; 200-250% FPL)
        ├─ "zero" → Zero Cost Sharing (HIOS suffix -02; AI/AN ≤300% FPL)
        └─ "limited" → Limited Cost Sharing (HIOS suffix -03; AI/AN)
          each variant has:
            planId, csrVariationType, planName,
            deductibleIndividual, moopIndividual,
            sbcScenarios.{havingABaby|havingDiabetes|havingSimpleFracture}
            copays.{42 benefit categories} (e.g. "Inpatient Hospital Services",
                                            "Delivery and All Inpatient Services for Maternity Care",
                                            "Specialist Visit", …)

Coverage: 4,326 plans total · 4,044 have base sbcScenarios · 1,453 Silver plans have CSR-variant SBC data. Non-Silver plans never have 94/87/73 variants (ACA: CSR is Silver-only).

3 · How the CSR tier reaches the plan-detail page (ENG-365 Option C)

The tier is computed in one place and consumed by everyone:

/api/eligibility    ← detects Medicaid → re-queries at adjusted income →
                      returns the Medicaid-adjusted estimate.csr (CMS string)

/api/plans          ← deriveCsrTierFromFpl(adjusted income) = clean tier
                      ("94" / "87" / "73" / "")
                      applies csrVariants[tier] to the plan's cost-sharing
                      returns { ..., csr_tier }   ← exposed in the response

fetch-plans         ← FetchPlansResult.csrTier (carried as a typed field)

use-calculator      ← POST /api/session/init { computed: { ..., csrTier } }

marketing-session   ← session.csrTier persisted

plan-detail routes  ← context.csrTier handed to fetchPlanDetailExtras

plan-detail-extras  ← reads csrVariants[csrTier].sbcScenarios SERVER-SIDE,
                      surfaces it as the "Your estimate" line

Florence rule: never call deriveCsrTierFromFpl from a tool. Always consume the tier the pipeline already decided (session.csrTier / FetchPlansResult.csrTier / api_get_plan_detail output).

4 · Reading the numbers: what each line on the UI means

The plan-detail "Year scenarios" card for a CSR-eligible Silver plan shows:

Line	Source	Meaning
Total cost of care	`SCENARIO_TOTAL_COST[scenario]`	The fixed CMS hypothetical total. Same across every plan.
Plan pays + %	`total − patientCost` from base `sbcScenarios`	What the base-variant plan would cover. Suppressed if `patientCost ≥ total` (issuer SBC variance — see §7).
Typically you pay	base `sbcScenarios.<scenario>` sum	What the patient on the standard Silver variant pays — what the SBC PDF discloses.
Your estimate	`csrVariants[csrTier].sbcScenarios.<scenario>` sum	What the patient pays with their CSR applied. Only shown when `csrTier` ∈ {"94","87","73"}. Non-Silver plans never show this.

When a user (or we) see "Your estimate $2,560 on a CSR-94 plan" it can feel high. The mental shortcut is "94% AV means the plan covers 94%, so patient ≈ 6% of $12,700 = ~$760." That shortcut is wrong.

Actuarial value (AV) is the share of total allowed medical costs the plan pays averaged across all covered services and a CMS-standard population. It's a statistical average over a typical year of utilization.
A single SBC scenario is a specific hypothetical (e.g. one hospital delivery). The patient's cost-share on it depends on the specific cost-share design (coinsurance rate, copay schedule, MOOP cap). It can and often does deviate substantially from the AV percentage.

Inpatient hospital and maternity services are coinsurance-heavy and expensive. Even a 94% AV plan with $0 deductible and a low coinsurance rate (e.g. 20%) generates real out-of-pocket on a $12,700 baby scenario — usually $500-$2,500 — because the patient pays coinsurance until they hit MOOP.

6 · Dataset reality (CSR-94 baby, all Silver plans w/ data)

Empirical distribution across 1,453 Silver plans in our DB (2026 plan year):

Bucket	Count
$0-500	11	▏
$500-1,000	241	██████████
$1,000-1,500	373	███████████████
$1,500-2,000	282	████████████
$2,000-2,500	509	█████████████████████
$2,500-3,000	7	▏
$3,000-3,500	25	█
$3,500-4,000	1
$4,000+	4

Mean: $1,649 · Min: $0 · Max: $8,570
Most CSR-94 plans land $1,000-$2,500 on the baby scenario.
~95% of CSR-94 plans are under $2,500.
The handful of $3,000+ outliers are issuer SBC-variance / specific cost-share designs that retain meaningful coinsurance on the 94% variant.

So when Florence sees a CSR-94 baby cost above $2,500, that's a real signal worth explaining — not a bug.

7 · Known data edges and the display guards

All-zero rows (7 plans): some plans report 0/0/0/0 for the baby scenario (sparse PUF data). The reader filters these out at the row level — the card simply isn't rendered for that scenario, so we never show "$0 / plan pays 100%" for childbirth.
patientCost ≥ total (~109 plans): for ~94 FL/DE bronze plans the fracture you-pay exceeds the standardized $2,800 (issuer SBCs use a slightly different total internally). The UI suppresses Total / Plan pays / % for that card and shows "You pay" only — never the impossible "$3,000 of a $2,800 total". Flagged as a possible ENG-219-class data follow-up.
Non-Silver plans: never have csrVariants["94"|"87"|"73"] — the reader returns estimateCost: null and the UI omits the "Your estimate" line. Correct: CSR is Silver-only by ACA law.

8 · Walkthrough Florence can quote — `68781UT0200014` (SelectHealth Signature Benchmark Silver, UT) at CSR-94

User context: ZIP 84094 (Salt Lake County), couple 35+30 married, $21,000 income → Medicaid-adjusted to $30,472 → CSR tier 94.

Variant -06 (94% AV) cost-share design (from puf.csrVariants["94"]):

Field	Base variant (-01)	CSR-94 variant (-06)
Deductible (individual)	$5,900	$0
MOOP (individual)	$9,500	$3,000
Inpatient hospital + maternity coinsurance	50% after ded.	20%
Specialist visit	$40 copay	$15 copay

Baby scenario ($12,700 total):

Prenatal specialist visits (~20 visits @ $15 + small copays): $300
Inpatient delivery — 20% × ~$11,000 facility/professional: $2,200
Non-covered services: $60
Patient pays: $2,560 ← UI: "Your estimate"
Plan pays the other $10,140 ($12,700 − $2,560)

Compared to base (no CSR):

	You pay	Plan pays
Base Silver (no CSR)	$9,460	$3,240
CSR-94 (this user)	$2,560	$10,140
CSR savings on this scenario alone	$6,900 saved (73% reduction)

That's on top of the $1,041/mo APTC premium subsidy. The plan card price ($9.95/mo) and the $2,560 baby cost are provably the same pipeline decision (Option C consistency cross-check: plan card deductible $0 = csrVariants["94"].deductibleIndividual).

9 · How Florence should use this when explaining

When a user asks "Why is my CSR-94 baby cost $X?" (or any scenario / tier), Florence should:

Read, don't compute. Call api_get_plan_detail (Phase E) to pull the plan's puf.csrVariants[tier] data. The numbers shown on the UI are the canonical source — Florence narrates them, never recomputes them.
Show the savings vs base. "Without your cost-sharing reduction this would be $Y. With it, you pay $X — saving $Y−X." (See §8 for the worked example.)
Explain the cost-share drivers (coinsurance rate on inpatient, deductible, specialist copay) — these are why two CSR-94 plans can have very different scenario costs.
Set expectations re: AV vs scenario. If the user invokes the "94% AV → patient pays 6%" shortcut, gently correct using §5.
Offer comparison. If the user's scenario cost is in the upper end (per §6), proactively offer "There are lower-baby-cost Silver plans in your area at similar premium — want me to surface them?". (This unlocks a planned follow-up tool: scenario-cost-sort filter on api_search_plans.)

10 · Open product / UX follow-ups (not in ENG-365)

"Best plan" sort by premium ≠ best by scenario cost. A $9.95/mo CSR-94 plan with a $2,560 baby cost may be worse than a $20/mo CSR-94 plan with an $800 baby cost for a household planning a delivery. Worth a scenario-aware sort/filter.
Surface CSR savings in the UI itself. Today the card shows "Your estimate $2,560" without the "vs base $9,460 — saved $6,900" framing. Adding it would make the CSR value visible at-a-glance.
Per-variant SBC URLs. The base SBC URL is on puf.urls.summaryOfBenefitsAndCoverage. Variant-specific SBC PDFs (one per -04 / -05 / -06) are filed by issuers but not in our ingest today — sourcing them per-plan is a small ingest project that would let us link the user to "their specific SBC."

11 · Provenance / how to re-verify

Code paths touched by ENG-365: see PR #416. Rollback anchor: eng-365-rollback-anchor (commit 3f37516).
Pricing regression gate: scripts/audit/calculator-baseline-diff.ts — 14 scenarios spanning every CSR tier; ZERO DIFFS required.
SelectHealth 2026 SBC (base variant -01): https://selecthealth.org/files/sbc/I61A0187_20260101_GGGGGGGG_GGGG_SSSS.pdf (page 7 = coverage examples).
CMS Plan Attributes PUF: the underlying source for puf.sbcScenarios + puf.csrVariants[*].sbcScenarios. Ingested via scripts/db/ingest-puf-augment.js.