Cognous Execution Runtime | Open Control Stack | Cognous
Open Control Stack/ Components/ Component 06 Group 04 · Constrained Execution

Cognous Execution Runtime

On the supported path, execute only the exact authorized operation.

The stack’s single-agent constrained execution boundary. Its Python execution layer (engine/) supplies the bounded synthetic destination and adapter boundary. It is a hardened derivative of Moltbot; the upstream TypeScript Moltbot application in the same repository is outside the reviewed boundary.

View repository All components
The problem
Authorization and execution drift apart

Between an allow decision and the effect, a payload can change, a count can grow, or a caller can claim an institution it does not represent.

With Execution Runtime
A frozen operation bound to one effect

The complete operation is snapshotted at entry; validation and execution use only that snapshot, and effect identity is bound to its digest.

What it provides
Execution Envelope 0.2.0

a deep snapshot of the operation taken before any resolver or Control Plane callback runs.

Strict refund rules

exactly one effect, a finite non-negative amount and a payload commitment that must match.

Trusted institution binding

institution and domain taken from the trusted resolver, never from a caller’s label.

Durable attempts

immutable attempt identities with append-only events; a reused attempt ID is rejected and never overwrites a success.

Producer profile 2.0.0

versioned export of envelopes, results, effects, attempts and observations for reconstruction.

In the refund workflow

The Control Plane’s revalidating workflow calls the refund adapter, which applies strict local execution policy, writes a durable synthetic SQLite refund and supports destination observation and reconciliation. SQLite serialization handles same-effect deduplication across separate processes sharing one database file.

Try it

Run the substitution cases (changed payload, target or adapter) and confirm each produces no effect. Then submit two different proposals for the same refund: both execute on the default path, and only one under the optional refund-intent profile.

Open the repository →
Known limit, shown explicitly: effect id is not business intent

Deliver the same $250 refund proposal twice and both deliveries carry the same effect_id: one refund. Submit a second, different valid proposal for the same customer refund and it gets a new effect_id: both can execute, producing two refunds. The selected runtime now includes refund-intent ownership (executor PR #14): run as a separate optional profile, it keeps one effect for two proposals of the same intent. The default release path does not enable it.

What it does not claim

Application-level restrictions, not OS confinement: a sufficiently privileged host process can bypass the package. A SQLite synthetic destination only, with no real accounts, payment services or production credentials. Live OpenShell confinement is unqualified.