The knowledge layer: opening the company library to AI

The previous post made the case for why the knowledge layer is worth building now: twenty years ago the data warehouse promised a model of the enterprise and largely did not deliver one. AI is the reason to try again: first people asking questions of their data in plain language, and soon agents acting on it. This time not by forcing consensus on definitions, but by making meaning explicit. It is fine that finance and marketing each keep their own definition of an active customer, as long as both are written down and the agent can tell which one the question calls for.

Do that for the concepts, the definitions and the processes together, and what you end up building is a digital twin of your business. Not of a machine or a production line, but of how the organization is put together and how its work actually gets done: a model complete enough that an agent can reason and act on it.

With agents that act we do not just model the familiar what, we have to model the how as well: processes that the business executes, with every step specified.

Moving from modeling just the what, to also modeling the how, also marks the progression from conversational analytics (human judges, low risk) to agents acting (agents decide, increased risk depending on the type of decision).

The how and the what get served from the same model. Its consumption is not restricted to AI use cases: ordinary applications and BI tools can also read from the same model.

This post is about what architecture that model is built on. I describe it as a library, and then run the Acme credit note case from the previous post through it end to end.

The knowledge layer architecture #

A knowledge layer is best understood as a library. The library has four parts:

• The library catalog: a structured register of what exists, what it is about, and where to find it. Or in our case: where to find the data about those things that exist in the business.
• The library shelves: the actual data itself, structured and semi-structured (tables, JSON) and unstructured (documents).
• The cataloger: populates the catalog with the right metadata, so that the structured and unstructured data can be found. It does this by applying extraction methods.
• The librarian: queries the catalog and gets data from the shelves. It makes sure that the books can stay on their shelves.

The inspiration for this analogy comes from “The Subject Approach to Information” by A.C. Foskett (4th edition), a book about information retrieval that I found a few years ago. Published in the early 1980s, it describes the foundations of information management and practically gives insight into how to organize a library, or any other knowledge repository, in a time just before the personal computer became common.

The layer sits between the existing data sources and the AI. It is not another data platform and it does not require you to consolidate anything first: it is bolted onto the systems that are already there.

From bottom to top:

• The cataloger extracts from structured and unstructured data that lives on the shelves, mines business logic from code, and elicits knowledge from business experts. It writes this meaning and index into the catalog.
• The library catalog has the model, the approved processes and an index of what has been observed in the data.
• The librarian resolves a question by finding relevant concepts in the catalog and then going to the shelves for the data itself.

The shelves already exist, so only the catalog, the cataloger and the librarian have to be built. Those three are the knowledge layer: a governed model that points at the data rather than a place that holds it. The catalog indexes the shelves, holding the concepts, the facts that identify things and the links between them, while the bulk of the data stays where it is.

The library catalog #

At the core of the knowledge layer is a store of structured knowledge. Usually this takes the form of a knowledge graph, generally stored in a graph database. The database is not the knowledge graph though. A graph database stores data; a knowledge graph encodes meaning.

What it encodes is the organization’s semantic memory: what the business means by its terms, and what it knows about the things those terms refer to. In the agent memory taxonomy that covers the concepts and the facts.

The knowledge graph holds two distinct things.

The TBox: the terminology box

• is the ontology: the classes, relationships, hierarchies and axioms that define what could exist
• in library terms: the classification scheme and the cataloging rules. Not a record of any individual book, but the system that decides how every book gets described
• in a business it for instance defines that customers exist, and that customers have contracts
• it is the map of the organization
• it is small, human-readable and slow-changing.

The ABox: the assertion box

• holds the instances: what actually does exist, with its attributes, edges and derived facts
• these are the catalog entries, an index into the actual underlying data. It records that Acme Corp is a customer holding contract ACME-2026-0894-MSA, and where the underlying data for both can be found
• it is the territory that the map describes
• it is large, machine-fed and fast-changing.

