The Three Layers of Context: Facts, Tacit Process, and Governance


When organizations prepare to adopt AI, they tend to focus on what the AI will do. The harder question is what it will know. Context is not a single thing you can hand over in a document dump. It has structure. There are three distinct layers: factual knowledge, tacit process, and governance. Each layer has its own location, its own failure mode, and its own cost when absent. Getting all three right is a prerequisite, not a polish step.

This article breaks down each layer in operational terms. Not as a framework to admire, but as a diagnostic you can actually use. If you are building toward AI adoption and trying to understand what your organization needs to prepare, this sits inside the broader territory covered in Organizational Context for AI: The Complete Guide.

Layer One: Factual Knowledge

Factual knowledge is your written record. It includes architecture decision records, runbooks, API documentation, incident post-mortems, onboarding guides, compliance policies, and any other artifact that captures what your organization has decided, built, or agreed to. This is the layer most teams think of first when someone says ‘we need to feed the AI our context.’

The problem is not usually that this layer does not exist. The problem is that it is fragmented, inconsistent, and stale. A runbook written eighteen months ago describes a system that has since been refactored. An architecture document reflects a decision that was reversed but never updated. The documentation exists, but the currency of that documentation is a different question entirely.

Where it sits

Factual knowledge lives in wikis, version-controlled repositories, ticketing systems, shared drives, and sometimes in email threads that were never promoted into anything durable. The distribution is rarely intentional. Content accumulates wherever the team was working at the time.

The challenge it carries

Volume is not the issue. The issue is signal quality. An AI system ingesting your documentation will treat a two-year-old deployment guide with the same weight as one written last month, unless you have structured the corpus to indicate otherwise. Garbage in, confident answers out. Stale factual knowledge does not produce silence from an AI system. It produces plausible, authoritative-sounding errors.

Before ingestion is the right time to audit this layer. That means culling obsolete content, establishing clear ownership per document, and building a cadence for review. It is unglamorous work, but skipping it means your factual layer is actively producing misinformation at scale.

Layer Two: Tacit Process

Tacit process is the judgment your experienced people carry that has never been written down. It is the senior engineer who knows that the batch job always fails on the third Tuesday of the month because of a downstream dependency that the vendor has not fixed. It is the support lead who understands which customer complaints are actually symptoms of a deeper configuration issue versus which ones are one-off noise. This knowledge exists. It shapes every high-quality decision made in your organization. It just does not live in any file.

This layer is the hardest to surface and the easiest to underestimate. When teams prepare context for AI adoption, they almost always skip this layer by default, not because they disagree with its importance, but because they do not have a method for extracting it.

Abstract illustration of tacit human knowledge flowing into a structured document, representing the transformation of implicit experience into explicit, organized information.

Where it sits

Tacit process sits in people. More specifically, it sits in the mental models of your senior contributors, in the tribal knowledge passed down through pairing and verbal handoffs, and in the informal channels where real operational decisions get made. Some of it surfaces in Slack threads or in code review comments, but capturing it requires deliberate effort.

The challenge it carries

Extracting tacit knowledge requires structured interviews, process mapping, and a willingness to sit with experienced operators and ask them to narrate their decisions out loud. That takes time. It also requires that the person doing the extracting understands the domain well enough to recognize what is genuinely tacit versus what is already documented elsewhere.

The output is typically a set of annotated process descriptions, decision trees, or worked examples that can be formatted as context for an AI system. Think of it as making the implicit explicit. The result is not perfect, but it closes the gap between an AI that read your manual and one that has absorbed something closer to real operational judgment.

Layer Three: Governance

Governance is the rules about your knowledge itself. It answers questions like: who can access which information, who is authorized to update it, what classification applies to different content types, how long it is retained, and what happens when a piece of context becomes outdated or disputed. Governance is not about the content. It is about how the content is managed and controlled.

Most organizations have some form of governance, but it was designed for human access patterns. AI systems change that pattern significantly. An AI operating on your internal knowledge base can, in principle, combine and surface information in ways no individual human would. That is often the point. It is also the risk.

Abstract governance layer filtering a structured knowledge corpus, allowing only selected information to pass through controlled access paths.

Where it sits

