AI Governance
What the AI is allowed to do, what it is structurally prevented from doing, and how a customer can check.
1.The rule everything else follows from
No black-box money. AI may extract, classify, summarise and draft. It may never determine an authoritative dollar amount, and it may never score, rank or prioritise a finding — the priority a finding carries is computed deterministically from its dollars, its filing deadline, the evidence on file and the payer's recorded history, with no model on the path.
Every reimbursement figure the platform asserts is produced by a deterministic engine from human-verified contract terms, and stores the inputs, the contract version and the engine version so it can be re-derived years later. A model cannot participate in that calculation because it is not on the path.
2.What is actually running today
The default provider is rule-based and runs in-process. The application makes no outbound call to any model provider. Its only outbound network call is transactional email through Resend, listed on the Subprocessors page; no claim, contract or patient data is sent in those messages. No customer data has been sent to any external model, and that is a checkable fact rather than a promise.
Every invocation of a model writes a record with the provider, the model, the prompt
version, the records it was permitted to see, and whether a human has reviewed the output —
today that is contract extraction and appeal drafting, the two places a model is called. A
customer with audit access can read that log. A row reading
provider=deterministic is what makes "no external model saw your data" verifiable
instead of merely stated.
3.Permitted uses
| Use | Constraint |
|---|---|
| Contract term extraction | Produces candidates only. A candidate term prices nothing and is never cited to a payer until a person verifies it against the agreement. |
| Denial classification | Driven by the payer's exact CARC and RARC codes against a deterministic table. Codes are never rewritten. |
| Appeal drafting | Retrieval-grounded to a frozen evidence bundle. Where a required
fact is missing it returns MISSING_EVIDENCE rather than filling the gap. |
| Explanation and summary | May restate what the deterministic engine computed. May not compute. |
4.Prohibited by design
- No training on customer data. Customer data, including PHI, is not used to train or fine-tune generalised external models. If that ever changes it requires an executed agreement permitting it, and it would be a change customers are told about first.
- No autonomous submission. A person approves every appeal before it goes to a payer, and their name is on it.
- No invented policy, deadline or rate. Where the platform does not hold a fact it says so — expected payment unavailable, no contract term on file — rather than producing a plausible number.
- No cross-tenant learning. One customer's data does not inform another customer's results.
5.The human in the loop is real
Not a disclaimer. A completeness gate blocks approval where required evidence is missing, an approval is bound to a fingerprint of the exact evidence and enclosures reviewed, and if either changes before sending, the approval is withdrawn and has to be given again.
The effect is that what a person approved is what the payer receives, byte for byte, and the system can prove it.
6.If a hosted model is ever introduced
Before any external model provider is enabled, the following must be in place: a business associate agreement with the provider; contractual terms prohibiting training on our customers' data; the provider added to Subprocessors; a data minimisation layer so only the fields required are sent; and notice to affected customers.
Questions about this document: · · · All policies