E2C stage boundary — legacy design-partner path and current Core OS release path

How the older 0.1 / 0.5 / 1.0 model relates to the current Core E2C OS commercial path.

Narrative update — July 2026. This page preserves the legacy 0.1 / 0.5 / 1.0 design-partner staging model. The current investor-facing release model has been updated: Commercial v0.1 is now defined as the first Core E2C OS product-level runtime scaffold — not a traditional proof slice and not a SaaS workspace. Design-partner 1.0 remains relevant, but it is downstream of multiple Core OS micro-releases.

Current commercial path

Core E2C OS runtime scaffold — E2C boots, owns state, consumes structured candidate intake, dispatches admitted capabilities, routes ledger / feedback / resume, and micro-releases itself.
Capability absorption / micro-release loop — Each high-value capability becomes valuable only after operational integration, first real consumption, invocation record, and system micro-release.
Controlled design-partner Responsibility OS — After Core OS compounds, selected design partners can run bounded intake, source-bounded projection, cost-visible transitions, and release / hold / block handoff packages.

Core E2C OS runtime release →

Legacy: E2C 0.1 — Private Alpha proof slice

Historically described as demonstrating one bounded AI-native project through artifacts, ledger, validation / authorization, and release / hold / block readiness. Retained for comprehension; current framing prefers Core OS runtime scaffold.

Legacy: E2C 0.5 — Controlled design-partner slice

Bounded onboarding
Limited domain scope
Manual support and guided artifact intake
Controlled run modes

Legacy / downstream: E2C 1.0 — Design-partner deployable commercial release

Downstream of Core OS micro-releases. Intended to support bounded project onboarding, source-bounded artifact construction, cost-visible runs, and handoff packages — still not unrestricted public SaaS or a replacement for customer release authority.

← Back to Documentation · Product path