The Governing Question

Every architecture was built to answer one. Most disagreements in AI governance begin when two people mistake one question for another.

Edward Meyman FERZ, Inc. · July 2026

1. A familiar pattern

New technical disciplines are described, at first, in the vocabulary of their neighbors.

When cloud computing arrived, infrastructure teams read it as remote data centers, virtualization specialists read it as hypervisors at scale, and capacity planners read it as elastic procurement. Every reading was accurate. Every reading was partial. The partiality was nearly invisible from the inside, because each community was looking at precisely the portion of the problem its instruments were built to resolve.

Security did the same thing. It assembled itself out of communications security, physical security, systems administration, and audit, and for years its internal debates were really jurisdictional. Network engineers said segmentation. Cryptographers said key management. Auditors said control documentation. The field matured when it stopped adjudicating and started layering.

Zero trust repeated the pattern. Network people read it as network architecture. Identity people read it as identity architecture. Both were substantially right, and jointly insufficient.

This is not a failure mode. It's how technical knowledge transfers. Practitioners bring what they know, what they know is genuinely useful, and the new field becomes tractable faster because they brought it.

But it's worth asking what actually separates those disciplines from one another, because the obvious answer is wrong. It is not tooling. Tooling migrates. Techniques migrate. Vendors converge.

Disciplines are distinguished by the questions they were built to answer.

That is the argument of this essay, stated early so the rest can be read against it. A field becomes independent at the moment its practitioners identify a question the parent disciplines were not built to answer, and find that answering it requires an architecture the parents do not contain. Not a new vocabulary. Not a new product category. A different question, with different structural requirements.

AI governance is in the middle of that process now.

2. The same pattern, running again

Read across the current literature on governing AI systems and a structure emerges that correlates less with AI than with the professional background of whoever is writing.

Infrastructure engineers describe placement, isolation, and failure behavior. Identity practitioners describe principals, scopes, delegation, and least privilege. Observability teams describe instrumentation, tracing, and reconstruction. Compliance and risk functions describe control frameworks, ownership, and evidence retention. Model risk governance, inherited largely from regulated financial institutions, describes validation, drift, and periodic review of a model as an artifact with a lifecycle. Safety and alignment research describes the behavioral disposition of the model itself.

Six accurate descriptions. Six mature bodies of practice. Each contributes something a serious deployment needs, and each is the correct application of a discipline that earned its methods the hard way.

The difficulty is not that anyone is mistaken. It's that accurate partial descriptions are routinely offered, and accepted, as complete ones.

3. Six questions

The clarifying move is to stop comparing architectures and start comparing what each was built to determine.

Identity asks who is requesting this, and what have they been granted. Infrastructure asks where control should sit, and how it behaves when things fail. Observability asks what happened, and whether it can be reconstructed. Compliance asks whether required controls were defined, applied, and documented. Model governance asks whether this model is fit for purpose, and whether it still is. Alignment asks how the system tends to behave.

The optimization is the point.

An observability architecture is optimized for completeness of record and minimal interference with the running system. Correct objectives, for a system whose job is to describe. A model validation regime is optimized for statistical rigor across a population of decisions. Correct, for a system whose job is to assess fitness. A credential architecture is optimized for the durable properties of actors. Correct, for a system whose job is to establish standing.

Which is exactly why substitution fails. An architecture tuned to describe events accurately after they occur is not thereby tuned to determine, in advance, whether a particular event should occur at all.

That is not a defect. It's the consequence of an architecture doing well the thing it was designed to do.

The questions are complementary, not competing. A serious deployment needs answers to all of them. What it does not get is one answer that covers the rest.

4. The inheritance trap

The vocabulary migrates before the architecture does.

The pattern is easy to recognize once you look for it. Access control acquires the label AI authorization. Monitoring acquires the label runtime governance. A rules engine acquires the label AI governance. Workflow orchestration acquires the label AI control.

In most cases nothing dishonest has happened. The component really does contribute to governing AI systems, and the new label is a fair description of the use case it now serves.

The trap is subtler than mislabeling. A relabeled component keeps the answer it was built to give while acquiring the name of a question it was not built to answer. The engine is the same. The badge is new.

And because the badge now matches the question the reviewer came to ask, the review ends early.

So the useful diagnostic is structural rather than lexical. Two questions do most of the work.

Where does the component sit relative to the effect? Before the action becomes real, in its path, or beside it? Observing an action is a different position from standing in its way, and naming does not change position.

What happens when the component is unavailable? If unavailability degrades visibility, it answers a visibility question. If it degrades the record, it answers a records question. If it halts the action, the component sits on the execution path and is answering something else entirely.

Failure behavior describes architecture more reliably than documentation does.

Neither question is hostile. Both are answerable in a sentence by anyone who knows their own system. The reason to ask them is that terminology has stopped distinguishing what they distinguish.

5. From governing models to governing actions

Here is the distinction I think matters most, and it is easy to miss because the two problems share a vocabulary.

The first generation of AI governance asked: how do we govern models?

The second asks: how do we govern actions?

Those are not successive versions of one problem. They are different architectural problems, with different objects, different timing, and different failure modes. Treating the second as a maturity increment on the first may be the most consequential inherited assumption in the field.

Consider why the first question was sufficient for as long as it was.

