Diagnostic mode
A lower-depth run for exposing major responsibility gaps. Best for first evaluation, release uncertainty, and triage.
E2C is not an unlimited autonomous run. Every meaningful engagement must be bounded by scope, expected depth, artifact trail, and authorization checkpoints.
A lower-depth run for exposing major responsibility gaps. Best for first evaluation, release uncertainty, and triage.
A bounded responsibility artifact chain with state ledger, source boundaries, and release / hold / block readiness output. Best for design partner pilots.
A higher-depth run that may include replay, validation, authorization review, and deeper artifact graph construction. Best for release-critical or high-responsibility systems.
Before a run begins, E2C should define:
If a run exposes new responsibility gaps, exceeds expected depth, or requires additional evidence, E2C may stop, hold, block, or request explicit authorization before continuing.
Commercial v0.1 boundary. The first commercial E2C release may not expose all run modes through a public UI. The initial release focuses on Core OS runtime capability: boot, state load, structured intake, responsibility cycle, capability dispatch, ledger / feedback / resume routing, and micro-release. Design-partner run modes are introduced through controlled application responsibility chains after Core OS capability absorption.
E2C does not spend tokens only to generate one-time answers. The goal is to convert compute into reusable responsibility assets: source boundaries, responsibility units, runtime tools, validation paths, negative cases, replay evidence, release / hold / block precedents, and operationally absorbed capabilities. When a high-value capability is absorbed into Core E2C OS, it becomes a micro-release and is recursively available for future runs.