The System of Context: Connecting the Records to Real Work

Connect the Agent Factory System of Record, every Vertical System of Record the customer runs, and the customer's own applications, so humans and agents receive the right context at the right time.

You have designed the Vertical System of Record from first principles, and you have built its first governed slice on the Agent Factory SoR Framework. The result is one governed source with two readers: humans read it in a browser, and Workers cite it over MCP. But professional work never happens inside that source alone. It happens inside a customer's company. That company is full of information your record will never contain: the signed contract, this morning's delivery, the running balance, last year's working paper, and the message where a manager explained a decision nobody wrote down. Your Worker needs all of it to finish the job. It must never mistake any of it for the law. The next architectural problem is not how to build another source of truth. It is how to bring the right truth and the right supporting context together, for one task, without flattening them into one ungoverned pile.

In plain words

A System of Record decides what is true. A System of Context decides what arrives.

Your records tell the Worker what the profession requires. The customer's applications tell it what is happening now. The System of Context connects both, finds what matters for the current task, checks who is allowed to see it, keeps every source labelled, and hands over a cited bundle to reason from. It adds no truth of its own. It never becomes a new source of truth. Its whole job is delivery, and delivery done honestly is harder than it sounds.

Fourteen words this page uses

Word	Plain meaning
System of Context	The layer that connects sources and assembles what the current task needs
Authority	The right of a source to settle one particular question
Authority routing	Deciding which source governs each part of a request, before retrieval begins
Context packet	The temporary, cited bundle assembled for one actor, one case, one moment
Provenance	Where an item came from, who owns it, which version it is, and when it was read
Connector	The controlled path into one source, carrying its content and its access rules
Indexed context	Content copied into a searchable index and kept synchronized over time
Live context	Current information fetched from its source at the moment the task runs
Permission inheritance	Carrying each item's access rules from its home system into every result
Governed truth	Content from a System of Record: citable, with a class, a version, and a scope
Supporting context	Content from an ungoverned source: citable as evidence of what was said or done, never as the governing rule
Federated	Many separate records, each keeping its own authority, joined by one layer that merges none of them
Canonical	The original, official version, as opposed to any copy made of it
Chunking	Cutting a document into small pieces so a search index can store them

Every other new word is defined in the glossary.

Where this term comes from

System of Context is not our coinage, and it would be dishonest to present it as one. The phrase is current in the enterprise software market, and Glean, the best-known company in this category, uses it as the name for its own data layer. We adopt it deliberately. A graduate who walks into a buyer's office should use the words that buyer already uses, and inventing a private vocabulary for a category the market has already named helps nobody.

But this book uses the term more narrowly than a vendor does, and the difference is the whole page. A vendor's system of context is a product. Ours is an architectural position: the layer that sits above two Systems of Record and below the Worker, carrying authority it never holds. Every rule on this page is defined here on our own terms, and none of it depends on any vendor's roadmap.

The same honesty applies to the older names. Analysts have called this category insight engines, cognitive search, enterprise AI search, and generative AI knowledge management apps. They will rename it again. Learn the layer, not the label.

How to use this page. Every section opens with a short In plain words box. If you read only those boxes, top to bottom, you will still have the whole argument.

Then, for the full reading: start with the two kinds of record, so you know what is being connected. Then follow one request through the architecture, from routing to a cited packet. Read the permission and conflict sections twice, because those are what separate a real System of Context from a document chatbot. Then watch Ayesha connect her first customer.

If you are new to this, read Ayesha and then the appendix, and stop there. The appendix runs one real request through all eight steps, and it is the fastest way to see the whole page working at once.

The templates, the definition of done, and the failure modes are working documents for your first real deployment, and they will make much more sense once you have one. The build itself lives in its own course. This page never mentions a container or a config file.

📚 Teaching Aid

Open Full Slideshow

View Full Presentation — System of Context

Why the Vertical System of Record is necessary and not enough

In plain words

Your record knows the profession. It does not know this customer's current contract, this morning's delivery, the latest approval, or the message that explains an exception. The Worker needs both.

You now hold two Systems of Record, and the ownership argument named both.

The Agent Factory System of Record owns the shared method: the architecture, the FDE AF Model, the manufacturing discipline, the standards every Worker is held to. It is identical at every customer.

Your Vertical System of Record owns the profession: the corpus, the map, the reflexes, the invariants, the source hierarchy, the permissions, the checkers, and the evaluations. It answers which rule applies to this contract type, what evidence a candidate needs before advancing, which clauses always escalate to a partner, and which approval can never be delegated. It is yours alone.

Neither one knows the customer's operating situation, and neither one can.

A revenue-recognition Worker needs the professional method from your record. It also needs the signed contract, every modification, the delivery record, current billings, project progress, customer acceptance, and this company's approval limits. A recruiting Worker may know the lawful screening method perfectly and still need the open role, the approved description, the candidate's application, and the hiring manager's authority. A ledger Worker may know the standard and still need to know why this firm treated a lease the way it did in 2023, when the person who decided has left.

So the Worker must know two different things at once.

What does the profession require?

and:

What is true in this case, right now?

The Systems of Record govern the first question, and the authoritative parts of the second. The System of Context assembles what is needed to answer both together.

Skip this layer and you learn the lesson the hard way. Your Worker will cite the standard perfectly and be unable to find the contract. It is a brilliant graduate on their first day, holding a textbook, in a building where nobody has shown them the filing cabinet.

Two kinds of record, and the layer above them

In plain words

The word "record" now covers two different things. The customer's ERP is a record of what happened. Your Vertical System of Record is a record of what the profession requires. Both are authoritative, and neither can answer the other's question. The System of Context is not a record at all.

Your record's own appendices already drew this line twice, and both times with a warning. The sales appendix says the CRM holds the deals and the System of Record holds the profession. The ledger appendix says accountants already call the general ledger a system of record, and they are right, and never confuse the two in front of a finance buyer because they will notice.

This page needs that distinction sharper, because the moment you connect a customer's applications you are holding all three things at once.

	Traditional System of Record	Governed knowledge record	System of Context
What it is	The ERP, CRM, HRIS, general ledger, practice management system	The Agent Factory SoR, plus one Vertical SoR per profession, built with the FDE AF Model	The connecting layer
What it owns	State: what happened, what the balance is, who approved, and when	Rules and method: what the profession requires, what evidence counts, which judgment escalates	No truth of its own. Connectors, indexes, routing policy, permission mappings, packet schemas, and logs
It is authoritative over	Facts inside its own scope	The profession's requirements and the build method	No question at all
What it decides	Nothing about truth	Nothing about state	Filtering, routing, ranking, assembly
The question it answers	What is the number?	What is the rule?	What is relevant to this task, right now?
How a Worker reaches it	A typed query over MCP	Retrieval over authored, governed pages, cited	Both of those, plus the ungoverned remainder
Who built it	The customer, over decades	You, with your expert	You, at each customer
What breaks without it	The business stops	Every Worker improvises the profession	The Worker knows the rules and cannot find the file

To be exact about the third column: the System of Context owns no business fact, no professional rule, and no authoritative record. It owns the machinery that locates, filters, routes, and assembles them. It makes real operational decisions all day. None of them is a decision about what is true.

Both of the first two are Systems of Record, and both are authoritative. They are authoritative over different kinds of truth. One owns state. The other owns rules. A ledger cannot tell you whether a treatment is correct. A standard cannot tell you what the balance is. Ask either one the other's question and you will get a confident, useless answer.

The middle column is the new thing, and it is worth pausing on why it did not exist before. In the human-only era, professional knowledge lived in people's heads, in training courses, and in unversioned procedure documents. It never needed to be machine-citable, because no machine was doing the work. The agentic era creates that need for the first time, and the FDE AF Model is the answer to it. That is the whole reason the design page exists, and the reason the asset you carry into a client is something no ERP vendor has ever sold.

QuickBooks holds the data. It does not hold the profession.

Take the most familiar example in accounting, because the abstract table above lands the moment you name a real product.