The TBox is the map, the ABox the territory. This is where the digital twin becomes concrete: a reviewed map combined with live facts about the territory is what makes it operational rather than just documentation. The map is small enough to be agreed on by people. Most of the territory keeps itself current.

The ABox holds two kinds of things: instances that people put there deliberately, and facts that machines load. They compare like this:

What is key is that the asserted part of the graph is small enough to be human reviewed, and should be human reviewed. That is the ontology plus the instances people put there on purpose, including the processes. Human review of everything on the asserted side is the foundation for making the whole system auditable. It also costs expert time, which is one of the constraints that decide whether any of this is affordable.

Further automation ensures the auditability:

• all data in the graph has provenance: at a minimum the source, timestamp and confidence.
• critical data in the graph is shape validated: the model defines what valid data looks like and upon load non-conforming data is rejected.
• every assertion is bi-temporal: it records both when the fact was true in the business (business validity) and when it was observed in the graph (technical transaction time).

Bi-temporality #

A graph without time can only talk about what is true now. This means it cannot answer an audit question. There are two timelines to keep track of, hence bi-temporal:

• Business validity time: the period in which a fact is true in the real world. Acme’s MSA started in January and later gets corrected to start in December.
• Technical transaction time: the period the graph was aware of the fact. The same MSA was only loaded into the graph in March and the correction arrived in June.

Both of these timelines are true and need to be tracked. The first tells us what the real world looked like, the second tells us when we were aware of it. Especially the latter matters when it comes to traceability and auditability. It is required to be able to replay agent decisions.

This is not new thinking and is seen in the 2006 parallel again. Data warehousing handles it with slowly changing dimensions, and Data Vault 2.0 made system-time history the default.

Modeling the how, not just the what #

What sets a knowledge layer apart from a semantic layer is that it models the how, not just the what.

Imagine a customer that is owed a credit note because a service level was missed. The what is the vocabulary involved: customers, agreements, service level terms, credit notes. The how is what actually gets done with them. Those are two different memories: the what is the semantic memory above, the how is the organization’s procedural memory.

The market already splits along that line.

Microsoft’s Fabric ontology feature allows you to turn a Power BI semantic model into an ontology, by extracting the concepts, properties and relationships from that model. That is not a bad starting point, but it results in a re-skinned schema that does not have the richness it could have. It has no rules, no provenance and no policies, and describes nothing the source model did not already provide. It describes the what.

Compare this to Palantir’s ontology, which explicitly splits its model in two. The semantic elements are objects, properties and links, “the nouns.” The kinetic elements are action types and functions, “the verbs.” Palantir’s ontology describes the what and the how.

For Acme, the how looks like this:

That is the credit note process. It might look like an ERP workflow, but keep in mind that this works across many data sources, structured and unstructured. Step 1 resolves a name across the CRM, the ERP and the contract repository, and step 3 reads a cap out of a signed PDF.

So the how is modeled as processes and their steps. A step at a minimum has a name, a description of what it does, its inputs and outputs, the conditions under which it applies and its exceptions, and any tools it might use. Every step above uses a different tool, including a tool to execute deterministic logic (scripts). Step 2 has a condition, because it only applies if the customer has an active MSA, and if there is none the standard terms apply instead. Step 1 has an exception: if the party in the request does not resolve to exactly one customer, stop and ask.

Steps compose: a step of a large process can itself be a process, down to the level where a step is a single query, an API call or a human approval. Step 4 is one of those, as it determines the monthly invoice value and then applies the 10% the clause specifies. Monthly invoice value has its own choices to make: which invoices count, issued or paid, a calendar month or the billing cycle, gross or net of credits already issued, which rate to use for the invoices that are not in euros. Calculating the monthly invoice value is something the semantic layer would hold as well. The knowledge layer treats it as a general thing, just like the other five steps that are not modeled in a semantic layer. It is the other steps that make it possible to arrive at an action.

