Skip to content

giorgioroth/ContinuumPort

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

384 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

ContinuumPort

Your system failed.

What guarantees that nothing changed?


Most systems can't answer that.

ContinuumPort can.

Failure should not change state.
In most systems, it does.
We made that structurally impossible.

What this means in practice

A batch of actions runs. Action 1 succeeds. Action 2 fails.

Default behavior: Action 1 is committed. The state is now partially modified. The system continues from a state it cannot justify.

ContinuumPort: Full rollback. The state is identical to what it was before the batch started. No residue. No residual state.

This is not convention. It is enforcement.


Run locally

git clone https://github.com/giorgioroth/ContinuumPort
cd ContinuumPort/quickstart

# No partial state escape
python run.py

# Same input → same output, always
python run_determinism.py

# Invalid input never becomes executable
python run_address_invariant.py

No dependencies. Runs in seconds.


What the output shows

I4 — No partial state escape

[FaultyAdapter — no rollback]
State after failure: {'account': 'active', 'balance': 100, 'processed': True}
✗ VIOLATED — partial state escaped

[ContinuumPort — atomic rollback]
State after failure: {'account': 'active', 'balance': 100}
✓ ENFORCED — rollback complete

I5 — Determinism

[FaultyAdapter]
Run 1: {'x': 2}   Run 2: {'x': 1}
✗ VIOLATED — same input, different outputs

[ContinuumPort]
Run 1: {'x': 2}   Run 2: {'x': 2}
✓ ENFORCED — identical output

I2 — Domain integrity

[NaiveSystem]
corrupted_addr accepted: True
✗ VIOLATED — invalid input entered execution

[ContinuumPort]
corrupted_addr accepted: False
✓ ENFORCED — invalid input never became admissible

Guaranteed properties

Every state transition is enforced against:

Property Guarantee
I1 — No unauthorized execution Authority gate cannot be bypassed
I2 — No out-of-domain execution Invalid input is structurally inadmissible
I3 — No invalid state transition Geometry constraints enforced before commit
I4 — No partial state escape Full rollback or full commit, nothing in between
I5 — Deterministic outcome Same input + same state = same result, always

If any invariant is violated, execution does not occur.


What the tests confirm

705 tests. 0 failures (reference implementation).

Including:

  • Concurrent execution under load
  • Replay attacks
  • State drift injection
  • Geometry swap attacks
  • Capability rebinding
  • Hash canonicalization attacks
  • Cross-cycle state traps
  • Authority enforcement under adversarial pressure

These are not unit tests. They are a closed adversarial threat model.

Test suite — 705 passing

image

What cannot happen under enforcement

  • Partial execution leaving residual state
  • Non-deterministic outcomes from identical inputs
  • Invalid input entering the execution domain
  • State corruption after failure
  • Authority bypass under concurrent load
  • Unauthorized state transitions

These outcomes are not detected. They are structurally unreachable.


Scope and limits

ContinuumPort enforces correctness of execution under declared constraints.

It does not guarantee:

  • Correctness of intent
  • Correctness of declared constraints
  • External side effects beyond the execution boundary

These limits are explicit and documented.


What this is

ContinuumPort is an execution control kernel for persistent systems.

It enforces that state transitions cannot violate declared invariants — across models, sessions, and environments.

Regen Engine is the enforcement layer. ContinuumPort is the protocol.

Execution is formally constrained:

Σ = (D, A, Auth)
execute(α) ⟺ authorize(G, α)

No state transition exists outside the authorization gate.


Where This Actually Matters

ContinuumPort is not a theoretical construct.

It is required wherever incorrect execution produces irreversible consequences.

Invalid execution is not rejected. It is unreachable.

→ See: Where Regen Engine Belongs

Concrete domains where structural execution control is not optional:

  • autonomous systems — no recovery from invalid execution at speed
  • agentic AI — prevents long-term state corruption
  • industrial / medical systems — no partial failure tolerance
  • neural interfaces — no safe fallback once execution commits

If your system can tolerate incorrect execution, you do not need this.

If it cannot, you already do.


Compliance interface

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: ...

Repository structure

regen-engine/     — execution kernel (Python)
compliance/       — invariant validation suite
quickstart/       — runnable demos
docs/             — formal specification
spec/             — model and properties
normative/        — canonical definitions

Further reading


Contact

If your system executes, test it.

access@continuumport.com


CP-Core Regen Engine Status

Gh. Rotaru (Giorgio Roth) — Independent researcher, 2026

About

ContinuumPort: A Structural Framework for Persistence, Governance, and Continuity. Open-source + Proprietary Regen engine.

Topics

Resources

License

Contributing

Stars

Watchers

Forks

Packages

 
 
 

Contributors

Languages