QuickBooks is a traditional accounting System of Record. It holds the chart of accounts, every transaction, the balances, the invoices, the reconciliation state, and the record of who posted what and when. Ask it what sits in account 1200 this morning and it answers exactly, and it is right, and nothing else in the building answers that question better. It also enforces real controls: double-entry, period locking, user roles, an audit trail. It is not a filing cabinet.

Now ask it whether the Henderson lease should have been classified as a finance lease under the current standard.

It has nothing to say. Not because it is a weak product, but because that was never its job. The classification rule lives in the standard. The firm's threshold lives in a policy document. The judgment about this particular lease lives in a partner's head, or in a memo nobody versioned. QuickBooks faithfully records the consequence of that judgment. It does not hold the judgment, and it cannot check it.

QuickBooks is authoritative about what was recorded. Your record is authoritative about whether it should have been recorded that way. Both are needed to finish one working paper, and connecting them changes neither one's authority over its own question. That gap, and not any shortcoming in the accounting software, is the whole reason your Vertical System of Record exists.

The same sentence works in every vertical. Salesforce holds the deals and not the qualification method. Workday holds the employment records and not the lawful screening standard. Epic holds the patient chart and not the clinical guideline. Each of them is complete about its own domain and silent about the profession that surrounds it, and each of them was built that way on purpose.

One word of caution about how this gets said

You will meet this distinction in vendor material. It usually arrives with one word bent in the seller's favour: the traditional record only stores data, while the context layer interprets it.

The point underneath is correct. The phrasing will cost you a meeting.

An ERP or a practice system does not only store. It enforces transactional integrity, segregation of duties, approval limits, period control, and an audit trail, and those controls are why the business is allowed to operate at all. Your own record's invariants lean on them. A finance director has spent a decade defending that system to auditors, and hearing it called storage tells him precisely how much you understand about his world.

So say the accurate thing instead, because it is also the more persuasive thing. The traditional record is authoritative and complete about its own domain, and silent about everything outside it. The gap is one of scope, not of seriousness. A buyer who hears you say that has just learned you are not there to replace the system he trusts.

This is worth noticing as a habit, not only as a fact. Vendor material describes the layer the vendor sells as the one where the intelligence lives, and every layer beneath it as plumbing. That is the third survival skill in its most ordinary daily form. Read the architecture. Discount the adjectives.

Three layers, three jobs

In plain words

Do not ask one layer to do all three jobs. The records own truth. The context layer assembles what is relevant. The Worker reasons and acts.

Layer	Its question	Its job	What it must never become
Systems of Record, both kinds	What is officially true?	Govern facts, rules, versions, permissions, and evidence	A loose search index
System of Context	What is relevant to this task, now?	Connect, route, retrieve, filter, rank, label, cite, assemble	A shadow source of truth
Human or AI Worker	What should be concluded or done?	Reason, decide within authority, act through tools, produce evidence	Its own ungoverned policy maker

One distinction holds the whole architecture together, and it is worth reading twice. The System of Context sits above the Systems of Record in access. It does not sit above them in authority. It can see across them. It does not outrank them. Access points upward. Authority still points back to the source that owns each fact or rule.

The one law: authority never moves

In plain words

Think of a delivery driver. The driver brings a parcel to your door. The parcel belongs to the sender, not to the driver.

The System of Context is the driver. The record is the sender. When a Worker says where an answer came from, it must name the record. It must never name the driver.

Everything on this page follows from one sentence, and it is worth putting on a wall.

The System of Context carries authority. It never holds it.

When a Worker cites a standard, the citation points at the register row in your Vertical System of Record: the publisher, the class, the jurisdiction, the version, the stable ID. It does not point at the context layer, and it does not point at the copy the context layer happens to be holding. The copy is a finding aid. The record is the source.

This matters most on the day something changes. A standard is superseded, and your impact record traces every map, reflex, and evaluation case that must move with it. That chain runs through the record. Let the context layer become a second authority and the chain grows a branch nobody governs. Your corpus is current, and a Worker quotes last year's rule from an index that never got the message.

The model is not a source either

In plain words

The law above says authority lives in the records, and never in the connecting layer. It does not live in the model either. A model can reason very well about information you give it. It cannot be the place that information comes from.

Ask a frontier model what the current lease classification threshold is and it will probably answer, fluently, and it may even be right. That is exactly what makes it dangerous. So it is worth being precise about what is missing, because the gap is not accuracy. It is everything around accuracy.

A model has no source. It has weights, and weights are a compression of a training corpus rather than a record of one. There is no register row behind the answer: no publisher, no authority class, no jurisdiction, no version, no effective period, no owner, no rights basis, and no path back to the text the answer came from. Your record's source register has nine columns. A model answer has none of them, and none can be added afterwards.

Plausibility is not provenance. A model produces the most likely continuation. A rule that sounds like a rule and a rule that is a rule have the same shape, so fluency carries no information at all about correctness. Your record already named this failure in another domain: an assumption written as a confirmed fact is the sales version of an invented citation. A model-supplied rule is the same error with better grammar.

A model release can be named and dated. The propositions inside it cannot. This is the argument that settles it. When a standard changes you edit a page, and the impact record traces every map, reflex, and evaluation case that must move with it. You cannot edit one statement inside a set of weights. A single rule in there has no source lineage, no authority class, no jurisdiction, no effective period, and no version you can correct on its own. Naming the model release does not fix that, because the release is one label over millions of propositions. A source whose individual claims cannot be corrected or dated is not a source a profession can stand behind.

A model must not be the permission enforcement point. Identity can certainly be supplied to the system around it. But anything placed inside the model's context is available to its reasoning, for whoever is asking. That is precisely why permission filtering happens before context reaches the model, and never after.

And its knowledge has a cutoff, while the profession does not. Rules change on the regulator's schedule, not the laboratory's.

Three places the model quietly becomes the source

None of these looks like a decision at the time. That is what makes them worth naming.

The gap fill. Retrieval returns nothing useful, and the model answers anyway from whatever it seems to know. The output is indistinguishable in form from a grounded one, and no error message appears. The cure is structural: missing evidence is a field in the packet, and a reflex that cannot find its governing source escalates rather than proceeds.

The drifting paraphrase. The model retrieves the right passage and restates it in its own words, and the restatement quietly loses a threshold, a condition, or a scope. Your record already warned about paraphrased authority inside the corpus, where a re-explained standard becomes citable and then drifts with your stamp on it. The same drift happens at answer time, and the cure is the same: quote and cite the governing text rather than re-expressing it.

Unmanaged persistent model memory. A model that carries facts across sessions, with nobody owning or versioning them, has become an unversioned and unauditable store. It is the shadow record arriving through a product feature rather than a design decision, which is why it is the hardest of the three to notice.

What the model is actually for

None of this makes the model a lesser participant. It makes it a different one.

The model is the execution layer, and in the 10-80-10 rule it holds the middle eighty. Give it the governing rule, the current facts, and the supporting context. It will then apply the reflex, run the calculation, notice what evidence is missing, spot a conflict between two sources, draft the working paper, and explain its reasoning so a reviewer can check it.

That is an enormous amount of professional work. Not one part of it needs the model to be a source.

Read the whole architecture back and this is what it is for. The records hold the first ten percent, which is the governed intent. The model carries the eighty. The named human closes the final ten. The System of Context exists because the middle eighty needs supplying, and the model cannot supply itself.

One test settles any borderline case, and it is the same test your record already applies to a working paper. Can a reviewer rebuild this conclusion from the record, without asking the model? If yes, the model reasoned. If no, the model was the source, and the conclusion is not defensible.

Authority is scoped across many records

In plain words

No single document wins every question.

Your record governs the professional work. A signed contract governs its own terms. The ERP governs whether an invoice was posted. And a company runs several governed records at once: one for sales, one for accounting, one for law, and more.

Federated means just one thing here: many records, each keeping its own authority, joined by one layer that mixes none of them together.

Your record already gave the refinement: a hierarchy is not always one ladder, because the higher source wins only when both sources speak to the same question. The System of Context makes that unavoidable. It connects sources that are authoritative over completely different kinds of truth, and they do not fit on one ladder at all.

