The Missing Layer
Authorization Topology and the Open-Scope AI Problem
The prevailing framing of artificial intelligence governance treats the problem as a capability question: systems become dangerous in proportion to their capability level. This paper argues the framing is wrong.
The distinction between "narrow" and "general" AI is not a capability property — it is a scope authorship property. Specific AI systems have scopes defined by their builders at build time. General AI systems have scopes defined by users at runtime. This distinction is structural and testable without benchmarks.
The structural consequence is immediate: open-scope systems require authorization topology — a runtime mechanism for evaluating what actions a system is permitted to initiate. This requirement is mechanical, not policy-driven. Systems with builder-closed scopes do not require it because the builder already made those decisions. Systems with user-defined scopes do require it because no pre-validation at build time can cover runtime-directed action.
We define Automated Intelligence as the architectural class that provides this authorization topology. The paper presents the formal derivation, the structural requirements, and an instrumentation layer for empirical validation.
The thesis: governance was never the wrong layer. It was the missing layer.
1. Introduction: The Framing Problem
Artificial intelligence policy has largely proceeded from a capability framing. The dominant question is: how capable is the system? Capability thresholds determine safety requirements, deployment restrictions, and regulatory treatment.
This paper argues the capability framing mislocates the governance problem.
Consider two systems:
- A chess engine with superhuman capability at chess
- A language model with modest capability across many domains
The chess engine, however capable, cannot initiate action outside its domain. Its scope is fixed at build time. No runtime governance layer is needed — the builder already bounded what the system can do.
The language model, even if less capable at any individual task, can be directed toward arbitrary goals across arbitrary domains. Its scope is open. Runtime governance is structurally required — not as a policy preference, but as a mechanical necessity.
The governance problem is not about capability level. It is about scope structure.
2. The Scope Authorship Distinction
We define the distinction formally.
A system whose action space is defined at build time by the builder. Execution resolves only into pre-specified outputs. The user triggers the system but does not direct its scope.
A system whose authorized action scope is determined at runtime by the user within an architecturally extensible action space. The user issues the directive; the system determines fulfillment across available domains.
The discriminating variable: who defines the scope, and when?
- Builder-defined at build time → Specific AI
- User-defined at runtime → General AI
This distinction is testable without capability benchmarks, without performance thresholds, and without reference to intelligence levels. It is a structural property observable from the system's authorization model.
Examples:
| System | Scope Authorship | Classification |
|---|---|---|
| Chess engine | Builder at build time | Specific AI |
| Spam filter | Builder at build time | Specific AI |
| OCR reader | Builder at build time | Specific AI |
| Large language model | User at runtime | General AI |
| General-purpose agent | User at runtime | General AI |
3. Action Space: Formal Grounding
We ground the distinction in a formal model.
An operation that produces a state change outside the system's transient working memory. This is the execution boundary — the point at which system behavior affects external state. Reads count.
The set of all state transitions the system can produce.
The full set of state transitions the system's architecture can produce, defined by its construction.
The subset of state transitions the system is permitted to initiate in a given deployment.
These are not equivalent. The formal relation is:
Authorized ⊆ Architectural
A system may be architecturally capable of producing a state transition while being unauthorized to initiate it. The authorized space is always a subset of the architectural space — never larger.
This separation matters: a constraint on the authorized space does not change the architectural space. A language model constrained by a system prompt is not a different architecture. It is the same architecture with a narrowed authorized space.
4. Structural Non-Enumerability
What makes a General AI system's action space "open" is not size. Very large finite sets are still closed and enumerable. The relevant property is structural extensibility.
A system's architectural action space is structurally non-enumerable if the set of external state domains it can act upon is not fixed at construction — it is a function of the runtime environment.
This is non-enumerability in principle, not in practice.
Future state domains — new APIs, new services, new data structures, new deployment contexts — do not exist at build time. They cannot be enumerated because they have not yet been constructed. The openness is not computational difficulty. It is structural indeterminacy.
A chess engine's action space is large but enumerable: all possible board states are definable at build time.
A general system's action space is not enumerable at construction time: the domains it will be directed toward include domains that do not yet exist when it is built.
The openness is not inside the system alone. It exists at the interface between the system's domain-general representations and an unbounded external environment. New domains become reachable as the environment evolves — without architectural modification.
5. The Authorization Topology Requirement
The governance consequence follows directly from the structural property.
If a system's architectural action space is structurally non-enumerable, then authorization cannot be fully pre-resolved at build time. Runtime authorization evaluation becomes structurally unavoidable in any complete authorization system.
Authorization requires evaluation against a rule set that references action classes or properties. At build time, that rule set can only reference action classes known at construction. If the action space is structurally non-enumerable — dependent on future runtime domains — the rule set cannot be completed at build time. Authorization evaluation must therefore occur at runtime, against the actual action class being initiated and its properties at the moment of execution.
Specific AI systems do not structurally require open-ended runtime authorization topology. The builder closed the scope at build time. The action space is pre-specified. No runtime evaluation is needed because all possible transitions were already evaluated at design.
General AI systems structurally require runtime authorization topology. Without it, no constraint exists between what the user requests and what the system is permitted to initiate. This is a mechanical requirement — not a policy preference, not a design choice.
The governance gap in AI deployment is not a gap in capability understanding. It is a gap in authorization architecture.
6. Automated Intelligence: The Architectural Class
We define the architectural class that provides the required authorization topology.
Automated Intelligence is a system architecture that performs reasoning and execution tasks under an authorization topology model, where every action is class-authorized by an external principal prior to execution, behavioral boundaries are enforced by a privilege-isolated gate, and all state changes are logged and recoverable within defined constraints.
Artificial Intelligence describes capability potential.
Automated Intelligence describes execution discipline.
Can the system initiate new goal-directed execution without fresh external authorization?
- No → automation remains
- Yes → autonomy begins
Automated Intelligence is defined by authorization topology — not by what the system does, but by what the system is permitted to initiate.
Five Defining Clauses
The minimal authorization unit is the execution class. Two actions share a class if authorization for one logically implies authorization for the other. A prior grant is required before any execution begins.
The objective does not authorize the means. Intent to achieve a goal does not authorize actions that achieve it. Each action class requires its own explicit authorization.
A privilege-isolated checkpoint, external to the reasoning engine, evaluates every action before execution. Atomic composite rejection applies: if any component of a composite action lacks authorization, the entire composite is rejected before any constituent executes.
Defined by state scope: execution begins at the first operation that accesses, observes, or modifies state outside transient working memory. Reads count. Transient working memory excludes caches, retrieval stores, vector databases, and tool-side persistence.
All state changes are logged, scoped, and recoverable within defined constraints.
7. Why Narrow Deployment Was Not a Capability Limit
The scope authorship distinction reframes the history of AI deployment.
General AI capability — open action space, user-directed scope — appears to be structurally approximated in large language models, subject to empirical validation. The constraint on deployment was not architectural capability. It was the absence of authorization topology.
Without a runtime authorization layer:
- The authorized space was undefined
- Any user directive could potentially reach any reachable domain
- No constraint between request and permitted execution existed
The response was to narrow deployment artificially — through training restrictions, system prompts, usage policies, and access controls. These are authorization approximations. They are not authorization topology.
Authorization approximations are:
- Advisory, not enforced at the execution boundary
- Inconsistently applied across deployment contexts
- Incapable of atomic composite rejection
- Not externalized from the reasoning engine
Automated Intelligence provides what the approximations cannot: a structurally enforced, privilege-isolated, runtime authorization layer.
Narrow deployment was not evidence that General AI was unsafe in principle. It was evidence that the authorization layer required to deploy it safely did not yet exist as a defined architectural class.
8. The Empirical Question
The structural theory is closed. One empirical question remains open and must not be conflated with the structural argument.
Current large AI systems encode domain-invariant structural abstractions sufficient for cross-domain execution — abstractions learned from training across diverse domains that transfer to previously unseen domains through structural pattern mapping.
This is not derivable from architecture alone. It must be tested.
Cross-domain operation requires domain-invariant structural representations plus runtime mapping information from context. Without both, valid state transitions in novel domains cannot be produced.
Performance tracks structural similarity rather than surface similarity across unseen domains.
The four possible mechanisms produce distinguishable failure signatures:
| Mechanism | Failure Pattern |
|---|---|
| Memorization | Collapses outside seen training cases |
| Interpolation | Degrades proportionally with surface distribution shift |
| Heuristic reuse | Fails when surface cues conflict with structural constraints |
| Structural abstraction | Transfers across surface-dissimilar, structurally-similar domains |
Context bleed — cross-context success observed across surface-dissimilar domains — is a candidate observable correlated with structural abstraction. It is evidence, not proof.
Instrumentation Layer
To measure structural similarity independently of surface similarity, we define a constraint graph extraction procedure. This procedure is deterministic, bounded, and reproducible.
Nodes — Five-class constraint taxonomy:
| Class | Detection Rule |
|---|---|
| Authorization | Spec contains execution-conditional based on identity, permission, or credential state |
| Input Validation | Spec defines schema or type constraint on inputs that must hold before execution |
| State Precondition | Spec contains execution-conditional based on prior system state |
| Output Contract | Spec defines required properties the output must satisfy post-execution |
| Sequencing Dependency | Spec contains explicit ordering relation between two or more operations |
Detection is binary per class. Rules are pre-committed before any domain is tested. Fallback rule: if omitting the constraint would allow a spec-violating transition, the node exists.
Multiplicity: Category resolution — one node per class per domain. Known limitation: domains differing only in instance count within a class are aliased at this resolution. Explicitly accepted.
Edges: Directed prerequisite dependency — edge (A → B) if satisfying A is required before B can be evaluated.
Path bound: Maximum path length = 5 (|taxonomy|). Derived from category resolution, not imposed arbitrarily.
Similarity metric: Path-set intersection over union.
Structural similarity = |path_set(G1) ∩ path_set(G2)| / |path_set(G1) ∪ path_set(G2)|
Surface similarity: Token and embedding overlap — independently measurable without structural reference.
Test design: Domain pairs with deliberately decoupled surface and structural similarity across four quadrants. If performance tracks structural distance, structural abstraction is operating. If performance tracks surface distance, interpolation or heuristic reuse.
9. Conclusion
The AI governance debate has largely proceeded from a capability framing. This paper argues the framing mislocates the problem.
The structural argument in full:
The distinction between Specific AI and General AI is a scope authorship property — not a capability property. Who defines the scope, and when, is the discriminating variable.
Open-scope systems have structurally non-enumerable action spaces. Future state domains cannot be enumerated at build time because they do not yet exist.
Structurally non-enumerable action spaces require runtime authorization evaluation. This is mechanical necessity, not policy preference.
Automated Intelligence is the architectural class that provides the required authorization topology — the missing structural layer for General AI deployment.
Whether current systems satisfy the empirical conditions for cross-domain structural abstraction is testable. The instrumentation layer to test it is now defined.
Narrow deployment was not evidence that General AI was architecturally limited. It was evidence that the authorization layer required to deploy it safely had not yet been formally defined.
Supporting Artifacts
| Artifact | Location |
|---|---|
| Automated Intelligence Class Definition v5 | Automated_Intelligence_Class_Definition_v5.md |
| Open Scope Authorization Topology Walk | open_scope_authorization_topology_walk.md |
| General AI Scope Authorship Derivation | general-ai-scope-authorship-derivation.md |
| AI Class v5 Copyright Filing | U.S. Copyright Case 1-15144594701, filed April 18, 2026 |
* Filed under Lumen Research Team — the project name prior to migration to Reiva. The filed document is unmodified.