The model is not your moat. Your context is.
The last three years commoditised capability. Any competitor can rent the same frontier model you can, on the same terms, this afternoon. What they cannot rent is what your business knows.
- EntityWho the customer, job, site and asset actually are.
- PrecedentWhat was quoted, approved and refused before, and why.
- PolicyHow work is meant to be done, unwritten rules included.
- ProcessWhat happens next, who signs off, what blocks it.
- Current stateWhat is true right now. The shortest shelf life.
- TacitWhat lives in one senior person's head.
- PermissionWho is allowed to know each of the above.
The marked row is the one a context project cannot skip. Section 02 sets out all seven. Section 06 is a six-question scorecard you can run on your own business, with nothing sent anywhere.
Capability got cheap. Context did not.
Three years ago, model quality was a genuine differentiator. It no longer is. Every serious lab now ships a model good enough for almost any business task, the price keeps falling every quarter, and the gap between the best model and the merely very good one closes a little more each release. Capability is a utility now, and it is priced like one.
Which means: if two companies in the same industry, doing the same kind of work, are both running the same model, the only variable left between them is what that model is allowed to see. That is context. Not a wiki, not a knowledge base — the live, structured, permissioned answer to the four questions any skilled worker in your business answers without thinking: who is this, what happened before, what are we allowed to do, and what is true right now.
A general-purpose model has none of that on day one. It has read the internet. It has never read your business.
A frontier model with no organisational context is an extremely expensive graduate on their first day — every single day.
Seven kinds of context. Every business has all seven, whether anyone has named them or not.
This is the actual inventory. Not "data" in the abstract — the specific categories of knowledge a model needs before it can do skilled work in your business rather than plausible-sounding work.
- 2.1Entity contextWho the customer, job, site and asset actually are. Not an abstraction — the concrete fact that one job carries four different identities across four systems. The CRM calls it by the site name. The ERP calls it customer number 10482. The service system calls it Job JB-2291. Accounting calls it a cost centre. Nobody built these to disagree; they just grew up in different systems and were never introduced to each other.
- 2.2Precedent contextWhat you have quoted, approved, refused and priced before, and why. Not the number on the last invoice — the reasoning underneath it. Why this client gets a 90-day account and that one prepays. Why a job shaped like this one usually runs over by a margin everyone quietly expects. Why a similar job got turned down in June and what would have needed to be true for it not to be.
- 2.3Policy and standard contextHow work is supposed to be done here, including the rules that were never written down. The manual says one thing. The way your best estimator actually prices a steep-site job is a modification of that standard that exists purely because it has never gone wrong, and everyone who matters already knows it.
- 2.4Process contextWhat happens next, who signs off, and what blocks it. A purchase order over a threshold needs two approvals, not one. A price variance on a fixed-price job goes to the operations manager, never the site lead. A safety incident routes to a named person within the hour, not a ticket queue that gets triaged tomorrow.
- 2.5Current-state contextWhat is true right now: stock on hand, cash position, who is rostered on site today, what is overdue, what changed an hour ago. This is the context with the shortest shelf life in the business, and it is the one most systems get wrong first, because it is cached somewhere rather than read live.
- 2.6Tacit contextWhat lives in a senior person's head and has never been recorded anywhere. Which subcontractor to avoid on a wet site. Which long-standing client disputes the freight line on principle, every time. This is genuine operating knowledge, and on the day that person leaves, it leaves with them, unless something has already captured it.
- 2.7Permission contextWho is allowed to know each of the above — and this one is not optional. A finance question a bookkeeper can answer safely is not the same question when a subcontractor asks it. Most context projects do not fail because a model produced a wrong answer. They fail quietly, later, because it produced a correct answer for the wrong person.
A general-purpose model has zero of these on day one. Most AI pilots do not fail because the model was weak — current models are good. They fail because a confident-sounding system was asked to do skilled work with none of the seven, and it produced answers that were fluent and wrong in ways that only someone with real context would have caught.
- ERP
- CRM
- Inboxes
- Drive / PDFs
- Spreadsheets
- Chat threads
- Standards & policy
- Four people's heads
Brilliant. Knows nothing about you.
Eight sources of organisational knowledge, unconnected. One model on the other side of the gap: brilliant, and blind to all of it.
Pointing a chatbot at a shared drive is not a context layer.
Retrieval is not understanding
Nearest-neighbour search over text chunks does not resolve entities. Ask it about "the Henderson job" and it will confidently stitch together three documents about three different Henderson jobs as if they were one, because retrieval matches on words, not on identity.1
A copied index goes stale and expands your audit scope
The moment you duplicate the data you own, you own two copies of your risk, and one of them is always out of date. Every access review, retention policy and breach procedure you already have now has to cover a second store that nobody remembers exists in six months.
Permissions collapse at index time
If access is resolved when the index is built rather than when the question is asked, permissions are a snapshot, not a rule. One revoked account, one changed role, one contractor whose access should have ended last month, and the index still has them baked in.2
Documents are the smallest part of it
Most operating context is not sitting in files. It is in transactional systems — the ERP, the CRM, the accounting ledger, the scheduling tool — and in people. A retrieval layer over a shared drive answers questions about your PDFs. It has nothing to say about what is overdue right now.
None of this makes retrieval over documents useless. For genuinely static reference material — policy manuals, product specs, signed contracts, anything that does not change and does not carry a permission gradient inside itself — a well-built retrieval index is a fast, appropriate answer. The failure mode is using it as the whole context layer, for entities, transactions and permissions it was never built to carry.
Six requirements, and a test you can apply to any vendor claiming to meet them.
- 01Identity resolution per request
Every question resolves to a real, authenticated person before anything is read.3
The testAsk the vendor whether it knows who is asking before it decides what to retrieve, or whether it retrieves first and checks second.
- 02Permission resolution at question time, not index time
Access is checked against current permissions at the moment of the question, never against a role snapshot taken when the data was indexed.
The testRevoke someone's access. Ask them the question sixty seconds later. If they still get an answer, the layer resolves permissions at index time.
- 03Entity resolution across systems
The same customer, job, site or asset is recognised as one thing, regardless of how many IDs it holds across your systems.
The testAsk about a job by the name your team uses, not the ID your ERP uses. If it can't find it, it isn't resolving entities.
- 04A deliberate freshness policy
Live read where a number must be current — cash, stock, roster. Materialised only where the content is genuinely durable — a signed contract, a closed job.
The testAsk what's overdue right now. If the honest answer is "as of this morning's sync", find out why.
- 05Provenance on every answer
Every answer carries the record it came from and the moment that record was true.
The testAsk it to show its working. If it can't name the system and the timestamp, don't act on the number.
- 06A complete audit record
Every question, every answer, every record touched, logged in one place.
The testAsk who asked what about a specific customer last month. If nobody can answer that inside a minute, you have logs, not an audit record.
- ERP
- CRM
- Accounting
- Email & calendar
- Documents
- Telephony
- Identityresolves who is asking, first
- Permissionsreads as that person, never around them
- Entity resolutionone customer, one job, one asset
- Precedent & policyyour standards, quotes, decisions
- Freshness controllive where it must be current
- Governed assistant
- Persona agents
- Alerts
- Reporting
Systems you own, joined through a layer that resolves identity, permissions, entities, precedent and freshness before anything reaches an assistant, agent, alert or report.
Six questions an operator can actually answer about their own business.
Score yourself against the same rubric we use, line by line, in an AI Review. Pick the sentence that matches your business for each dimension — not the one you wish were true.
Entity integrity
unscoredCan you list every system that holds a record of the same customer or job, and say which one is authoritative?
Precedent capture
unscoredIf your best estimator left tomorrow, could someone else explain why the last ten quotes were priced the way they were?
Policy explicitness
unscoredIs the way work actually gets done here written down anywhere, exceptions included?
System reachability
unscoredCan your core systems be queried programmatically with permissions intact, or only viewed through their own screens?
Permission clarity
unscoredCould you produce, today, an accurate list of what each role is allowed to see?
Freshness requirements
unscoredHave you decided which numbers must be live and which are fine as a daily snapshot, or does everything just sync overnight by default?
Answer all six to see your band and the dimension to fix first.
Nothing here is sent anywhere. Your answers stay in this browser tab.
Not benefits copy. Operating reality.
A new quote starts from a blank estimating sheet and the estimator's memory of what similar jobs went for.
A new quote starts from precedent: what jobs like this actually cost last time, and why the last few variances happened.
A customer asks where their job is up to, and someone opens four systems and stitches the answer together while the customer waits.
The same question is answered from one place, because the four systems already agree on which job the customer means.
Shadow AI is already happening: someone is pasting client detail into a personal chatbot account to draft something faster, and nobody who runs the business knows it.
The same drafting happens inside a governed assistant that can actually see the job, with a record of what went in and what came out.
None of this makes a bad process good. Closing the context gap makes a good process fast, and it makes a bad process visibly bad — which, uncomfortable as that is in the first month, is usually worth the fee on its own. A context layer will show you, precisely, where your business improvises. What you do with that is a different engagement.
- 1Entity resolution is the unglamorous majority of the work. It is invisible when it's done well, and it is most of the real engineering in any serious context layer — matching four IDs to one real customer demos far worse than a chatbot, and matters considerably more. ↩
- 2Live reads beat cached copies for permission-sensitive data because a permission is a fact about right now, not a fact you can store safely for later. A cached index answers with the access rights the world had at the moment you built it, not the ones it has when someone actually asks. ↩
- 3Identity and permission are not the same check. Identity answers "who is this". Permission answers "what is this person allowed to see", and it has to be asked again for every single question, because roles change and access changes with them. ↩
Come and find out what your business actually knows.
An AI Review scores your business against this rubric and hands back a ranked shortlist of where a context layer would actually pay. Org Brain is what we build once you know the answer.