We used external AI and platform capabilities for several operational functions. In one workflow, ChatGPT Memory was part of our persistent storage architecture. At some point, new information could no longer be stored persistently from that workflow.

The cause remained unclear. OpenAI Support was also unable to resolve the issue in a timely manner. That changed the decision we were making.

From: How do we get this working again?

to: Which parts of our operation do we actually want to depend on an external capability whose state we cannot sufficiently control?

What began as a planned technical workaround became a broader architectural change.

• Persistent state was moved into a more controllable external persistence layer.

• The model we used was treated more explicitly as a replaceable execution layer.

• Platforms were treated as distribution surfaces, not as the foundation of the underlying operating and publishing architecture.

This did not make us independent of external infrastructure. But it did make us less dependent on one specific capability, model, or platform.

That changes the classic buy-vs.-build question. For small organizations in particular, the real choice is often not:

Buy it or build everything yourself?

Time, capital, or technical resources are usually too limited for that.

The more important question may be:

What does the organization need to control itself, and what can remain external if it is replaceable?

The organization does not need to own the model. It does not need to own the platform. Nor does it need to operate the entire infrastructure itself. But replacing one of them should, where possible, not require rebuilding the operation around it.

Buy vs. build therefore answers only part of the architectural decision:

Where does the capability come from?

A second question follows:

How deeply should dependence on that capability be embedded in the organization’s architecture?

Replaceability is not a third sourcing category alongside buy and build. It changes the conditions under which buy remains operationally viable.

The relevant addition is therefore:

Buy, but design for replaceability.

Or, more concretely:

If you buy it, ask what happens when you have to replace it.

Now an employee in customer service wants to use an already approved AI tool to handle customer inquiries more efficiently. To do so, information from the internal customer system would be entered into the application.

So the question is: Is that allowed?

The policy may address this. But that still does not answer who assesses the conditions in this specific case and who is authorized to approve the use. The decision also has to work in practice.

Defining a rule is one thing. Being able to act on it is another.

An AI policy can describe what should apply within an organization. It can also define responsibilities, review procedures, and control requirements. Whether the organization can actually implement those provisions becomes visible in how it handles concrete use cases.

Suppose the employee receives approval to use the AI tool for certain customer inquiries. One condition is that no confidential customer data may be transferred to the tool.

A decision has been made, but the governance question is not yet closed.

What happens if the workflow later changes and confidential customer data is now transferred to the AI tool? The basis for the original approval may no longer hold. The organization needs to be able to recognize when a new assessment is required and who may restrict the use if necessary.

Not every organization needs permanent technical monitoring for this. What matters is that it has appropriate means to detect relevant changes and respond effectively.

The policy defines the rules. Operational governance is the organizational capability to apply those rules in concrete use situations, assess whether they continue to be met, and intervene when necessary.

The two belong together. A good policy can prepare and structure operational governance. But it does not create those capabilities simply by being adopted.

So if you want to understand how well your organization can actually govern its use of AI, it is not enough to ask:

Do we have an AI policy?

The more useful question is:

What can our organization actually decide, verify, and change when AI is being used?

Further Reading:

We spent quite a lot of time developing a research workflow designed to prevent AI from producing plausible answers without first doing the actual research.

By October 9, we were on Version 5.

The workflow was detailed. The instructions were clear. The AI was supposed to research, reconstruct, verify, and only then bring the findings together. There were checkpoints.

We gave it the assignment.

“What am I supposed to do with this?”

We had received pretty much exactly what we didn’t want: a plausible synthesis.

The AI had skipped substantial parts of the reconstruction.

So now we had a carefully designed research workflow, another experience with AI-assisted research, and a new entry in our research documentation.

Only the actual research was still unfinished.

V5 became V5.1.

A routine storage operation in an internal workflow failed. A piece of information could not be stored persistently in OpenAI ChatGPT Memory. It looked like a single failed write. So we started investigating.

But then it got more interesting: The storage capability available to our workflow had changed.

We just couldn’t tell when.

We knew when the failure became visible to us.

But not when the underlying capability had actually changed.

Looking back, that left a gap.

Maybe both happened at the same time.

Maybe they didn’t.

We couldn’t reliably reconstruct it.

Rolling back to Legacy Saved Memories didn’t make things any clearer. Existing memories were still readable. New persistent writes were now rejected with “Memory Context full.”

But that didn’t explain the original failure either. Technical cause unknown. No link to the migration or rollback could be established.

That’s when it became a governance problem.

What started as:

“Memory isn’t working.”

became:

A capability relevant to an operational workflow can change without that change being recognizable as such to the workflow that depends on it.

That is the gap between Capability Change and Change Detectability.

An organization can define very precisely which changes should trigger revalidation. But that logic only works if the organization can actually detect that a relevant change has occurred.

Two states can diverge:

the actual state of an external capability

and

the state the workflow continues to assume.

Capability Continuity is not the same as Property Continuity.

And Change Time is not necessarily Detection Time.

The uncomfortably simple question:

What exactly had we been relying on?

That an external capability was available.

And that a change to that capability relevant to our workflow would be detectable to us.

Since then, the order of our questions has changed.

First:

How would we detect a change relevant to our workflow in the first place?

And only then:

Does it require revalidation?

And how would your organization detect such a change?

Organizations can tightly control an individual AI workflow: its access, resources, execution environment and termination.

But those controls govern the workflow. They do not by themselves tell you where the effects of its actions continue.

The OpenAI/Hugging Face incident made that distinction operationally visible.

Agents ran in separate runs and isolated containers. But some could access the same internal infrastructure, allowing information, tools, results and credentials left by one run to become available to another.

The individual runs were separate. The resulting action chain could extend beyond them.

That is the problem even when workflow-level controls work as intended.

The workflow remains a valid governance unit. But its boundary may not contain the full operational effect of its actions.

So what tells your organization that the effects of a workflow have crossed into something its controls no longer govern?

And once they have, what governs what happens next?

