Skip to content

Developers

E2C is for teams building AI-native systems — not only model prompts. You integrate with a Responsibility Operating System where candidates become evidence, evidence becomes state, and state becomes release / hold / block readiness with a ledger trail.

Execution OS vs Responsibility OS

  • Coding environments help AI modify code (Codex-like, Claude Code-like).
  • Agent runtimes help AI execute workflows.
  • E2C admits and runs responsibility state into reality.

Claude Code, Codex, and similar tools are bounded implementation workers inside an E2C deployment — not the responsibility authority. They may start a runner or generate candidates. They cannot be runtime, ledger, resume, release, or dispatch authority.

Execution OS vs Responsibility OS →

GPT explores. E2C runs responsibility.

GPT, OpenAI, Claude, Cursor, and coding agents can provide candidate slots, candidate contracts, semantic projections, bounded explanations, and implementation candidates. They are not E2C authority.

E2C owns:

  • State and source
  • Runtime and dispatch
  • Ledger, feedback, and resume
  • Release / hold / block

Models propose. E2C admits and runs state.

Mental model

E2C does not control model generation. It adjudicates whether generated outputs may enter the responsibility state space and trigger permitted transitions — and runs the product-level runtime that makes those transitions mechanical. Think: candidate → evidence → adjudication → state → permitted action — not “make the model deterministic.”

Product-level runtime hierarchy

A commercial E2C run has three runtime levels:

  • Product-level loop — From structured intake to release / hold / block / replan.
  • Local transition loop — One product-state segment, possibly containing multiple atomic responsibility runs.
  • Atomic responsibility run — One minimal responsibility task plus mechanical byproduct dispatch.

E2C is domain-flexible, but responsibility-protocol rigid. Runtime hierarchy →

How E2C is evaluated

E2C is not evaluated by whether the model sounds right. It is evaluated by whether the system reduces:

  • False admission — state enters reality without sufficient evidence
  • Source-boundary error — artifacts detached from admissible sources
  • Field pollution — undeclared or cross-domain field leakage
  • Chain ownership ambiguity — unclear who authorized a transition
  • Unauthorized next action — agents act outside permitted transitions
  • Untraceable release decisions — release without artifact trail

Integration surfaces

  • Structured candidate intake
  • Source-bounded state projection
  • Runtime tool baseline
  • Product-level runtime harness
  • Operational capability registry
  • Invocation records
  • JSON + FPC pair emission
  • Ledger / feedback / resume routing
  • Application responsibility chains

Documentation

Start with the documentation hub — Core OS runtime release, three operating states, micro-release loop, and release semantics.

Private Alpha

Early engineering partners work toward Core OS capability absorption and controlled application responsibility chains — with release / hold / block readiness outputs and auditable artifacts. Request access on Support.