Skip to content
AskFlorence
Main Navigation ArchitectureFlorence AIAgentsMembersAgent PlatformValidationInfrastructure

Appearance

Sidebar Navigation

Overview

Home

Glossary

System Architecture

Consumer & Agent Flow

Florence AI

Overview

Principles

Runtime

Tool surface

Adding a tool

Tool registry

Knowledge: SBC scenarios & CSR

Voice

Evals & observability

Provider risk & portability

Outage playbook

Roadmap

Build plan

Agents

Overview

Workflows & pain points

Members

Overview

Medicaid coverage gap

Carriers

Overview

Marketplaces

Overview

Agency

Overview

Regulations

Overview

Agent Platform

Overview

Auth Architecture

MongoDB Permissioning

Compliance Model

Data Models

Data Sources

Overview

CMS Marketplace API

CMS dependency map

PUF Data

State Subsidies

SBE Ingestion Playbook

SBE State Watchouts + Decisions

CA Phase C/D Playbook

NY Phase C/D Playbook

Validation

Overview

Methodology

APTC Formula

California 2026

New York 2026

CAPS Formula

Scenario Results

Infrastructure

Account Inventory

AWS Setup Runbook

AWS Organizations

CloudTrail

GuardDuty

Security Hub

Config

CloudFront + WAFv2

Data sources & ingest

Phase 4 DNS

Change Log

Vulnerability Management

MongoDB Setup

Access Control

Data Classification

Documentation Hosting

Post-deploy Smoke

Development

Preflight (local CI mirror)

Testing strategy

Compliance

Overview (auditor entry point)

SOC 2 Control Mapping

HIPAA Control Mapping

CMS EDE Appendix A Mapping

Risk Assessment

Encryption Policy

Data Retention Policy

Privacy Impact Assessment

Consent Capture & Versioning

Incident Response Plan

Access Control Policy

Marketing vs. Portal Analytics

Vendor / Subprocessor Register

Dependency Vulnerability Policy

BAA / Compliance Evidence

Compliance-Automation Integration

Compliance-Automation Vendor Evaluation

Penetration Test Reports

Architecture

Portal entry handoff

Mobile app strategy

Deferred architecture decisions

Session cookie architecture

Share flows

Decisions (ADRs)

Index

0001 — Atlas project isolation

0002 — Append-only audit log

0003 — Narrow-scoped Mongo users

0004 — Cross-cluster Atlas PrivateLink

0005 — Delayed-job architecture

0006 — Mongo user simplification

0007 — Terraform owns ECS task def

0008 — E2E testing strategy

0009 — Self-hosted analytics + observability (superseded)

0010 — PostHog HIPAA Cloud (supersedes 0009)

Runbooks

Security Incident Response

Break-Glass Root Login

Onboard Team Member

Offboard Team Member

Atlas user provisioning

Deploy via Terraform (ENG-277)

Rollback via Terraform (ENG-277)

S3 data bucket migration (planned Phase 11)

Access Reviews

2026-Q2 Review

Session log

Index

2026-04-23 — Phase 10 DNS cutover

2026-04-22 — Phase 8 prod AWS mirror

2026-04-22 — Phase 7 Atlas VPC peering

2026-04-22 — Phase 6 CloudFront + WAF

2026-04-21 — Phase 5 staging go-live

2026-04-17 — Atlas staging

Briefs

Index

Member portal plan (ENG-187)

2026-04-16/17 handoff

2026-04-17 Atlas handoff

System briefing (2026-04-17)

Creative AdBundance proposal brief

Creative AdBundance analytics brief

ElevenLabs RN integration research

Policies

Overview

On this page

Comprehensive Plan Data Audit ​

Status: Active. Initial run April 14, 2026. Scope: All 30 federal (FFM) states, ~28K zip codes, ~4K plans Goal: Continuously prove our database matches Healthcare.gov accuracy without runtime CMS dependency

Source of truth ​

  • Federal states (30): CMS Marketplace API at marketplace.api.healthcare.gov/api/v1/
  • NY: NY DFS Exhibit 23 + NYSOH (separate methodology, see new-york-2026.md)
  • Other SBE states (zip→county only): CMS Marketplace API /counties/by/zip (the same endpoint that backs Tier 1). Deeper plan-level data lives on each SBE marketplace and is out of scope.

Tiered audit structure ​