The incident report calls it the first known case of an “automated agent collective acting offensively without authorization.”That sounds like a persistent AI collective launching a coordinated attack.

But technically, something different happened.

OpenAI had agents work on cybersecurity tasks in separate runs and isolated containers. One run started and ended. A later run was a new execution.

But some of these separate runs could access the same infrastructure.

That included Artifactory, an internal package server. Agents began leaving messages there. Other runs found them. The package server became an improvised message board where commands, results, tools, and credentials were later made available.

The runs were separate. What they left behind was not.

This eventually became a chain of actions.

One run found 14 Hugging Face credentials in a publicly accessible dataset and left them for later runs. Other runs found vulnerabilities and obtained production credentials. Those credentials and other results were shared as well. Later workloads could build on them.

It was not one powerful agent breaking through a boundary.

Multiple boundaries proved permeable in sequence, and the result of one step could become the starting condition for the next.

That is where the governance problem begins.

Capabilities, resources, access, and isolation can be constrained for an individual workflow.

But the chain of actions could extend beyond the boundary of that individual workflow.

Workflow
→ action
→ persistent result
→ shared, accessible infrastructure
→ another workflow
→ further action.

The first workflow may have ended long ago. Its result can still continue to matter in a later action.

This creates a divergence between two boundaries:

the boundary of the governance unit and the possible reach of the operational action chain.

The individual workflow remains an object of governance. But governance that considers only that unit can miss the transitions through which its action results continue to have effects in other workflows.

This makes the operational embedding of workflows and the transitions between them governance-relevant as well.

The open question is no longer whether the workflow boundary alone limits that operational reach. It is how far governance must follow a chain of actions that extends beyond that boundary.

No more than €350.
On a specific day and within a specific time window.
No more than one stop.
A window seat.
The agent has four days.

At this point, there is no specific financial action yet.

You have given the agent a bounded mandate.

Within this mandate, the agent can search, compare offers, and later make a specific selection on its own. The flight it eventually books may not even exist at the time you give the instruction.

Only later does the agent turn that mandate into a concrete action:

Book this flight for €345.

And this is where the authorization question changes.

The resulting payment can then enter the existing authorization and processing infrastructure.

But before that, an autonomous agent introduces a different question that must be answerable:

Why is this agent allowed to make this specific booking?

Is the price within the mandate?
Do the date and time window match?
Does the itinerary have no more than one stop?
Does the booking meet the seat requirement?
Is the mandate still valid?

The payment itself does not contain these answers.

The agent has turned a delegated mandate into a concrete financial action. This introduces an authorization question before the payment transaction itself: whether the specific agent action is still covered by the delegated mandate.

Delegated mandate → Agent → Concrete action → Mandate check → Payment transaction → Payment authorization

That is the structural change:

In agentic payments, the payment transaction is no longer the starting point for authorization.

But the agent’s identity does not yet determine the authority under which it acts.

Google distinguishes between an agent acting on its own authority and an agent acting with authority delegated by a user. The agent can therefore remain the same identifiable principal while the authority context behind a specific action changes.

This means that three questions need to be kept separate:

Who is acting?

On whose authority is it acting?

What is it authorized to do?

Cryptographic identity makes the agent identifiable. Its status as a principal makes the agent an identifiable subject of authorization. For authorization, this means that alongside the identified principal, the authority context under which the action takes place also becomes relevant.

The structure is therefore not simply:

Identity → Permission.

Rather:

Agent Identity → Principal

+ Authority Context → own or delegated

→ Authorization → authorized scope of action

This distinction becomes particularly relevant for reconstruction. If the same agent can act under different authority contexts, knowing which agent performed an action is not sufficient to reconstruct the governance conditions under which that action took place.

This distinction also becomes relevant for audit reconstruction: the Google architecture can keep agent identity and, in cases of delegation, user identity separately visible.

But even this does not fully represent the authority context. The identity of the delegating user shows to whom a delegation can be attributed. By itself, it does not determine what authority actually applied to the specific action.

Stable identity does not imply stable authority.

This does not, however, resolve the authority problem.

A verifiable agent identity and an attributable delegation do not by themselves determine how long delegated authority remains valid, how tightly it is bound to a specific action, or what happens if that authority changes between authorization and execution.

These are separate control conditions.

The governance question therefore extends beyond identifying the executing agent:

If the same agent can act under different authority contexts, what must remain reconstructable about the authority behind each individual action?

Reference:

Google Cloud, Agent Identity Overview

In a post, Raghvender Arni (Google) describes an agentic enterprise scenario in which this interaction does not rely on a single standard. Different functions are addressed separately: Open Knowledge Format (OKF) structures internal purchasing rules, Agentic Resource Discovery (ARD) is used to discover resources and endpoints, Agent2Agent (A2A) structures the interaction between agents, and SPIFFE provides cryptographically verifiable runtime identity.

What is notable is what this architecture does not require.

A2A explicitly treats the internal execution of the remote agent as opaque. The client does not need to know its internal state, memory, or the tools it uses for the two agents to interact.

The response to this opacity in the Google corpus examined here is not full transparency. Instead, specific conditions of the interaction are made explicit.

Policy context can be represented in structured form. Resources can be described and discovered. Interactions and task states can be formalized. Runtime identities can be made cryptographically verifiable.

The agent as a whole does not become transparent. Specific conditions of its interaction become explicit.

This changes the object of control.

Control does not have to depend entirely on being able to inspect the internal decision logic of another agent. Specific control conditions can be explicitly represented or made addressable or verifiable outside that logic.

This is not, however, a complete governance solution.

A verifiable identity does not prove correct execution. Structured policy context does not prove that a policy has been applied correctly. Discovery does not prove that a discovered resource is permitted for use. And a formally described task does not make the executing agent’s internal decision logic transparent.

This brings a more precise governance question into view.

Not only:

How transparent is the agent?

But:

Which conditions of a specific interaction must be explicit, verifiable, and reconstructable for control to remain possible under opaque execution?