Source	What it may govern	What it does not automatically govern
Agent Factory System of Record	Shared architecture, manufacturing method, Worker standards, FDE practice	The customer's transaction facts, or the profession's law
Vertical System of Record, and a customer may run several	One profession's rules, source hierarchy, judgment guidance, reflexes, checkers	Whether a delivery occurred this morning, or anything belonging to another profession
Signed contract or legal instrument	The parties' obligations, prices, dates, rights, and modifications	The professional method used to account for or administer it
Traditional System of Record, such as the ERP, CRM, or ledger	Current state within its own scope: invoice posted, item delivered, user approved	The professional rule that decides what that state means
Approved customer policy	Customer-specific thresholds, responsibilities, and operating rules	Law, or binding professional standards
Working documents and messages	Explanation, intent, clues, pending work, informal coordination	Final authority, unless formally approved or incorporated

So the architecture needs authority routing, and it is settled before any retrieved item is relied on as governing authority. Discovery may run first and help classify an ambiguous request. What may never happen is a passage being treated as the rule before routing has said which record governs. Eight questions resolve the shape of a request.

Which profession owns this question?
Who is asking?
For which customer, and which case?
What task is being performed?
Which jurisdiction and effective date apply?
Which source owns each required fact or rule?
What may this human, and this Worker, read?
What action, if any, may follow?

Question one is first for a reason, and the rest of this section is why.

A source can be perfectly relevant and still have no authority to settle the question. A chat message saying treat this as approved may explain why work stopped. It does not become an approval.

Relevance is not authority. Retrieval finds candidates. Governance decides what counts.

The portfolio, not the pair

Choosing Your Vertical tells you to build one: one profession, one country, one expert. That advice does not change. But the customer you deploy into is a company, not a profession, and a company runs several at once.

A mid-sized firm may hold an accounting Vertical System of Record, a sales one, and an HR one, built by three different people at three different times, and none of them yours. Its Workers read from all three. Its System of Context connects all three, alongside the traditional records and the ungoverned material. Over time the list grows: tax, legal, procurement, customer support, compliance. Each addition is a new column in the routing map, not a new pile in the index.

Three rules follow.

A vertical's methodology never crosses its seam. The sales record's qualification method has real authority over what counts as a qualified deal, and none at all over when revenue is recognisable. It will still retrieve well against a revenue question, because the words overlap. That is the sharpest everyday case of relevance without authority.

Never merge two records into one corpus. This is the same warning your record already gives about jurisdictions. A blended page cannot be cited in either profession, an accountant reading it will not recognise it as accounting, and the two hierarchies it flattened cannot be recovered afterwards. Separate records, separate ladders, one layer above them.

Your asset composes, and that is good news for your business. You never have to own a company's whole professional knowledge to be useful inside it. You own one profession, deeply, and the layer lets it sit beside the others unmerged. That is why choosing one vertical is a strategy rather than a limitation.

Notice what does not multiply. There are many Vertical Systems of Record and exactly one Agent Factory System of Record, because the method of building and governing them is the same in every profession. That is the whole reason it is shared.

One business event, several governing records

A customer asks for a twenty percent discount and wants the revenue in this quarter. That is one sentence from one buyer, and it is not one question.

The question inside it	Which record governs
Is this opportunity properly qualified?	Sales
Is a twenty percent discount within commercial authority?	Sales
Do the contract terms make the arrangement enforceable?	Legal
Has the customer passed the required checks?	Compliance
When may this revenue be recognised?	Accounting
What is the tax treatment?	Tax
What did the parties actually discuss?	No record governs this. Supporting context, from email, CRM notes, or transcripts
What was delivered and accepted?	The delivery, contract, or project record, queried live
May we issue the invoice today?	The traditional record, queried live

No single record owns that situation, and none can be asked to. The layer has four jobs here. Break the request into its parts. Send each part to the record that governs it. Fetch the customer facts those parts need. Then build one packet in which every finding still carries the name of the record it came from.

The alternative is what most implementations actually do: send the whole sentence to one search over everything, and let the top-ranked paragraph answer all eight questions at once. That is not a weaker version of this architecture. It is a different one, with no authority in it anywhere.

And the seams are where the interesting disagreements live. Sales says the deal closed in June, and it is right, because closing is a sales event with sales evidence. Accounting says the revenue is not recognisable until acceptance, and it is also right. Nothing here is broken. Two professions are answering two different questions, and a Worker that blends them produces a claim neither profession made. This is the cleanest case of resolved by scope, which is why that outcome is listed before resolved by authority.

The three questions, and the three paths

In plain words

A Worker asks only three kinds of question.

What is the rule? What is the number? What did people say about this case?

Each question has its own path to its own kind of source. Send all three down the same path, and the answers will be wrong in three different ways.

Routing sounds abstract until you see how few shapes a real request comes in. A Worker doing professional work asks three kinds of question, and each has its own path.

The question	The source	The path	What comes back
What is the rule?	Vertical or Agent Factory System of Record	Retrieval over governed, authored pages	Governed truth, citable, with class, jurisdiction, and version
What is the number?	The system that owns the number	A typed query over MCP	An exact current value, or an honest failure
What was said about this case?	The customer's applications	Retrieval over the ungoverned corpus	Supporting context: evidence, never the governing rule

Three questions, three paths, one connecting layer. Notice that the first two paths lead to the two kinds of record named earlier: the rule comes from the governed knowledge record, and the number comes from the traditional operational record. The third path leads nowhere authoritative at all, which is exactly why it needs the tightest handling. A Worker that cannot tell which question it is asking will answer all three the same way, and the third path will quietly swallow the first two.

What the layer assembles: the context packet

In plain words

The System of Context does not throw every matching paragraph into a prompt. It builds one controlled package for one task: the governing rules, the current facts, the supporting context, the conflicts, the missing evidence, the permissions, and the citations.

Seven operations produce that package. Connect to each source through a controlled interface that carries not just content but source identity, synchronization state, access rules, and provenance. Identify the actor, the Worker, the customer, the case, the jurisdiction, the effective date, and the intended action, because retrieval without identity and scope is only guessing. Retrieve what the task requires from the sources that own it, by whatever method fits: semantic, lexical, structured, relational, or tool-based. Filter out everything this reader may not receive, and everything outside the customer, jurisdiction, version, effective period, or case. Rank by more than textual similarity, because the most similar sentence is rarely the most useful source. Assemble the packet. Deliver it, and record what follows.

Ranking deserves one line of its own. A production ranking policy weighs authority, applicability, freshness, case identity, source confidence, and completeness alongside retrieval relevance. A layer that ranks on similarity alone has quietly made the model's embedding function into your firm's source hierarchy.

Assembly deserves a warning of its own, for the same reason. A packet is built against a budget, because a model's context window is finite and every token spent on a stale message is a token not spent on the governing rule. So the layer selects, compresses, and sometimes summarizes. That is legitimate work, and it is also the single place where invariant five is most often broken. Compression that drops a version stamp, merges two sources into one sentence, or strips an authority class has not saved tokens. It has converted evidence into text. Compress the prose. Never compress the provenance.

The packet itself is the output, and here is what a useful one contains.

Part	What it contains
Request	The task, actor, customer, case, jurisdiction, date, and intended action
Governing authority	The exact rules, standards, policies, or reflex steps that apply
Current facts	Live or synchronized facts from the systems that own them
Supporting context	Messages, notes, drafts, prior cases, and other useful background
Conflicts	Sources that disagree, with authority, scope, and dates preserved
Missing evidence	What the reflex requires and the layer could not find
Permission envelope	What may be read, recommended, prepared, or executed
Citations	Stable source references for every material claim

The packet is temporary, and that is the design

A context packet exists for one request, one actor, one case, and one moment.

That boundary is not a technical detail. The packet may hold a current balance, a contract clause, a policy passage, a manager's note, and a pending approval. Ten minutes later one of those facts has moved. A different colleague is not permitted to see the same set. A different task needs a different authority route.

