The outcome, and how it is measured
Documents that finish with no human touch
The lead number. Grooper measures it itself, per payer and per document type, and it climbs as saved decisions accumulate.
Measure straight-through rate, by payer
Minutes per exception, not hours
The reviewer opens a document and sees the failed rule, the field, and the value highlighted where it sits on the page. No hunting through a 40-page EOB.
Measure minutes per exception · exceptions per 1,000
Decisions that become rules
A payer record, a code crosswalk, a rule version: each decision a person makes is saved as data. The next document that matches never enters review.
Measure decisions saved per week · inconclusive rate
The manual process today, and what changes
| STEP | TODAY: A PERSON DOES IT | WITH GROOPER: WHO DOES IT |
|---|---|---|
|
1 Identify the document |
Sort EOBs, remits, letters and claim forms by eye. |
GROOPER Classify assigns the document type. Only uncertain documents go to a person. |
|
2 Find the payer |
Read the name and address, look up the payer ID, hope the spelling matches. |
AI GROOPER Extract matches the payer against your payer table with tolerance for OCR errors. No match: the document waits for a specialist, with candidates shown. |
|
3 Pick the rules that apply |
Know, or look up, which payer rules were in force on the document's date. |
GROOPER A lookup selects the rule set by payer and date. The version applied is recorded with the document. |
|
4 Check the data |
Eyeball each field against the rules. |
GROOPER Rules run on every field, every time, with no model in the loop. Each result is pass, fail or inconclusive. |
|
5 Decide |
Decide every document, including the ones that were fine. |
PERSON Passed documents flow through. A person accepts, rejects or completes only the failed and inconclusive ones. |
|
6 Record it |
A note in a spreadsheet, if there is time. |
GROOPER Who decided what, when, under which rule version. The decision is saved so the next matching document skips the queue. |
The person moves from doing all six steps on every document to doing one step on the exceptions. The six steps still happen; five of them become evidence a person can check instead of work a person has to do.
Where the AI is, and where it isn't
AI READS
Six OCR engines, Azure Document Intelligence among them. AI extraction where layouts vary. ReadScope sets what the model is shown, per field.
AI SUGGESTS
Candidate payers for an unmatched document. A standard code for a payer's reason code. Always with its reasons, never as a decision.
RULES CHECK
Validation, balancing and lookups run deterministically on every field. Same answer every time, no token cost, and any field can run on rules alone.
PEOPLE APPROVE
Nothing inconclusive passes on a model's say-so. A person's yes is a step in the process, and it is logged with the rule version it was given under.
Your documents. Your models. Your rules. AI-native, never AI-dependent. 1 / 3
Three words for what is built around the model
The conversation about AI has moved from "which model" to "what you build around the model." Three words carry it. Grooper is all three, running today; the model inside is swappable.
HARNESS
Everything around the model: the rules, the tools, the data, the approval, the record, a safe workspace.
For payer ID: the payer table, the rule sets, the review queue and the change log are all Grooper. Take the model out of the picture and everything that matters is still there.
GRAPH
A flowchart the system is forced to follow: which step may run next.
Import → Classify → Extract → Validate → Review → Export
A document moves only along these arrows. A failed or inconclusive check sends it to Review: a person is a box in the map, not an afterthought.
LOOP
Do the work, check it against evidence, then continue, retry or stop.
For payer ID: no payer match or a failed rule starts the loop. AI proposes with its reasons; a person decides; Grooper saves it; the next document like it never enters the loop. Stop on evidence, not confidence.
Your evaluation checklist, answered one for one
Each capability is tagged with the word it belongs to: HARNESS GRAPH LOOP PERSON
| CAPABILITY ASKED FOR | WHAT GROOPER DOES | HOW IT WORKS |
|---|---|---|
|
OCR for data extraction specific to a document type e.g. vs. Azure Document Intelligence HARNESS |
Azure Document Intelligence is one of six OCR engines Grooper runs; you pick the engine per OCR profile. Raw OCR returns text and coordinates. Grooper turns them into named fields per document type, each with a record of where the value came from. |
A data model per document type; each field chooses its method from about 57 (patterns, anchors, label sets, lexicons, lookups, AI). AI Transaction Detection splits EOB-style pages into claim records with no printed dividers. On every AI field, ReadScope sets what the model is shown: the page, one region, or only values already extracted. |
|
Document identification assign a category to each document GRAPH |
Classify assigns each document a type from your content model: EOB, remittance, correspondence, claim form, or the categories you define. Confident documents continue; uncertain ones go to a person. |
Trained on more than words: data tags (dates, amounts, addresses present), language constructs, phrases and label sets, with AI classification where layouts vary. Confidence thresholds you set define "uncertain"; a routing expression sends those to review. |
|
Execute validation rules on extracted data HARNESS |
Rules run on every extracted field as a step in the process, same answer every time, no model in the loop. Values are checked against your own systems while extraction is still running. |
Field-level validation, calculated expressions (totals that must balance), and lookups against databases, web services and content systems, with explicit no- match and multiple-match handling. What outgrows configuration escalates to expressions, then code, inside the product. |
|
Rules versioned by date range HARNESS |
Rule sets are data with effective and expiration dates, not code. The document's date selects the version that applied; changing a rule set never rewrites history. |
A rule table keyed by payer and date range, read by lookup at extraction time. The version applied is stored with the document: "which rules ran on this claim?" is a query. |
|
Rule sets specific to a payer HARNESS GRAPH |
One rule set per payer and date range. Shared rules are written once; payer-specific rules override them. |
The payer table is a tree: a root payer holds the payer ID and shared rules; subpayers (each printed name-and-address variation) inherit them and add their own. |
|
Summary of validation results LOOP |
Every rule result lands on the document in one of three states, and the summary decides where the document goes next. PASS straight through to export FAIL to review, rule and field highlighted INCONCLUSIVE to review, with the fields to complete |
Inconclusive is a first-class result: a missing value, a lookup with no match or several, or a value below the confidence threshold you set. It waits for evidence or a person; it never passes on a model's say-so. |
|
A user reviews the results and accepts, rejects or completes LOOP PERSON |
In the Review step a person sees each value highlighted on the source page beside the rule it failed, then accepts, rejects with a reason, or completes the missing fields. Nothing passes without that yes. |
Every decision is logged: who, when, which rule version, what changed. Recurring decisions are saved as data (a payer record, a crosswalk) or as a rule, so the same question is never asked twice. Queues split by specialty, routed by document type or payer. |
Azure Document Intelligence, AWS Textract and the language models from three providers are components Grooper runs on your behalf, selectable per field, never replaced. Any field can also run on rules alone.
Your documents. Your models. Your rules. AI-native, never AI-dependent. 2 / 3
Built to be called by the agents you already run
You have invested in agents. Grooper is not another one. It is the document-layer system of record those agents call: the operation that classifies, extracts, validates and records, the same way every run, while your agents decide what to do with the result. Every major Grooper function is exposed through the REST API, and the product surface is exposed as MCP tools, the open protocol your agent platform already speaks, so there is no captive assistant and no new seat to buy.
An agent working through Grooper inherits the evidence trail on everything it touches. It can propose a payer, a code or a rule change, but it cannot write to your data without a person's yes, and every proposal, hold and write is recorded: the only version of agentic operation a payer audit will accept.
An agent completes a task you supervise. Grooper runs an operation you can audit.
WHAT AN AGENT CAN ASK GROOPER TO DO
- Submit a document and get back its type, its payer, every field with its page location, and the pass / fail / inconclusive summary under the rule version that applied.
- List what is waiting in review and why; propose a payer record, a crosswalk or a rule change for a person to approve.
- Search the processed archive by field, not just by words: payer, date range, rule outcome, every hit linked to its source page.
- Build and operate the configuration itself by conversation, with every object it creates verifiable in the same tree as human-built work.
WHAT COMES BACK
Not a transcript. Records: fields with lineage, decisions with reasons, a process state you can query, an archive that stays alive.
RUNNING TODAY
Healthcare payer documents on Grooper
A healthcare revenue-cycle operation built on Grooper turns paper and image EOBs from bank lockboxes into posting-ready remittance data, turnaround measured in hours. Payer matching, code crosswalks and five specialist review queues run the loop above every day.
85
process steps in the graph
250+
data rules
500+
payer templates
12,000+
saved overrides
When a payer's reason code has no crosswalk, AI suggests the standard code with its reasoning, a specialist confirms it against the EOB, and Grooper saves it. The next EOB with that code is translated on its own. A person made the rule; the rule runs without the model. Elsewhere, Grooper handles Medicare administrative forms at contractor scale and tens of millions of pages for federal agencies.
HOW AUTOMATION IS EARNED
One checked decision at a time
- Checker: rules run on every proposal (identity, duplicates, balance, format) before a person ever sees it.
- Approval: nothing is written to your data without a person's yes, or a decision type that has earned auto-approval.
- Ledger: every proposal, hold, decision and write is recorded with its reason.
- Known-good set and regression run: solved documents with corrected answers; every rule or template change is re-tested against them before it goes live.
- Scoreboard: a decision type earns auto-approval after N cases at X% agreement with the person, and loses it the moment the rate slips.
Review, approval, the ledger and saved-decision loops run in production today. Scoreboard-driven auto-approval and regression runs are in development.
SECURITY BY DESIGN
Runs inside your perimeter. Grooper deploys in your Azure tenant or on your own hardware, or hosted and managed by BIS; you can change lanes later because the whole configuration serializes to JSON. Document text never has to leave your environment, Azure OpenAI inside your tenant is a supported choice, and per-field ReadScope means content that must not reach a model is never shown to one. Every action, human or agent, is a recorded row.
ALREADY A RAW DATA CUSTOMER?
If so, your users already know this work. Grooper is the successor Raw Data has planned for your workflows: capture through delivery in one system, with the document types and the people who run them carrying over. What is new is the governed validation layer above them: payer-specific, date-versioned rules, a three-state summary, and a review queue with a record. Nothing in this datasheet requires a new team.
CHECK US
Six questions to ask every vendor you evaluate, including us
- Can we set, per field, exactly what the AI is shown before it answers, not just inspect its answer afterward?
- Can a field run on rules alone, with no model, and return the same answer every time?
- Are rule sets versioned by payer and effective date as data, with the version applied stored on each document?
- Is "inconclusive" a routed state with its own queue, or does everything below a confidence score simply fail?
- Does every reviewer decision carry who, when and which rule version, and can a recurring decision become a rule without a developer?
- Can our own agents build and operate the product through an open protocol, or only through your captive assistant?
See it on your documents.
A proof of concept on your real payer documents and your rule sets, measured the way the outcome is measured: straight-through rate by payer, minutes per exception, decisions saved per week.
Your documents. Your models. Your rules. AI-native, never AI-dependent. 3 / 3