Demo runs on synthetic data (Flexpa test mode shapes)
clawback

Compliance

The hard questions, answered before you ask them. What happens to protected health data, whether Clawback ever decides a claim, and whether any of this is legal advice. Written engineer to engineer.

Data stance

This demo runs entirely on synthetic data shaped like Flexpa test-mode responses. No real protected health information is stored, processed, or transmitted anywhere in this build. Every patient, claim, and dollar you see is fabricated to exercise the same FHIR shapes a real plan exposes.

Secrets are handled the same way. No Anthropic credentials exist on the server. If you run a live sweep with your own key, that key lives in memory for the single request and is never written to disk or to a log. Error messages are redacted before they reach you, so a pasted key cannot leak back through a failure.

What a real deployment would sit inside

A production Clawback would be a patient-authorized app reading claims through patient-access APIs. Under HHS guidance, an app the patient authorizes to receive their own records is not a HIPAA covered entity or business associate. The regime with teeth is the FTC Health Breach Notification Rule, expanded in 2024, which reaches exactly this kind of consumer health app and carries a 60-day breach-notice obligation.

So the posture for a real build is honest and specific. Synthetic data today means zero exposure. Real data later means an FTC-rule breach protocol and a plain-language privacy policy from the first day a live record touches the system.

What Clawback does and does not decide

Clawback explains a claim, flags an anomaly, projects your exposure, and drafts a letter. It never adjudicates. The decision on any claim stays with you and your plan. Much of the country requires a human to review denial decisions, and Clawback is built to sit on the member side of that line, not to replace it.

AI is good for a yes. It's not good for a no.

A flag is a prompt to look, backed by the source record, never a verdict. That boundary is why every finding carries its provenance and why the letters are drafts you send, not actions the agent takes.

The appeal drafts

When Clawback drafts an appeal, it renders inside a fixed frame that appears on every letter. These four statements are load-bearing, not boilerplate.

  • This is an informational draft.
  • You file it yourself.
  • No attorney-client relationship is created.
  • This is not legal advice.

The lesson from the DoNotPay enforcement action is that the risk lives in the marketing claim, not the drafting. So Clawback makes no robot-lawyer claim, promises no outcome, and hands you an informational draft that you review and file yourself.

Guardrails in the build

  • Forced JSON schemas on every model response, validated with zod before anything renders.
  • Spend caps and per-run cost guards, so a runaway loop cannot run up a bill.
  • Rate limits on the live-key path.
  • Provenance required on every finding, traced to the source claim field.
  • Published eval scores and a failure gallery, updated per run.
  • Replay by default, so the deployed demo makes no live model calls unless you bring your own key.

How the numbers are handled

Every number on this site is sourced and labeled. Denial and overturn rates come from KFF and are marked for what they measure, ACA marketplace, 2024, where measured. The empty-findings state, for instance, cites 34% of appealed denials were overturned in ACA marketplace plans, 2024, KFF.

The folk statistic that most bills contain errors traces to audits of pre-selected problem bills with no peer review. It is not defensible, so it appears nowhere on this site and is not in the model prompt.

The engineering behind these guardrails is documented on how it's built. The published scores are on evals.