Shadow-mode pilot

Prove it on your cases. Production stays still.

A shadow-mode pilot runs LogicPearl beside your current process on a bounded set of historical cases. No integration. No workflow change. No SaaS dependency or phoning home. What you get back is a case-by-case readout in weeks, not quarters.

Talk about a pilot See the healthcare demo first
How it works

Three steps. Nothing touches production.

You provide

A bounded case batch

A set of historical cases in a format you already have, the policies they were decided under, and one reviewer or policy owner we can ask questions.

We run

LogicPearl in shadow mode

We compile the relevant policies into versioned decision artifacts and run your batch inside your environment or on de-identified data. Nothing touches production. Nothing phones home.

You get

A case-by-case readout

Every case, side by side with what your team actually did: where LogicPearl agrees, where it disagrees, and exactly why, down to the policy clause.

The deliverable

This is a readout, not a rollout.

The pilot produces a case-level readout with enough detail for clinical, policy, and operations teams to review together.

What the readout contains
  • A result for every case: ready, blocked, or missing evidence, with the blocking rule named
  • Packet evidence found and evidence missing, tied to the requirement it satisfies or fails
  • Policy checks matched, missed, or routed to review, in plain UM language, not model output
  • Reviewer-queue reasons your team can act on the same day
  • Replay proof for any case where the policy version matters
  • Agreement/disagreement comparison against your reviewers' decisions, if you provide labels

Shadow evaluation

A pilot ends with a reviewable readout, not a forced production rollout.

No production access required

LogicPearl runs beside your process on historical cases. Your systems, queues, and live decisions stay untouched.

Customer-controlled deployment

The runtime, artifacts, traces, and readout can live in your environment. No phoning home. You own the output.

No platform replacement

Your workbench, AI tools, and extraction stack stay in place. LogicPearl sits at the decision boundary.

Scoping

What makes a good first batch

Bring the cases your reviewers care about most: real variation, edge cases, and recent disagreements. Five case shapes make the first batch useful:

A clean, likely approval

Establishes the baseline: evidence present, criteria met, nothing interesting. The receipt proves it.

A likely denial

An investigational or excluded branch, so you can check the denial reason is the one you would defend on appeal.

A contradictory chart

Negated findings, family history, and copied-forward notes: the packets that fool summarizers.

A missing-documentation case

The readout should name exactly what is missing and draft the records request.

A policy-version case

A case decided near a policy update, so you can see the same facts replay differently across versions.

Measured before your first case

The engine arrives with its coverage already counted.

The current count is for Blue Cross Blue Shield of Massachusetts policies. We can run the same coverage accounting for any payer policy set before the pilot starts.

468
Blue Cross Blue Shield of Massachusetts policies compiled from 528 published policy PDFs
99.9%
measured clause coverage. The misses stay visible, never silent
~2,900
reviewable criteria, each tied to verbatim source policy text
~118k
policy table rows interpreted into checkable rules

Measured on the Blue Cross Blue Shield of Massachusetts policy corpus. The same coverage accounting can run against any payer policy set before a pilot starts.

FAQ

Pilot questions

What do you need from us to start?
Three things: a bounded batch of historical cases (a few dozen is plenty), the payer policies they were decided under, and one reviewer or policy owner who can answer questions about how your team reads those policies. We will confirm fit against your actual data in a 30-minute scoping call.
Does patient data leave our environment?
No SaaS dependency is required. The pilot is designed to run on de-identified cases, and where that is not practical we run inside your controlled environment. The runtime does not phone home, and the artifacts, traces, and readout belong to you.
What if LogicPearl disagrees with our reviewers?
Every disagreement includes the rule, evidence span, and source policy text, so your team can determine whether the gap is in the artifact, the packet, or the original review.
What happens to AI we already use?
Your choice. LogicPearl ships with its own OCR and extraction pipeline built for clinical paper, and it can equally consume the output of extractors you already run. Either way, what changes is the decision boundary: the model can propose, the policy rules decide.
How is a "policy artifact" different from a prompt?
An artifact is compiled from the source policy text, versioned, and hashed. Given the same packet and the same artifact version it returns the same answer with the same reasons every run, this year or next. You can run it in your own environment without a hosted model call or LogicPearl service call.

Start with one workflow. Prove it in shadow mode.

A bounded batch, a two-week-scale readout, and a decision you can defend either way.

Talk about a pilotSee the healthcare demo