This connects to our analysis „The Carrier Stability Problem“: governance does not operate directly on risks, but through carriers on which its functions can be exercised. The Google corpus examined here shows more concretely how, under agentic conditions, different parts of an interaction can become explicitly addressable.

References:

Raghvender Arni (Google), Enterprise AI Agent Interoperability Workflow

AI Governance & Markets, The Carrier Stability Problem

But these controls rely on an assumption:

that the conditions they enforce still hold.

This is where a different governance problem emerges.

A system can behave correctly and a control can function correctly while the conditions underlying the original authorization have changed.

The deployment context can change. The system’s capabilities can shift. Responsibilities or workflows can change.

A technically robust control architecture can therefore provide precise evidence that a governance condition was enforced correctly even though that condition is no longer appropriate.

These are two different questions:

Enforcement correctness:
Was the specified condition enforced correctly?

Governance validity:
Does that condition still hold under current circumstances?

This is where runtime control reaches its limit. When an authorization is translated into an executable control, it must be possible to verify not only whether that control operates correctly, but also whether the conditions underlying the authorization still hold.

That assessment cannot simply be performed by the runtime control itself. Its task is to enforce the applicable condition. If it were also to decide whether that condition still holds or needs to be changed, enforcement, revalidation, and modification would be combined within the same authority.

A trigger for revalidation does not fully solve the problem either. It can only respond to changes that produce a relevant signal within its defined observation space. Other changes may fall outside that space. They may also become visible first in the surrounding workflow while runtime telemetry continues to appear normal.

The absence of a trigger therefore cannot automatically mean that an authorization remains valid.

Between two reviews, a condition may remain formally in force even though its underlying assumptions have already eroded.

The tolerable delay before revalidation therefore depends on the deployment context. The higher the execution frequency and the greater the potential consequences, the shorter the acceptable interval between reviews may become. This raises requirements for provider-side architecture, evidence capabilities, and integration.

Revalidation therefore becomes more than a governance requirement. It affects integration costs and the conditions under which a system can be deployed operationally.

The architectural question therefore shifts:

From:
Where and how is a governance condition enforced?

To:
How do we know when the conditions underlying an authorization no longer hold, when must they be revalidated, and who has the authority to change them?

This shifts the focus of AI governance.

At first glance, the A5 Draft appears to be a catalogue of organizational requirements. On closer examination, however, it follows a different logic: it describes a governance architecture in which trustworthiness is operationalized through organizational roles, processes, responsibilities, and evidence.

The document places strong emphasis on a coherent organizational architecture. Roles are defined, responsibilities assigned, evidence requirements established, and processes linked together. Governance therefore emerges as an integrated organizational system rather than a collection of isolated controls.

This is particularly evident in the consistent connection between evidence, accountability, and auditability. Trustworthiness is expected to be demonstrable. As a result, the organization’s capability to sustain governance over time—and to provide verifiable evidence of that capability—moves to the center.

Yet this very strength creates a new governance tension.

The more systematically trustworthiness is operationalized through organizational structures, the more important the transitions within those structures become. When does continuous monitoring become a governance-relevant incident? How should organizations design the interfaces between observation, assessment, and incident management? And how can evidence remain meaningful as systems, contexts, and risks evolve over time?

These questions do not arise despite the architecture, but because of it. The more governance depends on organizational capabilities, the more critical their continuous operation, internal consistency, and adaptability become.

The A5 Draft therefore represents a broader shift in perspective.

Trustworthiness becomes an organizational capability to structure responsibility, govern processes, and maintain demonstrable governance over time.

This development is likely to extend well beyond the document itself. As AI governance becomes increasingly operationalized, attention will continue to shift away from individual technical measures toward the organizational capability to establish, maintain, and continuously demonstrate trust.

AI G&M Insight

The A5 Community Draft makes a broader structural movement visible: trustworthiness is increasingly being operationalized through organizational capabilities. As this shift continues, the central governance question changes. The primary challenge is no longer whether organizations have governance structures in place, but how effectively they can sustain, adapt, and govern those structures under changing conditions.

Regardless of how individual political announcements are assessed, this development points to a broader structural shift.

International AI competition is expanding into an institutional dimension.

For years, competition centered on models, computing power, and semiconductors. These factors remain decisive. At the same time, countries are increasingly competing through the institutional offerings they build around AI.

The United States emphasizes technological leadership and an innovation-driven ecosystem.

The European Union emphasizes regulatory reliability, trust, and institutional governance.

China increasingly positions itself through infrastructure, international engagement, and capacity building.

These approaches differ in their design. Yet they follow the same strategic logic: to create an institutional offering that other countries, companies, and organizations choose to join voluntarily.

Institutional attractiveness creates voluntary participation. Voluntary participation creates shared standards, governance structures, and organizational ties. Those ties, in turn, create long-term opportunities for influence.

Governance is therefore becoming a geopolitical value proposition. Geopolitical influence no longer begins only with the projection of power. It begins with institutional attractiveness.

Yet a different structural movement is becoming increasingly visible.

Governance is shifting its object.

No longer only:

• Which action is permitted?

• Which decision may be executed?

Increasingly, it is about:

• Access to frontier capabilities (EU Frontier AI Expert Report)

• Generation of context-specific policies (Google Semantic Governance)

• Evidence as the basis for decisions

• Context as a prerequisite for decision-making

Governance is moving further upstream in the decision process. It no longer regulates decisions alone.

It increasingly regulates the conditions under which decisions are formed.

This changes more than the location of governance.

It changes its object.

English term: Runtime Governance

Short definition

Runtime Governance describes a form of governance in which steering, control, and intervention do not end with the deployment of a system but continue throughout its ongoing operation. Governance becomes part of the conditions under which system execution is allowed to continue.

What real problem does the mechanism describe?

Traditional governance often assumes that the most important governance decisions are made before a system is deployed.

These typically include:

• approval,

• conformity assessment,

• risk assessment,

• documentation,

• deployment authorization.

For many modern AI systems, this assumption is no longer sufficient.

Important situations emerge only during actual operation.

Examples include:

