Enterprise Knowledge Layer: Three Approaches Compared
An enterprise knowledge layer can be a modelled knowledge graph, a governed metadata catalog or knowledge compiled from source. How each is built, what it covers, and when each one fits.
An enterprise knowledge layer is a shared, governed store of what an organization knows about its own systems and business, which AI agents and applications read instead of rediscovering it on every request. The term is new, and vendors use it, along with "context layer" and "context graph", for quite different products. The difference that matters most is how knowledge gets into the layer: someone models it, someone curates it, or it is derived from the systems themselves.
This page compares the three approaches, and plain retrieval (RAG) as a baseline. EKOS is one of them, so read it as a map, not a verdict. The other approaches are described from their vendors' own framing, linked below.
The three approaches
| Modelled knowledge graph | Governed metadata catalog | Compiled knowledge | |
|---|---|---|---|
| How knowledge gets in | an ontology is designed, data is loaded and linked into a graph database | connectors harvest technical metadata; people add owners, glossary terms and policies | source code, schemas, ETL, Git history and documents are read and compiled by deterministic passes |
| Who keeps it current | the team that owns the ontology and loaders | data stewards, with automated harvesting | a rebuild: the next compile re-derives it from the changed sources |
| Strongest at | rich, custom relationships across business entities; graph queries; agent memory | governance, ownership, access policy, a business glossary people trust | what systems actually do: call graphs, lineage through views and procedures, what breaks if something changes |
| Evidence per fact | as modelled | the source system of each asset | file, line and fragment on every fact, in an append-only ledger |
| Examples | Neo4j's knowledge layer | Atlan, Alation | EKOS |
RAG, retrieval over chunks of text, is not a knowledge layer in this sense, though it is often the first one teams build. It is fast to set up and works well for prose. It loses structure, though: a foreign key or a call from one function to another is a relationship, not a chunk. It also returns whatever text is closest, so an outdated page is retrieved as confidently as a current one. Most knowledge layers use retrieval inside them; none should be only retrieval.
When each one fits
- A modelled knowledge graph fits when the hard part is the business domain itself: customers, products and contracts linked in ways no source system records, maintained by a team that owns the ontology.
- A metadata catalog fits when the hard part is governance: who owns a dataset, who may see it, which definition of "revenue" is the approved one.
- Compiled knowledge fits when the hard part is that nobody knows what the systems do: a twenty-year-old schema with hundreds of stored procedures, Pentaho jobs nobody wrote down, a codebase where thirty files mention
customer. It also fits when every answer must be checkable against the source.
They are not exclusive. EKOS exports what it compiles (a graph export, and business semantics as a LinkML schema), so compiled facts can seed a modelled graph or a catalog's glossary instead of being typed in by hand.
How compiled knowledge works in EKOS
EKOS treats the problem as compilation. Connectors observe sources without interpreting them, and secrets and personal data are redacted before anything is stored. Deterministic passes then recover structure: tables, keys, views, procedures, calls, lineage, documentation links. Matching objects seen in different places are resolved into one, and the result is committed to an append-only ledger. Agents read it over MCP, read-only. When EKOS is unsure, for example whether two similarly named tables are one thing, it records an unconfirmed claim for a person to review instead of merging them. More: AI knowledge layer and The Knowledge Compiler.
Frequently asked questions
What is an enterprise knowledge layer?
A shared, governed store of what an organization knows about its systems and business, which AI agents and applications read instead of rediscovering it each time. Implementations differ mainly in how knowledge gets in: modelled into a graph, curated in a metadata catalog, or compiled from the source systems.
Is a knowledge layer the same as a knowledge graph?
Not necessarily. A knowledge graph is one way to store and query a knowledge layer. A layer can also be built on a metadata catalog, or compiled from source into a ledger of objects, relationships and evidence, as EKOS does.
How is a knowledge layer different from a data catalog?
A data catalog inventories data assets and governs them: owners, glossary terms, access policies. A knowledge layer for AI also has to answer questions about behaviour, such as what a procedure does, what depends on a column and what breaks if it changes, in a form an agent can query directly.
Do I need a knowledge layer if I already have RAG?
RAG retrieves text that resembles the question. It cannot follow a foreign key or a call graph, and it cannot tell a current document from an outdated one. For questions about how systems behave, you need structure and evidence, which is what a knowledge layer adds.