Stored steps are not a script, but guidance. An agent handling a routine request follows the path the business agreed on, which is what keeps day-to-day operations predictable. Faced with something nobody wrote down, it can still compose known steps into a process that fits, because every step has the same shape. Without processes and steps, an agent would reconstruct the steps every time and improvise every run from scratch.

Processes live on both sides of the TBox/ABox split. The vocabulary for describing a process is TBox: the classes for a plan, a step, a variable, and the ordering between steps. The processes themselves are ABox, because there are many processes like the credit note process that instantiate those classes. Their executions are ABox as well, but observed rather than asserted: every run is recorded as an execution trace against the steps it corresponds to. Together these traces are the organization’s episodic memory, which makes agents’ actions reconstructable afterwards.

This is a solved modeling problem. P-Plan is one such vocabulary, an extension of the PROV provenance standard that separates the plan from its execution, and that already treats a plan as something which can appear as a step inside another plan. What it does not give you is the binding of a tool to a step, or conditions and exceptions, so expect to extend it.

For deterministic steps, logging is straightforward: recording the inputs, outputs, and code version tells the whole story. When AI is involved, the best we can additionally track right now is its conversation history and chain of thought. Capturing this real-time rationale is what enables the process-improvement patterns discussed in keeping the model in sync.

One question, one slice #

An agent does not get the whole catalog. When it queries the graph it is served the slice relevant to the question asked: the concepts, definitions and rules. Anthropic frames the goal of context engineering as finding “the smallest set of high-signal tokens that maximize the likelihood of your desired outcome”, treating context as a finite resource with diminishing returns. A governed model is what makes that achievable over enterprise data. It is more accurate and cheaper to run at the same time.

Once the graph becomes rich enough, the slice by itself can answer the question. Questions about how the business is put together rather than about its numbers. Today these are usually unanswerable, as nothing captures the organizational structure. A question such as “which customers hold a contract that depends on the same supplier?” can be answered from the graph, without opening a single book.

The library shelves #

The shelves hold the data itself: the actual data in the systems of record and other pre-existing data sources. The catalog records what that data is, what it means and where to find it. The data keeps living where it already lives.

Typical data stored on the shelves:

• Structured: ERP, CRM, accounting, HR and payroll systems, service management and ticketing tools, operational technology such as MES and sensor historians, and data warehouses, lakes and lakehouses built on top of them.
• Unstructured: contracts and policy documents, manuals and specifications, document repositories and network drives, case and ticket notes, email and collaboration archives.

Many questions need both types of data, which is why the catalog needs to treat them as one collection.

The books come as they are #

Whenever I talk with data people, from engineer to boardroom, I hear the same thing: “my data quality is not good enough.” It is a real worry, and no modeling method magically makes it go away. Poor data quality is something that must be addressed.

Address it by following the same approach as the model itself: let data quality follow value. Do not clean the whole data estate up front. Only improve data in the fields that the use case actually reads, to the level that the use case needs. Do not aim for abstract perfection.

Detect with classic profiling and with AI. Profiling, pre-defined validation rules, anomaly detection, freshness and volume checks, reconciliation and referential integrity checks still detect the bulk of the issues. The graph adds some extra tools:

• Shape validation. Validating data as it is loaded into the graph does not only block invalid data from entering, it also surfaces the data quality issues, such as a contract without an end date.
• Cross-source reconciliation. Since the graph connects multiple sources, reconciling them becomes much easier. A customer with a different billing address in CRM than in ERP shows up as two conflicting values on the same node.
• Reasoning. The ontology already defines what is expected, so reasoning over the instances surfaces contradictions, such as a delivery that is dated before the order it belongs to.
• Peer comparison. Peers in the graph can be compared, such as products in the same category where one is a clear outlier: a weight in grams among kilograms, or a lead time in hours where the rest are in days.
• Edge analysis. Using AI, it is even possible to flag which edges look out of place and which ones might be missing, such as an active contract that is not linked to any customer.

