THE WORKMACHINE / RELEASE JOURNEY
R3 is live.
R4. A new generation begins.
A model-agnostic WorkMachine pairs your chosen compatible LLM with the UBIKITOS harness. Follow the architecture from useful work to persistent, traceable memory.
Status reviewed 11 October 2026: R3 is live, including R3.9. R4.17 remains the latest numbered checkpoint. Development now focuses on native integration, signed authorization, guarded results and recovery. Independent review and formal acceptance remain open.
CURRENT DEVELOPMENT FRONTIER
From components to a complete route.
R4.17 is the engineering baseline. Integration work now connects that control plane to the actual task loop. These milestones are integration stages, not newly numbered releases.
Guarded execution and result recovery＋
Local integration checks cover queued effects, output intake and current authorization before fresh or cached results enter validation, episode capture, learning and persistence. Recovery preserves existing custody instead of replaying an effect to obtain a new result.
Signed, bounded canary＋
The prepared metadata canary binds exact actor, request and scope, with one tool call, zero model cost and a sixty-second ceiling. Signed authorization and signer preparation are locally checked; they do not establish native activation.
Native identity and route preparation＋
The owner-reported 8 October route preflight reached key enrollment without execution grants. Identity enrollment is separate from permission to act. Complete native owner mappings, an exact authorized operation and retained execution receipts are still needed to demonstrate the route.
The gates before R5＋
Complete native route validation, normal and failure-recovery trials, remaining roadmap integration gates, independent review and formal acceptance. R4 remains in development; R5 has not been opened in the reviewed evidence.
Pre-RDefine the right task10 chapters ＋
Define the right task
Historical foundation
Define the right task
Preserve human intent, expose assumptions and turn an ambiguous request into a bounded task. Ten canonical design chapters carry the objective from raw intent to the R1 handoff.
PRE-R.0Raw Intent CaptureOpen explanation ＋
Canonical design chapter
Raw Intent Capture
raw request preservation, intent IDs, provenance. Acceptance gate: original human expression is never lost.
Requirements
PRE-R.0 · 1Raw request preservationRead explanation ＋
Design requirement
Raw request preservation
Raw Intent Capture includes raw request preservation. Acceptance gate: original human expression is never lost.
PRE-R.0 · 2Intent IDsRead explanation ＋
Design requirement
Intent IDs
Raw Intent Capture includes intent IDs. Acceptance gate: original human expression is never lost.
PRE-R.0 · 3ProvenanceRead explanation ＋
Design requirement
Provenance
Raw Intent Capture includes provenance. Acceptance gate: original human expression is never lost.
PRE-R.1Context ResolverOpen explanation ＋
Canonical design chapter
Context Resolver
relevant context collection, context typing, source precedence. Acceptance gate: explicit and inferred context remain distinguishable.
Requirements
PRE-R.1 · 1Relevant context collectionRead explanation ＋
Design requirement
Relevant context collection
Context Resolver includes relevant context collection. Acceptance gate: explicit and inferred context remain distinguishable.
PRE-R.1 · 2Context typingRead explanation ＋
Design requirement
Context typing
Context Resolver includes context typing. Acceptance gate: explicit and inferred context remain distinguishable.
PRE-R.1 · 3Source precedenceRead explanation ＋
Design requirement
Source precedence
Context Resolver includes source precedence. Acceptance gate: explicit and inferred context remain distinguishable.
PRE-R.2Intent ParserOpen explanation ＋
Canonical design chapter
Intent Parser
objective extraction, constraints, preferences, negative requirements, authority. Acceptance gate: material instruction components are represented.
Requirements
PRE-R.2 · 1Objective extractionRead explanation ＋
Design requirement
Objective extraction
Intent Parser includes objective extraction. Acceptance gate: material instruction components are represented.
PRE-R.2 · 2ConstraintsRead explanation ＋
Design requirement
Constraints
Intent Parser includes constraints. Acceptance gate: material instruction components are represented.
PRE-R.2 · 3PreferencesRead explanation ＋
Design requirement
Preferences
Intent Parser includes preferences. Acceptance gate: material instruction components are represented.
PRE-R.2 · 4Negative requirementsRead explanation ＋
Design requirement
Negative requirements
Intent Parser includes negative requirements. Acceptance gate: material instruction components are represented.
PRE-R.2 · 5AuthorityRead explanation ＋
Design requirement
Authority
Intent Parser includes authority. Acceptance gate: material instruction components are represented.
PRE-R.3Assumption & Unknown LedgerOpen explanation ＋
Canonical design chapter
Assumption & Unknown Ledger
assumptions, confidence, unknown classification, consequence analysis. Acceptance gate: hidden assumptions become visible.
Requirements
PRE-R.3 · 1AssumptionsRead explanation ＋
Design requirement
Assumptions
Assumption & Unknown Ledger includes assumptions. Acceptance gate: hidden assumptions become visible.
PRE-R.3 · 2ConfidenceRead explanation ＋
Design requirement
Confidence
Assumption & Unknown Ledger includes confidence. Acceptance gate: hidden assumptions become visible.
PRE-R.3 · 3Unknown classificationRead explanation ＋
Design requirement
Unknown classification
Assumption & Unknown Ledger includes unknown classification. Acceptance gate: hidden assumptions become visible.
PRE-R.3 · 4Consequence analysisRead explanation ＋
Design requirement
Consequence analysis
Assumption & Unknown Ledger includes consequence analysis. Acceptance gate: hidden assumptions become visible.
PRE-R.4Clarification EngineOpen explanation ＋
Canonical design chapter
Clarification Engine
ambiguity detection, Value of Information, consequence-aware clarification. Acceptance gate: ask when necessary, proceed when safely obvious.
Requirements
PRE-R.4 · 1Ambiguity detectionRead explanation ＋
Design requirement
Ambiguity detection
Clarification Engine includes ambiguity detection. Acceptance gate: ask when necessary, proceed when safely obvious.
PRE-R.4 · 2Value of InformationRead explanation ＋
Design requirement
Value of Information
Clarification Engine includes Value of Information. Acceptance gate: ask when necessary, proceed when safely obvious.
PRE-R.4 · 3Consequence-aware clarificationRead explanation ＋
Design requirement
Consequence-aware clarification
Clarification Engine includes consequence-aware clarification. Acceptance gate: ask when necessary, proceed when safely obvious.
PRE-R.5Goal & Metric CompilerOpen explanation ＋
Canonical design chapter
Goal & Metric Compiler
primary/secondary goals, hard/soft constraints, success predicates, proxy warnings, stop conditions. Acceptance gate: goal and proxy are distinct.
Requirements
PRE-R.5 · 1Primary/secondary goalsRead explanation ＋
Design requirement
Primary/secondary goals
Goal & Metric Compiler includes primary/secondary goals. Acceptance gate: goal and proxy are distinct.
PRE-R.5 · 2Hard/soft constraintsRead explanation ＋
Design requirement
Hard/soft constraints
Goal & Metric Compiler includes hard/soft constraints. Acceptance gate: goal and proxy are distinct.
PRE-R.5 · 3Success predicatesRead explanation ＋
Design requirement
Success predicates
Goal & Metric Compiler includes success predicates. Acceptance gate: goal and proxy are distinct.
PRE-R.5 · 4Proxy warningsRead explanation ＋
Design requirement
Proxy warnings
Goal & Metric Compiler includes proxy warnings. Acceptance gate: goal and proxy are distinct.
PRE-R.5 · 5Stop conditionsRead explanation ＋
Design requirement
Stop conditions
Goal & Metric Compiler includes stop conditions. Acceptance gate: goal and proxy are distinct.
PRE-R.6Problem DecomposerOpen explanation ＋
Canonical design chapter
Problem Decomposer
bounded task decomposition, dependency DAG, parent-intent traceability. Acceptance gate: every child task maps back to the parent objective.
Requirements
PRE-R.6 · 1Bounded task decompositionRead explanation ＋
Design requirement
Bounded task decomposition
Problem Decomposer includes bounded task decomposition. Acceptance gate: every child task maps back to the parent objective.
PRE-R.6 · 2Dependency DAGRead explanation ＋
Design requirement
Dependency DAG
Problem Decomposer includes dependency DAG. Acceptance gate: every child task maps back to the parent objective.
PRE-R.6 · 3Parent-intent traceabilityRead explanation ＋
Design requirement
Parent-intent traceability
Problem Decomposer includes parent-intent traceability. Acceptance gate: every child task maps back to the parent objective.
PRE-R.7Adversarial Specification ReviewOpen explanation ＋
Canonical design chapter
Adversarial Specification Review
specification-gaming search, counterexample generation, contradiction detection. Acceptance gate: obvious technically-valid-but-wrong solutions are rejected.
Requirements
PRE-R.7 · 1Specification-gaming searchRead explanation ＋
Design requirement
Specification-gaming search
Adversarial Specification Review includes specification-gaming search. Acceptance gate: obvious technically-valid-but-wrong solutions are rejected.
PRE-R.7 · 2Counterexample generationRead explanation ＋
Design requirement
Counterexample generation
Adversarial Specification Review includes counterexample generation. Acceptance gate: obvious technically-valid-but-wrong solutions are rejected.
PRE-R.7 · 3Contradiction detectionRead explanation ＋
Design requirement
Contradiction detection
Adversarial Specification Review includes contradiction detection. Acceptance gate: obvious technically-valid-but-wrong solutions are rejected.
PRE-R.8Admission EngineOpen explanation ＋
Canonical design chapter
Admission Engine
consequence classification, completeness requirements, R1 admission status. Acceptance gate: only admissible tasks enter R1.
Requirements
PRE-R.8 · 1Consequence classificationRead explanation ＋
Design requirement
Consequence classification
Admission Engine includes consequence classification. Acceptance gate: only admissible tasks enter R1.
PRE-R.8 · 2Completeness requirementsRead explanation ＋
Design requirement
Completeness requirements
Admission Engine includes completeness requirements. Acceptance gate: only admissible tasks enter R1.
PRE-R.8 · 3R1 admission statusRead explanation ＋
Design requirement
R1 admission status
Admission Engine includes R1 admission status. Acceptance gate: only admissible tasks enter R1.
PRE-R.9R1 HandoffOpen explanation ＋
Canonical design chapter
R1 Handoff
Intent Contract → Task Contract compiler, intent receipt, traceability. Acceptance gate: R1 receives a bounded task with explicit provenance to human intent.
Requirements
PRE-R.9 · 1Intent Contract → Task Contract compilerRead explanation ＋
Design requirement
Intent Contract → Task Contract compiler
R1 Handoff includes Intent Contract → Task Contract compiler. Acceptance gate: R1 receives a bounded task with explicit provenance to human intent.
PRE-R.9 · 2Intent receiptRead explanation ＋
Design requirement
Intent receipt
R1 Handoff includes intent receipt. Acceptance gate: R1 receives a bounded task with explicit provenance to human intent.
PRE-R.9 · 3TraceabilityRead explanation ＋
Design requirement
Traceability
R1 Handoff includes traceability. Acceptance gate: R1 receives a bounded task with explicit provenance to human intent.
R1Execute useful work10 chapters ＋
Execute useful work
Historical foundation
Execute useful work
Run a bounded task with typed tools, explicit budgets, validation and reproducible evidence. These ten chapters come from the canonical DO engineering specification.
R1.0Task Contract FoundationOpen explanation ＋
Canonical design chapter
Task Contract Foundation
task schema, preconditions, postconditions, task IDs, task versions. Acceptance gate: invalid tasks fail before execution.
Requirements
R1.0 · 1Task schemaRead explanation ＋
Design requirement
Task schema
Task Contract Foundation includes task schema. Acceptance gate: invalid tasks fail before execution.
R1.0 · 2PreconditionsRead explanation ＋
Design requirement
Preconditions
Task Contract Foundation includes preconditions. Acceptance gate: invalid tasks fail before execution.
R1.0 · 3PostconditionsRead explanation ＋
Design requirement
Postconditions
Task Contract Foundation includes postconditions. Acceptance gate: invalid tasks fail before execution.
R1.0 · 4Task IDsRead explanation ＋
Design requirement
Task IDs
Task Contract Foundation includes task IDs. Acceptance gate: invalid tasks fail before execution.
R1.0 · 5Task versionsRead explanation ＋
Design requirement
Task versions
Task Contract Foundation includes task versions. Acceptance gate: invalid tasks fail before execution.
R1.1Work Machine RuntimeOpen explanation ＋
Canonical design chapter
Work Machine Runtime
executor, lifecycle state machine, planner/dispatcher, terminal status. Acceptance gate: bounded task runs end in explicit terminal states.
Requirements
R1.1 · 1ExecutorRead explanation ＋
Design requirement
Executor
Work Machine Runtime includes executor. Acceptance gate: bounded task runs end in explicit terminal states.
R1.1 · 2Lifecycle state machineRead explanation ＋
Design requirement
Lifecycle state machine
Work Machine Runtime includes lifecycle state machine. Acceptance gate: bounded task runs end in explicit terminal states.
R1.1 · 3Planner/dispatcherRead explanation ＋
Design requirement
Planner/dispatcher
Work Machine Runtime includes planner/dispatcher. Acceptance gate: bounded task runs end in explicit terminal states.
R1.1 · 4Terminal statusRead explanation ＋
Design requirement
Terminal status
Work Machine Runtime includes terminal status. Acceptance gate: bounded task runs end in explicit terminal states.
R1.2Tool Contract LayerOpen explanation ＋
Canonical design chapter
Tool Contract Layer
typed tool adapters, timeouts, error normalization, permission metadata. Acceptance gate: tool failure cannot silently become success.
Requirements
R1.2 · 1Typed tool adaptersRead explanation ＋
Design requirement
Typed tool adapters
Tool Contract Layer includes typed tool adapters. Acceptance gate: tool failure cannot silently become success.
R1.2 · 2TimeoutsRead explanation ＋
Design requirement
Timeouts
Tool Contract Layer includes timeouts. Acceptance gate: tool failure cannot silently become success.
R1.2 · 3Error normalizationRead explanation ＋
Design requirement
Error normalization
Tool Contract Layer includes error normalization. Acceptance gate: tool failure cannot silently become success.
R1.2 · 4Permission metadataRead explanation ＋
Design requirement
Permission metadata
Tool Contract Layer includes permission metadata. Acceptance gate: tool failure cannot silently become success.
R1.3Identity & ProvenanceOpen explanation ＋
Canonical design chapter
Identity & Provenance
run IDs, runtime identity, hashes, artifact lineage, receipts. Acceptance gate: every terminal run can be reconstructed from evidence.
Requirements
R1.3 · 1Run IDsRead explanation ＋
Design requirement
Run IDs
Identity & Provenance includes run IDs. Acceptance gate: every terminal run can be reconstructed from evidence.
R1.3 · 2Runtime identityRead explanation ＋
Design requirement
Runtime identity
Identity & Provenance includes runtime identity. Acceptance gate: every terminal run can be reconstructed from evidence.
R1.3 · 3HashesRead explanation ＋
Design requirement
Hashes
Identity & Provenance includes hashes. Acceptance gate: every terminal run can be reconstructed from evidence.
R1.3 · 4Artifact lineageRead explanation ＋
Design requirement
Artifact lineage
Identity & Provenance includes artifact lineage. Acceptance gate: every terminal run can be reconstructed from evidence.
R1.3 · 5ReceiptsRead explanation ＋
Design requirement
Receipts
Identity & Provenance includes receipts. Acceptance gate: every terminal run can be reconstructed from evidence.
R1.4ValidationOpen explanation ＋
Canonical design chapter
Validation
input validators, result validators, postcondition engine. Acceptance gate: self-reported completion cannot create SUCCEEDED state.
Requirements
R1.4 · 1Input validatorsRead explanation ＋
Design requirement
Input validators
Validation includes input validators. Acceptance gate: self-reported completion cannot create SUCCEEDED state.
R1.4 · 2Result validatorsRead explanation ＋
Design requirement
Result validators
Validation includes result validators. Acceptance gate: self-reported completion cannot create SUCCEEDED state.
R1.4 · 3Postcondition engineRead explanation ＋
Design requirement
Postcondition engine
Validation includes postcondition engine. Acceptance gate: self-reported completion cannot create SUCCEEDED state.
R1.5Resource GovernanceOpen explanation ＋
Canonical design chapter
Resource Governance
runtime budgets, cost budgets, tool-call caps, retry caps. Acceptance gate: hard budget violations fail closed.
Requirements
R1.5 · 1Runtime budgetsRead explanation ＋
Design requirement
Runtime budgets
Resource Governance includes runtime budgets. Acceptance gate: hard budget violations fail closed.
R1.5 · 2Cost budgetsRead explanation ＋
Design requirement
Cost budgets
Resource Governance includes cost budgets. Acceptance gate: hard budget violations fail closed.
R1.5 · 3Tool-call capsRead explanation ＋
Design requirement
Tool-call caps
Resource Governance includes tool-call caps. Acceptance gate: hard budget violations fail closed.
R1.5 · 4Retry capsRead explanation ＋
Design requirement
Retry caps
Resource Governance includes retry caps. Acceptance gate: hard budget violations fail closed.
R1.6Failure SemanticsOpen explanation ＋
Canonical design chapter
Failure Semantics
normalized failure taxonomy, retry policy, failure receipts. Acceptance gate: injected faults produce correct classifications.
Requirements
R1.6 · 1Normalized failure taxonomyRead explanation ＋
Design requirement
Normalized failure taxonomy
Failure Semantics includes normalized failure taxonomy. Acceptance gate: injected faults produce correct classifications.
R1.6 · 2Retry policyRead explanation ＋
Design requirement
Retry policy
Failure Semantics includes retry policy. Acceptance gate: injected faults produce correct classifications.
R1.6 · 3Failure receiptsRead explanation ＋
Design requirement
Failure receipts
Failure Semantics includes failure receipts. Acceptance gate: injected faults produce correct classifications.
R1.7ReproducibilityOpen explanation ＋
Canonical design chapter
Reproducibility
environment fingerprinting, replay harness, deterministic/statistical reproducibility metrics. Acceptance gate: benchmark runs reproduce within declared tolerance.
Requirements
R1.7 · 1Environment fingerprintingRead explanation ＋
Design requirement
Environment fingerprinting
Reproducibility includes environment fingerprinting. Acceptance gate: benchmark runs reproduce within declared tolerance.
R1.7 · 2Replay harnessRead explanation ＋
Design requirement
Replay harness
Reproducibility includes replay harness. Acceptance gate: benchmark runs reproduce within declared tolerance.
R1.7 · 3Deterministic/statistical reproducibility metricsRead explanation ＋
Design requirement
Deterministic/statistical reproducibility metrics
Reproducibility includes deterministic/statistical reproducibility metrics. Acceptance gate: benchmark runs reproduce within declared tolerance.
R1.8Benchmark & CertificationOpen explanation ＋
Canonical design chapter
Benchmark & Certification
benchmark families, adversarial cases, certification panel, frozen evidence bundle. Acceptance gate: all P0 invariants pass and reliability thresholds are met.
Requirements
R1.8 · 1Benchmark familiesRead explanation ＋
Design requirement
Benchmark families
Benchmark & Certification includes benchmark families. Acceptance gate: all P0 invariants pass and reliability thresholds are met.
R1.8 · 2Adversarial casesRead explanation ＋
Design requirement
Adversarial cases
Benchmark & Certification includes adversarial cases. Acceptance gate: all P0 invariants pass and reliability thresholds are met.
R1.8 · 3Certification panelRead explanation ＋
Design requirement
Certification panel
Benchmark & Certification includes certification panel. Acceptance gate: all P0 invariants pass and reliability thresholds are met.
R1.8 · 4Frozen evidence bundleRead explanation ＋
Design requirement
Frozen evidence bundle
Benchmark & Certification includes frozen evidence bundle. Acceptance gate: all P0 invariants pass and reliability thresholds are met.
R1.9R2 HandoffOpen explanation ＋
Canonical design chapter
R2 Handoff
clean action interface, outcome-event schema, external-action extension points. Acceptance gate: R2 can add consequential action without rewriting R1's execution semantics.
Requirements
R1.9 · 1Clean action interfaceRead explanation ＋
Design requirement
Clean action interface
R2 Handoff includes clean action interface. Acceptance gate: R2 can add consequential action without rewriting R1's execution semantics.
R1.9 · 2Outcome-event schemaRead explanation ＋
Design requirement
Outcome-event schema
R2 Handoff includes outcome-event schema. Acceptance gate: R2 can add consequential action without rewriting R1's execution semantics.
R1.9 · 3External-action extension pointsRead explanation ＋
Design requirement
External-action extension points
R2 Handoff includes external-action extension points. Acceptance gate: R2 can add consequential action without rewriting R1's execution semantics.
R2Act, then compare10 chapters ＋
Act, then compare
Historical foundation
Act, then compare
Make consequential actions externally verifiable. The ACT specification supplies these ten engineering chapters; the later master roadmap also frames R2 around reproducible comparison between approaches.
R2.0External Sink FoundationOpen explanation ＋
Canonical design chapter
External Sink Foundation
sink registry, typed sink contracts, environment identity, account binding. Acceptance gate: every consequential action has a declared sink identity.
Requirements
R2.0 · 1Sink registryRead explanation ＋
Design requirement
Sink registry
External Sink Foundation includes sink registry. Acceptance gate: every consequential action has a declared sink identity.
R2.0 · 2Typed sink contractsRead explanation ＋
Design requirement
Typed sink contracts
External Sink Foundation includes typed sink contracts. Acceptance gate: every consequential action has a declared sink identity.
R2.0 · 3Environment identityRead explanation ＋
Design requirement
Environment identity
External Sink Foundation includes environment identity. Acceptance gate: every consequential action has a declared sink identity.
R2.0 · 4Account bindingRead explanation ＋
Design requirement
Account binding
External Sink Foundation includes account binding. Acceptance gate: every consequential action has a declared sink identity.
R2.1Launch Identity & State CustodyOpen explanation ＋
Canonical design chapter
Launch Identity & State Custody
launch manifest, runtime identity verification, generation-bound state roots, explicit relaunch/resume semantics. Acceptance gate: declared experiment equals actual runtime.
Requirements
R2.1 · 1Launch manifestRead explanation ＋
Design requirement
Launch manifest
Launch Identity & State Custody includes launch manifest. Acceptance gate: declared experiment equals actual runtime.
R2.1 · 2Runtime identity verificationRead explanation ＋
Design requirement
Runtime identity verification
Launch Identity & State Custody includes runtime identity verification. Acceptance gate: declared experiment equals actual runtime.
R2.1 · 3Generation-bound state rootsRead explanation ＋
Design requirement
Generation-bound state roots
Launch Identity & State Custody includes generation-bound state roots. Acceptance gate: declared experiment equals actual runtime.
R2.1 · 4Explicit relaunch/resume semanticsRead explanation ＋
Design requirement
Explicit relaunch/resume semantics
Launch Identity & State Custody includes explicit relaunch/resume semantics. Acceptance gate: declared experiment equals actual runtime.
R2.2Action Contract & PreflightOpen explanation ＋
Canonical design chapter
Action Contract & Preflight
decision objects, action canonicalization, pre-action snapshots, authorization, idempotency keys. Acceptance gate: no action reaches sink without validated identity, authority, and preconditions.
Requirements
R2.2 · 1Decision objectsRead explanation ＋
Design requirement
Decision objects
Action Contract & Preflight includes decision objects. Acceptance gate: no action reaches sink without validated identity, authority, and preconditions.
R2.2 · 2Action canonicalizationRead explanation ＋
Design requirement
Action canonicalization
Action Contract & Preflight includes action canonicalization. Acceptance gate: no action reaches sink without validated identity, authority, and preconditions.
R2.2 · 3Pre-action snapshotsRead explanation ＋
Design requirement
Pre-action snapshots
Action Contract & Preflight includes pre-action snapshots. Acceptance gate: no action reaches sink without validated identity, authority, and preconditions.
R2.2 · 4AuthorizationRead explanation ＋
Design requirement
Authorization
Action Contract & Preflight includes authorization. Acceptance gate: no action reaches sink without validated identity, authority, and preconditions.
R2.2 · 5Idempotency keysRead explanation ＋
Design requirement
Idempotency keys
Action Contract & Preflight includes idempotency keys. Acceptance gate: no action reaches sink without validated identity, authority, and preconditions.
R2.3Execution SemanticsOpen explanation ＋
Canonical design chapter
Execution Semantics
submit/acknowledge/execute/settle states, partial execution, external IDs, time semantics. Acceptance gate: submission can never masquerade as execution.
Requirements
R2.3 · 1Submit/acknowledge/execute/settle statesRead explanation ＋
Design requirement
Submit/acknowledge/execute/settle states
Execution Semantics includes submit/acknowledge/execute/settle states. Acceptance gate: submission can never masquerade as execution.
R2.3 · 2Partial executionRead explanation ＋
Design requirement
Partial execution
Execution Semantics includes partial execution. Acceptance gate: submission can never masquerade as execution.
R2.3 · 3External IDsRead explanation ＋
Design requirement
External IDs
Execution Semantics includes external IDs. Acceptance gate: submission can never masquerade as execution.
R2.3 · 4Time semanticsRead explanation ＋
Design requirement
Time semantics
Execution Semantics includes time semantics. Acceptance gate: submission can never masquerade as execution.
R2.4ReconciliationOpen explanation ＋
Canonical design chapter
Reconciliation
authoritative external queries, local/external state comparison, unknown execution handling, duplicate prevention. Acceptance gate: timeout and crash scenarios reconcile safely.
Requirements
R2.4 · 1Authoritative external queriesRead explanation ＋
Design requirement
Authoritative external queries
Reconciliation includes authoritative external queries. Acceptance gate: timeout and crash scenarios reconcile safely.
R2.4 · 2Local/external state comparisonRead explanation ＋
Design requirement
Local/external state comparison
Reconciliation includes local/external state comparison. Acceptance gate: timeout and crash scenarios reconcile safely.
R2.4 · 3Unknown execution handlingRead explanation ＋
Design requirement
Unknown execution handling
Reconciliation includes unknown execution handling. Acceptance gate: timeout and crash scenarios reconcile safely.
R2.4 · 4Duplicate preventionRead explanation ＋
Design requirement
Duplicate prevention
Reconciliation includes duplicate prevention. Acceptance gate: timeout and crash scenarios reconcile safely.
R2.5Outcome CustodyOpen explanation ＋
Canonical design chapter
Outcome Custody
post-state snapshots, outcome schema, horizons, measurement provenance. Acceptance gate: executed actions can be linked to measured consequences.
Requirements
R2.5 · 1Post-state snapshotsRead explanation ＋
Design requirement
Post-state snapshots
Outcome Custody includes post-state snapshots. Acceptance gate: executed actions can be linked to measured consequences.
R2.5 · 2Outcome schemaRead explanation ＋
Design requirement
Outcome schema
Outcome Custody includes outcome schema. Acceptance gate: executed actions can be linked to measured consequences.
R2.5 · 3HorizonsRead explanation ＋
Design requirement
Horizons
Outcome Custody includes horizons. Acceptance gate: executed actions can be linked to measured consequences.
R2.5 · 4Measurement provenanceRead explanation ＋
Design requirement
Measurement provenance
Outcome Custody includes measurement provenance. Acceptance gate: executed actions can be linked to measured consequences.
R2.6Liveness & HealthOpen explanation ＋
Canonical design chapter
Liveness & Health
process-derived liveness, worker heartbeat, sink health, mission health vector. Acceptance gate: dead/invalid missions cannot report healthy.
Requirements
R2.6 · 1Process-derived livenessRead explanation ＋
Design requirement
Process-derived liveness
Liveness & Health includes process-derived liveness. Acceptance gate: dead/invalid missions cannot report healthy.
R2.6 · 2Worker heartbeatRead explanation ＋
Design requirement
Worker heartbeat
Liveness & Health includes worker heartbeat. Acceptance gate: dead/invalid missions cannot report healthy.
R2.6 · 3Sink healthRead explanation ＋
Design requirement
Sink health
Liveness & Health includes sink health. Acceptance gate: dead/invalid missions cannot report healthy.
R2.6 · 4Mission health vectorRead explanation ＋
Design requirement
Mission health vector
Liveness & Health includes mission health vector. Acceptance gate: dead/invalid missions cannot report healthy.
R2.7Safety & Circuit BreakersOpen explanation ＋
Canonical design chapter
Safety & Circuit Breakers
action limits, kill switch, environment locks, abnormal-state suspension. Acceptance gate: unsafe conditions halt new consequential actions.
Requirements
R2.7 · 1Action limitsRead explanation ＋
Design requirement
Action limits
Safety & Circuit Breakers includes action limits. Acceptance gate: unsafe conditions halt new consequential actions.
R2.7 · 2Kill switchRead explanation ＋
Design requirement
Kill switch
Safety & Circuit Breakers includes kill switch. Acceptance gate: unsafe conditions halt new consequential actions.
R2.7 · 3Environment locksRead explanation ＋
Design requirement
Environment locks
Safety & Circuit Breakers includes environment locks. Acceptance gate: unsafe conditions halt new consequential actions.
R2.7 · 4Abnormal-state suspensionRead explanation ＋
Design requirement
Abnormal-state suspension
Safety & Circuit Breakers includes abnormal-state suspension. Acceptance gate: unsafe conditions halt new consequential actions.
R2.8Fault & Adversarial HarnessOpen explanation ＋
Canonical design chapter
Fault & Adversarial Harness
network faults, partial actions, stale state, identity mismatch, wrong environment, crash/restart. Acceptance gate: no injected fault creates false clean success.
Requirements
R2.8 · 1Network faultsRead explanation ＋
Design requirement
Network faults
Fault & Adversarial Harness includes network faults. Acceptance gate: no injected fault creates false clean success.
R2.8 · 2Partial actionsRead explanation ＋
Design requirement
Partial actions
Fault & Adversarial Harness includes partial actions. Acceptance gate: no injected fault creates false clean success.
R2.8 · 3Stale stateRead explanation ＋
Design requirement
Stale state
Fault & Adversarial Harness includes stale state. Acceptance gate: no injected fault creates false clean success.
R2.8 · 4Identity mismatchRead explanation ＋
Design requirement
Identity mismatch
Fault & Adversarial Harness includes identity mismatch. Acceptance gate: no injected fault creates false clean success.
R2.8 · 5Wrong environmentRead explanation ＋
Design requirement
Wrong environment
Fault & Adversarial Harness includes wrong environment. Acceptance gate: no injected fault creates false clean success.
R2.8 · 6Crash/restartRead explanation ＋
Design requirement
Crash/restart
Fault & Adversarial Harness includes crash/restart. Acceptance gate: no injected fault creates false clean success.
R2.9Certification & R3 HandoffOpen explanation ＋
Canonical design chapter
Certification & R3 Handoff
experience objects, action/outcome evidence bundles, certification panel, R3 ingestion contract. Acceptance gate: R3 can consume trustworthy action episodes without reconstructing them from prose.
Requirements
R2.9 · 1Experience objectsRead explanation ＋
Design requirement
Experience objects
Certification & R3 Handoff includes experience objects. Acceptance gate: R3 can consume trustworthy action episodes without reconstructing them from prose.
R2.9 · 2Action/outcome evidence bundlesRead explanation ＋
Design requirement
Action/outcome evidence bundles
Certification & R3 Handoff includes action/outcome evidence bundles. Acceptance gate: R3 can consume trustworthy action episodes without reconstructing them from prose.
R2.9 · 3Certification panelRead explanation ＋
Design requirement
Certification panel
Certification & R3 Handoff includes certification panel. Acceptance gate: R3 can consume trustworthy action episodes without reconstructing them from prose.
R2.9 · 4R3 ingestion contractRead explanation ＋
Design requirement
R3 ingestion contract
Certification & R3 Handoff includes R3 ingestion contract. Acceptance gate: R3 can consume trustworthy action episodes without reconstructing them from prose.
R3Evidence-Bearing Work10 chapters ＋
Evidence-Bearing Work
Live generation
Evidence-Bearing Work
What happened, and what evidence supports it? R3 makes work reconstructable through episodes, action logs, tool receipts, provenance, outcome capture and custody. R3 is the live generation.
R3.0Experience ContractOpen explanation ＋
Canonical design chapter
Experience Contract
Give experience a typed input and output contract, explicit state ownership, telemetry and an independently checkable certification gate.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R3.1Institutional Knowledge StoreOpen explanation ＋
Canonical design chapter
Institutional Knowledge Store
Retain institutional knowledge with authoritative identity and evidence, preserving uncertainty and negative results for later use.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R3.2Belief & Thesis LayerOpen explanation ＋
Canonical design chapter
Belief & Thesis Layer
Represent beliefs and theses as inspectable objects with provenance, uncertainty and explicit checks against stale or contradictory evidence.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R3.3Research AutonomyOpen explanation ＋
Canonical design chapter
Research Autonomy
Make research a separately testable capability with typed contracts, visible human intervention, bounded resources and adversarial evaluation.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R3.4Policy DiversityOpen explanation ＋
Canonical design chapter
Policy Diversity
Give alternative policies a reproducible evaluation surface with explicit identity, evidence of success, costs and failure cases.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R3.5Epistemic Self-DiagnosisOpen explanation ＋
Chapter scope
Epistemic Self-Diagnosis
Distinguish reasoning failure from missing information and limits of observation.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R3.6Promotion & Rejection GatesOpen explanation ＋
Canonical design chapter
Promotion & Rejection Gates
Require independently checkable evidence before a learning candidate is promoted. Preserve rejection evidence, uncertainty and failure classifications.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R3.7Prospective Experience TransferOpen explanation ＋
Chapter scope
Prospective Experience Transfer
Test whether earlier experience causes a later change in behavior or performance.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R3.8Epistemic Cognitive SubstrateOpen explanation ＋
Chapter scope
Epistemic Cognitive Substrate
Give the WorkMachine persistent identity, traceable memory and governed context.
Checkpoints
R3.8.1WorkMachine IdentityRead explanation ＋
Engineering checkpoint
WorkMachine Identity
Same machine. New conversation. A persistent identity keeps the WorkMachine recognisable across conversations, restarts and model changes.
R3.8.2Identity SeparationRead explanation ＋
Engineering checkpoint
Identity Separation
Give every kind of work its own identity. Separates the machine, conversation, mission, task, episode and environment so records do not quietly blur together.
R3.8.3Canonical EpisodeRead explanation ＋
Engineering checkpoint
Canonical Episode
Turn work into an inspectable story. Binds objectives, observations, actions, decisions and outcomes into episodes with evidence and custody.
R3.8.4Observation Source TypesRead explanation ＋
Engineering checkpoint
Observation Source Types
Know where a fact came from. Distinguishes user input, tool observations, inference and candidate output before they enter the record.
R3.8.5Untrusted Candidate OutputRead explanation ＋
Engineering checkpoint
Untrusted Candidate Output
Inspect an idea without obeying it. Keeps candidate output separate from trusted instructions for evaluators and supervisors.
R3.8.6Memory ArchitectureRead explanation ＋
Engineering checkpoint
Memory Architecture
Give memory a structure. Organises what happened, what is believed, how to do something and how the machine operates into four memory kinds.
R3.8.7Memory ScopeRead explanation ＋
Engineering checkpoint
Memory Scope
Keep the right knowledge in the right place. Defines private, conversation, mission, team, organisation and canonical scopes, with explicit promotion boundaries.
R3.8.8Temporal EpistemicsRead explanation ＋
Engineering checkpoint
Temporal Epistemics
What was knowable—at that moment? Separates world, observation, ingestion, activation and promotion times to prevent future knowledge leaking into earlier decisions.
R3.8.9Provenance GraphRead explanation ＋
Engineering checkpoint
Provenance Graph
Follow a claim back to its grounds. Connects claims and memory objects to their source episodes, observations and evidence.
R3.8.10Epistemic Context CompilerRead explanation ＋
Engineering checkpoint
Epistemic Context Compiler
Build the context the model is allowed to see. Compiles approved memory, skills, policies and provenance into an exact context manifest under permissions and budget.
R3.8.11Context Exposure LedgerRead explanation ＋
Engineering checkpoint
Context Exposure Ledger
Know what reached the model. Records which memories, episodes, observations, skills and policies were exposed through a specific model context. The local adapter distinguishes preparation, attempts, acceptance, observation and loss.
R3.8.12Hybrid RetrievalRead explanation ＋
Engineering checkpoint
Hybrid Retrieval
Find the right memory. Keep its grounds. Combine semantic, lexical, graph, temporal, provenance, causal, outcome and failure signals. Filter permissions before ranking, then trace selections through context compilation and exposure recording.
R3.8.13Versioned CognitionRead explanation ＋
Engineering checkpoint
Versioned Cognition
Give cognitive change a history. Cognitive state snapshots, diffs, branches, rollback and merge preparation. Keep state changes traceable; rolling back cognition does not undo external actions.
R3.8.14WorkMachine SnapshotRead explanation ＋
Engineering checkpoint
WorkMachine Snapshot
Carry the machine forward. A portable package of WorkMachine identity, cognition, configuration, skills, policies, lineage and evidence.
R3.9Evidence-Aware Experience CompilerOpen explanation ＋
Chapter scope
Evidence-Aware Experience Compiler
Turn retained experience into traceable learning candidates while keeping reuse, evaluation and promotion distinct.
Checkpoints
R3.9.1Experience CompilerRead explanation ＋
Engineering checkpoint
Experience Compiler
Transform selected episode observations into traceable candidate facts, patterns, models, policies, skills and schemas.
R3.9.2Candidate LifecycleRead explanation ＋
Engineering checkpoint
Candidate Lifecycle
Give compiled candidates durable identities, attributable decisions and recoverable receipts.
R3.9.3Reflection FabricRead explanation ＋
Engineering checkpoint
Reflection Fabric
The roadmap defines specialist reflection roles for questioning and refining experience. No role has unilateral promotion authority. The successor report verifies this predecessor’s source baseline; its standalone implementation report remains under reconciliation.
R3.9.4Memory Authority LevelsRead explanation ＋
Engineering checkpoint
Memory Authority Levels
Check source-bound applicability across L0 RAW through L5 CANONICAL, separately from visibility and control authority.
R3.9.5Human Correction LearningRead explanation ＋
Engineering checkpoint
Human Correction Learning
Bind human corrections to their source and scope before compiling them into the candidate lifecycle.
R3.9.6Contradiction and ForgettingRead explanation ＋
Engineering checkpoint
Contradiction and Forgetting
Restrict current reuse through explicit candidate dispositions while retaining historical content and evidence lineage.
R3.9.7Compression AuditRead explanation ＋
Engineering checkpoint
Compression Audit
Detect structural loss or changes in provenance, uncertainty, counterevidence, causality, time and unresolved questions.
R3.9.8Negative TransferRead explanation ＋
Engineering checkpoint
Negative Transfer
Compare retained performance with and without an exact learned candidate. Real application trials remain open.
R3.9.9Memory Poisoning DefenseRead explanation ＋
Engineering checkpoint
Memory Poisoning Defense
Expose circular confirmation and shared ancestry so repetition cannot turn dependent claims into independent evidence.
R3.9.10Candidate Schema EvolutionRead explanation ＋
Engineering checkpoint
Candidate Schema Evolution
Propose and compare changes to remembered fields. Proposals do not install schemas, migrate records or promote themselves.
R4Supervisory Autonomous Control Plane17 chapters ＋
Supervisory Autonomous Control Plane
In development
Supervisory Autonomous Control Plane
Keep work moving under bounded authority: mission contracts, continuation, planning, scheduling, budgets, risk and information boundaries. R4.17 is the latest numbered checkpoint. Current work connects native execution, signed authorization, guarded results and recovery; independent review and acceptance remain open.
R4.1Mission and Execution FoundationsOpen explanation ＋
Chapter scope
Mission and Execution Foundations
Describe the mission and mediate execution through current authorization, scope and budget checks.
Checkpoints
R4.1.1Mission Contract FoundationRead explanation ＋
Engineering checkpoint
Mission Contract Foundation
Give work a clear objective, success criteria, scope, budget and evidence requirements. A mission description does not grant execution permission.
R4.1EExecution EnforcementRead explanation ＋
Engineering checkpoint
Execution Enforcement
Check current authorization, expiry and budget before an effect passes through an enrolled adapter. Native non-bypassable integration remains open.
R4.2Autonomous Continuation EngineOpen explanation ＋
Chapter scope
Autonomous Continuation Engine
Retain decisions to continue, retry, replan, wait, schedule, recover, escalate, abort or complete without granting new authority.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R4.3Recursive DecompositionOpen explanation ＋
Chapter scope
Recursive Decomposition
Validate proposed work trees, preserve parent intent and bind action requests to reviewed tasks.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R4.4Autonomous ReplanningOpen explanation ＋
Chapter scope
Autonomous Replanning
Replace an invalid plan while preserving mission criteria, permissions and execution history. Recover committed revisions after lost replies.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R4.5Scheduling + Sleep/WakeOpen explanation ＋
Chapter scope
Scheduling + Sleep/Wake
Keep dormant missions and recurring schedules durable. Resume without duplicating a wake or losing the original mission boundaries.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R4.6Event-Triggered Wake + IntegrationOpen explanation ＋
Chapter scope
Event-Triggered Wake + Integration
Add durable event-triggered wake records, inheritance checks and a local LangGraph/LangChain path. Jev and LangSmith adapters are prepared; native integration remains incomplete.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R4.7Multi-Mission QueueOpen explanation ＋
Chapter scope
Multi-Mission Queue
Coordinate priorities, dependencies, concurrency and blocked missions. Carried-forward LangSmith/Jev and Paperclip/Hermes integration remains open.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R4.8Budget GovernorOpen explanation ＋
Chapter scope
Budget Governor
Account for cash, tokens, quotas, compute, elapsed time, retries and parallelism within the verified local store.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R4.9Risk GovernorOpen explanation ＋
Chapter scope
Risk Governor
Classify reversibility, financial, security, privacy, communication, destructive and architectural consequences without creating execution permission.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R4.10WatchdogOpen explanation ＋
Chapter scope
Watchdog
Detect retry storms, repeated errors, oscillation, stalled progress, expanding task trees and runaway spend.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R4.11Human EscalationOpen explanation ＋
Chapter scope
Human Escalation
Retain decision cases with evidence, options and risks when judgment or authority belongs to the human.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R4.12Execution Environment FabricOpen explanation ＋
Chapter scope
Execution Environment Fabric
Manage environment descriptors, eligibility, reservations, termination evidence and recovery as mission resources. Physical environment integration remains open.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R4.13Environment MigrationOpen explanation ＋
Chapter scope
Environment Migration
Coordinate exact checkpoint transfer, state verification and recovery. Local custody verification does not establish physical migration between hosts.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R4.14Capability AuthorityOpen explanation ＋
Chapter scope
Capability Authority
Give workers narrow temporary grants, preserve revocations and authenticate capability recreation during migration.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R4.15Information Flow ControllerOpen explanation ＋
Chapter scope
Information Flow Controller
Apply endpoint rules and provenance restrictions to information crossing workers and missions. Preserve restrictions on derived information.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R4.16Epistemic BrokerOpen explanation ＋
Chapter scope
Epistemic Broker
Govern exact cross-agent releases with source lineage, explicit declassification and durable send records.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
R4.17Untrusted Output BoundaryOpen explanation ＋
Chapter scope
Untrusted Output Boundary
Keep model responses, tool results, browser content and experiment output as untrusted observations, separate from governing instructions.
This chapter has a documented scope. Separately numbered subreleases are shown when recorded in the source roadmap.
Chapter names follow the canonical engineering specs and later master roadmap. Design chapters describe scope and acceptance gates; they do not certify implementation. Requirements are labelled separately from numbered releases.