So the layer does not build one giant permanent prompt for the company. It rebuilds the relevant packet when the task runs. Three rules follow, and they are the packet's whole constitution.

The packet inherits authority. It never creates it.
The packet inherits permissions. It never widens them.
The packet expires. Current facts are refreshed whenever freshness could change the answer.

The durable things are the source and the evidence written back after the task. The packet is only the working view.

What may be indexed, and what must be asked

In plain words

Three kinds of information reach a Worker, and each one arrives by a different route.

The customer's emails, chat, and files can be put in a search index. Your governed pages can be indexed too, but the record must confirm before the Worker relies on them. Live numbers must be asked for, every single time, from the system that owns them.

Two mistakes are easy and expensive. Copying live numbers into an index, where they quietly go out of date. And treating the customer's emails as if they were law.

Almost every real failure in this layer is one of those two mistakes. So here is the whole rule first, and the reasoning after.

Information	How it is reached
Ordinary company working context	Permission-aware indexing
Stable governed knowledge from a record	A discovery index, confirmed by the record before it is relied on
Current records, applicable versions, and any action	A live query over MCP or an API

Index working context. Discover governed knowledge. Query current truth live.

Working context is indexed

Their shared drive, their chat, their email, their prior working papers. Search it freely, with permissions inherited. This is what the layer exists for, and none of it is authority.

Governed knowledge is discovered, then confirmed

Governed pages can be synchronized into a search index, and doing so is useful. A student who cannot find the accounting rule at all is worse off than one who finds a copy. What must never happen is reliance on the copy.

So the layer runs two different jobs here, and confusing them is the most common way a careful architecture quietly becomes a careless one.

Discovery asks: where might relevant information exist? It optimises for recall, similarity, speed, and reach. Its output is a pointer. It says look here.

Confirmation asks: which source is officially applicable to this decision? It checks domain, authority class, jurisdiction, version, effective date, applicability, approval status, permission, and canonical identity. Its output is an answer. It says this is what governs.

The sequence is fixed. Search discovers. The layer routes. The applicable record confirms. The Worker cites and reasons. The checkers validate. Governed tools act and record.

Current state is asked for, every time

Balances, transactions, reconciliation status, open items, approval state. None of it was authored, none of it is stable, and all of it is exact. Put it in an index and you have made a rough, ageing copy of something whose entire value is being current and precise. The Worker then answers a balance question from a chunk that was true last Tuesday, and it sounds completely confident doing it.

One sentence decides every borderline case, and it belongs in every engagement's design record.

If a stale value could change the conclusion, the permission, a payment, a filing, or a customer action, fetch it live.

The same source often needs two modes at once. A contract document is indexed so its clauses can be found, and the contract system is queried live to confirm the version found is still the active one. Format and length decide nothing here. Freshness risk decides everything.

And the ungoverned stays ungoverned

One line needs care here, because the customer's world is not uniformly ungoverned. Their signed contracts, approved policies, posted transactions, delivery records, and authorisations are governed, and they belong to the operational records above. What this section is about is everything else: the working material.

That working corpus is not your corpus, and it never becomes your corpus.

Their ordinary working material is not governed simply because the customer created it. Nobody assigned an owner. Nobody recorded a version. Nobody cleared a rights basis. Some of it is wrong, and some of it was replaced three years ago by a memo nobody filed. It is genuinely useful. It is not authority.

So it enters as supporting context, and it stays supporting context. It never moves into your Vertical System of Record, because that is exactly the contamination the promotion law exists to prevent. Customer material moves only when a pattern repeats across three or more customers, is de-identified, passes promotion review, and is rewritten by your expert in her own voice. That is authorship, not indexing.

Why chunking is where governance disappears

One mechanism deserves naming, because it is invisible and it happens automatically.

An entry in a Vertical System of Record carries twelve things with it. A stable ID. A domain. An authority class. A jurisdiction. A version. An effective date. An approval status. Applicability conditions. An owner. A superseded-by link. A required checker. A permission boundary.

A generic indexing pipeline preserves the sentence:

Revenue may be recognised when control transfers.

The words survive. All twelve controls are gone, and nothing in the retrieved text announces their absence. The Worker can no longer tell six things. Which standard governs the statement. Whether it applies to this contract type. Whether it is current. Whether it applies in this country. Whether it is authority or only orientation. And which exceptions would change the answer.

This is the failure your record already names inside the corpus, where paraphrased authority drifts with your stamp on it. Here it happens at ingestion rather than at authorship, which makes it harder to see and much easier to do at scale.

The cure is not to stop indexing. It is to treat every search hit as a pointer, never as an answer, and to require that each synchronized item keeps its canonical identity so the confirmation step has something to check against.

And now the shortcut worth refusing. A single vector database holding chat messages, an old contract draft, a sales rule, an accounting policy, a legal note, and a historical example is not a System of Context. It is one unsorted pool, and four things go wrong in it at once:

a chat message can outrank a standard
last year's policy can outrank this year's
a sales rule can be used to answer an accounting question
one country's rule can be applied in another country

It has become an accidental shadow System of Record, and nobody ever decided to build one.

Permission comes before the model

In plain words

Do not retrieve everything and hide the forbidden parts afterwards. Information a reader may not see must never enter the model context at all.

This is the invariant most likely to be skipped, because skipping it makes everything easier for about six weeks.

A document's access rules live in its home system. A private channel is private. A restricted folder is restricted. A partner's file is the partner's. When your layer copies that document, it must copy the access rules with it, and it must re-check them at the moment of every query, for the specific person or Worker asking. Permission is inherited, never invented.

There are three separate permission questions, and they have three separate answers.

May this human see this source?
May this Worker see this source, for this task?
May this Worker perform the action that could follow?

They differ constantly. A manager may read salary data. A recruiting Worker may read one narrow field to run an approved check. Neither permission lets the Worker change payroll. Read, reason, recommend, prepare, and execute are separate grants, exactly as your record's permissions section already established.

The safe order is: resolve identity, resolve source permissions, filter eligible records, retrieve and rank, assemble the packet, and then resolve action permission separately at the tool boundary. The unsafe order is: retrieve everything, send it to the model, and ask the model not to mention what the reader should not see.

A hidden passage inside the model context is not hidden.

Build your own permission model instead of inheriting one, and you have created something worse than a leak. You have created a system that is helpful about leaking. A junior asks a reasonable question and receives, ranked first, with a friendly summary, the compensation memo they were never allowed to open. Nobody attacked anything. The layer simply did its job against the wrong rules.

Why this is a control question, not only a privacy one

In most domains a permission failure is a privacy problem. In a regulated profession it reaches further. But it is worth being exact about how, because the loose version of this argument is wrong, and a controller will catch it.

Segregation of duties is about combinations of ability, not about visibility. The classic conflicts are creating a journal entry and also approving it, or originating a transaction and also reconciling it. An audit walkthrough samples a user and asks whether that person's combination of entitlements breaks a documented rule. Read access on its own is usually not such a combination. Claim that your context layer "breaks segregation of duties" and you will lose the argument in the room.

The real exposure sits one layer lower, and it is broader than segregation of duties.

Access control is the foundation the rest of the control environment stands on. Data integrity assumes that only authorised people can reach the data, so when access itself is not governed, every control above it inherits that weakness. This is why auditors treat weak IT general controls as a reason to doubt the application controls sitting on top of them: the environment underneath cannot be trusted.

Now put a context layer inside that environment. The firm's periodic access review certifies that a named user holds a specific set of entitlements. Your layer then hands that user content those entitlements never granted. Nothing was stolen. No documented rule was formally broken. But the access review is now certifying a picture that is not true, and access management is already among the most commonly reported control deficiencies.

So the argument to make is this one, and it is both accurate and stronger. A context layer that grants effective access outside the entitlement model does not break one control. It quietly invalidates the review that certifies all of them.

