Boldly triage every claim

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.

Scroll to beam them down

Run the claims desk

Three fictional claimants. Three very different problems. One claims desk trying to route them before the next shuttle arrives.

Checking the model...
Warning signsCrewman M. JonesRed Shirt · Operations · Away missionPossible SIU referral
Death at the sceneFatal collisionCrew member on shore leave · Starbase 12 colonyMandatory complex escalation
Complete low-severity packetCracked cooktopCrew quarters · Starbase 12Straight-through candidate
Request · Claim packet

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.

Evidence the decision contract cares about
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.

Sends this exact packet to the deployed model.
Response · recommendation

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.

The Starfleet model did pretty well

92%
Oumi-Starfleet
vs
78%
Claude Sonnet

On a frozen 197-claim test, Oumi-Starfleet routed 92% correctly versus 78% for Claude Sonnet.

ResultOumiClaude SonnetProduction path
Exact routingOumi 181/197Claude Sonnet 153/197Add carrier-specific examples and boundary cases.
Must-escalate claimsOumi 56/59Claude Sonnet 59/59Missed escalations: add deterministic safety checks and targeted SIU training.
Over-routingOumi 12/197Claude Sonnet 30/197Add cost-aware examples showing when not to escalate.
Under-routingOumi 4/197Claude Sonnet 10/197Add hard negatives and fail-closed validators.
Conflicting answersOumi 0/197Claude Sonnet 4/197Enforce one structured response and retry invalid outputs.
Prompt retriesReduce prompt size and test production token limits.

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.

How you can build this

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.

Start with the prompt and the agent automates all the steps.
Prompt: Start with the prompt and the agent automates all the steps.
The Starfleet Insurance mug: the HQ building, a red shirt beaming up, and two more on the street.

Now build one for your company and get the Starfleet mug

You're not here to build another Starfleet model. You're here to improve a decision inside your own company.

  1. 1

    Sign up for Oumi.

    Make an account on the Oumi platform.

  2. 2

    Start your build.

    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.

    The Perfect Starting Prompt

    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.

    Why This Prompt Works

    It hits every dimension I'd need to build a strong end-to-end workflow without follow-up questions:

    DimensionWhat it provides
    TaskClassification + extraction (triage tier, claim type, severity, fraud flags)
    FormatStructured JSON output — unambiguous, testable
    Concrete exampleA real input/output pair that calibrates tone, detail level, and field values
    UsersClaims intake specialists — tells me the reading level and domain context
    Scale context2,000/week — justifies a small, fast, task-specific model over an API
    Edge casesFour specific ones, each with a real business scenario
    Why a fine-tuned modelAuto-triage the obvious ones — a clear cost/speed motivation

    What Makes It Better Than a Vague Prompt

    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.

    Key Ingredients to Include

    If someone's adapting this for their own use case, the formula is:

    1. What the model does — the specific task, not just the domain
    2. One concrete input → output example — worth more than a paragraph of description
    3. Output format — structured (JSON/labels) vs. free-text, and what fields matter
    4. Who uses it and how — shapes tone, complexity, and error handling
    5. 3–5 edge cases you’re worried about — the hard cases define the model more than the easy ones
    6. Why a fine-tuned model — helps me right-size the approach (small/fast vs. large/capable)
  3. 3

    Train it, deploy it, and test the API.

    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.

  4. 4

    Submit product feedback and claim the mug.

    Tell us what worked and what to fix. Then tell us where to ship the mug.

Booth operator

BOOTH OPERATOR

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.

Endpoint status
Ready

The endpoint is connected and waiting for a claim.