• new information changes the operational context,

• agents generate intermediate actions,

• tools are selected dynamically,

• risks evolve,

• system boundaries are reached,

• human intervention becomes necessary.

These situations frequently cannot be fully anticipated before deployment.

Governance therefore cannot end with approval.

Runtime Governance describes governance that remains active during the operation of a system.

Mechanism

Runtime Governance does not merely move governance into runtime. It integrates governance into the conditions of execution itself.

As a system operates, new information, changing system states, and additional action possibilities continuously emerge. These developments may require evaluation, restriction, escalation, or intervention that cannot be completely predefined before deployment.

Governance therefore becomes part of the execution architecture. It no longer acts exclusively before system execution but within ongoing execution itself. Steering, control, and intervention become continuous elements of operation.

Runtime Governance does not replace deployment approval, risk assessment, or compliance. Instead, it continues these governance decisions under real operating conditions and continuously evaluates whether their underlying assumptions still hold.

Governance therefore changes from a one-time prerequisite of deployment into a continuous property of system execution.

Why is it important?

Many governance approaches focus primarily on system development, approval, or deployment. This can create the impression that governance is largely completed once a system has been released.

Runtime Governance extends this perspective.

It recognizes that governance may also be required throughout system operation. Rather than ending with deployment, governance becomes a continuous operational capability.

This becomes particularly relevant for adaptive and agentic AI systems, where new situations emerge continuously during execution.

Runtime Governance makes this governance layer visible as a distinct and recurring mechanism.

Reality Anchors

Runtime Governance can be observed across multiple operational settings.

Typical Reality Anchors include:

• agentic AI systems that continuously generate new actions,

• Human-in-the-Loop architectures with operational intervention,

• monitoring and intervention infrastructures,

• post-deployment governance processes,

• continuous oversight, incident handling, and operational risk management,

• AI systems whose permissions, capabilities, or execution must be continuously evaluated during operation.

Boundaries of the Mechanism

Runtime Governance does not describe every form of monitoring or system operation.

The mechanism requires that governance itself becomes part of the conditions under which system execution continues. Observation alone is therefore not sufficient.

Likewise, Runtime Governance does not replace deployment approval, documentation, conformity assessment, or compliance. These remain essential governance activities. Runtime Governance extends them into ongoing operation.

Not every AI system requires Runtime Governance to the same extent. The mechanism becomes increasingly relevant as systems gain greater autonomy, interact with changing environments, use external tools, or continuously generate new operational situations.

Related Mechanisms

• Reality Anchor

• Operational Tension

• Structural Mechanism

• Decision Threshold

• Verification Requirement

• Admission Layer

• Governance Capacity

Position in the AI G&M Reconstruction Logic

Runtime Governance is a Core Mechanism.

It describes how governance operates after a system has entered real-world operation.

Within the AI G&M reconstruction logic, Runtime Governance becomes relevant once a Structural Mechanism has reached a Decision Threshold and governance must continue under operational conditions.

Reality Anchor → Operational Tension → Structural Mechanism → Decision Threshold → Runtime Governance

Unlike the Foundation Mechanisms, Runtime Governance does not describe how AI G&M reconstructs reality. It describes a stable governance mechanism that can be reconstructed using that methodology.

Common Misunderstandings

• Runtime Governance is not identical to system monitoring.

• Runtime Governance is not a replacement for deployment approval or compliance.

• Runtime Governance does not imply continuous human intervention.

• Not every AI system requires Runtime Governance to the same degree.

• Runtime Governance describes a governance mechanism, not a specific technical implementation.

• Runtime Governance governs the conditions of execution, not merely the observation of execution.

Level 2 – Core Mechanisms

Status: Fundamental

English term: Decision Threshold

Short definition

A Decision Threshold describes the transition zone in which a Structural Mechanism turns into a real consequence.

It marks the point at which organizational, technical, or institutional possibilities become a new binding state.

What real-world problem does this mechanism describe?

Organizations develop processes, rules, and governance structures to prepare decisions and manage risk. These structures remain without effect until they are translated into real-world consequences.

Only at specific transitions is it determined:

• whether an action will be executed,

• whether access will be granted,

• whether a system will be approved,

• whether a payment will be initiated,

• whether market access will be granted,

• or whether an organizational consequence will take effect.

These transitions are often more important for governance than the preceding processes themselves. A Decision Threshold describes exactly this transition zone.

Mechanism

Before a Decision Threshold is crossed, multiple courses of action remain possible. Information may still be added, evidence collected, risks assessed, or alternatives considered. Once the threshold is crossed, however, a new real-world state emerges.

An action is executed.
Access is granted.
A product enters the market.
A payment is made.
An agent acts.

A Decision Threshold does not describe the decision itself. It describes the transition zone in which possibilities become real consequences. This transition may be triggered by human decisions, organizational procedures, technical rules, or automated control mechanisms.

The form of the transition may differ. The underlying mechanism remains the same.

Why is it important?

A Decision Threshold identifies where governance actually becomes effective. Rules, processes, and organizational structures do not create impact uniformly. Their real significance lies at the transitions where preparatory possibilities become binding consequences.

This makes it clear that governance does not primarily exist in documents or organizational charts. It exists at the thresholds where actions are permitted, constrained, delayed, or prevented.

A Decision Threshold therefore connects Structural Mechanisms with operational reality.

Reality Anchors

Decision Thresholds may become visible through:

• formal approval procedures,

• admission processes,

• conformity assessments,

• human oversight requirements,

• runtime checks,

• policy enforcement,

• API authorization,

• access control decisions,

• payment authorization,

• deployment approval.

Reality Anchors reveal the observable consequences. The Decision Threshold reconstructs the transition zone in which these consequences become binding.

Limits of the mechanism

Not every decision represents a Decision Threshold. Routine decisions without structural significance do not belong to this mechanism.

Likewise, a Decision Threshold does not describe the quality of a decision or the responsibility of individual actors.

It describes only the transition zone in which multiple possible states are reduced to one real consequence. A decision is the most common, but not the only, form of this transition.