The invariants you wrote for the Worker mean nothing if the retrieval beneath them has no boundaries. This is why permission fidelity is not a feature added at the end. It determines which tool you can use and which deployment you can afford, and finding that out in week one is very much cheaper than finding it out in front of a compliance officer.

One note for your expert. The framing above uses IT general controls and access-review language, which travels across most regulated professions. The exact rule your firm is held to, and whether your jurisdiction treats a given access pattern as a reportable deficiency, is a question for your domain expert. Ask it early, because the answer decides what your layer must block rather than merely log.

Provenance travels with every item

In plain words

A useful answer does not only show the sentence. It shows where the sentence came from, which version it belongs to, what it governs, and whether it was current when it was used.

Every material item in the packet carries at least these fields.

Field	Why it matters
Source system	Identifies the owner of the information
Stable ID	Lets a reviewer retrieve the exact item again
Authority class	States whether it is law, standard, contract, policy, transaction, guidance, message, or example
Scope	States which question, customer, jurisdiction, and case it governs
Version and effective period	Stops retired rules from silently returning
Owner	Names who is responsible for the content or the record
Retrieved or synchronized at	Shows how fresh the item was
Permission basis	Shows why this reader was allowed to receive it
Citation	Lets a human check the claim

Without provenance a packet is a pile of text. With it, the packet is reviewable evidence.

This is also why the layer must never strip source labels while reranking or summarizing. A summary that merges five sources into one smooth paragraph erases the difference between a signed contract, an approved policy, and an informal message. Fluency is never worth that loss.

Governed truth and supporting context

Your record already holds two classes of content: authority the Worker cites, and orientation the Worker reads but never cites. The context layer needs the same discipline one level up, on a different axis.

Governed truth comes from a System of Record or another authoritative instrument. It is citable. A reviewer can check it. Supporting context comes from the customer's working material. It may be cited or attributed as evidence of what was said, observed, requested, or previously done. An email can prove what a client asked for. A prior working paper can prove how the firm treated something last year. What it can never be is the professional rule that governs the conclusion.

The rule mirrors the one your record already enforces. A Worker may read any permitted, task-relevant supporting context. It may never present supporting context as the rule that governs the answer.

Watch the failure, because it is subtle and fatal. A Worker is asked whether a cost should be capitalised. The best-matching passage is an internal email from three years ago: we always capitalise these. Fluent, relevant, and precisely wrong as a basis. The correct answer routes the requirement to the standard in the governed record, uses the email only as evidence of past practice, and flags the two against each other if they disagree. An accounting error repeated for twelve months remains an error, and the same is true of one repeated in a thousand indexed messages.

Content	Class	How the Worker may use it
The applicable reporting standard	Governed truth	Cite it, with version and jurisdiction
Your expert's authored procedure	Governed truth	Cite it as expert methodology
The signed contract and its modifications	Governed truth, registered at the customer layer	Cite it as a contract
A current ERP posting record	Governed truth for its own scope, fetched live	Cite the record and the time it was read
A prior-year working paper from the shared drive	Supporting context	Read it, attribute it, never cite it as the requirement
A salesperson's message saying the customer accepted	Supporting context	Read it as a clue, never as proof of acceptance
A message in a channel this reader cannot open	Nothing	It never appears, because permission was inherited

Conflict is a result, not a retrieval failure

In plain words

When two sources disagree, do not blend them into a sentence that neither source said. Keep the disagreement visible, work out which source governs, and escalate when authority cannot settle it.

This is the section that separates a System of Context from a good search tool, because a search tool has no opinion about disagreement and a professional system must.

Take a contract-revenue case. The signed modification adds an optional service. The project system shows work already started. A salesperson writes in chat that the option is "just an extension." Your Vertical SoR says a modification must be evaluated against the governing recognition criteria before it is combined with the existing contract.

All four items are relevant. They are not equally authoritative. So the layer keeps all four apart. It labels each one with its authority, its scope, its version, and its date. It marks the signed modification and the record as governing different parts of the question. It treats the chat message as supporting context, not as contract. It shows what is still unresolved. And it stops the Worker from acting as though the disagreement were not there.

A conflict has exactly three outcomes.

Resolved by scope. The sources answer different questions, and both are right about their own. The seam between two verticals is the everyday case: sales closed the deal in June, accounting cannot recognise the revenue yet, and neither is mistaken.
Resolved by authority. One applicable source governs, and the hierarchy says which.
Unresolved. The Worker escalates, with the conflicting evidence already organized.

The escalation bar is the one your record already set: it must reduce the human's work. So it never says the sources conflict. It says which sources conflict, what each one states, which authority test was applied, what remains open, and which named person can settle it.

A trustworthy System of Context does not make disagreement disappear. It makes disagreement reviewable.

Read, reason, act, and record

In plain words

Finding is not the same as doing.

The layer finds. The Worker thinks. The governing record checks the rules. The tool performs the action. The system that owns the result writes it down.

Five different jobs, always in that order.

The System of Context is not a search screen. It is the information layer through which humans and Workers understand the organization. But understanding and acting stay separate capabilities, and the sequence matters.

The layer supports find and understand. The Worker performs the permitted reasoning and the decision. The governing Vertical System of Record validates the rules, the permissions, and the invariants. Only then do governed tools perform the action, and the system that owns the result records it.

That middle step is easy to drop and expensive to lose. A discount approval is validated against the sales record before the CRM writes it. A journal entry is validated against the accounting record before the ERP holds the draft. A contract exception goes through the legal record. An employee change goes through the HR record. In each case the Vertical System of Record is not merely where the rule was read. It is where the proposed action is checked against the rule, which is what makes the invariants real rather than advisory.

The context layer retrieves the opportunity, the price policy, the buyer's messages, and the qualification method. The sales Worker recommends a stage change. The sales record confirms the change is permitted at this stage with this evidence. The CRM tool performs it and records who changed it. Or: the layer retrieves the contract, the delivery evidence, the professional rule, and the customer policy. The accounting Worker prepares a journal entry. The accounting record checks the entry against its invariants, including that the preparer is not the approver. The ERP holds the draft, and a named approver posts it.

One rule sits under all of it. The System of Context must never become a second transaction system, and it must never become a way to write around a governed record.

So: if a customer record changes, it changes through the tool that owns it, and only after the governing record has approved the change. If a professional conclusion is reached, the conclusion and its evidence go into the governed case record. The loop closes only when the result is stored where truth belongs.

One source often exposes two surfaces, and they carry very different risk.

Surface	Typical operation	What goes wrong
Retrieval	Search, read, cite, compare	Information exposure
Calculation or checking	Validate, classify, calculate, test	An incorrect conclusion
Preparation	Draft an entry, prepare a form, stage an update	An incorrect proposed record
Execution	Send, post, release, approve, pay	A real-world consequence

A Worker may be excellent at retrieval and hold no execution authority at all. The System of Context must never turn access into permission.

The eight invariants of the connecting layer

In plain words

These eight rules do not change.

They stay true for every profession, every customer, and every product you might use. If you remember nothing else from this page, remember these.

Eight rules stay true whatever tool you deploy, whatever profession you serve, and whatever the customer's stack looks like. Write them into your own build, and enforce each one with something stronger than words.

#	Invariant	Why it holds
1	Authority never moves. The layer carries citations to the record, and neither the layer nor the model ever becomes the cited source.	Otherwise the impact chain grows a branch nobody governs.
2	Relevance is not authority. Routing happens before retrieval.	Otherwise the highest-ranked passage silently becomes the rule.
3	Permission is inherited, never invented, and enforced before the model.	Otherwise your layer becomes the most helpful data breach the customer has ever bought.
4	Freshness is decided per field: index working context, discover governed knowledge, query current truth live.	Otherwise the Worker answers exact questions with stale approximations, confidently.
5	Provenance travels with every item, and summarizing never strips it.	Otherwise a contract, a policy, and a rumour arrive looking identical.
6	Conflict is preserved and escalated, never blended.	Otherwise the system produces a claim no source ever made.
7	The ungoverned never silently becomes governed. Promotion is authorship, reviewed and recorded.	Otherwise the customer's mistakes enter your profession's record wearing your stamp.
8	Discovery is not confirmation. A search hit is a pointer, and the governing record confirms before anything is relied on.	Otherwise an indexed copy quietly becomes the authority, in whatever version it was synchronized.

