Trust & Reliability

Don't trust the model. Trust the architecture — and the human who reviews it.

No AI vendor can honestly promise zero hallucinations. So we built Paveo so the model is never in a position to invent a clinical fact, every claim traces back to your documents and the payer's own policy, and two people read an appeal before it reaches a payer — our operator, then your named approver.

“We don't ask you to trust the model. We built the system so the model can't invent a clinical fact, and no appeal reaches a payer without a named person approving it. Let us show you how.”

The model never acts on its own. It reads and it drafts; it does not decide what is clinically true and it does not submit. Every appeal is approved by a named person at your organization before it is filed, and that approval is bound to the exact document they read.

What keeps the output accurate

Reliability is engineered, not promised

Four design decisions that make a fabricated clinical claim structurally hard — not just unlikely.

The model can't invent a clinical fact

Paveo runs in two hard-separated stages. Stage A only extracts what is literally in your documents — it never infers or fills gaps. Stage B drafts using only those extracted facts. A claim that isn't in your notes has no path into an output.

It surfaces what's missing — it doesn't paper over it

The product is built to flag absence: the missing lab, the undocumented step therapy, the gap in prior-therapy evidence. A tool that points out what's incomplete is the opposite of one that fabricates confidence.

It never invents a score

Readiness is shown as a real met / total ratio (e.g. 6 of 8 requirements met) plus a risk band — never a made-up percentage. Every item traces back to a concrete requirement in the payer's actual policy.

Grounded in the real payer policy

Paveo checks each case against that payer's actual coverage criteria, injected whole — not against the model's memory of what a payer 'usually' wants. The reasoning is anchored to a real document you can read.

The core safeguard

A wall between reading and writing

The single thing that makes hallucinating a clinical fact structurally impossible.

Stage A — Extract

Reads the documents. Extracts only.

Pulls what is literally on the page — diagnoses, labs, prior therapies, dates. It is not allowed to infer, guess, or fill a gap. If it's not in the record, it doesn't come out.

Stage B — Draft

Writes using only Stage A's facts.

Builds the readiness check or appeal from the extracted facts alone, splitting evidence present from evidence missing, and rejecting any claim it can't trace back to the notes.

Patient data

No identified patient record enters Paveo before the BAA is signed

That is a deliberate boundary, not an accident of timing. Here is exactly how documents are handled today, and what changes when live cases start.

De-identified or synthetic — by design

Today Paveo runs on synthetic and de-identified data. No real patient record flows through it until the proper agreements are in place. We'd rather tell you that plainly than overclaim.

Your documents are kept — where only your organization can reach them

We keep what you send us, because an appeal worked on Tuesday needs the letter that arrived on Friday. Every file sits in a private store — there is no public link to any of it — under a key scoped to your organization and the specific case. A database constraint and a storage policy both enforce that scope, so a file cannot be written or read outside the organization it belongs to. We keep documents for 12 months after a case closes, delete them sooner whenever you ask, and return or destroy everything when we stop working together. Filenames and file contents never reach our logs or error reports.

Encrypted and access-controlled

All traffic is encrypted in transit (HTTPS), and the operators' console is behind authentication and role checks. There is no public surface where case data can be reached.

The honest inventory

What is in place, and what lands before your first live case

Written for the person who has to sign off on us. Most vendors show you only the left column; the right one tells you exactly what arrives, and when.

In place today

  • Tenant isolation enforced by the database

    Row-level security in Postgres, so one organization's cases are unreachable from another's session. Enforced by the database itself, not by application code remembering to filter.

  • An append-only audit log

    Who did what, and when — case creation, status changes, assignment, the sign-off that authorises filing, every document received, and every time a Paveo operator opens one of your cases. No permission to update or delete an entry is granted to anything, so the record cannot be quietly rewritten.

  • Sign-off bound to the exact content approved

    An approval is tied to a fingerprint of the packet as it was read. Edit or regenerate the document afterwards and it reverts to draft rather than continuing to display a reviewer's name over text they never saw.

  • Role separation on the action that matters

    A junior operator can prepare a case but cannot mark it submitted. The restriction lives in the database policy, because a screen that hides a button is not access control.

  • Logging built to be PHI-free

    Error reporting runs with personal data collection disabled and never captures request bodies or query strings. Patient data is not in our logs by construction, rather than by a filter someone has to maintain.

  • Documents scoped to one organization, by two independent rules

    Stored files are keyed by organization and case, from a random identifier rather than the filename. The database refuses to record a file at another organization's path, and the store refuses to reveal one — two separate rules reading the same prefix, so neither is the only thing standing between two pharmacies.

  • Encryption in transit, and policy freshness enforced

    All traffic is HTTPS. Separately, every payer policy has a verification date we track; anything unverified for 90 days is flagged and 180 days fails our build, so criteria cannot silently age.

Before we handle your PHI

  • A signed BAA chain

    Before your first live case

    Three agreements: our AI provider to us, our host to us, and us to you. It needs the US entity we are in the process of incorporating. This is a prerequisite to live work, not something to be discovered halfway through it.

  • HIPAA-eligible hosting

    Before your first live case

    Our infrastructure moves to HIPAA-eligible plans as part of the same step as the BAA. Until it does, there is no identified patient record on it.

  • Retention enforced on a schedule, not by hand

    With the BAA

    The period is stated and we honour a deletion request whenever you make one — but removing a document today is an operational step a person takes, not a job that runs on its own. The automated purge belongs with the same set of controls as the BAA. The contractual version of the schedule is set out in the BAA and services agreement.

  • SOC 2

    When a buyer requires it

    SOC 2 is a real audit and we will not imply we hold a report. It is what a health system's procurement asks for, and it is a step we take when a customer needs it rather than in advance of anyone asking.

  • An independent penetration test

    Alongside SOC 2

    The controls in the left-hand column are real and readable in our own code. None has been reviewed by an outside firm yet; that review belongs with the same procurement step that asks for SOC 2.

  • SSO, data residency, and a public API

    When a customer needs them in writing

    We would rather build these against a real requirement than guess at one and get it wrong.

We build to HIPAA's Security Rule requirements, and no identified patient record enters Paveo before the BAA is signed — so the right-hand column is a sequence, not a gap. The free five-case audit runs on de-identified documents, which means none of it is load-bearing while you are still deciding about us.

The path to real cases

Going live with real PHI is paperwork, not a rewrite

When your team is ready to pilot with real cases, three agreements unlock it — scoped to that pilot, done before any real record is processed.

Step 1

AI provider BAA

The model reads the documents, so the LLM provider is covered by a Business Associate Agreement.

Step 2

HIPAA-eligible hosting

The backend moves to a HIPAA-eligible host that signs a BAA before any real record is processed.

Step 3

BAA with your team

Paveo signs a BAA with your organization. Tenant isolation, role-based access and the audit trail already exist on our side — your team doesn't log into anything, so this step is paperwork rather than a build.

This page describes Paveo's design and data posture; it is not legal advice. Specifics are confirmed with each provider and reviewed by counsel before a pilot with real patient data.

Judge the method on your own cases

Send five denials you have already lost, de-identified. We will show you the criterion each one turned on and what we would have argued. Free, and it needs no BAA.