02 / IN PRACTICE
Claims that take weeks, decided on one screen
GembaOS is a zero-trust governance runtime for enterprise AI agents: policy-decided access, single-use clearance tokens bound to exact parameters, and accountable human approvals, running on-premises or in a private VPC. This scenario is the claims desk. A model reads the file and GembaOS holds what it read to the record, so a small, clean claim is settled in minutes. A claim that runs for weeks and passes the adjuster, medical review and legal still ends as one approval request that a manager can decide on one screen.
What does the model do on a claim, and what can it not do?
The claims playbook declares an investigator: a model with read access to the claim and the policy and one typed form to fill in. It reads the statement, every file and every answered document round, and hands the people who sign a brief.
| The investigator does | The investigator cannot |
|---|---|
| Read the amount and the date off the receipts, invoices and certificates | Propose the amount: the reserve is the claimed amount on record |
| Write a short chronology and a summary, keeping facts apart from inference | Pick a finding: covered, not covered and the rest belong to the signers |
| Raise issues from a closed list (amount differs, prior condition, possible exclusion and others), citing the policy’s clauses and quoting their words | Cite a clause the policy does not carry, or put words in one: GembaOS marks a clause the policy lacks “not in the policy”, and checks every quote against the clause’s own text |
| Sort each file into a kind: medical record, receipt, invoice, photo | Decide that the file is complete: GembaOS counts the required kinds against the files the case really has |
| List the documents still missing and who is worth consulting | Send anything to the applicant, or sign, or change the route in any direction but stricter |
GembaOS checks the brief before anyone reads it. Every value with a counterpart in the claim record is compared and marked Matches or Differs. A difference, an issue, or no brief at all (the model is down) is a risk flag on the request, and a flag only ever adds a person to the route. The signer reads the one line that differs, not every page.
How do I know the clause says what the brief says it says?
Because the clause is there to read, and the quote is checked against it.
An issue that cites a clause has to carry that clause’s own words. The investigator reads the policy wording through a read of its own, and copies the sentence it relies on into the brief. GembaOS then does two things a model cannot talk its way past: it holds the clause number to the clauses the policy record carries, and it holds the quoted sentence to the text of that clause, character for character (spaces and case aside). The form shows one of:
| On the form | What it means |
|---|---|
| these words are in the clause | the quote is in the clause the citation names |
| these words are NOT in the clause | the clause was read and does not say this - a paraphrase, or worse |
| no words quoted | the citation is not backed by anything |
| not in the policy - disregard | the policy record carries no such clause |
Anything but the first is a risk flag, so the fast lane closes and a person looks.
What this proves is narrow, and we would rather say so: the words are the clause’s. Whether the clause carries the point the brief makes is a judgment, and it stays the signer’s - which is why the clause is printed in full beside the quote, with the quoted sentence marked in it. The reader is one glance away from the wording instead of one search away.
What happens to a small claim?
A small claim takes the fast lane. The applicant confirms the statement on the ticket page. The claim is within the playbook’s auto band and within the tenant’s authority matrix, a file is on record and nothing is flagged, the brief included. The playbook’s rule then signs, and the reserve is booked under a clearance token and read back. The applicant has the answer within seconds. Both limits are the customer’s: remove the band and every claim goes to the adjuster.
A small claim with anything flagged goes to the adjuster instead. In the demo below, a clinic receipt totals $180.00 against a claim of $120. The line is marked “Differs”, the fast lane stays shut, and the adjuster decides with the receipt one click away.
Who chases the missing documents?
GembaOS keeps the case on the work item, not on the approval. The playbook names the documents each kind of claim must have: an accident claim a medical record and a receipt, a property claim the repair invoice. The investigator sorts every file into a kind; GembaOS checks each against the files the case really has and counts what is missing. The count is GembaOS’s, not the model’s: a kind counts only when it names a file the case really has, and the signer sees which file was sorted as what.
For the required documents, GembaOS asks the applicant itself, in a document round: the kinds, a due date, and one reminder three business days before it. The applicant sees the kinds only, never the model’s words, and answers on the ticket page with files and a sentence, or by replying to the email. The investigator reads each answer again, and GembaOS asks for what is still missing, up to the playbook’s limit on rounds. The adjuster can still ask for anything else. The approval request is drafted only when the file is complete, once.
What if the documents never come?
The playbook says, in one setting, what happens when a due date passes or the rounds run out with a required document still missing:
| Setting | What happens |
|---|---|
| The handler decides | Recorded; the adjuster sees it on their desk and decides |
| Escalate | The case moves to the desk of a named role, for example the claims manager |
| Close as incomplete | The applicant is told the documents did not arrive; this is not a decision on the claim, and they may claim again |
| Decline | A decline request is drafted and goes to the people the route names; a person signs it, or refuses and the case returns to the adjuster |
A decline is never executed on a missed date alone. A playbook can let its own rule sign one, but gemba config check then warns that a claim could be declined without a person signing.
| Before | With GembaOS | |
|---|---|---|
| Reading the file | The adjuster reads every page and retypes the amounts | The investigator reads it; each value is marked as matching or differing from the record |
| Small claims | The same queue as the large ones | The fast lane once the applicant confirms, within the tenant’s limits, nothing flagged |
| Missing documents | A reminder in someone’s diary, forgotten when they change desks | GembaOS asks for the required ones itself, reminds once, and applies the playbook’s setting when they do not come |
| What the claimant said | Retyped into a claim note | Their own words and files, rendered back to them and confirmed, pinned by a hash |
| Medical or legal opinion | A comment in the file | A consult finding from a closed list, in the signature chain |
| The manager’s review | The whole file, from the top | What changed since they last looked, then the one decision left |
| Booking the reserve | Keyed in after the approval email | Executed once under a clearance token, after the claim is read again |
What happens, step by step?
| Step | Who | What is recorded |
|---|---|---|
| 1. Intake | The claimant writes on the claim number; the runtime records the statement and files and issues the ticket | The statement, the files, the claim it names (only the claimant’s own) |
| 2. Brief | The investigator reads; GembaOS checks its values against the record | The brief, each value marked as matching or differing, the flags |
| 3. Documents | GembaOS asks for the required kinds the files lack; the claimant uploads; the investigator reads again | Each round: kinds, due date, the reminder, what came back and when, the new brief and the new count |
| 4. Confirmation | The claimant confirms what was recorded, or says what is wrong | The applicant confirmation, or the correction beside the original |
| 5. Fast lane | GembaOS, on the confirmation | Taken (the rule signs), or not taken, with who signs instead and why |
| 6. Proceed | The adjuster, when the file is complete | One approval request with the brief on top, the claim as read and derived facts: days since the incident, rounds answered, files on record |
| 7. Sign | The adjuster, then the claims manager, each with a finding | The signature chain with findings and reasons |
| 8. Execute | The runtime, under the clearance | The claim read again against what the approvers saw, then the reserve booked once |
Who signs when AI suggests a denial?
The model never suggests a denial here: it raises issues from a list, and people decide. The people on the route sign with findings the playbook defines. The adjuster’s are covered, not covered, or needs investigation. Medical review’s are treatment necessary, not necessary, or records insufficient. Legal’s are exclusion applies, does not apply, or ambiguous.
A finding also decides what happens next. “Needs investigation” puts medical review on the route right after the adjuster. “Records insufficient” returns the request and asks the claimant for the medical record. The approver picks the finding; the playbook decides the move.
On the regulatory side, the EU AI Act lists risk assessment and pricing for life and health insurance among high-risk uses (Annex III, point 5(c)); in the United States, the NAIC model bulletin on insurers’ use of AI asks for a written program and accountability for decisions that AI supports. Whatever applies to your book, the record here names who decided, on which facts, with which finding, and what the model read.
What does it look like?
Two small claims on the same desk: one the brief stops, one through the fast lane.
What do we need to start?
- Your claim handling authority as it is today: who signs up to which amount, when medical review or legal is consulted, and whether small claims may be settled by rule at all.
- Read access to claims and policies, and one adapter that books the reserve, through the REST or SQL adapter.
- The values the investigator should read off the documents and the issues it may raise, in your own words.
- The documents each kind of claim must have, and what happens when they do not come.
- A model profile for the investigator, self-hosted or SaaS, within your data egress ceiling.
- The findings each role signs with, in your own words.
- The claimant’s channel: the ticket page, email, or both.
Related: procurement exceptions, refunds under an approval limit, why an agent should ask for documents by kind.
Questions this note answers
Can an AI agent decide an insurance claim?
Not in GembaOS. An investigator model reads the file and briefs the people who sign; it proposes no amount and picks no finding. A claim ends in an approval request that named people sign with a finding from a closed list, or, for a small confirmed claim with nothing flagged, the playbook's own rule signs within the tenant's authority matrix.
What does the AI do on a claim?
It reads the statement, every file and every answered document round, and the claim and policy records, then hands in a typed brief: the amount and the date the documents give, a chronology, issues from a closed list citing the policy's own clauses, the documents still missing and who is worth consulting. GembaOS compares each value with the claim record and marks it as matching or differing.
How do I know the AI did not invent a policy clause?
Because the clause is on the form and the quote is checked against it. An issue that cites a clause has to carry that clause's own words; GembaOS holds the clause number to the clauses the policy record carries and the quoted sentence to that clause's text, character for character. "Not in the clause", "no words quoted" or "not in the policy" is a risk flag, and the clause is printed in full beside the quote. The check proves the words are the clause's, not that the clause supports the point - that judgment stays with the person signing.
Who chases the missing claim documents?
GembaOS does, for the documents the playbook requires. The investigator sorts the files into kinds; GembaOS counts which required kinds are not on file and asks the applicant for them itself, with a due date and one reminder. The adjuster can still ask for anything else. When the documents do not come, the playbook's setting applies: the adjuster decides, the claims manager takes the case, it is closed as incomplete, or a decline goes to the adjuster to sign.
What does the claims manager see after two weeks away?
What changed since they last looked (days waited, signatures and findings added, new files, rounds, the applicant's confirmation), then the one remaining decision: their role, the question set for it, and any finding still open.
Last updated: · GembaOS v0.2