Know, Do, Prove: The Governance Layer Above Context Engineering

Context needs governance before it needs engineering

Context engineering concerns how we assemble and supply the information an AI system needs for a task. Context governance sets the conditions under which that information may be used.

The distinction matters. Retrieving a relevant document does not establish that it is current, approved or permitted for this person and purpose. Putting more information into the context window does not settle those decisions either.

I position Know, Do, Prove above context engineering as a layer of accountability, not as another retrieval technique. Its rules need to shape the architecture before the model receives information and before an agent acts.

Permissions before retrieval. Authority before action.

KNOW: Establish what deserves to be trusted

Start with one authoritative source for each document. Then make its status explicit.

The minimum labels I would look for are:

• Owner.
• Approval status.
• Effective date.
• What it supersedes.
• Classification at section level.
• Version identifier or content hash.
• Retention date.

These labels answer different problems. An owner gives someone responsibility for resolving ambiguity. Approval status distinguishes a working draft from an agreed position. An effective date and supersession link help separate the current policy from the one it replaced.

Section-level classification matters because a document can contain material with different access boundaries. A single broad label may conceal those differences.

A content hash helps identify the exact content involved. It does not prove that the content is correct or approved. Retention rules address how long information should remain available, rather than treating every searchable document as permanently usable context.

Consider an illustrative travel-policy question. The repository contains a superseded version, the current approved version and a newer draft. The newest file is not necessarily the authoritative answer.

The system needs to select the approved, effective source and identify its version. Metadata alone cannot guarantee that result. Retrieval and validation controls still need testing.

KNOW turns duplicated, stale, overshared and unlabelled information into explicit decisions about what belongs in context.

DO: Separate access from authority

Before retrieval, establish who is asking through authenticated identity, not through a claim typed into a prompt. Then check the purpose, the information's classification, the person's entitlement and any location or jurisdiction restrictions.

These checks belong before search ranking and before content reaches the model.

Removing sensitive passages from the final answer is too late if the model has already received information it should never have seen. Even saying that inaccessible documents exist can disclose something the user is not entitled to know.

If access is denied or unresolved, stop the request and escalate to the appropriate owner where resolution is needed. Empty permission settings should deny access, not quietly allow everything.

Access is only the first gate.

Being permitted to read a policy does not authorise an agent to change a record, send a message or place an order. Those actions need their own boundaries:

• Suggest: a person decides what to do.
• Draft: a person reviews the proposed work.
• Act with approval: a named approver, separate from the requester, approves the exact action.
• Act alone: a narrowly defined action proceeds within explicit authority and the strongest controls.

These are authority levels, not a ladder every use case must climb. More autonomy is not automatically a better design.

Approval must also remain valid at release. A changed policy, revoked permission or activated kill switch must be able to stop an action that was previously approved.

The practical test is whether someone can stop the system and establish who was affected when something goes wrong.

PROVE: Keep a receipt, not just an answer

Six months later, a regulator or chief executive may need to understand an AI-assisted decision. A screenshot of the answer will not explain the conditions under which it was produced.

For each answer or action, keep a receipt covering:

• The request and authenticated user.
• The sources, versions and effective dates supplied.
• The access decisions, including the relevant rule and rule version.
• The output, citations, model version as served and timestamps.
• The approver, reviewer or exception outcome, where required.

Record approvals and denials. Keep model refusals separate from policy blocks. A model declining to answer is different from an access control preventing disclosure. Combining them makes it harder to establish whether the control actually worked.

Evidence should be append-only and tamper-evident, including detection of deleted recent entries. The receipt records what the system supplied and did. It does not reveal the model's internal reasoning or promise an identical regenerated answer.

The aim is to reconstruct the event, with its sources and permissions, rather than rely on someone's memory of the demonstration.

Where it fits with the other models

PINPOINT helps specify work clearly enough for AI to perform it, including the inputs, constraints and success criteria. Know, Do, Prove asks what information the system may use, what authority it has and what evidence must remain.

BLUEPRINT addresses the design of the agent as a governed system. DAPA follows the decision loop from Data through Analytics and Prediction to Action.

These are complementary lenses. They are not a claim that every model has already been integrated into one implemented system. Know, Do, Prove makes the context governance questions explicit across the work.

Start with one repository

My recommendation is deliberately small: one repository, one use case, one measurable improvement.

Choose a policy library or knowledge base. Name the use-case owner. Identify the authoritative sources. Test access before retrieval and authority before action. Reconstruct a permitted answer and a denied request from their receipts.

Choose a measure before changing anything. For example, measure the proportion of test answers for which the team can reconstruct the source version and access decision. That is a proposed test, not a reported result.

Find the missing control. Start there.

Before you give AI more intelligence, give it better-governed information.