The Second Control Plane

Where things live is not the same question as what is allowed to leave. A boundary rule that only knows the first question is half a governance model.

That was the tease at the end of the last post. This is the second question.

The first five posts in this series were about provenance: where the canonical copy of a thing lives, and how you stop a second brain from slowly rotting into a stale copy of everything it mirrors. The boundary rule, the linter, the scheduled check. All of that was provenance enforcement. By the end of post five, the brain knew where things lived, and a machine was checking that the rule held.

That is a complete answer to one question. It is not a complete governance model.

Two questions that look like one

The second question is egress: what is allowed to leave the vault, and where is it allowed to go?

These look like the same question. They are not. You can have perfect provenance enforcement (every file living in exactly the right place, the linter catching every violation) and still accidentally publish something you meant to keep local. Provenance governs the internal graph. Egress governs the boundary between the brain and everything outside it.

I had both sets of fields in my project.yaml files for months. Every project had a privacy_boundary: values like local-first, internal, or public. Some had a vault_mutation_allowed flag indicating whether an agent was permitted to write to the vault on behalf of that project. The fields were there. They described my intent precisely.

Nothing checked them.

The field that existed but wasn’t checked

A field in a config file is intention, documented. Enforcement is what runs after you commit.

The provenance plane taught me this the hard way in post three: the boundary rule existed in three different contract files before a linter caught the first violation. The egress plane repeated the same lesson with less drama, because by now I knew what to look for. The fields existed. The lint check did not. The gap between those two things is exactly the gap between policy and enforcement.

There is a version of this failure in every governed system. An external framing I found useful: “Writing policies is straightforward. Enforcing them continuously, with enough context to prioritize what actually matters, is the hard part.” The hard part is not knowing what the rule should be. The hard part is running the check on every commit, not just the ones where you remember to look.

What enforcement looks like

I added two new checks to lint-vault.py.

The first is EGRESS_MISSING. If a project in the registry is missing privacy_boundary or vault_mutation_allowed, the check warns. A warning, not a failure: missing fields are likely a gap from an older project that predates the policy, not an active decision to leave something ungoverned. Gaps are recoverable. You add the field, you move on.

The second is EGRESS_UNLOCKED. If any project has vault_mutation_allowed: true, the check fails hard. This one is not a warning. An open write permission is a standing exposure: an agent that can write anywhere in the vault without a project-scoped gate. The asymmetry is deliberate: a missing field means you have not yet stated your intent; an unlocked field means you have stated it, and the intent is permissive. One is a gap. The other is a choice you made, and the lint check is asking you to confirm you made it intentionally.

A clean run looks like this:

OK  EGRESS UNLOCKED (vault_mutation_allowed: true): clean
OK  EGRESS MISSING (project.yaml missing privacy_boundary or vault_mutation_allowed): clean

What it found

Before it was clean, it was not.

hekton-platform, a platform project and one of the load-bearing projects in the registry, was missing vault_mutation_allowed entirely. It had a privacy_boundary. It did not have the egress flag. The old lint did not know to check for it. The project had existed without the field for the entire time the field had existed as a policy. That is the snapshot problem: a field that exists in new projects tells you nothing about whether it exists in the projects that predate the policy.

There were also three entries in the registry that pointed to branches without local directories: tekton-chronicle--draft-p02, blog-factory-lab--typography, tekton-chronicle--wave-1-review. These are worktrees for branches that were merged and cleaned up. The lint check was treating the absence of a local directory as a violation: no directory means no project.yaml to check, so the field is technically missing. The fix was to skip entries where the local path does not exist rather than flag them. A closed branch is not a policy gap.

As a side effect of the same session, I caught that field-journal, an archived project with sync.enabled: false, was still triggering the drift check. A project that has opted out of sync should not be counted as drifting. Fixed in the same pass.

The reusable pattern

Every policy field needs a lint check. The field is the intention; the check is the enforcement.

This is the same move as post three, applied to a different plane. The provenance boundary rule existed in contracts before a linter caught the first violation. The egress fields existed in project configs before a lint check confirmed they were set. The sequence is consistent: you write the rule, you document it, you build the tool, you schedule the tool, and then the tool tells you whether the rule is actually holding. Skipping the tool leaves you in the documentation phase, where the rule is real in your intentions and nowhere else.

The same principle applies beyond the vault. Any system where human intent is expressed as config fields (feature flags, IAM policies, infrastructure tags, compliance labels) has the same gap. The fields describe what you meant to do. A check describes what you actually did.

Two planes down

The provenance plane says where. The egress plane says what leaves. Together they answer the two governance questions a second brain needs to answer before it can be trusted with anything sensitive.

But there is a third question, and it is a different kind of question. The first two are gates. They say no: this file does not belong in the vault, that project is not allowed to write here. Gates are important. A brain with no gates is a brain that leaks. But a brain with only gates stays clean and stays empty.

The third question is: what does the brain do with what it keeps?

That is the synthesis plane. Not a gate. A flow. It does not prevent things from entering the wrong place. It takes what has been kept in the right place and turns it into something that grows. Two planes protect the brain. The third one makes it compound.