What the work looks like, week by week.
The three engagements below are illustrative composites built from the way our projects run. No client is described and no result is claimed. What is real: the scope, the team, the sequence of gates, and what each engagement measures.
Why we publish composites instead of testimonials
Our clients' records are sensitive, and so, often, is the fact that they are building AI at all. Our standard agreement doesn't let us name a client without written permission, and we usually advise clients not to give it.
A testimonial also tells you very little. It says someone was pleased; it doesn't say what was in scope, who did the work, how long it took, or what was measured. A composite can show all of that. Each one below combines patterns from projects of the same type. The organizations, record counts and timelines are representative, not taken from any single client, and the "measured" lists describe what the engagement measures, not results we are claiming.
If you'd rather see an actual deliverable than read about one, our sample datasheet shows the documentation that ships with every dataset, field by field.
Illustrative engagement · Healthcare
A discharge-summary drafting model for a regional health system
Illustrative composite, not a client case study. It combines patterns from several projects of this type; the organization and figures are representative.
A regional health system with six hospitals wants a model that drafts discharge summaries from the inpatient record for physicians to edit and sign. It has about 400,000 summaries from the last five years in its EHR reporting database, along with the progress notes, medication lists and results behind them. Compliance will not approve any use of identified notes, and the CMIO wants evidence that a draft is at least as complete as a hospitalist's before any pilot.
Scope: de-identification, a fine-tuning set and a clinician-calibrated evaluation for adult medicine admissions. Team: a lead data engineer, a privacy reviewer, an annotation lead, an evaluation engineer, and six hospitalists and two clinical pharmacists from our expert network, part-time. Timeline: eleven weeks.
Weeks 1–3 · Source and Protect
Working inside the health system's cloud tenant, the team profiles the notes, sets aside records flagged as substance use disorder treatment, and pseudonymizes the rest: surrogate names consistent within an admission, dates shifted per patient so the hospital course keeps its shape, locations generalized. Redaction recall is measured on 1,200 hand-labeled notes the rules were never tuned on, and the privacy officer reviews every miss.
Weeks 2–4 · Evaluation first
Before any training data exists, hospitalists write the rubric: required elements (diagnoses, procedures, discharge medications and changes, pending results, follow-up) and error types (omission, contradiction, invented fact). They grade 300 held-out admissions' real summaries against it, producing a frozen test set and a human baseline at the same time.
Weeks 4–8 · Build the fine-tuning set
From 400,000 candidates the team keeps about 6,000 source-to-summary pairs that pass the rubric's automated checks, cover service lines in proportion, and include hard cases on purpose: long stays, transfers, readmissions, discharges against medical advice. Templated summaries and near-duplicates come out, and so does anything that resembles a test admission. Hospitalists review a 10% sample; pharmacists check every medication-change statement in it.
Weeks 8–11 · Calibrate the judge and run the baseline
A judge model is calibrated against the hospitalists' grades item by item and used only on items where it agrees with them well enough. A baseline fine-tune of an open-weight model runs on the health system's infrastructure, and the results are read out to the CMIO and compliance in the same meeting.
Delivered
- A de-identified corpus of adult medicine admissions, with the re-identification key held only by the health system
- A redaction recall report by identifier type, with every miss documented
- A discharge-summary rubric and grading guide written with hospitalists
- A fine-tuning set of about 6,000 reviewed pairs, with its datasheet
- A frozen test set of 300 graded admissions and a calibrated judge
- A baseline fine-tune comparison and a provenance manifest
Measured
- Redaction recall and precision on 1,200 hand-labeled notes, by identifier type
- Agreement among hospitalists (Krippendorff's alpha) on each rubric item
- Omission and invented-fact rates per summary: physician-written, base model, fine-tuned model
- Accuracy of medication-change statements against the reconciled discharge list
- Agreement between the judge model and the hospitalist panel, per rubric item
Illustrative engagement · Insurance
Claims-file AI for a Gulf Coast property insurer after a hurricane season
Illustrative composite, not a client case study. It combines patterns from several projects of this type; the organization and figures are representative.
A property carrier writing homeowners and small commercial policies in coastal counties of Mississippi, Alabama and Louisiana comes out of a hurricane season with two landfalls and a backlog. Desk adjusters, many of them brought in for the surge, are working claim files that run to hundreds of pages. The carrier wants an assistant that answers questions about a file with citations, and a summary a senior adjuster would sign off on. Its AI governance committee wants a release gate before anything reaches production.
Scope: Document AI and retrieval over claim files, adjuster preference data, and a release gate. Team: a lead data engineer, a Document AI engineer, an annotation lead, an evaluation engineer, a privacy reviewer, and eight licensed property adjusters from our expert network. Timeline: twelve weeks, with first retrieval results in week four.
Weeks 1–4 · Make the claim files readable
Notes, estimates, photos, engineer reports, correspondence and recorded-statement transcripts are parsed inside the carrier's tenant. Estimates keep their line-item tables, photos are captioned and linked to the claim, and system-generated diary entries are separated from adjuster-written ones. Policyholder identifiers are pseudonymized in everything outside the production index.
Weeks 2–5 · Questions before answers
Senior adjusters write 600 questions they actually ask of a file ("When was the roof last replaced?" "Is there evidence of water intrusion before the storm?") and mark the page that answers each. Half come from surge-season files. The set measures retrieval before any model writes a word.
Weeks 5–10 · Adjuster preference data
For 2,400 claims, adjusters compare two candidate summaries against a rubric covering cause of loss, coverage-relevant facts, timeline and open items, and explain each choice in a sentence. Hidden gold comparisons check every reviewer, and a second adjuster reviews 15% of pairs.
Weeks 9–12 · Release gate
A golden set of 400 claims, a judge calibrated to the adjusters' preferences, and outcome checks across the geographic segments the governance committee specified are wired into the carrier's deployment pipeline. A release that moves factual errors or citation accuracy the wrong way fails automatically.
Delivered
- Parsed, indexed claim files with page-level citations, built in the carrier's tenant
- A retrieval test set of 600 adjuster-written questions with answer locations
- A preference dataset of 2,400 adjudicated summary comparisons with rationales
- A summary rubric and reviewer guide
- A release gate: golden set, calibrated judge and pipeline configuration
- Datasheets and a lineage manifest for the AI governance file
Measured
- Retrieval recall at 10 on the adjuster question set, calm-season and surge-season files separately
- Citation accuracy: whether the cited page supports the answer
- Factual-error and omission rates per summary on the golden set
- Win rate of the tuned model over the baseline in blind adjuster comparisons
- Reviewer agreement on preferences, and each reviewer's score on hidden gold comparisons
- Gate results by geographic segment, as defined by the carrier's governance committee
Illustrative engagement · Logistics
A work-order agent for a river logistics and maintenance operator
Illustrative composite, not a client case study. It combines patterns from several projects of this type; the organization and figures are representative.
An operator running towboats, a barge fleet and a repair yard on the lower Mississippi has about fifteen years of work orders in its maintenance system, roughly 220,000 of them, along with engine-room logs and a shelf of OEM manuals, many scanned. When a vessel reports a fault, a shore-side port engineer works out the likely cause, checks parts on hand and writes the work order. The operator wants an agent that drafts that work order for the engineer to approve, and proof that it works before it touches a live system.
Scope: expert trajectories, a sandbox environment with a verifier, and the compute pipeline that feeds both. Team: an agent-environment engineer, a data engineer, an annotation lead, and four senior port engineers and marine mechanics from our expert network. Timeline: fourteen weeks, with on-site days at the yard.
Weeks 1–4 · The compute pipeline
In the operator's cloud, a batch pipeline runs OCR on the scanned manuals, expands maintenance shorthand using a glossary the mechanics approve, links work orders to vessels and components across two asset re-numberings, and embeds everything for search. The cost model is agreed before the full archive runs.
Weeks 3–8 · The sandbox
The workflow is rebuilt as a sandbox: a replica of the maintenance system seeded with historical vessels and faults, a parts-inventory tool, a manual-search tool and a work-order form. A verifier compares the agent's diagnosis, parts list and labor codes with what actually fixed each historical fault. Nothing in the sandbox can write to production.
Weeks 6–12 · Expert trajectories
Port engineers work 300 historical faults inside the sandbox with the same tools the agent will have, leaving short notes on why they took each step. A second engineer reviews every trajectory. Forty are held out as a test set, split by vessel class so the agent is tested on boats it hasn't seen.
Weeks 11–14 · Baseline and readout
A baseline agent runs thousands of episodes in the sandbox, its failures are categorized with the engineers, and the results go to operations leadership with a plain recommendation on whether a supervised pilot is justified.
Delivered
- A processing pipeline in the operator's cloud, with a cost model, monitoring and a runbook
- A shorthand glossary and asset crosswalk approved by the maintenance team
- A sandbox environment with tools, seeded data and an automatic verifier
- 300 reviewed expert trajectories, with a held-out test split by vessel class
- Baseline agent results and a categorized failure report
- A provenance manifest covering every source and transformation
Measured
- Task success rate in the sandbox, as scored by the verifier
- First-time-right parts lists against the historical fix
- Tool-call error rate and steps per task
- Results on vessel classes held out of training
- Verifier agreement with port engineers on a reviewed sample of episodes
- Compute cost per thousand episodes and per thousand documents processed
What every engagement has in common
Whatever the sector, these show up in every statement of work.
- A written task specification and rubric, agreed with your experts before labeling starts
- An evaluation set built and frozen before the training data, so before-and-after numbers mean something
- Work inside your tenant or on your premises, with named accounts you can revoke
- A weekly readout: batch delivered, agreement scores, evaluation movement, open questions
- A second reviewer on at least 10% of every batch, and hidden gold questions for every reviewer
- A datasheet and provenance manifest with every delivery
- A written deletion record within 30 days of project close
Questions about these examples
Are any of these real clients?
No. Each is an illustrative composite that combines patterns from projects of the same type. Organizations, record counts and timelines are representative, and the measured lists describe what is measured, not results we are claiming.
Can we see a real deliverable?
The sample datasheet is a complete example of the documentation that ships with every dataset, built for a fictional dataset so we can show every field.
How long does a typical engagement take?
Fixed-scope pilots run three to six weeks. Builds like the three above run ten to fourteen weeks. Ongoing work after launch moves to a monthly managed operations retainer.
Can we start smaller than this?
Yes. Each engagement above could begin as one pilot: a de-identification pilot, a Document AI pilot, or an agent environment build. Starting prices are on the pricing page.
Services used in these engagements
Bring us one messy data source and one question.
Tell us what the data is and what you want a model to do with it. A data engineer, not a salesperson, will reply within one business day with questions and a proposed first step.