Teams with a real domain
You are building retrieval over a domain you know, and you already feel the cost of leaving the atomic unit undefined: drifting quality, debates that reopen, regressions you cannot explain.
Home › The reading
The reading
Bring one domain.
Leave with a data model.
Twenty minutes, one domain, three artifacts you keep whether or not we ever work together. This is a working session between engineers, not a demo.
What you leave with
Three artifacts, yours to keep.
01
Your atomic unit, in one sentence
The single event that is your chunk boundary, named precisely enough to build on.
02
A first draft of its event schema
The typed fields and timestamp you would lock in week one, sketched on the call.
03
The benchmark that proves it
The shape of the 50-query set with known answers that will tell you iteration 5 beat iteration 4.
If we cannot produce those three in twenty minutes, the call was free and you have lost nothing but the time.
Before you book
This call is not for everyone.
Anyone shopping for a demo
This is not a managed RAG product pitch or a tool walkthrough. If you want someone to take the problem away rather than help you name it, we are the wrong call.
The twenty minutes
How the call runs.
0-5
We name your atomic unit
The one event that is your chunk boundary.
5-12
We sketch your core event schema
The typed fields and timestamp you lock in week one.
12-18
We define your benchmark queries
The shape of the 50-query set that guides every later decision.
18-20
You decide
Build it with us, or take the plan and run. Either is a good outcome.
Come with one thing: one domain, and one real query you wish your retrieval answered well and it does not.
Straight answers
Questions a skeptic asks first.
Isn't this just structured logging?
It is structured logging with a retrieval contract. A log is written to be grepped by a human during an incident. An event here is written to be embedded, ranked, and assembled into a brief a model reads. Same instinct, opposite consumer. If your logs already carry a typed schema and a timestamp, you are most of the way here.
Why not just wait for bigger context windows or better models?
Because lost-in-the-middle is a ranking problem, not a capacity problem. A bigger window is more middle to lose. The positional bias is a property of attention, not of model size, which is why every generation ships with it. You do not wait out a structural problem.
We already have a RAG stack.
Then the question is narrow: can you name your atomic unit, are your indexes version-tagged, and do you have a benchmark that proves iteration 5 beat iteration 4? Three yeses and you do not need us. Any no is the leak, and it compounds in silence until quality visibly drops.
This sounds rigid.
It is rigid where rigidity is cheap and flexible where it matters. Schema-first on the types you know, a structured catch-all for the rest, mined quarterly and promoted into first-class types. Determinism on the known, signal on the unknown. The rigidity is what makes retrieval reproducible.
Who are you, and why should I trust this?
Do not trust it, test it. The method reduces to a number: 50 queries with known answers, run against every change. We hand you the instrument that proves or kills the architecture. Bring your domain, leave with the benchmark spec, run it yourself.
What does twenty minutes actually give me?
The three artifacts above, yours to keep whether or not we work together. If we cannot produce them in the time, you have lost nothing but twenty minutes.
How much does an engagement cost?
Scoped to your domain and named on the call. The sharper question is what another quarter of unexplained retrieval regressions is already costing you.
The reading
Pick a slot. Bring one domain.
Twenty minutes, three artifacts you keep, and a clear next step whatever you decide.
Book my technical call →