Execution Control in Persistent AI Systems A Geometry-Constrained Model

 Execution Control in Persistent AI Systems

A Geometry-Constrained Model

Giorgio Roth

2026

https://github.com/giorgioroth/ContinuumPort/blob/main/AI_Architectural_Thinking.md

1. Introduction

This work does not attempt to improve model intelligence, but to constrain execution correctness.

Persistent AI systems do not typically fail through single errors. They fail through drift.

Partial success, partial failure, and uncontrolled updates gradually desynchronize system state from reality. Once divergence occurs, subsequent decisions compound the error.

This work proposes a different approach: control execution structurally, not heuristically. Instead of evaluating outputs, the system evaluates whether state transitions are permitted.

2. Model

We define the system configuration as:

S = (D, A, Auth)

Where:

• D — Declarative task state

• A — Adaptive memory (optional, bounded or absent)

• Auth — Execution authority

Σ is reserved for observed or reconciled state representations used in later sections.

Execution is governed by a geometry:

G = (S, A, T, I)

Where:

• S — State space

• A — Action set

• T — Transition rules

• I — Invariants

Execution occurs if and only if:

execute(α) ⇔ authorize(G, α)

An Authority Gate enforces this condition. The gate cannot be bypassed, and the geometry it evaluates is externally controlled and immutable during execution.

3. System Properties

The system guarantees:

• Determinism — identical input produces identical output

• Atomicity — full commit or full rollback

• No partial state escape — failed execution leaves no residue

• TOCTOU protection (intra-cycle) — state drift invalidates execution

• Monotonic filtering — no layer can add actions

• Decision idempotency — repeated filtering is stable

• Divergence collapse — uncertain state halts execution

• No authority escalation — execution cannot modify permissions

• Controlled mutation — all state changes pass through the gate

• Bounded intake — evaluation cost is limited

• State-local constraints — no temporal dependency in validation

• Error layer separation — failures are structurally localized

These properties are enforced by architecture and validated empirically.

4. Empirical Validation

The system is validated through an adversarial test suite (344 tests). Key verified behaviors include:

• Direct state mutation attempts are blocked

• TOCTOU drift is detected and rejected

• Partial execution cannot occur

• Invalid capabilities fail closed

• Rollback restores full state

• External drift is detected post-execution

• Epistemic uncertainty halts execution

The system does not rely on correctness of individual components, but on structural guarantees across layers.

5. Critical Experiment: Geometry as the Control Variable

A critical test isolates the role of geometry:

Same:

• execution engine

• initial state

• action

Different:

• geometry definition

Result:

• permissive geometry → action commits → state mutates

• restrictive geometry → action rejected → state unchanged

This demonstrates: behavior is a function of geometry, not of execution logic.

6. Limits of the Model

The model explicitly does not guarantee:

• temporal correctness

• cross-cycle replay protection

• action composition safety

• intent correctness

• control plane correctness

Additionally, the current geometry DSL has limited expressiveness. For example, invariants apply only to explicitly referenced keys and do not generalize automatically across state.

These limitations define the boundary of the execution model.

7. Discussion

Most AI systems optimize generation.

This model constrains execution.

The shift is: from action-level control to state-transition control. Correctness is evaluated over trajectories, not outputs.

8. Conclusion

Reliable execution in persistent systems does not emerge from better models alone.

It requires: explicit state, constrained transitions, non-bypassable enforcement.

Control is not what the system can evaluate. Control is what the system can refuse to execute.

Appendix A — Property-to-Test Mapping

Property	Test
Determinism	test_state_hash_deterministic, test_assess_is_pure
Atomicity	test_transaction_rollback, test_atomic_rollback
No partial state	test_no_effect_survives_failed_commit
TOCTOU protection	test_drift_between_propose_and_commit_is_rejected
Divergence collapse	test_diverged_returns_empty
No authority escalation	test_capability_sequence_cannot_escalate_authority

Appendix B — Test Evidence

The system has been validated with a full adversarial suite. 

A representative execution log is included (sanitized) to demonstrate deterministic and fail-closed behavior under adversarial conditions.

Full implementation and tests are available in the public repository.

344/344 tests passing under volume, concurrency, and adversarial conditions.

Giorgio Roth • 2026