Where Did That Answer Come From?

Most of the AI governance I see in practice is a pile of guards. A filter here, a validator there, a reviewer at the end who is supposed to catch whatever slipped through. It works until it doesn't, and when it doesn't, nobody can say which rule should have applied, or where that rule came from.

That second question is the one that matters. Every decision an AI system helps make rests on knowledge that came from somewhere: a standard, a contract, a policy, a project note. Without that traceability, it's harder to judge the basis of a result or know what to revisit when a source changes.

Knowledge has a lineage. Good governance keeps it intact.

Where authority comes from

Rules usually reach the person doing the work through layers. There may be an external standard or law, then agreements with customers, then a company's own policy, then the rules for one project. Each layer interprets what sits above it and often adds constraints of its own. A project can be stricter than company policy. It shouldn't quietly be looser.

That picture is useful, but it's schematic. The number of levels varies by organisation. Standards, legal obligations, business policy and customer agreements each have their own applicability, and they overlap rather than forming one universal chain. A data-privacy obligation can cut across every project at once, while a customer agreement may cover one product line and not another. A hierarchy alone doesn't capture that cross-cutting authority, or all the relationships that matter.

The layers and the graph

The layers tell me where authority comes from. The knowledge graph tells me how an interpretation, a process or a decision connects to that authority. The number of layers varies with the business. What matters is preserving the relationships as knowledge moves through them. That only works if knowledge is broken into units small enough to link precisely, which is why the structure of the writing matters as much as what it says.

In practice that means a few things.

Sources keep their identity and scope. A requirement should say where it comes from and what it applies to. "Our policy" is not a source. A named policy, at a named version, covering a named set of work, is.

Interpretation stays distinct. I want to distinguish a source from our interpretation of it, and that interpretation from the procedure we use to act on it. Each should retain its identity and its version. Interpretation is where a business adds its own constraints, and it should be visible as such.

Relationships have types. A useful link explains the relationship: this procedure implements that requirement; this decision relied on this interpretation; this result was checked against that version. A bare "related to" tells you almost nothing when something goes wrong.

Old versions are retained. If a decision relied on last year's policy, you need last year's policy to understand the decision.

Changes trigger downstream review. When a source changes, those connections identify what needs review. They don't mean every dependent procedure can safely update itself. They give us a way to find the affected work, inspect the reasoning and record the next decision.

Decisions, execution and evidence connect. The plan, the work that carried it out and the evidence it was checked against belong in the same web. That's what makes rationale reviewable rather than something you take on trust.

A schematic example

Take a small bookkeeping practice. General accounting principles and tax law apply to its work, and nobody there gets to rewrite them. The practice interprets them into its own rules: how it categorises expenses, who reviews a reconciliation before it goes out. A client's arrangement adds more, like two approvals on any payment over a set amount. The person closing this month's books follows a checklist that sits inside all of it.

Now suppose a tax rule changes. The useful question isn't only what the new rule says. It's which interpretations relied on the old one, which checklists implement them, and which closed months were checked against the old version. Recorded relationships let you find the affected work. Without them, you're reconstructing dependencies by hand. Reviewing the implications still takes judgement. Closing the books is exactly the kind of process you want moving through visible, checked stages. More on that in rks for Business Process Management.

The boundaries don't stifle the work. They focus it, the same way good design innovates within boundaries.

Why this matters more with AI

A model is probabilistic. Give it the same prompt twice and you can get two different answers. That's part of what makes it useful, but it means the reliability has to come from somewhere else. The system around the model has to supply the structure.

Lineage is a large part of that structure. When an agent answers a question or proposes a change, I want to know which sources it retrieved, at which versions, and which interpretation it was working from. Without that, a wrong answer is just wrong. With it, you have a trail to investigate: the source, the interpretation, and how it was applied.

Rails, guards and what actually enforces

Most AI setups have too much guard and not enough rail. A guard blocks a bad action after the model has decided to take it. A rail is a path the work runs on. It shapes what the model sees, what it's allowed to touch, and what has to happen before the next step. That's constrained generation: AI that works inside defined patterns, not around them. Designing rails for an agent is the same work as designing for any other user. More on that in The Agent Is a User. It Isn't a Person.

It's worth being precise about what does the enforcing. A requirement written in a note is declarative. Retrieving it into context or putting it in a prompt makes the model more likely to follow it, but enforces nothing. Enforcement comes from mechanisms outside the model: hooks that intercept actions, gates that hold work until a check passes, permissions that make some actions unavailable. The knowledge layers say what should happen. Enforcement makes sure certain things can't happen regardless.

What this looks like in RouteKit

I build software with AI agents using RouteKit, an open-source tool built around this pattern, applied to code.

Scope is explicit. Each project has its own knowledge base, and the agent answers from that project's notes and code, with citations. That doesn't erase what the underlying model learned in training. An AI CFO built on a general model still knows something about fixing bikes. Scope bounds the application instead: the questions it's meant to answer, the evidence it retrieves and cites, and the actions it's permitted to take. A finance tool that starts giving advice on bike gears is outside its scope, and the system should treat it that way.

Enforcement is layered. RouteKit ships general rules, each project adds its own, and a workflow can tighten them further. Hooks sit underneath and redirect risky actions onto the governed path, instead of trusting the agent to remember not to take them.

Workflows are gated. Work moves through named stages: agree on the story, get it reviewed, plan it, carry it out, ship it. Before anything runs, the system checks that the story hasn't changed since it was approved and that the plan is the same one that passed review, and it won't start if either check fails. Testing happens as part of that step, and a change that fails is rolled back instead of committed. Every commit is tagged with the story it came from, and the system keeps a running log of each attempt, including the ones that failed.

A critic reviews the plan before any code is written. One agent proposes. Another reads the actual code and argues against the plan. Finding a problem at the five-minute mark costs a conversation. Finding it at the forty-five-minute mark costs a rollback, and often a second attempt that inherits the first one's confusion.

Why outcomes alone aren't enough

There's a popular management idea that you should manage to outcomes and leave the method to the people doing the work. With people, that's often right. Skilled people carry judgement, habits and accountability that make good results repeatable.

With AI, it's risky. A good outcome today doesn't prove you'll get one tomorrow, and from the outcome alone you can't tell which parts of today's success were skill and which were luck.

Process records don't guarantee the next outcome either. What they do is make the outcome diagnosable. If a result came with a plan, a review, the sources it relied on and the checks it passed, I can see why it worked, judge how likely it is to work again, and find what broke when it doesn't.

Don't make it a person

It's tempting to describe agents as colleagues: a researcher, a reviewer, an architect with opinions. Those names are handy labels. They aren't a governance model.

We trust people with judgement because they carry context, accountability and a stake in the outcome. An agent's access, context and authority come from the system around it. A role name doesn't supply accountability. When we anthropomorphise agents, we start granting them the latitude we'd give a trusted employee, and we stop recording the lineage that would let us check their work.

What this isn't

This isn't a claim that lineage makes AI safe, or that guards are unnecessary. Some actions need an independent check no matter how well the knowledge is organised. It isn't a product pitch either. The pattern works with any tooling. RouteKit is one place it's written down in code.

Before you ask what your AI can do, ask whose rules it answers to.