Related mechanisms

• Reality Anchor

• Operational Tension

• Structural Mechanism

• Governance Capacity

• Verification Requirement

• Runtime Governance

• Admission Layer

AI G&M connection

The Decision Threshold forms the fourth step of the AI GM reconstruction logic.

Reality Anchor → Operational Tension → Structural Mechanism → Decision Threshold

Reality Anchors make observable reality visible. Operational Tensions create adaptation pressure. Structural Mechanisms describe the common logic underlying recurring adaptations. At Decision Thresholds, these adaptations become real consequences.

Many specialized AI GM mechanisms describe different forms of Decision Thresholds. These include, for example:

• Admission Layers,

• Runtime Governance,

• Human Approval,

• Policy Enforcement,

• Commit-Time Governance,

• Agentic Payments,

• Runtime Admission.

Although they differ in implementation, they all follow the same underlying mechanism: They determine the conditions under which possibilities become binding consequences.

Common misunderstandings

• A Decision Threshold is not the decision itself.

• A Decision Threshold is not a single moment in time.

• A Decision Threshold is not an organizational role.

• Not every decision constitutes a Decision Threshold.

• Decision Thresholds may be human, organizational, technical, or automated.

• A Decision Threshold describes the transition to a real consequence, not the entire decision-making process.

• A Decision Threshold may extend across multiple process steps rather than existing as a single formal approval point.

Level 1 – Foundations

Status: Fundamental

English term: Structural Mechanism

Short definition

A Structural Mechanism describes the common structural logic underlying recurring adaptations that become observable under comparable Operational Tensions across different contexts.

It explains not individual events, but the recurring pattern that connects these adaptations.

What real-world problem does this mechanism describe?

Organizations, markets, and institutions constantly change. Many of these changes are remarkably similar, even though they emerge independently of one another.

Organizations introduce similar documentation processes. They establish comparable governance roles. They create similar control or admission structures.

Viewed individually, these developments often appear to be organization-specific solutions or isolated management decisions. As a result, the underlying structural logic frequently remains invisible.

A Structural Mechanism makes this common logic visible.

It does not describe the individual adaptations themselves, but the recurring pattern that underlies them.

Mechanism

Comparable Operational Tensions frequently give rise to similar structural adaptations.

These adaptations may take the form of:

• new organizational roles,

• additional processes,

• modified decision pathways,

• new governance structures,

• organizational reconfiguration,

• new verification or control structures.

When such adaptations repeatedly emerge across different organizations or application contexts, their common structural logic can be reconstructed.

AI GM refers to this common structural logic as a Structural Mechanism.

The Structural Mechanism itself is not directly observable. What can be observed are the individual adaptations. The Structural Mechanism describes the recurring pattern that connects them.

Why is it important?

A Structural Mechanism shifts attention from isolated events to recurring patterns of organizational adaptation. This makes it possible to understand individual developments as part of a broader structural movement rather than as unrelated cases.

It enables analysts to:

• connect seemingly separate observations,

• compare developments across organizations and sectors,

• and identify structural change at an earlier stage.

A Structural Mechanism therefore forms the explanatory layer between observable reality and concrete decisions.

Reality Anchors

Structural Mechanisms are grounded in recurring observations.

Typical Reality Anchors include:

• similar organizational adaptations,

• recurring governance structures,

• comparable market responses,

• similar regulatory consequences,

• repeated changes in roles or processes,

• independent empirical observations of the same adaptation pattern.

A single Reality Anchor is not sufficient.

Only the repeated occurrence of similar adaptations across different contexts allows a Structural Mechanism to be reconstructed.

Limits of the mechanism

A Structural Mechanism does not describe a universal law. Organizations may respond differently to the same Operational Tension. Likewise, a Structural Mechanism does not describe an individual organizational measure.

It describes only the common structural logic underlying recurring adaptations.

Whether observed adaptations actually belong to the same Structural Mechanism must always be reconstructed from observable reality.

Related mechanisms

• Reality Anchor

• Operational Tension

• Decision Threshold

• Governance Capacity

• Verification Requirement

• Runtime Governance

• Admission Layer

AI G&M connection

The Structural Mechanism forms the central explanatory layer of AI Governance & Markets. It connects observable reality with recurring forms of organizational, institutional, and market adaptation.

Nearly all later mechanisms within the Encyclopedia - such as Verification Requirement, Governance Capacity, Runtime Governance, or Admission Layer—can be understood as specific Structural Mechanisms. They describe particular recurring forms of structural adaptation that emerge under comparable Operational Tensions.

Common misunderstandings

• A Structural Mechanism is not a theory.

• A Structural Mechanism is not an individual event.

• A Structural Mechanism is not a universal law.

• A Structural Mechanism does not describe a single organizational measure.

• Not every recurring observation constitutes a Structural Mechanism.

• Structural Mechanisms are not directly observable; they are reconstructed from recurring structural adaptations.

• A Structural Mechanism explains the common logic of recurring adaptations, not every individual action.

Level 1 – Foundations

Status: Fundamental

The EU AI Act begins with a seemingly technical question: What qualifies as an AI system?

The question appears purely definitional. In reality, it determines whether risks can be classified, obligations assigned, and conformity assessed. Only once this entity has been defined can governance operate on it.

A bank seeking to deploy AI in credit approval faces a different question: Who is authorized to approve a loan? The challenge is not merely to assess risks. The decisive issue is where authorization is anchored and who is permitted to make a decision.

A hospital deploying diagnostic AI systems faces yet another challenge: Who bears responsibility when AI influences treatment? Here, roles, responsibilities, and organizational accountability move to the forefront. A decision must be made about where responsibility is anchored.

An organization introducing new AI systems faces a different task: Which systems should be admitted into the organization at all? The central question concerns the admission decision as much as the subsequent risk.

A security team, by contrast, is often concerned primarily neither with models nor with procurement processes. The decisive question is: Can the organization detect, coordinate, and respond to threats? Here, the focus shifts away from the individual system toward the organization’s capacity to respond.

