A runtime governor does not get rebuilt or retrained for each system it governs. It is one engine that reads the same two things in every deployment, what an action would do at the actuator and how far the run has drifted from the trajectory the system was assured to follow, and the only thing declared fresh for a new system is the envelope, the bound each action's authority is graded against in that system's own units. Wayfinder Systems Group builds that governor, a control that sits above control and below intelligence, and governing a new system means handing it a new envelope rather than building a new control.
The claim is narrow and it is about the control, not the systems it is pointed at. The judgment is universal. The bound is local.
What does a runtime governor read to set authority?
Two readings, and both exist in every system. The first is the effect the action would have at the actuator, measured in whatever the actuator acts on, a sum moved, a set of hosts touched, a valve position. The second is the divergence between where the run has actually gone and the trajectory the system was assured to follow. Neither reading is a fact about a domain. A transfer and a valve position are different quantities, and the question the governor asks about each is the same. How much would this action do, and is the run heading somewhere it was not cleared to go.
Because the two readings are the same kind of object everywhere, the engine that grades them does not change when the system does. It does not ingest the business logic and it does not need a theory of what the agent is for. It reads an effect and a divergence and returns a number. A system it has never seen, taking an action it has never seen, is graded by the same two readings as any other.
What changes from one system to the next?
The envelope. A safety envelope is the declared bound each action's authority is graded against, set before the run by someone who is not the agent, and stated in the units the actuator acts on. For a payments agent it is denominated in money and counterparties. For a remediation agent it is denominated in hosts and blast radius. For an industrial controller it is denominated in setpoints and rates. The quantities are local to the system. The act of declaring them is the same act every time.
So the work of governing a new system is the work of writing its envelope. That is a declaration, made once and maintained by the accountable party, not a rebuild of the control. The engine that reads the new envelope is the engine that read the last one.
Why not a rule set tuned for each system?
The common alternative ships the rules as the product. A library of patterns to match, a list of banned topics, a table of intent categories retrieved and compared against each request. That control is only as good as its table, and the table is local to the system. A new domain needs new categories. A new integration needs new patterns. Each is written out by hand and maintained by hand, and the control has to be reworked for every system it is pointed at.
A governor carries no table of the actions it is looking for. It grades the effect of the action in front of it against a declared bound, so the per-system work is the bound and nothing else. The difference between the two categories is where that work lives. In a rule-matching control the work is the rules, rebuilt for every deployment. In a governor the work is one envelope, and the engine is unchanged.
What has to be declared locally, and who declares it?
Model-agnostic is not setup-free. One thing has to be produced for each deployment, and it is the envelope. The engine arrives the same for everyone. The bound does not, because only the people who run the system know what a safe action looks like in their units and what the system was fielded to stay inside.
That bound cannot be set by the system under governance, because a boundary a system draws for itself drifts with the behavior it is meant to bound. It is declared before the run, held outside the acting process, and set by the party accountable for the outcome. On an action the envelope never anticipated, the governor grants less authority, not the benefit of the doubt. Silence is not a grant.
What the regulators ask, and what they leave out.
SR 26-2 took effect April 17, 2026 with generative and agentic AI placed outside its scope and the interagency request for information it promised still not issued. EU AI Act Article 14 asks that a high-risk system be designed so the people assigned oversight can monitor, override, or interrupt it, and Article 15 asks for accuracy and robustness held across the lifecycle, with high-risk obligations applying from December 2, 2027 for standalone systems and August 2, 2028 for AI embedded as a safety component under Regulation (EU) 2026/1744. The NAIC exposed version 5.0 of its AI Risk Evaluation Supplement, with a later version targeted for the Fall National Meeting in November.
Each asks a deployer to describe the governance it runs, system by system. None asks whether the control is one engine reading a bound declared for that system, or a rule set rebuilt each time the system changes. The same engine, in every deployment, can grant less authority on an action whose present trust reads higher, because its forward look caught a divergence before the outcome landed. The bound was local. The judgment that pulled authority back was the same judgment everywhere.
What we are building.
Wayfinder Systems Group builds one runtime governor. It sits above control and below intelligence. It observes, assesses, modulates, enforces, and signs the record. The engine that modulates authority and holds the bound at the actuator is the same across every system it governs, and the one thing each deployment declares is its own envelope. The sealed record is what the governor emits as it runs. We call her Velma.
Thirty minutes. Architecture, not sales.
A conversation about the one envelope your deployment has to declare, and how a single governor sets authority at the actuator across the systems you run.
JonathanLuethke@WayfinderSystemsGroup.com