Usage is a source for detecting issues as well:

• processes that fire exceptions, such as step 1 of the credit note process resolving to more than one customer
• humans that override a value and provide feedback
• an agent’s chain of thought that marks a value as implausible

Prioritize for value. To make sure the right data gets fixed, issues need to be prioritized. This can be automated to a large degree. Issues with high impact can be found by looking at:

• declared use, such as the inputs of a process step
• observed use, the parts of the graph that query logs and execution traces show get read, and how often
• structural importance, such as the edge linking a customer to its contract, or a key bridge in the graph that has a ripple effect when it is incorrect

The issues are then weighted by risk: an issue that affects an ERP write matters more than one impacting the answer to a conversational question.

Show why it is wrong and let AI propose the fix. The provenance of the affected data often shows that many issues trace back to the same cause and tells you when it started. For example, every order with an amount in the wrong currency came in through the same nightly load, starting the day an exchange rate feed changed format. By reasoning over the data, AI can deduce what is wrong and propose a fix.

Have a person approve. Most proposals are quick decisions that should be reviewed as such: one at a time from a queue, accept or reject, i.e. “Tinder with your data”. If the impact is larger, the corrected data is replayed against the business process it feeds into, so that the reviewer can see the downstream impact before approving.

Fix at the source when you can, but do not wait for it. The durable way is to fix the issue in the system of record. The reality is that changing the system of record in time is not always feasible, especially when ownership is unclear, release cycles are long or change boards are involved. When this takes months, let the knowledge layer correct the data (both existing and incoming), with provenance attached for traceability.

I will come back to improving data quality in a future post.

The cataloger #

To get the catalog populated, knowledge needs to be extracted and categorized against the ontology. It comes from four kinds of sources, roughly in order of how easily it can be extracted:

1. Structured sources. Schemas that can be mapped declaratively onto the ontology: this table is that class, this column is that property. The usual starting point, because the mapping is straightforward.
2. Unstructured sources. Documents are processed to extract entities (NER, named entity recognition) and the relationships between them. Linking the entities across documents is the harder part of the job: resolving “Acme”, “ACME Corp.” and “Acme Corporation B.V.” to the one customer that already exists in the graph. This entity resolution is what MDM tools try to solve as well. Without that linking step, the extraction produces a parallel set of nodes that cannot be traversed together with the rest of the graph.
3. Embedded logic. This is code, ETL and events. This rich source of business logic is parsed and interpreted. It is where the business rules actually ended up, which makes it the main source of the how.
4. Tacit knowledge. This is experience, judgment, know-how, “how we really do it.” This deep source of organizational knowledge is the messiest, and it can only ever be approximated. Methods include task analysis, expertise extraction, storytelling and observation. Traditionally this is hard and takes a lot of time away from the most valuable experts. However, AI is also accelerating this field, by for instance running AI-driven interviews that people can take at their own level of expertise and pace.

The reliability of extracted knowledge is not equal, which is why it is tracked through its provenance and confidence. Declarative mappings are deterministic, extracted relationships are probabilistic, and elicited tacit knowledge is an approximation.

The librarian #

The librarian is what makes the collection usable. It queries the catalog to establish which concepts and rules a question involves and where the relevant data sits, and then goes to the shelves for the data itself. That second step is federated: the agent punches through to the source system, so the query travels to the data instead of the data being copied to the query. Nothing is migrated, so the source systems and data platforms you already run keep serving what they already hold. The books stay on their shelves.

An agent uses tools to access the librarian. This includes tools for keyword search, semantic search and graph traversal. In the end it allows the agent to first understand what terms mean, before it asks the data anything. People and regular applications just as much benefit from this access pattern, as they can utilize the same governed knowledge.

