How our decoder works

Transparency about what happens to your inputs, what the decoder does with them, and what we log. The short version: your inputs never leave the browser at identifying granularity.

What you provide

• The kind of service that was billed (emergency, OON ancillary at INN, air ambulance, etc.).
• The kind of plan you have (commercial, ERISA self-funded, Medicare, etc.).
• The state where the service was provided.
• Whether the facility and provider were in-network or out-of-network.
• Whether you signed a notice-and-consent waiver (for scheduled OON only).
• Bill and EOB dates (insured patients) or GFE and actual-bill amounts (self-pay).

What stays in your browser

All of it. The decoder is a pure deterministic function evaluated client-side in JavaScript. There is no POST to the server with any of your input data. The decoder reads the state matrices and citation manifest from the build bundle (already served to your browser) and computes the verdict locally.

What we log on the server

Standard web-server access logs (IP, user-agent, request path, response status, timestamp) only. We do NOT log:

• Bill amounts
• EOB dates
• Payer names
• GFE amounts
• Any other input that could re-identify a transaction

If we add analytics aggregation (path classification / payer-type buckets / state buckets), it will be aggregate-only — never amounts, never dates, never anything that could re-identify a transaction. See /privacy for the full policy.

The decoder logic

See /methodology for the 8-axis decision tree, the branching rules, and the statute anchors. The full decoder source code lives in our repository; every verdict is reproducible by hand from the statute pins.

What we are NOT doing

We are not uploading your bill or EOB. We are not parsing documents. We are not filing complaints on your behalf. We are not paying claims. The decoder produces a routing verdict; the patient acts on it.