Your Knowledge Base and Your Database Have Never Met. That Is What Knowledge Engineering Is For.
You have a database of rows and a knowledge base of documents, PDFs, flat files and everything else nobody could ever query. Both are full of what your organization knows. Neither has ever been read together with the other, so a person still opens two systems and does the join in their head. Why? Because fusing them safely is not a plumbing problem: the two halves carry their sensitivity in completely different ways, so the governance has to hold across the join. Knowledge engineering is the layer where that fusion happens and stays governed.
Infozense Knowledge Engineering · CIO · Head of Data · CISO · ~7 minutes
The Infozense Knowledge Engineering library describes a governed data layer with five gates: Input (who may ask) · Egress (what may leave) · Output (safe and true) · Action (who approves) · Operational (prove it later). This piece is about what the gates are gates on. Not a gate. The thing itself.
Ask your organization a real question and watch how the answer gets built.
Are we within the limit on this client? The limit is in a document. Somebody wrote it, it was approved, it sits in a policy your compliance team maintains. The current position is in a database. Nobody wrote it. It accumulated, one transaction at a time, and it changed while you were reading this sentence.
Neither system can answer the question. A person answers it, by opening both and doing the join in their head.
That person is the integration layer. They are slow, they are expensive, they are the only one who knows which policy applies to which table, and one day they will leave, taking with them the skills that came from years of doing the job.
The question needs both halves. Neither system has ever had both.
Who this is for
If your questions are answered from documents alone, this is not your problem. A retrieval system over a good corpus is the right tool and you already have it.
You have this problem when the question needs both halves. Is this claim reimbursable needs the coding rules and the encounter. Can we approve this needs the credit policy and the exposure. Did that supplier breach the agreement needs the contract and the delivery history. In each one the document supplies the rule and the database supplies the fact, and the answer is the collision of the two.
It is sharper if the rule is regulated, the fact is personal, or both. Which, in the businesses that ask these questions, is usually both.
We have solved half of this twice
Business intelligence solved one half, and solved it well. You pointed tools at the database and could finally ask what happened: how many, how much, which region, since when. Most organizations still run on it, and keep doing so, because there are not many alternatives. Worse, it cannot make sense of the text in a document. It can tell you how much was spent, never whether the policy allowed it.
Retrieval solved the other half. Point a model at the corpus and ask what the policy says, in plain language, and get an answer with citations. Also real, also widely deployed. But it never touched a row. It answers from what was written down, never from what actually happened.
So you own two capable systems that have never met, and one person in the middle holding the only working copy of how they connect.
The two halves are different kinds of thing
Nobody overlooked this. The two halves never met for the same reason that joining them safely is hard.
A knowledge base and a database are different kinds of thing. One holds text that a person wrote and another person approved. Its meaning is in the prose, and its sensitivity was decided by whoever classified the document. The other holds rows that no one wrote. Their meaning is in the schema, and their sensitivity depends entirely on which columns you touched.
So a system that reads both is not reading two data sources. It is reading two different theories of what data is, and it has to hold the governance of both at once.
Bolting a database onto a retrieval system does not do that. It gives an AI a second source and no way to reason about what the second source was allowed to be used for. The usual result is a system that lets a regulated row and a public paragraph into the same prompt and sends the whole thing to whichever model was configured that month.
One answer, two kinds of source, one rule
A knowledge engineering layer treats the pair as the unit.
A question arrives that needs both. The layer retrieves the relevant passages from the corpus, and it runs a read-only query against the customer's own database, in place, without copying the rows anywhere. Then it assembles both into one answer, and this is where the interesting part happens.
Every piece of that answer arrives carrying its own sensitivity, and they arrive by different routes. A document passage carries the classification assigned when the document was taken in. A set of query results carries the sensitivity of the tables the query actually touched. Two mechanisms, two histories, one answer.
The layer then takes the strictest of everything present and treats that as the sensitivity of the answer itself. Not the average. Not the document's. The maximum across both kinds of source.
And that single value decides everything downstream: whether the answer may be composed by an outside model or must stay on your own hardware, whether personal details are masked before it leaves, what marking the reader sees, and what the record says afterwards. One rule, applied to a thing that came from two worlds.
What that buys, in one sentence
Your policy can be public and your position can be confidential, and the answer that combines them is treated as confidential, automatically, by rules set up in advance rather than by anyone remembering.
That is the sentence a retrieval system cannot say, because it never had the second source to be strict about.
Two sources, two ways of carrying sensitivity, one value that decides.
Where data is combined is where the risk is highest
In typical orchestration, an agent or a piece of code (called a flow) pulls data from several databases and documents, combines it itself, and sends it straight to the model. Because the combining happens on its own, the combined data never passes through the gate. Because it never passes the gate, nothing checks its classification and nothing masks it. So confidential rows can reach a model that was never allowed to see them. Writing the rules into the prompt does not prevent this, because a prompt can leave out a governance rule, and nothing checks that the rules were followed.
Typical orchestration
Pulls the data itselfRows from databases, passages from documents.
→
Combines it itselfInside the agent's or the flow's own code.
→
The model
The gate is never passed. No label check, no masking, no record. A rule written into the prompt can be left out, and nothing checks that it was followed.
Through the layer
Data the layer retrieved itself
A flow that combines database rows with documents
→
One gate, the same for both
Takes the strictest label the pieces arrive with
Checks it against the ceiling; a refusal stops here
Sends only to an allowed destination
Masks, when the destination is an outside model
Records every call it sends
→
The model
Combining outside the gate, and combining through it.
This risk does not happen once and go away. Every time someone adds a flow that combines data, if that flow does not go through the gate, it can send data straight to the model again, and nobody will know, because nothing records it.
The answer is not a patch on each flow. It is to give flows a way in through the same gate the layer's own retrieved data passes through, so that data a flow combines itself takes the strictest label its pieces arrive with, is checked against the ceiling, goes only to an allowed destination, is masked when that destination is an outside model, and is recorded. In this system, the flow that combines database rows with policy documents goes through that gate.
Any product that has fused these two sources has met this problem. Ask whether a flow built in the product can reach a model any way except through the gate.
Why not just query directly?
It is a fair question. If everyone who asked could be trusted to judge what they may see and what they may combine, the rules in this layer would be overhead, and most people can. But the caller is increasingly not a person. It is an application or an AI agent, and more and more often it is one agent handing its results to another.
A person weighs what they are about to combine. An agent does what it is asked, and what it is asked can come from the material it reads: a line planted in a document, a cell in a table, a row a query returned. The model is not the attacker. It is the instrument. So a rule that lives inside the agent can be talked out of by the very text the agent is processing. The rules have to live in the one place every caller passes through, where no instruction hidden in the data can reach them.
That is also why, on the governed path, the agent never holds the database credential. The layer does. The agent sends a request; the layer decides whether it may run, runs it, and records it. When the layer combines results from several sources, the combination takes the strictest level among them, and every answer it returns carries that level with it, so the next step, person or agent, can be held to it.
The five Gates that do this work are described in You Governed the Agent. This section is the reason they sit in the layer rather than in the agent. What the layer governs is the machine caller. The decisions and the actions stay with people, and that is the subject of the next section.
Where a person stays in the loop, and why
A layer that combines your documents with your database should not also be the one deciding what that data means, or what to do about it. So the design leaves these decisions with a person, on purpose.
Data with a label
The label travels with the dataSet by the people accountable for the data, not by the model.
→
The request takes the strictest label presentNot the average, not the first item. The strictest one in front of it, this time.
→
Public → a frontier model in the cloud
Confidential → a model on your own hardware
Most sensitive → no model at all
An example mapping, set once by an operator.
Data without a label
No label, an unknown one, or a malformed one
→
Treated as the most sensitive it could be
→
Only the strictest destination: your own hardware, or no model at all
With verification switched on, a person's decision made per workspace: any text the layer cannot trace back to a classified passage in its own index joins this second lane, whatever label it arrived with.
People decide: who labels the data, whether verification is on, and what to do with every answer. The layer never writes to your systems, and records the level each answer carried.
How data with and without a label is handled, and where a person decides.
The layer reads. People act. It runs one read-only statement, checked against an allowlist before it runs, only against tables the data's owner has approved, and it records that it did. It cannot change a record or update a system. When an answer shows that something needs doing, a person does it, in their own system, under their own authority.
People own the labels. The sensitivity levels the layer acts on are set by the people accountable for the data: a document's when it is taken in, a table's on its catalog entry. The layer's job is not to decide what is confidential. It is to make sure that what a person decided is applied every time, including when two sources are combined into one answer.
How strict to be is a decision, and it is on the record. A workspace can be set to accept only what the layer can check for itself. In that mode, the only content that may go to an outside model is content the layer fetched itself from a classified document, carrying that document's label. Everything else, database results included, stays on your own hardware. That trades an outside model's reach for certainty. Whether the trade is right for a given workspace is a judgement for the people accountable for it, not for the software, and changing it is a recorded setting.
Errors run toward caution. A query that touches a sensitive table carries that table's level even if all it does is count rows. A combined answer takes the strictest level among its parts. So an answer is sometimes handled more carefully than it needed to be, and that is the direction the design chooses. Every query and every model call is recorded with the level it carried, so a person can always see why.
The bottom line
Every organization of any size has two kinds of memory. One holds what it decided, and it is written down. The other holds what actually happened, and nobody wrote it at all.
Your people already join them. They do it in their heads, they do it slowly, and they are the only reason the two halves ever meet. Handing that job to an AI is not an efficiency exercise, it is a governance problem, because the moment a machine holds both halves it can combine them in ways no one reviewed.
Which is the entire subject of this library. Not retrieval with a policy attached. A layer that can hold both kinds of memory at once and still answer for what it did with them.
You don't build this. You configure it.
You do not write a fusion engine or a classification join. Infozense Knowledge Engineering reads your corpus and queries your database in place, assembles the answer from both, takes the strictest sensitivity present across the two, and routes, masks, marks and records on that one value.
You classify your documents and you connect your database. The layer makes sure that combining them never quietly produces something neither of them was allowed to be.
Do your people answer one question by opening two systems?
That's the conversation we have best. Bring one question that needs a policy and a table, and we'll walk through what would have to be true to answer it safely.