For much of applied machine learning's history, a model produced information. A score, a classification, a recommendation, a paragraph. Something else decided what to do about it, and that something else was usually a person.

That arrangement had a structural property worth stating plainly: the human recipient made the authorization determination. Not formally. Not by design. Structurally. A person read the output, applied judgment, and performed the act. Authority, determination, and execution sat in one actor, which is why the vocabulary never needed to separate them. There was no practical reason to distinguish concepts that were always exercised together.

With a person still positioned between output and effect, governing the model could function as a practical proxy for governing the outcome. And the proxy held for a structural reason rather than an accidental one: the person and the model occupied different roles. The model informed the decision. The human owned it.

Autonomous systems break the proxy.

When a system can both propose and execute an action, calling an interface, moving funds, filing a document, provisioning access, dispatching a physical process, a human is no longer the necessary boundary between output and effect. The system producing the action may also be the system treating it as permissible. The historical fusion of roles survives, with one amendment: the acting system is not itself the source of the authority under which the action proceeds.

That shift introduces a question the inherited disciplines were not built to answer.

Should this specific proposed action execute, before it executes?

Three properties of that question are worth isolating, because they are what make it structurally distinct rather than rhetorically distinct.

Its object is a specific proposed action. Not an actor. Not a model. Not a class of operations. A single instance, with its parameters, in its context.

Its timing is prior. The determination has to exist before the effect does, because once the effect exists the question has been answered by default, and the answer was yes.

Its force depends on conditionality. A determination that execution may proceed governs nothing unless execution was in fact conditional on it. A determination that merely accompanies execution is advice, however rigorous the reasoning that produced it.

That third property is the one most often assumed rather than checked. It is also the easiest to falsify. Remove the determination and observe whether the action still occurs.

Now run the inherited questions against it.

Establishing that an actor holds standing is a determination about an actor. Credentials, scopes, and delegation chains describe what a system is entitled to do, and a contextual access-control decision can narrow that considerably by evaluating the operation, the resource, and the surrounding attributes at the moment of the call. In that use, the governed object remains whether the actor may invoke the operation. Whether this specific proposed act should proceed, with these parameters and on this evidence, is a determination about the action. The distinction is one of decision scope and governed object. The conditionality test then asks whether the action-level determination actually governs execution.

Establishing that a model is generally well behaved is a claim about a distribution, and an action is a single draw from it. Establishing what happened is a claim about the past.

All three are necessary. None is the pre-execution determination.

Which produces the failure mode that motivated this essay. A system can satisfy every inherited question and still have no layer that answered the action-level one. The gap goes unnoticed, because each reviewer asked their own discipline's question and received a good answer.

6. A division of labor

None of this argues that the inherited disciplines are inadequate. It argues that AI governance is separating into complementary disciplines, and that separation is a sign of maturity rather than fragmentation.

Operational visibility answers what happened. Behavioral alignment shapes what the system tends to do. Model governance establishes and maintains fitness for purpose. Identity and access management establishes standing and scope. Execution authorization determines whether a specific proposed action proceeds, and whether that determination governs.

Five disciplines. Five distinct failure modes when one is asked to cover for another.

Visibility without action-level determination produces excellent accounts of events nobody was positioned to prevent. Determination without visibility produces decisions nobody can review. Alignment without either produces a system that behaves well until it does not, with no layer positioned to notice. Standing without action-level determination produces an agent that was entitled to operate and unexamined on what it actually did.

Autonomous deployments need all five. The interesting design work is at the seams.

Which suggests where the discipline goes next. Maturity comes from knowing where each constituent discipline ends, not from stretching one to cover the whole surface. Fields reach that point by developing the vocabulary to state their own boundaries, and then by holding to those boundaries in review.

Practitioners can start ahead of the vocabulary. Three questions do most of the sorting.

Which question does this component actually answer? Where does it sit relative to the effect? What happens when it is not there?

Call this the governing question framework: identify the question an architecture was built to answer before evaluating how well it answers it. The order carries the weight. An architecture assessed against a question it was never built to answer will look deficient. The same architecture assessed against its own question will look complete. Neither judgment tells you whether it addresses the question you actually have.

The answers clarify in both directions. Sometimes a component turns out to do more than its category suggests. Sometimes a governance architecture turns out to be four good answers to four questions, none of which was the one that mattered for the action that eventually caused the problem.

One further consequence, and it is the practical one.

Much of the current disagreement in AI governance is not about architecture at all. It is about problem definition. Practitioners reach different conclusions because they began from different governing questions, and then conduct the disagreement as though it were about answers. Make the questions explicit and a good share of it resolves, not because anyone was persuaded, but because it becomes clear the parties were never answering the same question.

AI governance will mature when the field stops asking which architecture is best and starts asking which governing question each architecture was built to answer.

Every architecture answers a question. The work is making sure it is the one you needed answered.

Further reading

Meyman, E. (2026). Authority versus Authorization: A Definitional Framework for AI Governance. FERZ, Inc. https://doi.org/10.5281/zenodo.21341907

Meyman, E. (2026). A Taxonomy of AI Governance Approaches: Distinguishing Visibility, Alignment, and Authorization. FERZ, Inc. https://doi.org/10.5281/zenodo.18275969