Where it sits in the FDE AF Model

In plain words

The System of Context is not a third System of Record, and it is not another permanent layer in the shared kernel. The vertical prepares the pattern. The customer deployment connects the real applications, identities, and records.

It spans two layers of the FDE AF Model, in two different forms, and getting this wrong is expensive.

Layer 3 prepares the pattern. The vertical ecosystem holds reusable pieces that contain no customer data at all. The source classes and routing rules for the profession. The shape of a context packet. The metadata and citation formats. Connector templates, retrieval evaluations, conflict tests, tool contracts, and permission patterns.

All of it belongs to the profession rather than to any one client, and all of it is yours.

Layer 4 binds the customer. The instance supplies everything that belongs to one company. Their applications. Their identity provider and user groups. Their contracts, records, policies, and thresholds. Their credentials and source permissions. Their case identifiers, their approvals, and their audit rules.

That is where the System of Context becomes real. It is fitted to one company's data, rules, workflows, and people, and it fits nowhere else.

The promotion law still governs the traffic between them. A connector pattern, an authority rule, or a conflict test that repeats safely across three or more customers may move down into the shared vertical. Customer records, credentials, messages, policies, and private evidence never move down. Reuse is never a reason to move private knowledge.

That split has a commercial consequence worth naming plainly. The Layer 3 pattern is what you own and carry from client to client. The Layer 4 fitting is deployment work you perform at each one. The first is an asset. The second is a service. The capstone explains why the difference decides what your work is worth, and confusing them is how a founder mistakes a busy consulting practice for a business with something to sell.

Consolidate by default, specialize deliberately

In plain words

Earlier the book said: keep your data in one place. This page looks like the opposite advice. It is not.

This section explains when one store is right, and when two stores are right.

The book's stance on infrastructure is direct, and this page appears to break it. It does not, and the reconciliation is worth stating because a careful reader will notice.

The Thesis says: consolidate by default. One Postgres holding relational data, documents, full-text search, and AI vectors together, rather than scattered across systems that drift out of sync. AI Searchable Context is how you build it, and your governed record follows that stance exactly.

The System of Context is the other half of the rule. Consolidation is correct when one set of invariants governs all the data. Specialization is correct when two sets of invariants pull in opposite directions.

Look at what each side actually needs. Your record needs exactness, versioning, an audit trail, and a rights basis for every source. The customer's world needs breadth, freshness, and permission fidelity mirrored from a dozen systems you do not control. Force them into one store and you get a record whose provenance is now uncertain and an index whose permissions are now guesswork. Both get worse.

This is not an exception to the stance. It is the clearest example of the second half of it, and it is what the word deliberately was reserved for. One governed store for the profession. One connecting layer for the customer's world. A shared discovery index may help locate things across both, and it must never flatten the source classes or become a shared authority store. Every governed item keeps its canonical identity, and the governing record confirms it before use.

The open reference implementation

In plain words

This page teaches an idea, not a product. But you need something real to practise on.

Onyx is the open tool you can install, read, and take apart. Glean is the paid product large companies buy. Learn the idea. The products will keep changing.

The reference products

In this book, Onyx is the open reference implementation of a System of Context. Glean is the best-known commercial example.

The doctrine is product-independent. Onyx is how students see and practise the architecture openly. Glean is how they recognise the commercial market category.

The hands-on build is Building the Context Layer. We teach Onyx there for the same reason this book teaches OpenCode alongside Claude Code. The discipline must be visible to be learned. A student can connect multiple sources, watch a sync run, trace one request from identity through routing to a returned packet, inspect the citations, test a conflict, and replace a component. That is a lesson no demo delivers. Onyx also runs in real companies at real scale, which is the second half of the requirement: a graduate who can deploy and reason about it holds something a hiring manager recognises.

Glean matters for a different reason. When a company asks for enterprise AI search, a work assistant, a knowledge layer, or an enterprise context platform, a graduate should recognise the category and read the architecture beneath the product language. It is also where the term at the top of this page comes from. And studying how the best-known vendor in the category describes its own layer is the fastest way to learn something useful: which parts of this doctrine a product actually implements, and which parts it quietly leaves to you.

Four interfaces must stay open, whatever product you deploy, because they are what make the layer replaceable.

MCP, for agent-facing knowledge and tools.
OpenAPI, for governed application capabilities.
Connectors and ingestion APIs, for synchronized content.
Source-owned identifiers and citations, so the context layer can be swapped without losing the record.

Onyx is the reference implementation, not the definition. A customer may later run Glean, Microsoft, Google, ServiceNow, Atlassian, or a custom stack. Not one architectural test on this page changes.

What the tool teaches, and what you must still design

Concept	What a student practises in the tool	What must still be designed explicitly
Connectors	Bringing many sources into one retrieval experience	Which sources are allowed, and who owns each connection
Retrieval	Finding relevant information across sources	Authority routing, applicability, and freshness rules
Citations	Returning source links with answers	Stable IDs, authority classes, versions, and reviewer evidence
Agents and actions	Using retrieved knowledge in a workflow	Tool permission, approval gates, and write-back ownership
Users and access	Operating a shared organizational system	Production identity mapping and source-permission fidelity
Open deployment	Inspecting and extending the implementation	Hardening, audit, scaling, backup, and operations

Two honest notes before the build course.

The category is young enough that names will keep moving. Learn the layer, not the logo. The eight invariants will outlive every product in the list, and when the tool you deploy in three years has a different name, they are still how you judge it.

And no tool gives you the invariants for free. Every one draws a boundary between what its open edition does and what its paid edition does, and permission handling is very often on the paid side of that line. Onyx is the case you will meet first, so name it plainly rather than discovering it in week six.

What the Community Edition cannot prove

Onyx Community Edition is enough to learn connectors, indexing, retrieval, citations, agents, and actions. It is not enough on its own to demonstrate production permission fidelity across different users.

Onyx's own documentation lists permission-sync connectors, which inherit user permissions from external systems, together with user groups, RBAC, and group-based permissions, as Enterprise Edition features. Deployments needing permission inheritance from external systems are named as a reason to move to Enterprise.

That matters because permission before the model is one of the eight invariants on this page. So student labs use public, synthetic, or class-authorized sources, and the permission architecture is either bought or implemented separately before any real corpus is connected. Building the Context Layer has students write that gate themselves and test it with a role whose correct answer is nothing.

A feature list is not proof. A production deployment must demonstrate that the chosen platform actually enforces the required identity, permission, synchronization, audit, and isolation controls, and the demonstration is the permission test set below. Students work with public, synthetic, or class-authorized data until it passes.

When you do not need one

In plain words

Not every project needs this layer. Building it too early can waste months.

This section tells you how to know whether yours needs one.

Not every vertical needs this layer, and building it too early is a real way to lose a quarter.

You do not need one when the governed record and the customer's operational systems together answer every question the outcome requires. A tax practice whose work is defined by the code, the client's filings, and the ledger may never need to search a shared drive. A single MCP connection to the system that owns the numbers is not a System of Context. It is a tool, and your Worker already has tools.

You need one when the answer to why was it done this way lives outside every system anyone governs. Long professional relationships produce this by nature: audit firms with twenty years of working papers, legal practices with matter files, consultancies whose reasoning lives in decks and threads. When institutional memory is part of the deliverable, the layer is worth its cost.

So reach for this when the engagement calls for it, not automatically after the record. One gate is not negotiable: do not build a System of Context until your thin slice is finished and your first Worker cites it. A connecting layer with nothing governed to connect to is a search box with ambitions.

Two temperaments, one layer

In plain words

The record changes a great deal from one profession to another. The connecting layer barely changes at all. What changes is which sources carry the weight, and which mistake is most likely to hurt.

