A six-stage system for the other half of AI consulting: making a company's own documents answerable. Start with the questions the business actually needs answered, score the corpus that would have to answer them, and only then build a retrieval system — with a trust discount applied before anyone writes code.
Ask first. Score the corpus. Earn the right to build.
LEVER and RECALL share a spine — a signed goal, a scoring instrument, honest gates, a sequenced plan, and a paid diagnostic that can recommend against building. They differ only in the unit of analysis. One routing question decides which applies.
"We keep making this call badly." Recurring operational judgements with recorded outcomes. Output: a bespoke ML decision tool — a ranked worklist, a forecast, a flagged queue.
Binding constraint: are past decisions outcome-labelled?
"We can't find or trust what we already know." Recurring questions whose answers exist somewhere in the document estate. Output: a retrieval system people can rely on.
Binding constraint: is the corpus in a fit state to be retrieved from?
"When this goes wrong, is it because someone chose badly, or because someone couldn't find out?" Ask it in the first meeting. The answer decides which method applies. Most sellers have one product and bend the problem to fit it; the question exists so that does not happen here.
Published 2026 build data says the quiet part plainly. In one legal-tech project, ingestion and OCR alone were 29% of total cost. Access control, not the LLM, is repeatedly named the dominant cost driver. And across every pricing tier, the same sentence appears: messy source documents are the biggest schedule risk.
of one documented legal-tech RAG build — before a single retrieval query was tuned.
competitors selling a corpus diagnostic. Everyone quotes the build, discovers the mess, and eats the overrun — or passes it to the client as a change request.
rising to $80–150k+ on-premises with SSO and compliance logging. That is the number at risk when the corpus turns out to be unfit.
A retrieval system cannot be better than the corpus it retrieves from — and nobody measures the corpus before quoting the build. That single omission is why these projects overrun, why demos impress and production disappoints, and why a four-week paid diagnostic is not an upsell but the cheapest insurance a buyer will ever be offered.
R·E·C is the paid diagnostic and stands alone. A·L·L is the build. As in LEVER, the client can stop after C and still own something valuable — which is exactly why they say yes to C.
Phase 1 · The RECALL Diagnostic · 4–5 weeksStart with what people need to know, never with what documents exist. Every question gets a row in the Question Ledger: who asks it, how often, how long it currently takes to answer, and what it costs when the answer is late, wrong or never found.
Find every place an answer could live, and who governs it. This is where projects quietly die: the authoritative version is in a mailbox, a shared drive nobody admits to, or a system whose owner left.
Sample and score. This is the stage nobody else sells, and it is the reason the build quote is safe when everyone else's is a guess.
The architecture is prescribed by the question archetype, not by fashion. Metadata is designed before chunking, because chunking without metadata is how you build something that retrieves confidently and wrongly.
The gold set exists from stage C, so evaluation is not an afterthought bolted on when someone complains — it is the acceptance criterion the contract is written against.
Adoption is a trust problem here, not a training problem. People abandon a retrieval system the third time it answers confidently and wrongly, and they never come back.
Six dimensions, 0–5 each, scored from a stratified sample. Total 0–30, then normalised to 0–1 as the C term in the equation. This is the instrument that turns "your documents are a mess" — a sentence that sounds like blame and closes the conversation — into a number the client can act on.
Can clean text be got out at all? Scans, image-only PDFs, tables that collapse into soup, multi-column layouts, handwriting.
Is there hierarchy to preserve — headings, clause numbering, sections? Structure is what lets chunking keep meaning instead of slicing it.
Duplication and near-duplication. The classic finding: half a repository is the same documents with trivial format differences.
How much is stale or superseded — and crucially, can you tell? An undated corpus cannot answer any time-sensitive question safely.
Do you know source, author, version, effective date and authority tier? Without provenance you cannot cite, and without citation nobody trusts it.
Access rules, PII, confidentiality tiers, retention obligations, and the material that must never be retrievable at all.
A CCI is a reusable asset for the client even if they never build anything. It tells them which repositories to consolidate, what their retention exposure is, and where the authoritative version of the truth actually lives. Some clients remediate and postpone the system — and that is a good outcome.
Seven question archetypes. The archetype prescribes the architecture — and, more valuably, tells you when the honest answer is this is not a retrieval problem. Three of the seven are not. Naming them is the most credible thing you will do all engagement.
| Archetype | Example question | Architecture | Honest note |
|---|---|---|---|
| Lookup | "What's the notice period in the Acme contract?" | Small chunks, hybrid lexical + dense, hard metadata filters, rerank. The easiest win. | Retrievable. Start here — it builds trust cheaply. |
| Procedural | "How do I onboard a supplier in France?" | Hierarchy-preserving chunking; a step must never be split. Parent-document retrieval. | Retrievable, but fixed-size chunking destroys it. |
| Compare | "How does this policy differ from the 2024 version?" | Multi-document retrieval with version metadata, then structured diff — not free-text generation. | Retrievable only if Currency and Provenance score well. |
| Trace | "What changed, when, and who approved it?" | Temporal metadata, versioned corpus, event-style indexing. | An archive-design problem before it is a retrieval one. |
| Synthesise | "What's our overall position on data residency?" | Hierarchical retrieval, map-reduce summarisation, mandatory citation, forced abstention on thin evidence. | Highest hallucination exposure. Apply a heavy Trust Discount. |
| Aggregate | "How many contracts have terms over 90 days?" | Not RAG. Structured extraction into a table, then SQL. Retrieval cannot count and will confidently guess. | The single most common doomed request. Say no early and propose extraction instead. |
| Judgement | "Should we accept this clause?" | Not RAG alone. Retrieve, cite and assemble the evidence — then a human decides. Never generate the conclusion. | If a client insists, this is a professional-indemnity conversation, not a build. |
"About a third of what you've described isn't a search problem — it's a counting problem, and search will answer it confidently and wrongly. Let me show you which ones."
Nobody selling a RAG build says this.
Deliberately the same shape as LEVER's — one mental model across both methods — with one term that only exists here. Output in pounds per year, per question class.
Value of the answer × Answerability × Trust discount
How many times a year this question class is asked. From search logs and ticket systems, never from a workshop.
Time to answer at loaded cost, plus rework, plus duplicated effort, plus the cost of deciding without the answer.
0–1. The fraction of Δ that finding could remove. If the answer genuinely does not exist anywhere, no retrieval system creates it — and pretending otherwise is how these projects earn their reputation.
Corpus condition × retrievability of the archetype × adoption and trust feasibility. Multiplied, not averaged — any zero correctly kills the whole thing.
0–1. The share of value destroyed by an unacceptable wrong-answer rate in this domain. The term that exists here and nowhere else.
A£ ÷ (build cost + year-one run cost). The ranking number. Build if AQ ≥ 3.
In a high-stakes domain, a system that is right 90% of the time can be worth less than nothing — because every answer must now be verified by hand, so you have added a step rather than removed one. H is what stops that system being built. Set H high for clinical, legal-advice, regulatory and financial-promotion contexts, low where a wrong answer is merely annoying and obvious.
Pre-loaded with a 200-person professional services firm and the question class "Have we done work like this before, and what's reusable?" — scored after corpus remediation. Drag C down to 0.45 to see it today: A£ falls to £193,882 and AQ to 1.88, which is the entire argument for remediation first.
Answerability C·R·A = 0.512 · the ceiling on everything downstream
Checked in this order, before AQ. A large A£ sitting on an unfit corpus is a mirage, and AQ will happily endorse it.
The corpus cannot support retrieval yet. Run a corpus remediation project — dedup, OCR, dating, metadata backfill — then revisit. This is the honest recommendation, and it is real work, not a delay.
Structured extraction into a table plus SQL. Retrieval cannot count. This gate alone saves one doomed build a year.
Build retrieve-and-cite for a human reviewer. Never generate the conclusion. The scope shrinks, the fee shrinks, and the answer stays defensible.
Fifty to a hundred real questions with verified answers and source spans, before a line of code. Without it there is no acceptance criterion, fixed-fee is unsafe for both sides, and "is it working?" becomes a matter of opinion forever.
Below three times year-one cost the risk premium on a bespoke retrieval system is not earned. Narrow to a single question class, or walk.
Remediation is a separate engagement because it is separate work — and keeping it separate is what keeps the build scope honest.