These situations originate from different domains and address different risks. Each places a different object at the center of attention.

The differences are substantial. AI systems, organizations, authorizations, admission decisions, and organizational capabilities differ fundamentally from one another. Nevertheless, they all qualify as objects of governance.

Reconstruction

The most immediate explanation is that different risks give rise to different governance units.

This explanation captures part of reality. It does not, however, explain why precisely these reference points are selected. The same risks could often be reconstructed through different reference points. Credit risks can be reconstructed through models, organizations, or approval rights. Clinical risks can be examined through systems, hospitals, or medical personnel. Security risks can be analyzed through individual systems, processes, or organizational capabilities.

The risk perspective alone therefore does not explain why certain reference points repeatedly move to the forefront.

Their significance derives from the governance functions they enable. An AI system can be classified. An approval right can be granted or revoked. An organization can assume responsibility. An admission decision can be approved or denied. A security capacity can be developed, assessed, and mobilized.

Despite their differences, the functions performed through them exhibit a striking similarity. Governance classifies, authorizes, admits, verifies, assigns responsibility, and coordinates.

Attention therefore shifts from the units themselves to the functions performed through them. Their commonality lies in enabling particular governance functions.

Risks can be described, assessed, and analyzed. Governance, however, cannot operate directly on risks themselves. It operates on objects to which responsibilities can be assigned, authorizations granted, or requirements imposed.

Governance therefore does not address risks directly. It addresses them through carriers.

Carrier Selection

Once governance functions become the focus, another question arises:

Why are certain carriers selected repeatedly?

Many other reference points are equally relevant: contexts of use, chains of action, delegations, and interactions among multiple systems. Yet they are less frequently chosen as primary governance reference points. Why?

Because relevance alone is not sufficient. Governance must be able to operate on a unit. That unit must remain identifiable, be capable of delimitation, carry responsibility, and serve as the object of decisions.

Relevance alone does not make an object governance-capable.

Against this background, the repeated selection of particular carriers can be understood as a search for carriers on which governance functions can be performed.

From Selection to Stability

The repeated selection of particular carriers points to an underlying logic of selection. Governance appears to prefer certain carriers because they possess characteristics that make governance operational.

These carriers can be delineated. They can be documented and verified. They can be linked to rights, obligations, and responsibilities. Above all, they remain identifiable over a sufficiently long period of time.

Against this background, the repeated selection of particular carriers can be understood as a search for carriers that are sufficiently stable for governance.

The Carrier Stability Problem

The crucial point, however, lies elsewhere.

Governance frequently operates on carriers other than those on which risks arise.

This difference is not new. Governance has always had to address risks through governance-capable carriers. Under AI conditions, however, risk genesis increasingly shifts into relational, distributed, and dynamic constellations, while governance must continuously adapt its carriers to these changes.

Many relevant risks now emerge in contexts of use, delegations, chains of action, and interactions among multiple components - in other words, in relationships.

These relationships lack many of the characteristics that governance requires of stable carriers. They are often difficult to delineate, change over time, generate ambiguous responsibilities, and can only be documented or institutionally embedded to a limited extent.

Governance responds by constructing new carriers - for example, monitoring pipelines, runtime controls, or evidence systems. In doing so, relational risks are translated into objects of governance.

This adaptation does not eliminate the underlying tension. With each new generation of governance carriers, the constellations in which risks arise continue to evolve. Governance therefore continuously adapts its carriers to an evolving risk genesis.

The Carrier Stability Problem therefore does not describe a one-time distance between risk genesis and governance carriers. It describes an ongoing process of adaptation in which governance continuously adjusts its operational carriers to changing forms of risk genesis.

The stability of the problem therefore lies not in immutable governance carriers, but in the recurring necessity to create new governance carriers under changing conditions.

The Reappearance of the Tension

The Carrier Stability Tension is not confined to individual governance regimes. It reappears across different decision contexts.

An organization procuring new AI systems frequently operates at the level of the admission decision. Many risks, however, only become visible during subsequent deployment. Governance intervenes where it can operate - not necessarily where risks arise.

A hospital faces a similar challenge. Diagnostic systems influence decisions, treatment trajectories, and responsibilities. The risks arise neither exclusively within the model nor exclusively within the organization. Nevertheless, governance must determine where responsibility, accountability, and control are anchored.

The examples differ substantially. The underlying tension remains the same. Governance operates on carriers capable of supporting its functions. Risk genesis frequently occurs elsewhere.

Consequence

The Carrier Stability Problem does not create a one-time trade-off. It creates a continuous pressure for adaptation.

Governance must continuously adapt its carriers to new forms of risk genesis. New governance carriers can reduce existing tensions while simultaneously changing the operational reference points, responsibilities, and control structures on which governance subsequently operates.

The central challenge lies in continuously organizing governance functions under conditions of ongoing change while preserving stability, traceability, and institutional embedding.

Implications for the Governance Discourse

The Carrier Stability Tension explains a striking characteristic of many AI governance debates.

Positions that appear to contradict one another often address different governance problems. They differ not only in their perspective on risk, but also in their choice of the carrier on which governance should operate.

As a result, conflicts frequently appear to be disagreements about risk. The reconstruction suggests, however, that they often begin one level earlier: with the question of which governance function is at stake and which carrier can reliably support that function.

Core Insight

The central tension is that the characteristics of effective governance carriers do not necessarily coincide with the characteristics of actual risk genesis.

Governance prefers carriers that are stable, clearly delineated, attributable, and verifiable. Many AI-related risks, by contrast, arise in distributed, relational, and context-dependent constellations.

Current governance conflicts often appear to be conflicts about risk. The reconstruction suggests, however, that they frequently begin one level earlier: with the question of the carrier on which governance should operate in the first place.

Governance does not primarily search for the places where risks arise. It searches for carriers on which it can operate.

Under AI conditions, the relationship between risk genesis and governance carriers becomes a continuous process of adaptation.

Evidence Note