The design page needed two full worked examples, because the method produces genuinely different records. Sales gets a shallow policy hierarchy and a Worker that sends. The ledger gets a deep law-governed hierarchy and a Worker that only prepares.

Run the same comparison on this layer and almost nothing moves. The eight invariants are identical. The three questions are identical. The indexing rules are identical. Two things change.

	Sales	General ledger
Where the ungoverned material sits	At the centre: transcripts, emails, and threads are the evidence base for the deal file	At the edge: the systems hold the numbers, and the corpus explains past treatments
The heaviest connection	Conversation records, indexed	The accounting system, queried live
What question three usually asks	What did the buyer actually say, and when	Why was this treated this way before
The characteristic mistake	An offhand remark promoted into a confirmed field	A stale indexed balance answered as current
What a permission failure costs	A confidentiality breach	An access review that now certifies a false picture

Sales is the uncomfortable case, because there the ungoverned material is the evidence. A call transcript is supporting context by class and the primary evidence for the deal file at the same time. That is the closest ungoverned content ever comes to being the record, and the invariant holds anyway. What holds it is the deal file's own discipline: the six evidence states. The transcript shows where a claim came from. It never proves the claim is true, and a buyer's offhand remark that becomes a confirmed field is the sales version of an invented citation. One further rule governs what may be connected at all, and it is law rather than design. A conversation you had no right to record is one you have no right to index.

The ledger is the sharper lesson, and it is the control point made earlier. A permission failure there does not merely expose information. It grants effective access outside the entitlement model the firm's access review certifies, and every control above that review assumes the access beneath it is governed.

Now notice the shape of this section beside the two full appendices that closed the design page. That page needed both, in full, because the record differs in every profession. This one needs a table, because the layer is nearly the same in all of them. That asymmetry is not an accident of writing. It is the architecture stating its own economics: what varies by profession is what you own and carry, and what is the same everywhere is what you perform at each client.

Ayesha connects her first customer

She has her slice. One outcome, covered completely: the working paper, the sort record, the invariants, her aunt's derived reflex, the checker, the evaluation set. A partner at a Chicago firm read her working-paper page, told her his juniors spend four hours a file, and signed a first engagement. Now she is inside his firm, and the record she built is suddenly the smallest thing in the room.

The firm has twenty-two years of working papers in SharePoint. Engagement letters live in email. The reasoning behind unusual treatments lives in chat, and in the head of a senior manager who is often travelling. The trial balance sits in a system that changes hourly. Her Worker knows the standards perfectly and knows none of this.

She routes authority before she connects anything. What does the standard require for going-concern evidence? That is her Vertical System of Record: governed, cited, versioned, unchanged. What is the closing balance in account 1200, right now? That is the accounting system, by typed query, and she writes down the rule that will save her later. This number is never indexed. When a colleague suggests indexing the trial-balance exports so the Worker can "just find them," she says no, and can say why in one sentence: an embedded balance is a photograph of a number that has already moved. Why did we treat the Henderson lease as a finance lease in 2023? That is SharePoint, and that is the whole reason this firm needs a context layer at all. The memo exists. Its author has left. No governed system holds it, and without it her Worker cannot prepare a defensible current-year paper.

Then she tests permissions before she tests answers. She logs in as a first-year junior and asks a broad question about the firm's compensation policy. The correct result is nothing, because that junior cannot open those documents in SharePoint. She runs the same test as the engagement manager, and as the partner. Only when all three return exactly what each of them may already see does she connect a second source. Her aunt's rule, from twenty years of practice, is the one she follows: you find out what a control is worth by testing it before you need it.

Then she writes one line into the engagement's design record, and it is the sentence this whole page exists to produce. The firm's own material is evidence about this client. The profession's requirements come from the record. The Worker will never confuse the two, and every answer it produces will show which is which.

Six weeks later that line proves its worth, and it earns it as a conflict rather than an answer. The Worker prepares a lease classification. It cites the standard from the governed record. It attaches the 2023 memo separately, labelled as the firm's prior treatment. And then it does the thing a search tool never does: it reports that the two disagree, states what each says, names the authority test it applied, and escalates to the partner as the person who can settle it. He reads it, agrees, and corrects a treatment his firm has repeated for three years.

Ordinary similarity search does not produce that on its own. It has to be designed for and tested. A search tool finds the memo, finds it relevant, and answers from it. The difference between those two outcomes is the whole of this page.

The failure modes

In plain words

People often think this layer is one of five things. It is none of them.

It is not a document dump, not a vector database, not the model's memory, not a universal source of truth, and not a way around permissions. Each of those is a real project that went wrong.

Eleven ways it goes wrong follow. Learn to name them, and you will see each one coming early enough to stop it.

Eleven ways this goes wrong, so you can recognise each one early.

The flat index. Every source searchable, every result treated as equally authoritative. The cure is authority routing, resolved before retrieval.
The flattened portfolio. Several governed records poured into one pool, so a sales rule answers an accounting question and last year's policy outranks this year's. The cure is federation: route by profession first, and merge nothing.
Reliance on the copy. A synchronized governed page used as the authority, in whatever version it was indexed. The cure is discovery is not confirmation: a search hit is a pointer, and the governing record confirms.
The stale answer. A synchronized copy used for a fact that should have been fetched live. The cure is an indexed-or-live decision for every field that can change the outcome.
Retrieve first, hide later. Forbidden content entering the model context before filtering. The cure is permission before the model, and again before action.
The model as the quiet source. Retrieval returns nothing, and the model answers from what it seems to know, in a form indistinguishable from a grounded answer. The cure is the model is not a source: missing evidence is a packet field, and a reflex that cannot find its governing source escalates.
The prompt as integration layer. A long prompt telling the model how to interpret ten systems, while the connections, identifiers, and checks are never implemented. The cure is connectors, tools, schemas, and deterministic policy.
Citations without provenance. An answer that links to a page but loses its authority class, version, scope, or owner. The cure is the full provenance envelope.
The blended conflict. Two disagreeing sources summarized into one fluent sentence. The cure is conflict preservation, authority testing, and escalation.
The shadow record. The context platform storing its own copy of transactions, and quietly becoming the place people trust more than the source. The cure is source-owned live retrieval and governed write-back.
The product-shaped doctrine. The architecture defined by whichever vendor is in the lab. The cure is open interfaces and replaceable components.

The templates

Four working documents. Fill each one inside the customer's engagement record, not inside your shared vertical, because everything here is that customer's. Building the Context Layer fills all four against a worked customer case.

Template 1: The connected source register

One row per source. Fill this before the first connector runs.

Source system	What it governs	What it does not govern	Mode (indexed / live / both)	Max tolerated lag	Permission origin	Citable?	Owner at the customer
						yes / no

Template 2: The authority routing map

One row per question the outcome requires. This is the layer's version of the decision map.

Question	Which profession owns it	Governing source	Scope and jurisdiction	Path (retrieval / typed query)	What is supporting context only	Conflict rule
						resolved by scope / by authority / escalate

Template 3: The boundary contract

One per engagement. This is the document you show a compliance officer.

Field	Your entry
What may be indexed
What must be fetched live, and why a stale value would matter
What is never connected at all
How each item's access rules travel with it
How permission is re-checked at query time
What appears in an answer as governed truth
What appears in an answer as supporting context
Where an executed action is recorded
What must never leave this customer's instance
The route by which anything may be promoted downward
What happens when a source is unavailable

Template 4: The permission test set

Run this before the layer answers a single professional question.

Role tested	Question asked	What the role may see in the source system	What the layer returned	Pass or fail	Date	Retested

Include at least one question whose honest answer for a junior role is nothing at all. A layer that never returns nothing has not been tested.

The definition of done

The System of Context is ready to serve a Worker on one thin outcome when every box is checked. The customer's information owner checks the permission boxes personally.

The evaluation set must contain far more than successful searches. Test a relevant but non-authoritative message. A retired policy that matches the wording perfectly. The wrong customer's document. The wrong jurisdiction. A live value that changed after indexing. A reader without source permission. A Worker without action permission. Two applicable sources that conflict. A required source that is missing. And a source outage in the middle of a high-risk action.

