The engagement in detail
Four to six weeks from kickoff to a system running on your data
The short version is on the homepage. This is the long one: what scoping produces, what ships each week, what the gate checks, and what your team is left holding.
Scoping ends in a document, not a deck
Scoping runs before there is a price to protect, and it produces a short document both sides sign. The fixed scope is fixed to that document.
What the document contains
- The one workflow, named by the team that runs it, and what it costs them in hours a week.
- What good output looks like, written as accepted and rejected example answers. These become the first eval cases.
- The systems an answer must come from, where a human stays in the loop, and what sits outside the scope.
What you provide
Time with the people who do the work, real data rather than a cleaned-up sample, and one person who can decide.
What might happen instead
We say no. Some workflows want a promise no model can make. Scoping is a cheap place to hear it.
Working software every week, in your repositories
Kickoff to a working system takes 4 to 6 weeks, in your repositories from the first commit, under your license. The week boundaries move with the workflow. The order does not.
- Week one
Access, and the thinnest path that runs end to end
We index a real slice of your data and stand up the ugly version: question in, answer out, source attached. It is wrong often. It runs on your data, which is all week one is for.
- Week two
The tests, written before any tuning
The accepted and rejected answers from scoping become a suite that grades every change. Without it, better and worse are opinions.
- Weeks three and four
Search, the honest no, and the checkpoints
Two ways of searching at once, then a second pass that puts the best source on top. A path for questions your data cannot answer, so they get an honest no. Checkpoints, so a person signs off before anything expensive to undo.
- Weeks five and six
A pilot group, on real work
A small group uses it for real while we read the logs. Every refusal and every complaint becomes a case.
Six weeks is the long end of the range, not the plan. If the workflow turns out smaller, we rescope in the open.
How access works, and what is retainedNothing ships because it looked good in a demo
Every change to an answer path runs the full battery before a user sees it. Fail one threshold and the change goes back. The gate does not switch off after launch.
- Was it right to hold back?
- When the system said it did not know, we check that the answer really was not in your records.
- One client's data in another's answers
- Can one client's records show up in another client's answer? Checked in both of the places the system stores its search index.
- Answers we already know
- Questions with a known right answer, including ones an earlier release got wrong. One wrong value fails the run.
- The same answer every time
- The same question returns the same answer. Drift is a bug even when both readings look fine.
- Every claim traceable
- Every claim has to trace back to a document the search returned, or it is blocked.
One live system, re-measured at every release. It scored 1.000 for holding back correctly. No client's data reached another client's answers. No known answer came back wrong. The same question always got the same answer. A gate tests what somebody wrote a case for, and a question nobody thought of sits outside every figure here.
What the monthly rate is actually for
A flat monthly rate after launch, no open-ended retainer. Support is a word that means nothing, so here is the list it stands for.
Monitoring you can see too
Answers given, times it held back, searches that missed, and how fast it replied, all on a dashboard your team can open.
Incident response
A wrong answer in front of your customer is an incident, not a ticket. The fix ships with an eval case attached, so that failure cannot come back quietly.
The engineer who built it is the one on call
Not a support queue. When a provider changes a model under you, the battery runs against the replacement before it goes near your users.
The test is whether you can end the monthly and keep running
The code has been in your repositories since week one. What gets handed over is everything else you need to run it without us.
- The eval suite and the gate, wired into your change process, so your engineers can hold their own changes to the same bar.
- A runbook written for whoever is on call: what it does, where it deliberately stops, what to check first.
- The infrastructure it runs on, with the alerts pointed at your on-call rota rather than ours.
You can end the monthly rate and keep the system running. A handover that fails that test is lock-in with better manners.
What actually kills these, and what we do about it
Almost never the model. It is week four, when the scope has quietly grown. So the scoping document lists the questions the system must answer. That list is the definition of done. The weekly demo runs on your real data, never a chosen set. If we are drifting, you see it in a week, not in a quarterly review.
Where this shape does not fit
- A workflow with nothing written down behind it. Grounding needs something to ground in.
- Anything that needs a guarantee of correctness. The gate makes mistakes catchable, not impossible.
- A scope nobody can write down cannot be priced, and scoping is where that surfaces.