TierScopeMethodCadence
1 — Zip → County (federal-30)Every unique federal-state zip (~18.8K)CMS /counties/by/zip vs our zip_county federal-state docsMonthly
1.5 — Zip → County (SBE-state)Every unique SBE-state zip (~13K)CMS /counties/by/zip vs our zip_county SBE docs (with sbeRedirect)Monthly
2 — Zip → PremiumEvery federal zip-county entry (~28K)CMS /plans/search vs our cheapest SilverMonthly
3 — Scenario matrix200 stratified counties × 10 scenariosRealistic households w/ Medicaid auto-adjustmentMonthly
4 — Internal integrityAll 4K plans + all 28K zipsPure DB queries, no CMS callsEvery commit

Standard test parameters ​

Unless otherwise noted, all audits use:

  • Year: 2026 (current enrollment year)
  • Market: Individual
  • State filter: 30 federal FFM states
  • Match tolerance:
    • Tier 1: exact set equality (FIPS codes)
    • Tier 2: $0.01 (cheapest Silver age 35)
    • Tier 3: $0.50 (allows for rounding in household premium calculations)

Medicaid flow handling (CRITICAL) ​

Problem: CMS API does not return APTC-discounted plans for users below 138% FPL. It returns is_medicaid_eligible: true with no APTC. Our app handles this differently — it auto-bumps the income to 138.5% FPL + $500 and shows what plans would look like if denied Medicaid (e.g., immigration status).

Audit approach: When a scenario triggers Medicaid (income < 138% FPL):

  1. Compute effectiveIncome = autoAdjustIncome(income, householdSize)
  2. Query CMS with effectiveIncome (not original income)
  3. Compare against our DB output (which uses the same auto-adjustment)
  4. Match on cheapest plan + premium

This compares apples-to-apples: the plans CMS shows at the adjusted income vs the plans we show after auto-adjustment.

Auto-adjustment formula (matches src/lib/owned-plans.ts):

js
const FPL_BASE = 15650;        // 2025 FPL for 2026 enrollment
const FPL_PER_PERSON = 5500;
const fpl = FPL_BASE + FPL_PER_PERSON * (householdSize - 1);
if (income < fpl * 1.38) {
  return Math.round(fpl * 1.385) + 500;
}
return income;

CMS API rate limit handling ​

CMS doesn't publish exact rate limits. Conservative target:

  • Sustained: 25 req/sec
  • Burst: 30 req/sec
  • Concurrency: 5 parallel requests
  • Backoff: Exponential on 429/503 (1s → 2s → 4s → 8s)
  • Timeout: 30s per request
  • Max retries: 4

Implementation:

  • scripts/audit/lib/rate-limiter.js — token bucket
  • scripts/audit/lib/cms-client.js — retry wrapper with stats tracking

Resumability ​

All Tier 1, 2, and 3 audits write progress to /tmp/audit-progress-{tier}.json every 100 items. If a script dies, simply re-running it picks up where it left off. On successful completion, the progress file is deleted.

Output ​

Each audit run produces:

  1. Stdout summary — pass/fail counts + per-state breakdown
  2. JSON report at audit-tier-{N}-results.json (root of repo)
  3. Documentation update in docs/validation/audit/tier-{N}-*.md
  4. Atlas snapshot (manual safeguard) before running

Failure policy ​

Flag, don't block. Failures are documented and tracked in GitHub issues. Production rollouts only block if Tier 2 falls below 99% match rate.

Reproducibility ​

  • Tier 4: identical output on the same DB state (deterministic)
  • Tier 1, 2, 3: ≥99% identical on consecutive runs (small variance from CMS-side data updates is normal)
  • Atlas snapshots allow full DB rollback if needed

Scripts reference ​

ScriptPurpose
scripts/audit/tier-1-zip-county.jsZip → county resolution audit (federal-30)
scripts/audit/tier-1-5-sbe-zip-county.jsZip → county resolution audit (SBE-state)
scripts/audit/tier-2-zip-premium.jsZip → premium audit
scripts/audit/tier-3-scenarios.jsHousehold scenario matrix
scripts/audit/tier-4-integrity.jsInternal data consistency
scripts/audit/lib/rate-limiter.jsToken bucket rate limiter
scripts/audit/lib/cms-client.jsCMS API wrapper
scripts/audit/lib/progress.jsSave/resume progress
scripts/audit/lib/db-helpers.jsShared MongoDB helpers
Pager
Next pageHome

AskFlorence Internal Documentation. Not for public distribution.

AskFlorence

Internal Documentation

Access restricted. Not for public distribution.