Recent governance papers exhibit a consistent operational convergence.

Across runtime governance, monitoring, safety, reporting, and institutional capacity, governance is consistently attached to specific operational governance carriers rather than to risk itself. These include failure surfaces, admission boundaries, runtime controls, monitoring pipelines, identities, evidence systems, and institutional capacities.

This convergence appears across documents from Microsoft, IMDA, DeepMind, OpenAI, Anthropic, OECD, RAND/Oxford, and GovAI despite their different objectives, governance traditions, and problem settings.

The vector developed here does not derive its argument from these documents. Instead, it reconstructs a general governance mechanism and subsequently observes that the current governance literature increasingly organizes operational governance around comparable carriers.

The governance paper stack therefore does not prove the Carrier Stability Problem. It provides independent evidence that contemporary AI governance is increasingly operationalized through identifiable governance carriers rather than through abstract risk categories alone.

English term: Operational Tension

Short definition

An Operational Tension describes a real conflict between operational requirements that cannot all be fully satisfied under existing conditions. It creates adaptation pressure and forms the starting point of structural change.

What real-world problem does this mechanism describe?

Observable reality alone does not explain why organizations, markets, or institutions change.

Between an observable reality and a later structural change, an operational tension often emerges first. Different legitimate requirements simultaneously act upon the same resources, processes, or decision structures, yet cannot all be fully satisfied.

Examples include:

• speed versus control,

• innovation versus regulatory verifiability,

• automation versus human oversight,

• openness versus security.

Without reconstructing this operational tension, subsequent organizational changes often appear to be isolated management decisions or unique cases.

Operational Tension makes this otherwise invisible layer of adaptation pressure reconstructable.

Mechanism

An Operational Tension emerges when multiple operational requirements exist simultaneously, but the prevailing conditions prevent them from being fully reconciled.

These conditions may include:

• limited time,

• constrained resources,

• regulatory requirements,

• technical limitations,

• organizational structures,

• institutional constraints.

This creates operational adaptation pressure.

Organizations respond by introducing, for example:

• new processes,

• additional governance structures,

• revised organizational roles,

• prioritization,

• organizational redesign,

• or new capabilities.

When comparable Operational Tensions repeatedly occur across different contexts and consistently produce similar forms of adaptation, a Structural Mechanism can be reconstructed.

Operational Tension therefore describes the transition from observable reality to structural adaptation pressure.

Why is it important?

Operational Tension explains why Structural Mechanisms emerge.

It prevents organizational changes from being derived directly from isolated observations or events.

Instead, it reconstructs the operational pressure underlying the observed adaptations.

This makes it possible to understand why similar organizational solutions repeatedly emerge in different contexts.

The explanation therefore shifts from individual events to the conditions under which organizations must operate.

Reality Anchors

Operational Tensions may become visible through, for example:

• recurring implementation problems,

• regulatory trade-offs,

• documented governance bottlenecks,

• prolonged development or approval processes,

• organizational restructuring,

• new documentation and control processes,

• recurring human intervention in automated workflows,

• procurement or integration constraints,

• recurring prioritization conflicts.

Limits of the mechanism

Not every difficulty constitutes an Operational Tension.

Personal conflicts, isolated management failures, or temporary implementation problems do not, by themselves, constitute an Operational Tension.

Likewise, the mechanism describes only the adaptation pressure.

It does not yet explain the specific form of the resulting Structural Mechanism.

Related mechanisms

• Reality Anchor

• Structural Mechanism

• Decision Threshold

• Governance Capacity

• Organizational Layering

• Verification Requirement

AI G&M connection

Operational Tension represents the second step of the AI GM reconstruction logic.

Reality Anchor → Operational Tension → Structural Mechanism → Decision Surface

Reality Anchors describe observable reality.

Operational Tension reconstructs the adaptation pressure emerging from that reality.

Structural Mechanisms explain the recurring forms of adaptation.

Decision Surfaces identify where organizations or institutions must actually make decisions.

Operational Tension therefore connects observation with structural explanation.

Common misunderstandings

• An Operational Tension is not a personal conflict.

• An Operational Tension is not a management problem.

• An Operational Tension is not a Structural Mechanism.

• Not every operational problem is an Operational Tension.

• Operational Tension describes adaptation pressure, not its solution.

• Operational Tensions are reconstructed from observable reality rather than assumed theoretically.

• Resolving one Operational Tension may generate new Operational Tensions.

Level 1 – Foundations

Status: Fundamental

German working term: Realitätsverankerung

English term: Reality Anchor

Short definition

A Reality Anchor is an observable real-world condition on which the reconstruction of a structural mechanism is based. It provides the empirical starting point of an analysis while simultaneously limiting how far conclusions may be generalized.

What real-world problem does this mechanism describe?

Many analyses begin with an explanation or a theory without clearly showing what they are actually based on. Individual events are generalized, narratives replace observations, or theoretical frameworks are directly projected onto reality.

As a result, three different levels become blurred:

• what was actually observed,

• what was reconstructed from those observations,

• and what is only assumed beyond them.

The Reality Anchor addresses this problem by requiring every reconstruction to begin with observable reality. Only then can further analytical steps follow.

Mechanism

A Reality Anchor is always an observable real-world condition.

It is neither an explanation nor a theory, but a fact that can be observed and reconstructed.

Typical Reality Anchors include:

• an enacted law,

• a published technical specification,

• a documented organizational process,

• a real-world deployment,

• observable market behavior,

• a publicly documented incident,

• a court decision,

• an institutional decision,

• or a robust empirical study.

The Reality Anchor forms the first step of the reconstruction.

From this starting point, the analysis examines:

• which operational tensions become visible,

• which structural mechanisms can explain these tensions,

• and which decision implications emerge.

At the same time, the Reality Anchor defines the analytical scope.

A single Reality Anchor may justify proposing a possible mechanism.

Only multiple independent Reality Anchors can strengthen or stabilize a broader structural mechanism.

Why is it important?

The Reality Anchor protects analysis from two opposite errors.