Governance sits at the intersection of security policy, data classification, and access control frameworks. It should define what categories of information are eligible for AI consumption and under what conditions. Role-based access control principles that apply to human users need to extend to AI-mediated access as well. If your organization handles regulated data, this layer has compliance dimensions that cannot be deferred.

The challenge it carries

The challenge is that governance frameworks were not built with AI retrieval in mind. A document may be accessible to all employees for human reading but should not be surfaced verbatim in an AI response to a customer-facing query. The distinction between who can read something and how it can be used in AI outputs is a new class of problem that existing policies rarely address.

Building governance for AI context means extending existing policies rather than replacing them. It means classifying content by both sensitivity and AI-eligibility, establishing review cycles for context used in AI systems, and deciding who has authority to approve or revoke content from the AI-accessible corpus.

What Goes Wrong When You Skip a Layer

The failure modes here are specific enough to be worth naming directly. They are not theoretical.

Skipping the tacit layer: the AI that read the manual but never did the job

A team builds a well-structured knowledge base from their documentation and deploys an AI assistant for internal engineering support. The documentation is accurate and reasonably current. The AI performs well on straightforward questions. Then a production incident hits. The AI surfaces the correct playbook steps but misses the known edge case that every experienced engineer on the team knows about: the one that sends you down a two-hour dead end before you realize the real fix is in a different system entirely.

The AI gave technically correct answers from its available context. The tacit knowledge that would have prevented the wrong path was never extracted. The result is an AI that inspires misplaced confidence precisely because it sounds competent. That is a harder failure to detect than an AI that simply says it does not know.

Skipping governance: a leak with a friendly interface

A team deploys an internal AI assistant with access to the full internal wiki. They build it fast, governance review is on the backlog. Three months later, someone queries the assistant for help drafting a client proposal and the AI, drawing on its available context, surfaces salary band information from an HR document that was accessible but clearly never intended for that use. In a more serious variant, it surfaces pre-decisional acquisition details or security configuration specifics.

No one intended this. The access control model simply was not built to account for an AI that synthesizes and presents internal content on demand to anyone with a query interface. Absent governance, every piece of content in the corpus is implicitly available to every query. That is a fundamentally different access model than what most organizations designed their internal documentation around.

Skipping factual quality: confidence without accuracy

This is the quietest failure. An organization ingests a large internal documentation corpus without auditing it first. The AI performs well in demos. In production, over weeks and months, users start noticing that the AI’s answers sometimes conflict with current practice. The answers were accurate historically. The documentation reflects a prior state of the system. Users lose trust not in the documentation but in the AI, which is the opposite of the intended outcome.

Three side-by-side layer stacks showing missing or weakened knowledge layers, with amber warning indicators highlighting gaps and system instability.

Why All Three Must Be Present and Healthy

These layers are not optional components you choose between. They are interdependent. Factual knowledge without tacit process produces an AI that is technically literate but operationally naive. Factual and tacit knowledge without governance produces an AI that is capable but uncontrolled. Governance without the underlying knowledge layers produces a well-secured system with nothing useful inside it.

The practical implication is that you cannot address these sequentially and call it done. All three require ongoing maintenance. Factual knowledge goes stale. Tacit knowledge changes as people leave or processes evolve. Governance frameworks need to be updated as the AI’s role and access scope change. This is not a one-time preparation exercise. It is an operational discipline.

For organizations in earlier stages of preparation, the diagnostic question is simpler: which of the three is your weakest layer right now? Most engineering-led teams have a reasonably solid factual layer, an almost entirely undocumented tacit layer, and a governance framework that was designed for human access patterns and has not been revisited. That is a common starting point, and it is workable. But you need to know where you are before you can close the gaps.

Ivan Dabić

A man with a beard and glasses, wearing an orange hoodie and a black cap with a Hard Rock Cafe logo, stands with his arms crossed against a plain white background.

Ivan Dabić

Co-founder and CEO of BlueGrid.io, with a background in cloud infrastructure, distributed systems, monitoring, and security operations. He works closely with engineering teams to build and operate reliable systems while documenting both technical and organizational aspects of modern engineering work.

Ivan is a metalhead, and big fan of cyberpunk move genre. If you are his secret Santa go with Star Wars Lego box!

Share this post

Share this link via

Or copy link