Three things, done end to end.

LLM and ML systems from evaluation harness to production: retrieval, agents, fine-tuning, guardrails, observability. We publish the evals alongside the model.

dataset:
  path: evals/sets/triage-v3.parquet
  labelled_by: claims-handlers (senior)   # disagreements kept, not resolved
  size: 2,1xx
  split: held-out

thresholds:                 # change only by PR with an eval run attached
  straight_through: 0.82
  route_to_handler: 0.55

metrics:
  - precision          min: 0.xx
  - recall             min: 0.xx
  - cost_per_request   max: £0.xx   # SOW ceiling; incl. retries
  - latency_p95_ms     max: xxxx

drift:
  compare: live_7d vs dataset
  on: claim_type, region, confidence_histogram
  alert: on-call-claims-platform   # pages your rota, not ours

Web, API and data products built by the two founders, end to end. Typed, tested, documented, handed over with an architecture decision log.

# ADR-011 · Secondary fraud-signal model stays in-house
Status: accepted · Date: 2026-xx-xx · Supersedes: —

## Context
The triage layer needs a second signal for fraud flags. Two
options: a third-party scoring API, or a small classifier
trained on the insurer's own labelled claims.

## Decision
Train and host the classifier in the insurer's cloud account.

## Options considered
- Third-party API   rejected: claim text leaves the data
                    boundary; p95 latency 900 ms; per-call fee
- Prompted LLM only rejected: recall 0.xx on held-out set
- In-house model    accepted: recall 0.xx, p95 40 ms

## Consequences
+ Data stays in-region; no new vendor contract
+ Inference cost per claim falls by ~xx%
- Re-labelling runbook needed (owned by claims ops, quarterly)
- One more model in the drift alert

Decided by: A. Rathi · Reported in: weekly note wk 07

Warehouses, pipelines and the governance that lets the first two actually work. Lakehouse-first, vendor-neutral, cost-modelled before build.

Do we actually need AI?

Sometimes no. Many problems are better served by a clean data model, one well-placed automation or a faster system than by a model. The discovery sprint says which is true for you, and we will say "not yet" when it is.

Is our data used to train someone else’s model?

No. We build on enterprise API tiers where inputs are not used for training, or on models self-hosted in your cloud. An NDA is signed before you share anything sensitive, and every credential sits in your accounts, not ours.

What happens when the model gets it wrong?

It will. That is why the eval set is built before the model is chosen, every decision carries its evidence and a confidence band, and anything below the band goes to a person. Accuracy is measured on your own data before roll-out, not promised in advance.

Who owns what at the end?

You do: code, prompts, eval sets, infrastructure definitions, runbooks and the accounts it all runs in. Any team can take over. A monthly care plan is available, never required, to keep it online.

Why a two-person firm and not a larger vendor?

Because the people who scope the work build it. Large firms sell senior judgement and deliver junior capacity; freelancers can disappear. We are two senior people, accountable by name, and we will tell you when you need fifty engineers instead.

We are not in India. Does that matter?

No. Remote by default, on site by arrangement. Work runs with weekly demos and a written note; we keep 09:00–20:00 IST, which covers the Gulf working day and most of the European and UK one.

What is the smallest way to start?

A two-week discovery sprint at a fixed fee. You get a findings document, a prototype and a costed build plan, and you keep all three whoever you build with.

How do you price?

Fixed price for scoped work, billed by milestone, never a large lump sum up front. We do not publish a rate card; a fixed itemised quote follows the discovery call, and you can stop after any milestone and keep what was built. No hourly billing.