Because both structured and unstructured data are accessible, a person asking in conversation, or an agent acting on its own, can combine an understanding of the business with calculation over its data. It can for instance:

• verify whether the delivery lead times recorded in ERP stay inside the commitment set out in the customer’s contract
• compare the temperatures and cycle times a machine logged last week against the operating limits in its maintenance manual
• reconcile a supplier invoice against the payment terms in the signed contract rather than the terms in ERP master data
• check whether a change followed the approval path its policy describes, by reading the policy against the ticket history
• explain a margin drop by pairing transaction data with the pricing exceptions that were approved by hand

With query federation, identity travels with the query: access to the data is limited to whoever initiated it. A person in the case of conversational analytics; a service principal in the case of business process automation. The source systems apply their own authorization, so that an agent sees exactly what its principal may see.

Putting the four together #

With the catalog, shelves, cataloger and librarian in place, the following scenario is possible:

• In the TBox we define that there are customers that have MSAs, that contain SLA terms, along with the vocabulary for describing a process and its steps.
• In the asserted ABox sits the credit note process from earlier, its six steps reviewed and approved by whoever owns commercial terms.
• Through the cataloger the observed ABox gets filled: Acme Corp arrives from the CRM as a customer, and MSA ACME-2026-0894-MSA comes out of the contract repository with the clause SLA breach penalty capped at 10% of monthly invoice value, linked to that same Acme Corp.

An agent then receives a request to issue a €15,000 credit note to Acme Corp for a late delivery. Through the knowledge layer it retrieves the credit note process and runs it:

• Step 1 queries the catalog for Acme Corp, which resolves to exactly one customer, so the exception does not fire.
• Step 2 traverses to MSA ACME-2026-0894-MSA. The condition holds because the MSA is active, so the standard terms never come into play.
• Step 3 retrieves the SLA remedy clause and its cap rule: 10% of monthly invoice value.
• Step 4 punches through to the ERP for the monthly invoice value, €100,000, counting the invoices the stored definition says to count, and applies the 10% to arrive at a €10,000 cap.
• Step 5 finds that the requested €15,000 exceeds that cap.
• Step 6 takes the exception path and routes the case to a human supervisor.

Each execution is recorded against the step it corresponds to, with the values and version of the process it used. This way the decision is reconstructable, thus explainable and auditable.

The stored steps are guidance, not guardrails. So the process says to escalate, but it cannot make the agent obey. True enforcement has to sit where the action happens, entirely outside the agent’s reasoning. In practice, this means intercepting the tool call at a policy decision point, evaluating the requested action and its arguments against rules the agent can neither see nor edit, denying by default.

While that enforcement machinery is mature, the tooling is not yet connected to the model in the knowledge layer. However, this entire guardrail layer only becomes relevant once agents start taking unsafe, irreversible actions. Starting with agents that merely propose actions, or only execute safe ones, covers an enormous amount of ground without needing that complexity. I will dive deeper into how policy engines and agent guardrails wire into the knowledge layer in a future post.

Library mapped on the knowledge layer #

Earlier I defined the terms that I use for the knowledge layer. This is how the library metaphor maps onto it:

The agent’s own conversation state is short-term and local with the agent. Once it is complete, the execution trace through the graph and data is stored in the episodic memory. The full conversation history is kept, so that its chain of thought can be mined for its decision intent, something I address in the evolution loop.

What comes next #

Everything above describes the layer as if it is finished: the ontology defined, the processes reviewed and approved, the catalog filled. In practice it rarely stays that way. The business starts selling a product the ontology has no way to express, agents keep composing a process that nobody wrote down, or a process that turns out to be fully specified in every branch should become code instead. This is expected in a dynamic organizational context. It is what happens to any map of something that keeps changing.

So a knowledge layer is not a project that defines an ontology once and hands it over. It needs the machinery to notice where it has drifted from the business, to propose the correction, and to get that correction reviewed by someone who can decide. That is what I dive into in the next post.