Track 3: Governance

This is the chapter most teams skim. It’s the chapter that makes everything else work.

Without governance, the artifacts you built in Tracks 1 and 2 — the encoded processes, the compiled topic pages, the structured ontology — start drifting from reality the moment they ship. Skills go stale. Topic pages contradict the actual current state. The agent reads the wrong version, makes a confident wrong recommendation, and the team’s trust in the whole apparatus drops by a notch. A few cycles of that and the whole investment becomes a thing the team works around instead of with.

Governance is what prevents that. It is the same discipline as data governance, applied to the same kind of asset. You already know how to do it. You probably haven’t applied it to AI context yet.

The three layers

The most useful frame I’ve found is to think of organizational AI context as living in three layers, each with different ownership, different update cadence, and different governance rules.

Long-term context is the slow-moving foundation. Mission, values, principles, regulatory and compliance constraints, brand voice, the things that change rarely and that everything else is built on top of. Owned by leadership. Reviewed annually. Changes are explicit and rare.

Medium-term context is the working state of the organization. Team processes, architecture standards, design principles, encoded skills, compiled topic pages. Owned by team leads or domain experts. Reviewed quarterly. Changes go through a lightweight review process — usually a pull request with at least one reviewer.

Immediate context is the operational layer. Project briefs, sprint goals, current customer issues, in-flight specs. Owned by individuals. Updated continuously. Governance is light — these are short-lived artifacts, and the cost of a stale brief is low.

Each layer has different rules because each layer has different stakes. A stale brand voice document corrupts every piece of customer communication for months. A stale sprint brief corrupts one week’s work. The governance you apply has to match the blast radius.

The minimum viable discipline

The temptation is to over-engineer the governance system. A taxonomy. A SLA. A review board. A tool. None of this is necessary at the start, and most of it never becomes necessary.

The minimum viable discipline has four parts:

Every artifact has one named owner. Not a team. A person. The owner is responsible for whether the artifact is current. If they leave, the first thing the manager does is reassign owners for the artifacts they held.

Every owner has a defined review cadence. Annual for long-term context, quarterly for medium-term, ad hoc for immediate. The cadence is in the artifact’s metadata. The artifact gets a “last reviewed” date when the review happens.

Stale artifacts are flagged automatically. A nightly job, a CI check, a calendar reminder — any mechanism that surfaces “this artifact has not been reviewed in N months” without anyone having to remember. Without this, the cadence is aspirational and won’t survive contact with a busy quarter.

Changes go through review. For medium- and long-term context, changes are proposed, reviewed by at least one other person who knows the domain, and merged. The review doesn’t have to be heavy. A pull request and a lightweight comment is fine. What matters is that no one person can quietly change an authoritative artifact without anyone else seeing it.

That’s the entire system. Owner, cadence, staleness flag, review. You can implement all of it with git, a calendar, and a one-line CI check. You don’t need a tool. You don’t need a vendor. You don’t need a process champion. You need exactly four habits, and the discipline to hold them.

Why git is the right substrate

Almost all the context you’re managing is text. Encoded skills. Compiled topic pages. Process documents. Briefs. Text fits naturally into the kind of versioning, review, and history that git was built for, and most teams already know how to use it.

Putting context in git gives you, for free:

• Versioning. Every change is recorded. You can see who changed what, when, and why.
• Review. Pull requests give you the lightweight review layer the governance discipline requires.
• History. When something breaks, you can see what changed. When something improves, you can see what worked.
• Diff. Changes to the structure of a topic page are visible at a glance, not buried in a wiki edit.
• Programmability. Staleness checks, ownership assertions, and link validation can run in CI.

Some teams resist this because non-engineers are expected to edit context too, and “git is for engineers.” This concern is real and the friction is solvable. Git-backed wikis (Notion, Outline, Lume, etc.) cover the editing surface for non-technical contributors while preserving the substrate. Or you accept the editing friction and let an editor or owner liaise. Pick whichever makes sense for the team. The substrate matters more than the editing UX.

The roles you actually need

You don’t need a Chief AI Context Officer. You don’t need a context governance committee. You need three kinds of named role:

Artifact owners. One per artifact. Responsible for currency, accuracy, and appropriate review cadence. Most owners own one to three artifacts.

Domain stewards. One per domain (product, engineering, design, etc.). Responsible for the coherence of all artifacts in their domain, for resolving conflicts between artifacts, and for retiring artifacts that no longer serve. Usually a senior IC or team lead, not a manager.

One overall governance owner. One person, organization-wide, responsible for the system as a whole. This person makes sure stewards and owners exist, that staleness is being addressed, and that the system is being used. Usually a head of operations, a chief of staff, or an engineering lead. The role is not full-time. Two to four hours a week is typical.

That’s the org chart. Three role types. Most of the work is delegated to artifact owners, who are the people closest to the work and the people most affected by whether the artifact is right.

The two governance failure modes to watch for

The first is governance theater — a heavy review process, formal approval boards, monthly governance meetings — that produces lots of motion and no actual currency. This always emerges when governance is treated as an oversight function rather than a maintenance function. The fix is to delete the theater and replace it with the four-part minimum above. If your governance system requires a meeting to update a topic page, your governance system is too heavy.

The second is governance abandonment — owners exist on paper, no one reviews on cadence, staleness flags exist but nobody acts on them. This always emerges when governance is treated as a one-time setup rather than a continuous practice. The fix is the named overall owner above, whose job is to notice when the system is decaying and to apply social pressure to fix it.

What success looks like in 90 days

Ninety days from now, if governance is going well:

• Every encoded process and compiled topic page has a named owner.
• A staleness check exists and runs at least monthly.
• At least one quarterly review has happened, and produced visible updates to artifacts.
• The team treats authoritative artifacts as authoritative — when somebody contradicts the topic page in a meeting, somebody else asks them to update the topic page.

The last bullet is the cultural marker that governance has actually taken hold. It’s the moment the artifacts stop being a parallel system and start being how the org thinks. After that, the system is largely self-maintaining.

The next chapter — Track 4 — is about what becomes possible once Tracks 1, 2, and 3 are in place: progressive automation. Not because automation was the goal all along, but because automation that runs against weak foundations produces confident wrongness at industrial scale. Strong foundations first. Automation second. That sequence matters.