Imagine renovating a house with a builder. The plan, what has been done, and what comes next live in a file, so another builder can continue if the first one leaves. If the builder wants to knock down a wall or spend money, a note saying "ask first" is not enough: the approval has to stop the work when permission is missing. And a builder who follows the plan perfectly does not prove the plan is right, or that he had the right to change it.
In this analogy, CP-Core is the portable file within ContinuumPort. Regen Engine is the execution gate that checks whether the work may proceed.
Public development in this repository is paused as of September 2026. The repository is not abandoned.
Work on the execution kernel continues privately. Its source is not published, and this repository does not track that work.
The published specifications, books and documents reflect their state at the time of their last commit. A private review has since narrowed some claims in them, in particular the definition of compliance in REGEN-COMPLIANCE-v1.md. Those revisions are not reflected in the public files. Read each published claim as of the commit that contains it.
The public quickstart demonstrates checks against a declared geometry and restoration of managed state after a failed sequence. The private kernel has been tested on transitions that enter its declared boundary. It has not been shown that every effect in an application reaches that boundary, and this does not promise reversal of external effects. The published model does not establish governance over replacing one accepted geometry with another; that remains an open research problem in the public record.
Your system failed. What does that leave intact?
Persistent systems need explicit controls to preserve selected invariants under adversarial or partial-failure conditions. ContinuumPort defines the constrained execution model; the private Regen Engine enforces declared constraints on transitions that reach its boundary. This does not establish application-wide enforcement or universal structural integrity.
In persistent systems, execution fails mid-sequence. When it does, the state may reflect a committed prefix — neither the initial state nor the intended result. This is not an edge case. It is a structural property of unconstrained execution.
Reactive recovery — rollback, retry, or compensation — addresses failures after execution has begun. For non-invertible transitions or externally visible side effects, restoration cannot be guaranteed.
ContinuumPort addresses this at the execution layer: invalid sequences are excluded from the admissible execution space before any state is committed.
git clone https://github.com/giorgioroth/ContinuumPort
cd ContinuumPort/quickstart
python run.py # I4 — no partial state escape
python run_determinism.py # I5 — deterministic outcome
python run_address_invariant.py # I2 — domain integrityNo dependencies. Runs in seconds.
I4 — Partial state escape
[FaultyAdapter]
Action 1 succeeds. Action 2 fails.
State after: {'account': 'active', 'balance': 100, 'processed': True}
✗ VIOLATED — partial state escaped
[ContinuumPort]
State after: {'account': 'active', 'balance': 100}
✓ ENFORCED — internal state restored to pre-execution snapshot
I5 — Determinism
[FaultyAdapter] Run 1: {'x': 2} Run 2: {'x': 1} ✗ VIOLATED
[ContinuumPort] Run 1: {'x': 2} Run 2: {'x': 2} ✓ ENFORCED
Composition attack
Same engine. Same actions. Different geometry.
Incomplete geometry → authorized=True → budget=-50
Complete geometry → authorized=False → BLOCKED
The engine does not decide what is safe. The declared geometry does.
Domain integrity
The system does not reject the action. The action does not exist.
Invalid input is structurally inadmissible — it never enters the execution domain.
The five invariants do not have the same epistemic status. The distinction matters.
| Property | Enforcement basis |
|---|---|
| I1 — No unauthorized execution | Formally demonstrated: authority gate is a necessary condition in GF(S); no admissible sequence bypasses it. Full proof: Trajectory Integrity in Persistent AI Systems, §3–§5 |
| I2 — No out-of-domain execution | Formally demonstrated: domain boundary is encoded in the geometry; out-of-domain input has no image in the execution space. Full proof: same source, §3–§5 |
| I3 — No invalid state transition | Formally demonstrated: geometry constraints are enforced before commitment; violating transitions are inadmissible by construction. Full proof: same source, Theorem 5.1 |
| I4 — No partial state escape | Formally demonstrated within the declared execution boundary: atomic commit/rollback prevents intermediate managed state from escaping under the stated adapter assumptions. This does not cover external effects. Full proof: same source, Theorem 5.1, Corollary 5.4 |
| I5 — Deterministic outcome | Exercised empirically by the subset of the suite that tests it directly: repeated execution of the same configuration and sequence, compared for identical final state, with negative controls. Other tests document limitations or exercise other properties; a suite total would not be a count of evidence for I5. The audit replay mechanism is assumed by construction: no test independently verifies replay determinism across adapter implementations |
Within the declared boundary and adapter assumptions, violations of I1–I4 are structurally inadmissible: they do not reach execution. Recorded tests exercise I5 under their stated conditions; the audit replay assumption is documented in the invariant table above. A passing suite establishes that the cases written were satisfied under the conditions run. It does not establish that the corpus covers the claim set, which is a separate assumption.
This is not a convention. It is enforcement — within the declared execution boundary, by a compliant adapter enforcing the compliance interface below. An adapter that either fails to implement that interface, or bypasses it, is outside this guarantee entirely; enforcement applies to compliant adapters, not to arbitrary code. The FaultyAdapter demos above show what enforcement looks like when the boundary condition is not met.
The self-contained quickstart demos above run on a clean checkout of this repository with no dependencies. The full validation suite runs against the Regen Engine kernel, which is proprietary (Beta license) and is not included in this public repository. Evaluation access to the suite is available on request (access@continuumport.com).
The screenshot above records a historical run in the author's Windows environment. It is not a current suite total; its execution date and source revision are not established by this README.
Paper 4 (Adversarial Execution Governance) reported a historical cumulative corpus of 1,806 tests at submission, after Batches 1–12. A subsequent historical result and its provenance limits are recorded in the private evidence ledger CP-EVIDENCE-001, revision 0.5.4, entry EV-KERNEL-SUITE-001 (reviewed 21 September 2026 UTC). That is the ledger's review date, not an established execution date; the entry also lacks the executed build and suite revision. The canonical ledger is maintained privately and is not synchronized with the historical GitHub copy. It is available on request at access@continuumport.com. This README does not assert a current suite total.
The adversarial corpus was developed across 13 batches with the assistance of Claude (Anthropic), ChatGPT (OpenAI), and Gemini (Google) — in that order of contribution. The validation suite is the primary empirical research artifact of this project.
The validation suite includes:
- replay attacks
- state drift injection
- geometry swap attacks
- capability rebinding
- TOCTOU patterns
- composition attacks
- hash canonicalization failures
- authority desynchronization
- rollback desynchronization
- cross-cycle state trap scenarios
- malformed capsule reconstruction
- deterministic integrity verification
- hostile observation (H1–H5)
- commitment graph attacks (G1–G6)
- causal opacity (O1–O5)
- provenance enforcement (P1–P5)
- authority laundering (L1–L6)
- admissibility erosion (E1–E5)
- concurrent adversarial pressure (C1–C5)
- control-effect binding (the subject validated for admissibility versus the object whose effects commit)
- fail-closed ordering (refusal before the actuator, not materialization followed by rollback)
- audit provenance substitution (a caller's description of intent varying the record of what was performed)
- commit-boundary enumeration (a second, unasserted implementation of a repaired boundary)
The recorded tests exercise these patterns and limitations: some show refusal at the declared boundary, while others document gaps or assumptions. Coverage of enumerated cases does not establish structural impossibility for categories beyond the formal model (see Scope and limits).
ContinuumPort specifies correctness conditions for execution under declared constraints. Regen Engine enforces those constraints on transitions that reach its declared boundary, subject to the adapter and effect limits below.
It does not guarantee:
- Correctness of intent
- Correctness of declared constraints
- External side effects beyond the execution boundary
Undeclared risks are not blocked.
These limits are explicit and documented in EXECUTION_MODEL_LIMITS.md
Actions
↓
Authority check
↓
Geometry enforcement
↓
Execution (atomic)
↓
Commit / Rollback
ContinuumPort defines the constrained execution model. Regen Engine enforces it.
Formal model: GF(S) — the maximal prefix-closed, failure-free execution space. Only sequences inside GF(S) are admissible for execution. Corrupted states are structurally inadmissible, not merely detected after the fact.
This guarantee holds for an adapter implementing the compliance interface below correctly ("compliant"). An adapter that does not implement it, or that bypasses it, is outside this guarantee — there is no enforcement over code that never enters through the kernel. Within that boundary, the Regen Engine functions as an execution-governance kernel: governed state-affecting transitions submitted by a compliant adapter must pass through it.
This is not middleware. It is not a validator that can be disabled. It is not a hook that can be skipped.
The distinction matters:
- Non-bypassable execution governance — a compliant adapter routes its governed state-affecting transitions through the enforcement layer. It does not provide an alternative path for those transitions.
- Centralized admissibility enforcement — governed transitions entering that boundary are evaluated against the declared geometry before commitment. Authority, invariants, and epistemic state are checked at that point.
- Invariant-preserving state transitions — the system does not detect violations after the fact. Transitions that would violate declared invariants are structurally inadmissible. They do not execute.
- Fail-closed execution semantics — under uncertainty, divergence, or insufficient data, the system halts. It does not degrade gracefully into permissive behavior. It stops.
Non-bypassability here is a property of the compliant path, defined by the interface. It has not been shown that every effect in a deployed application takes that path; see the status note above.
Loggers can be bypassed. Validators can be disabled. Middleware can be removed.
A compliant adapter cannot route around an execution-governance kernel. Every transition from a compliant adapter passes through it, or the transition does not occur.
This mandatory check within the compliant path distinguishes the Regen Engine from advisory systems, monitoring layers, or behavioral guardrails. Whether a deployed application has any effect path outside it remains a separate question.
class RegenAdapter(ABC):
def reset(self, state: dict) -> None: ...
def snapshot(self) -> dict: ...
def execute(self, actions: list[dict]) -> ExecutionResult: ...
def simulate(self, state: dict, action: dict) -> dict: ...See EXECUTION_MODEL_LIMITS.md §2.9 for the trust assumptions this contract relies on.
This public repository contains the specification, the self-contained demos, and the published books and essays:
quickstart/ — self-contained runnable demos (no dependencies)
docs/ — formal specification, scope boundaries, invariant-test documentation
cp-core/ — CP-Core normative schema and handoff specification
regen-engine/ — engine demonstrations (attack, side-effects)
The Regen Engine kernel and the full compliance/validation suite are proprietary (Beta license) and are not included in this public repository. Evaluation access is available on request: access@continuumport.com
The numbered documents at the repository root are meant to be read in order:
- PROJECT_STATUS — where the project stands
- Whitepaper — what it is, technically
- LICENSE_REGEN — under what conditions it may be used
- Roadmap — where the project is going
- WHERE_REGEN_ENGINE_BELONGS — where it applies, and where it does not
Documents 1–4 are normative or contractual. Document 5 is non-normative positioning; where it and the license differ, the license governs.
- AI Architectural Thinking — the conceptual framework (62 chapters)
- EXECUTION_MODEL_LIMITS.md — explicit scope boundaries
- Blog — context and philosophy
- continuumport.com
Gh. Rotaru (Giorgio Roth) — Independent researcher, 2026
contact: access@continuumport.com