Every organisation that deploys AI discovers the same thing: the model does the same work over and over. Ask it a hard question about your business and it starts from a blank interpretation of your world, re-deriving conclusions your people reached months ago. This is written by Fifty One Degrees, a UK and US AI consultancy that embeds senior practitioners inside mid-market teams and runs this pattern, a curated context layer, in production today.
Last updated: July 2026
The Short Answer
A context layer is a curated, governed layer of your organisation's current knowledge that sits between your documents and your AI. It records the running conclusion, what is true now, who owns it, what was promised and what was ruled out, rather than the raw pile of emails, meeting notes and contradictory document versions a model would otherwise reconcile from scratch every time. Almost no organisation writes this down: it lives in the heads of senior people. That is why AI that is brilliant in general is mediocre inside your business. A context layer is defined by five principles, not one technology: it is native to the model, provenanced, temporal, human-reviewable and adjudicated. Get those right and no one, and no model, starts from a blank prompt.
Why is general-purpose AI mediocre inside your business?
The frontier models are extraordinary. Drop one into your organisation and it turns ordinary. The reason is subtle, and it is not the model's fault.
An email thread or a meeting note records what was said once, in one room, at one moment. The truth about a project rarely lives in any single document. It emerges across dozens of them, and they contradict each other, because that is what progress looks like. A model handed that pile has no way to tell the current answer from a superseded one. It reconciles everything from scratch, every time, and it does so unreliably.
What your organisation actually needs the AI to remember is the running conclusion: what is true now, who owns it, what was promised, what was ruled out. That a regulation does not apply in this domain because someone already checked with Legal. That a colleague's off-hand comment in a meeting was exactly that, and not something to treat as canonical. Almost no organisation writes any of this down. It lives where it has always lived, in the heads of senior people.
So capable people burn hours, and tokens, reconstructing conclusions they or others have already reached. The fix is a layer of captured, current organisational knowledge sitting between your documents and your AI. We call it the context layer.
Why don't RAG and knowledge graphs solve this on their own?
The first generation of solutions each got something right and each missed the same thing.
Retrieval-augmented generation (RAG) scales cheaply to millions of documents, but vector matching retrieves fragments by similarity. No relationships, weak provenance, no sense of time. It tells you what is similar, not what is true, and certainly not what is still true. It also cuts against how models actually answer hard questions. A model's strength is not one-shot retrieval but traversal: query, inspect what comes back, decide the next hop, repeat until the picture is complete. Vector search gives that loop nothing to hold onto, because each hop just returns more disconnected fragments. RAG remains the right tool for the knowledge layer of a Claude implementation, but it is not a context layer.
Knowledge graphs are the natural response, and they fit the traversal loop properly: every hop returns structure, typed relationships, entity attributes and sources, that the model can reason over before choosing where to go next. But traditional graph databases are not natively model-friendly, and certainly not human-friendly. A graph of millions of nodes cannot be audited line by line the way a compliance function needs. And most graphs have no concept of time: a fact that stopped being true last quarter sits in the graph looking identical to one decided yesterday.
Both approaches share a deeper flaw. They can only ever reflect what the documents say. The interpretation a user adds, the check with Legal, the conclusion reached after reading all ten versions of a plan, has nowhere to be recorded, so it is lost the moment the conversation ends.
What the curated LLM wiki gets right
The markdown-wiki pattern, popularised by Andrej Karpathy, takes the opposite approach: curated knowledge, compiled once, in a format the model reads and writes natively. When someone checks with Legal or kills a proposal, that conclusion finally has somewhere to be written down. And it recreates the traversal loop in miniature: the model navigates from index to page to linked page, each hop human-readable, and when it reaches a conclusion worth keeping, it writes that conclusion back into the wiki.
Curation quietly solves the problem that sinks most enterprise knowledge bases: agreeing what things are called. Canonical page names, aliases and cross-links form a lightweight registry the model maintains as a by-product of normal work, so the same thing is called the same thing everywhere, without a six-month upfront ontology-modelling exercise.
It delivers the five principles a context layer must have:
- Native to the model, so it improves through use.
- Provenanced, so every claim is traceable to its source.
- Temporal, recording not just what is true but when it became so, and when it stopped.
- Human-reviewable, so a compliance function can audit it line by line.
- Adjudicated, meaning when sources conflict the conflict is surfaced and resolved by a person with the authority to resolve it, never silently averaged by the model. A confidently wrong answer wearing false authority is worse than no context layer at all. And the moment a human resolves a conflict is the moment their interpretation gets captured, which is the whole point.
Fifty One Degrees runs this in production. A live deployment of several hundred curated files has produced a clear productivity uplift and better outcomes. In practice it means no one starts from a blank prompt. For less confident users it acts as a safety net that raises the average quality of every output. For expert users it removes the tax of re-writing the same context in every session.
Where the wiki pattern strains
The honest weakness is ingestion at scale. Beyond a few thousand source documents, building and maintaining the wiki through curation alone becomes impractical, and there is not yet a mature off-the-shelf product that does it for you. Everything above also holds for a wiki with one curator. Open it to a whole organisation and a harder question appears.
From one curator to a whole organisation: the adjudication problem
Open the context layer to hundreds of people reading and writing it, and claims start to collide. Yesterday's meeting note contradicts the signed agreement from March. A junior analyst's summary sits alongside the decision it misreads. A speculation aired in one meeting gets written down and starts reading like a conclusion.
Navigating these collisions takes at least three signals:
- Temporal: when was this true?
- Authority: a sponsor's decision outranks a corridor comment.
- Epistemic status: is this decided, proposed, speculated or superseded?
A wiki with a single curator gets away without encoding the last two, because the curator is the ranking function. They decide what earns a place on the page. At organisational scale that judgement has to become structure.
Concretely, that means a permission model over the knowledge itself: who may assert facts in a given domain, who may suggest changes for review, and who adjudicates when claims conflict, defined team by team and, where it matters, person by person. A trading desk's conclusions about its own book carry authority there and nowhere else. A compliance determination outranks everything in its scope. A new joiner can propose but not assert.
None of this needs exotic technology. The review-and-approve mechanics engineering teams have used for years cover it today. What it requires is discovery, because the right structure is a map of how decisions actually flow through a specific business, and that map is different in every organisation. This, not the storage engine, is where a context layer succeeds or fails at scale.
Where the technology is heading
Two developments point at the answer to the ingestion bottleneck.
Google Cloud's Open Knowledge Format (OKF), released in June 2026, is an open, vendor-neutral specification that formalises the wiki pattern as portable bundles of curated knowledge any agent can read. It represents knowledge as a directory of markdown files with structured frontmatter, links acting as the graph, published under an open licence. It is early, version 0.1 by its authors' own description, but the direction matters: it arrives with reference tooling that walks a data source and drafts knowledge documents automatically, which suggests ingestion will eventually be solved as a product rather than a manual effort.
The second development is a new generation of graph databases built to be model-friendly. Graphiti, an open-source example, was designed for AI agents rather than adapted for them. It records when each fact became true and when it was superseded, links every node back to the source that produced it, and is built to be read and written by a model in the course of normal work. That makes it possible to generate a graph index from a curated wiki: the relationships and scale of a graph on top, while the knowledge itself stays open and human-readable underneath. Fifty One Degrees is prototyping both approaches today, running the wiki pattern in production and building a graph index from it to test how each performs.
Which approach is right for your organisation?
It depends on your size and your regulatory posture, and there is no single answer yet. Anyone selling one is ahead of the evidence. But this problem is fundamental to the next twelve months of enterprise AI, and three things are already clear:
- The principles are non-negotiable: native, provenanced, temporal, human-reviewable, adjudicated.
- The storage layer is a replaceable engineering choice: wiki, graph, or both.
- The curated knowledge itself is the compounding asset, and the adjudication structure around it is the part no vendor can ship, because it is a process shaped to your business, not a product.
Organisations that start building both now will own something durable. Those that wait pay the Inertia Tax, the compounding cost of delay, reconstructing the same context in every tool, every year.
What Fifty One Degrees builds
Fifty One Degrees builds context layers inside client teams. We start with a controlled proof of concept on one well-bounded part of the business, prove the uplift, then scale with the architecture the evidence supports. This is Embed Over Advise in practice: senior practitioners building alongside your team, not handing over a report.
A core part of the work is discovery of the adjudication structure: mapping who may assert, who may suggest and who decides across your teams, and encoding that so the knowledge stays trustworthy as it grows. A context layer is maintained and governed, not installed, so we build the capability in your team to own it. It is the groundwork that makes everything else, from firm-wide AI enablement to the data foundation underneath it, data engineering and BI, actually reason over your business rather than generic prompts.
If your capable people are burning hours reconstructing what the organisation already knows, that is the Inertia Tax showing up on your P&L as flat output and slow decisions. A context layer is how you stop paying it.