Claims are beaming in from Planet Nieuw-Vennep. Fender benders go straight through. Red shirt injuries go to a specialist. Anything that smells like a Ferengi goes to SIU.
We built this claims AI in Oumi. You can build your own.
Three fictional claimants. Three very different problems. One claims desk trying to route them before the next shuttle arrives.
A Red Shirt lost on an away mission, a lawyer instructed, and warning signs that only line up when the three documents are read together.
STARFLEET INSURANCE — FIRST NOTICE OF LOSS Claim Number: DEMO-01 Policy Number: DEMO-POLICY-01 Date reported: 2371.203 Reported by: Lt. Cmdr. security division, USS Enterprise (NCC-1701-D), on behalf of next of kin INSURED Name: Jones, M. (Crewman) Division: Operations, Away-Team Support Policy in force since: 2368.014, no lapses LOSS DETAILS Date/time of loss: 2371.201, approx. 1140 hours shipboard time Location of loss: Class-M planet survey site, designated LZ-2, unnamed system (survey mission authorization #SM-4471) Type of loss: Fatality, away-team member, cause under review LOSS NARRATIVE (as reported by surviving away-team members) The away team (four personnel, including Crewman Jones) beamed down to LZ-2 to conduct a routine mineral and atmospheric survey per mission authorization #SM-4471. Approximately 40 minutes into the survey, the team came under sudden energy-weapons fire from an unidentified small craft that had not hailed, challenged, or otherwise signaled the team prior to firing. No away-team member discharged a weapon, issued a challenge, or took any action prior to the first shot. Crewman Jones was struck directly by the first shot and was not recovered — away-team members reported he "was gone" at the location where he had been standing, with a quantity of fine particulate residue at the site. The remaining three team members took cover and were beamed back to the ship without further injury. The unidentified craft departed the area at high impulse before it could be hailed or identified by ship's sensors; partial sensor telemetry has been forwarded to Starfleet Security for identification. INJURIES / FATALITIES Fatalities: 1 (Crewman Jones). No remains recovered for standard processing; particulate residue collected at scene by away-team medic, forwarded to Sciences for analysis (see attached lab note). Other injuries: none reported. WITNESSES Three surviving away-team members provided statements. All three statements agree on the sequence of events described above. One witness statement notes Crewman Jones "seemed distracted" in the minutes before the incident and had stepped slightly apart from the group to check a tricorder reading, though the witness could not say what he was reading. LEGAL / REPRESENTATION Next of kin has retained outside counsel (Voss & Tellun, Starbase 12) as of 2371.202. Counsel has sent a preliminary notice indicating intent to pursue recovery from the operator of the unidentified craft, once identified, for the unprovoked attack, in addition to the claim filed under this policy. POLICY / ACCOUNT NOTES (per account history) - 2371.187 (14 days prior to loss): beneficiary designation on the policy changed from spouse-of-record to a named civilian individual, S. Rell, listed relationship "personal associate," processed via standard self-service beneficiary-change form. - 2371.187 (same date): coverage limit increased from 75,000 credits to 300,000 credits via standard self-service coverage-change form. - No other account changes in the 12 months prior to loss. REQUIRED NEXT STEPS PER STANDARD FNOL INTAKE - Away-team medical tricorder scan from scene: attached (see DEMO-01, document 2 of 3). - Sciences forensic lab note on collected residue: attached (see DEMO-01, document 3 of 3). - Sensor telemetry request to Starfleet Security: submitted, pending. - Next-of-kin counsel correspondence: on file, available on request. [END FNOL INTAKE FORM]
The highlighted facts drive the route. In a real deployment, these rules would come from the carrier's decision contract.
Press Make it so to route this claim.
Three claimants. Three routes. Zero actual redshirts harmed in testing.
Licensed people make coverage, reserve, settlement, and fraud decisions. The model recommends the next path. It doesn't make the claim decision. All claims are fictional.
On a frozen 197-claim test, Oumi-Starfleet routed 92% correctly versus 78% for Claude Sonnet.
Oumi-Starfleet was stronger on exact routing and over-routing in this test. Claude Sonnet was stronger on mandatory escalation recall. The next build should improve the safety boundary without losing the routing advantage.
Start with a prompt. Oumi handles the build loop.
You describe the decision, the output you want, and the boundaries the model should respect. Oumi creates starter samples, trains a specialist, evaluates it, and gives you a model to try.

You're not here to build another Starfleet model. You're here to improve a decision inside your own company.
Copy the build prompt and paste it into the Oumi platform assistant. Swap in your own decision workflow, or keep Starfleet's claims desk to start.
Here's what I'd recommend someone type as their first message:
I want to build a claims triage model for my property & casualty insurance company. The model should read an incoming claim description (free-text from a policyholder or agent) and classify it into a triage tier — urgent, standard, or low-priority — while also extracting key fields like claim type (auto, home, liability), estimated severity, and whether fraud indicators are present.
The output should be structured JSON so it can feed directly into our claims management system. Here's an example of what a good input/output pair looks like:
Input: "My car was rear-ended at a stoplight on 6/12. The other driver fled the scene. Airbags deployed, I was taken to the ER by ambulance. Police report filed #2024-38291."
Output:
{
"triage_tier": "urgent",
"claim_type": "auto",
"severity_estimate": "high",
"fraud_indicators": false,
"reasoning": "Bodily injury with ER visit, hit-and-run, police report present. Requires immediate adjuster assignment."
}
The users are claims intake specialists who currently do this manually. We process ~2,000 claims/week and want to auto-triage the obvious ones so adjusters focus on complex cases.
Edge cases I'm worried about: claims with multiple coverage types (e.g., auto + medical), vague descriptions with almost no detail, potential fraud red flags, and claims that reference prior open claims on the same policy.It hits every dimension I'd need to build a strong end-to-end workflow without follow-up questions:
Compare it to what most people actually type:
"Help me build a claims triage model"
That 6-word version would require me to ask 5–6 rounds of clarifying questions about output format, claim types, triage logic, edge cases, and who the users are. The detailed version skips straight to building — I could go directly to setting up the acceptance rubric, picking models, and generating data.
If someone's adapting this for their own use case, the formula is:
Let Oumi synthesize the data, fine-tune the model, and score it against a held-out set. Then deploy it and call its API with a real claim. A working endpoint is the bar.
Tell us what worked and what to fix. Then tell us where to ship the mug.
For the person running the booth. Not part of the visitor flow.
Pings the model every 90 seconds. This lowers cold-start risk but can't prevent every delay.
Uses recorded answers from this model. Every replay is labeled as recorded.
The endpoint is connected and waiting for a claim.