Read this list twice, as you read the last one. It is the definition of done for the layer. It is also your definition of safe to deploy, because every unchecked box above is a way for a helpful system to hand the wrong person the right document.

Appendix: one cross-domain request, end to end

Everything on this page runs on one request, in Ayesha's firm, six months into the engagement. The firm now has an accounting Vertical System of Record, which is hers, and a sales one bought from someone else. Read this once and the whole page is a description of these eight steps.

A partner forwards a message from a client and asks: can we approve a twenty percent discount on this renewal and book the revenue in June?

Step 1. Identify. The partner is asking. The customer is the client firm. The case is the renewal contract. The task is a recommendation, not an approval. The jurisdiction and reporting basis come from the customer instance. The intended action is prepare and recommend, never approve.

Step 2. Decompose and route. One sentence, several questions. Is the discount within commercial authority? Sales. Are the renewal terms enforceable? Legal. When is the revenue recognisable? Accounting, which is Ayesha's own record. What did the client actually agree? No record governs that, so it is supporting context. Has the last invoice been posted? The traditional record, and only live.

Step 3. Retrieve in three modes. The sales record's discount rule and Ayesha's recognition reflex are found in the discovery index, then confirmed against each record before anything is cited. The client's messages and the prior renewal file come from SharePoint, permission-checked. The current billing state and the contract's active version are fetched live, because a stale value here would change the answer.

Step 4. Filter. The partner may see all of it. Had a first-year junior asked the same question, the pricing history would not have appeared, because the permission travelled with the document.

Step 5. Assemble. One packet. The governing rules, each naming its own record. The current facts, time-stamped. The client's messages, labelled supporting context. One missing item: no signed acceptance for the second deliverable. The permission envelope: prepare and recommend only.

Step 6. Notice the conflict. The sales record permits twenty percent at this contract size. Ayesha's accounting record says the revenue cannot be recognised in June without acceptance evidence. Both are correct. They answer different questions, and this is resolved by scope, not by one record outranking the other.

Step 7. Reason and recommend. The Worker recommends approving the discount, and recommends against June recognition. It cites the sales rule for the first and the standard for the second. It names the one missing document that would change the second answer. It does not blend the two into a single cheerful yes.

Step 8. Act and record. The partner approves the discount. The sales record validates that the approval is within authority. The CRM writes it and records who approved it. The recognition question stays open, and the conclusion with its evidence goes into the governed case record, where a reviewer can rebuild it without asking the model.

Read the eight steps again and notice what never happened. No record was merged into another. No indexed copy was cited. No live number was answered from an index. Nothing the partner could not already see appeared. The disagreement was not smoothed away. And the layer that made all of it possible made no professional judgment and created no authoritative fact of its own.

The architecture in one sentence

The whole page compresses into one rule.

Many domains. Many Vertical Systems of Record. One System of Context connecting them without flattening their authority. The records own truth, the layer assembles relevance, the Worker reasons and acts within permission, and the evidence returns to the record that owns the result.

Build the truth first, with the Agent Factory record and your vertical record. Connect the context second, with the customer's systems, identities, permissions, and provenance. Assemble the task, with authority, current facts, support, gaps, and citations. Operate the Worker through governed tools and human approval. Record the result where truth belongs.

Where to go from here

This page sits between the record and the engagement. Designing the Vertical SoR built the governed truth, and the build course turns that design into running software. This page adds the layer that carries it into a customer's world. The hands-on build is Building the Context Layer: it deploys Onyx Standard, connects the four source classes, serves your record over MCP, and proves the permission gate. It sits in Mode 2 directly after AI Searchable Context, which teaches the retrieval layer your record itself is built on, and the two together make the scope jump visible: one builds a store for a single Worker, the next builds the corpus a whole workforce reads from.

Then the fixed order continues. Skills & Connectors teaches MCP, an important interface for agent-facing knowledge and governed tools, alongside the OpenAPI, connector, and typed-query paths this page also uses. Eval-Driven Development teaches the proof. This layer needs an evaluation set of its own, built around the conflict cases: the customer's own material says one thing, the governed record says another, and the passing answer is the one that shows both and names which governs. Building a Digital FTE builds the Worker that reads from all of it, and Human-Agent Teams puts that Worker beside the people who will trust or distrust its answers.

One last framing, for when this layer feels like plumbing beside the record you spent months designing.

It is plumbing, and that is exactly the point. Nobody buys plumbing, and every building has it. The asset you carry from client to client is the governed profession, plus the Layer 3 pattern that connects it. The fitting is what makes that asset usable inside a company that has never heard of it. A vertical Forward Deployed Engineer who cannot connect the record to a customer's real information is holding a beautiful book in a room where nobody can reach the shelf.

Which is also the honest reason this page comes last in the Ecosystem. The record is what makes you worth hiring. The connecting layer is what makes you worth keeping.

The page on one poster

For sharing, teaching, and quick revision: the whole architecture on one poster. The page above stays the canonical wording, and the poster is the summary.

Flashcards Study Aid

Test Your Understanding

Checking access...

📚 Teaching Aid​

Why the Vertical System of Record is necessary and not enough​

Two kinds of record, and the layer above them​

QuickBooks holds the data. It does not hold the profession.​

One word of caution about how this gets said​

Three layers, three jobs​

The one law: authority never moves​

The model is not a source either​

Three places the model quietly becomes the source​

What the model is actually for​

Authority is scoped across many records​

The portfolio, not the pair​

One business event, several governing records​

The three questions, and the three paths​

What the layer assembles: the context packet​

The packet is temporary, and that is the design​

What may be indexed, and what must be asked​

Working context is indexed​

Governed knowledge is discovered, then confirmed​

Current state is asked for, every time​

And the ungoverned stays ungoverned​

Why chunking is where governance disappears​

Permission comes before the model​

Why this is a control question, not only a privacy one​

Provenance travels with every item​

Governed truth and supporting context​

Conflict is a result, not a retrieval failure​

Read, reason, act, and record​

The eight invariants of the connecting layer​

Where it sits in the FDE AF Model​

Consolidate by default, specialize deliberately​

The open reference implementation​

What the tool teaches, and what you must still design​

When you do not need one​

Two temperaments, one layer​

Ayesha connects her first customer​

The failure modes​

The templates​

Template 1: The connected source register​

Template 2: The authority routing map​

Template 3: The boundary contract​

Template 4: The permission test set​

The definition of done​

Appendix: one cross-domain request, end to end​

The architecture in one sentence​

Where to go from here​

The page on one poster​

Flashcards Study Aid​

Test Your Understanding​

📚 Teaching Aid

Why the Vertical System of Record is necessary and not enough

Two kinds of record, and the layer above them

QuickBooks holds the data. It does not hold the profession.

One word of caution about how this gets said

Three layers, three jobs

The one law: authority never moves

The model is not a source either

Three places the model quietly becomes the source

What the model is actually for

Authority is scoped across many records

The portfolio, not the pair

One business event, several governing records

The three questions, and the three paths

What the layer assembles: the context packet

The packet is temporary, and that is the design

What may be indexed, and what must be asked

Working context is indexed

Governed knowledge is discovered, then confirmed

Current state is asked for, every time

And the ungoverned stays ungoverned

Why chunking is where governance disappears

Permission comes before the model

Why this is a control question, not only a privacy one

Provenance travels with every item

Governed truth and supporting context

Conflict is a result, not a retrieval failure

Read, reason, act, and record

The eight invariants of the connecting layer

Where it sits in the FDE AF Model

Consolidate by default, specialize deliberately

The open reference implementation

What the tool teaches, and what you must still design

When you do not need one

Two temperaments, one layer

Ayesha connects her first customer

The failure modes

The templates

Template 1: The connected source register

Template 2: The authority routing map

Template 3: The boundary contract

Template 4: The permission test set

The definition of done

Appendix: one cross-domain request, end to end

The architecture in one sentence

Where to go from here

The page on one poster

Flashcards Study Aid

Test Your Understanding