On the one hand, it prevents theoretically elegant models from being developed without sufficient empirical grounding.

On the other hand, it prevents isolated observations from being prematurely treated as general structural laws.

This makes reconstruction transparent, reviewable, and incrementally expandable.

Future refinements or corrections can always return to the same Reality Anchors or incorporate additional ones.

Reality Anchors

Reality Anchors may include, for example:

• laws and regulations

• court decisions

• technical benchmarks

• documented deployments

• organizational processes

• market developments

• public organizational decisions

• regulatory guidance

• robust empirical studies

• reproducible field observations

What matters is not the type of anchor, but its observability and reconstructability.

Limits of the mechanism

A Reality Anchor does not prove a mechanism.

It only demonstrates that a particular observation exists.

Whether this observation supports a broader structural mechanism depends on additional Reality Anchors, their consistency, and the quality of the reconstruction.

The strength of an analysis therefore does not automatically increase with the amount of data, but with the quality and interconnectedness of its Reality Anchors.

Related mechanisms

• Operational Tension

• Structural Mechanism

• Decision Threshold

• Reality Density

• Source Continuity

• Constructed Reality

AI G&M connection

The Reality Anchor is the first building block of almost every AI GM analysis.

The fundamental reconstruction sequence is:

Reality Anchor → Operational Tension → Structural Mechanism → Decision Surface

Every subsequent analytical layer remains traceable back to its Reality Anchors.

This makes it possible to distinguish:

• what is directly observable,

• what has been analytically reconstructed,

• and what remains a hypothesis.

The Reality Anchor is therefore not only the starting point of analysis but also a mechanism that limits analytical reach. It prevents structural claims from becoming stronger than their empirical foundation. This logic is consistent with the AI GM principles Reality before framework and the Source Continuity Check, which require every structural reconstruction to remain traceable to its original observations.

Common misunderstandings

• A Reality Anchor is not a theory.

• A Reality Anchor is not an explanation.

• A Reality Anchor is not proof of a general mechanism.

• More Reality Anchors do not automatically produce a better analysis.

• Plausibility is not a substitute for a Reality Anchor.

• A Reality Anchor describes observation, not interpretation.

• Without a Reality Anchor, analysis becomes speculation.

Level 1 – Foundations

Status: Fundamental

Browse

Level 1 - Foundations

• Reality Anchor

• Operational Tension

• Structural Mechanism

• Decision Threshold

Level 2 - Core Mechanisms (coming soon)

Examples include:

• Runtime Governance

• Verification Requirement

• Admission Layer

• Governance Capacity

• Organizational Layering

• Re-Manualization

• Operational Object Drift

Level 3 - Specialized Mechanisms (coming soon)

Examples include:

• Detection–Recovery Decoupling

• Signal Explicitness as Containment Variable

• Discovery-to-Exploitation Gap

• Governance at the Execution Boundary

• Human Judgment as Residual Governance Layer

Core

The AI Governance & Markets Mechanism Encyclopedia is a long-term reference work that documents the structural mechanisms through which artificial intelligence changes governance, organizations, markets, and deployment conditions.

It is not a glossary of AI terminology.

It is an encyclopedia of reconstructable mechanisms.

Every entry explains one mechanism that can be observed, reconstructed, and applied across multiple real-world contexts.

The encyclopedia follows three core principles:

• Mechanism before terminology.

• Reality before framework.

• Reconstruction before interpretation.

Mechanisms are not derived from opinions, trends, or isolated publications. They are reconstructed from observable reality and supported by identifiable Reality Anchors.

The purpose of the encyclopedia is to provide a stable conceptual infrastructure for understanding how AI reshapes operational, organizational, and institutional conditions.

Structure

The encyclopedia is organized into three levels.

Level 1 – Foundations

Foundational mechanisms that form the analytical basis of AI G&M.

These mechanisms describe the basic building blocks required to reconstruct structural change.

Level 2 – Core Mechanisms

Stable mechanisms that repeatedly appear across governance, deployment, organizational adaptation, and market transformation.

Level 3 – Specialized Mechanisms

More specialized mechanisms that describe particular operational dynamics or emerging structural developments.

Mechanism Status

Each mechanism is assigned one of four maturity levels.

Fundamental

A foundational mechanism on which the analytical system itself is built.

Established

A stable mechanism repeatedly supported by multiple independent Reality Anchors.

Developing

A mechanism that already shows recurring empirical support but continues to evolve.

Candidate

A promising mechanism that requires additional Reality Anchors before becoming part of the stable framework.

How to read a mechanism

Every encyclopedia page follows the same structure:

1. German working term

2. English term

3. Short definition

4. What real-world problem does this mechanism describe?

5. Mechanism

6. Why is it important?

7. Reality Anchors

8. Limits of the mechanism

9. Related mechanisms

10. AI G&M connection

11. Common misunderstandings

12. Level

13. Status

Each page explains exactly one mechanism.

If two different mechanisms emerge, they are documented on separate pages and linked to each other.

Scope

The encyclopedia explains mechanisms.

It does not document:

• companies,

• laws,

• papers,

• institutions,

• technologies,

• products,

• or historical events.

These may appear as Reality Anchors where they help explain a mechanism, but they are never the subject of the encyclopedia itself.

Method

Every mechanism follows the same reconstruction logic:

Reality Anchor → Operational Tension → Structural Mechanism → Decision Surface

This sequence reflects the analytical workflow of AI Governance & Markets.

The encyclopedia documents the resulting mechanisms—not the research process that produced them.

Purpose

The AI G&M Mechanism Encyclopedia serves four complementary purposes.

It is:

• the permanent reference architecture for AI Governance & Markets,

• an internal reconstruction framework for analytical work,

• a public knowledge base for practitioners, researchers, and decision-makers,

• and a durable conceptual reference for future AI-related search and retrieval systems.

Its objective is not to explain everything about AI.

Its objective is to explain the structural mechanisms that repeatedly shape AI governance, markets, organizations, and deployment under real-world conditions.