Skip to content

AOI v0.5.0a1 implementation and release plan

Status: release-convergence scope approved on 2026-08-01.

This document is the canonical tracked contract for AOI v0.5. It supersedes the unpublished v0.4.0a4 publication objective, but preserves e2d3082608dfccbf9446e63caaf0124c5ad70224 as the frozen N-1 controller baseline. It does not turn a planned feature or acceptance target into current runtime evidence.

Current delivery tranche: AOI READY and v0.5.0a1 release

The user-approved implementation order for the current tranche is narrower than the complete public-release plan below. AOI must first become a usable company that can itself lead ARISE; the current Codex conversation must not substitute manual coordination for that product capability.

Before ARISE work resumes, this tranche must provide:

  • one durable logical Chief with fenced Codex carrier handoff and explicit Claude unavailability;
  • durable RTL, DV, and PD departments with snapshot, park/resume, automatic wake, delegation, and result return to the Chief;
  • one Supervisor writer, durable ledger/replay/readmodel, stable lifecycle IDs, and plain verifiable checkpoint/export;
  • organization, execution, and artifact/evidence graphs;
  • recursive status for every AOI-dispatched or registered agent and job, with runtime/observation status separate from engineering/task status;
  • provider adapters with explicit coverage degradation, needs-user, and raw usage/missingness seams; and
  • a minimum useful GET/SSE-only Command Center in which the user can inspect the whole company and each department lead can inspect its descendants.

The Command Center is an early vertical slice, not a final presentation phase. Immediately after the Supervisor can durably bootstrap the logical Chief and the RTL/DV/PD identities, AOI must expose the read-only API and a usable Command Center showing those objects, the ledger cursor, coverage, jobs, and the separate runtime/engineering states. Chief takeover, department park/wake, nested-agent lifecycle, provider adapters, and usage events are then integrated into that same visible surface as they are implemented. They may not accumulate behind a CLI-only implementation until the end of the tranche. Organization identities remain visible while parked, but the execution tree contains only dispatched, registered, or provider-observed executions. A missing provider session is shown on the logical carrier as unavailable or unknown; AOI must not manufacture a thread, turn, agent, or execution ID merely to make the tree look populated.

The following complete-v0.5 items are explicitly deferred from v0.5.0a1: encrypted backup/recovery-key onboarding, broad security and retention hardening, Claude parity, optimizer/benchmark/paper evaluation, rate-card calibration, arbitrary executable plugins, and cross-repository UI. Plain digest-bound checkpoint/export and non-in-place restore remain mandatory.

ARISE source mutation, EDA execution, commit, and push remain frozen during the release tranche. After public readback, a separate AOI-managed ARISE K dogfood task may begin. Its results do not retroactively become v0.5.0a1 release evidence. AOI candidate code cannot self-approve readiness or release.

Operational-alpha authority decision

The company-core alpha uses one cooperative authority domain:

  • <company-slot>/company.lock is a stable, never-replaced lifetime process lock. The Supervisor holds its OS handle from before it opens company state until every ledger/readmodel/blob handle is closed.
  • <company-slot>/current.json is the cross-lifetime locator for the active incarnation. It changes only by compare-and-swap while the stable company lock is held.
  • During one verified Supervisor lifetime, the ledger connection bound after resolving the current pointer is transaction authority. SQLite COMMIT is the mutation linearization point; readmodel.sqlite3 is a replaceable projection only.
  • Compliant rebuild, pointer switch, and future restore operations stop ingest, close live state handles, publish the replacement, reopen, and verify in that order. A live readmodel is never replaced underneath its owner.
  • Existing path/inode guards detect startup drift, in-operation drift, and violations by cooperative AOI components. They do not claim to close the impossible interval between the final userspace check and function return against a hostile same-UID actor that ignores the advisory lock, replaces files directly, or monkeypatches the interpreter.
  • A post-COMMIT authority mismatch is effect_unknown and quarantines the Supervisor. AOI does not silently choose either the old inode or the new pathname as authoritative.

Chief takeover, release, and Company OS canaries require a plain, digest-bound, replay-verified checkpoint/export. Encrypted backup/restore is deferred beyond v0.5.0a1; the alpha makes no encrypted disaster-recovery claim.

Product contract

AOI v0.5 models one repository as one local company.

  • The user normally speaks to one logical Chief. v0.5.0a1 supports replaceable Codex carrier episodes for that durable role; Claude carrier parity is deferred and must be shown as unavailable.
  • The default company contains durable RTL, DV, and PD departments. The user does not create three separate chats.
  • Department identities and snapshots persist while provider sessions may be resumed, parked, or replaced.
  • AOI-dispatched and formally registered agents, turns, workers, and external jobs appear in a read-only local Web dashboard.
  • Work may continue while the Chief window is closed only while the host, WSL, network, providers, and required services remain operational.
  • Usage keeps the raw provider token vector and derives relative burn from a versioned rate card. USD and subscription quota are not primary metrics.
  • Dashboard navigation and export are read-only. Mutations remain Chief- or CLI-authorized operations.

AOI remains cooperative, tamper-evident governance. It is not an OS sandbox, cannot guarantee visibility of provider-invisible bypass work, and does not claim general superiority over a strong single agent.

User experience

First-run

Chief-led onboarding:

  1. Show the repository/company binding.
  2. Confirm the RTL, DV, and PD template.
  3. Select a checkpoint/export destination outside the repository and company state root.
  4. Create and verify a digest-bound plain checkpoint/export.
  5. Show the Chief provider, subordinate carrier limit, notification policy, and dashboard URL.
  6. Start the platform-local Supervisor and open the dashboard once.

Later Chief conversations attach to the existing company. They do not rebuild departments or repeatedly open browser tabs.

Command Center

The primary page is a dark, dense engineering console:

  • Left: company, Chief, departments, and durable employees.
  • Center: recursive execution tree. Active, waiting, blocked, and unknown nodes expand by default; idle and completed nodes collapse with counts.
  • Right: critical alerts, needs-user items, recent events, and coverage gaps.
  • Fixed top bar: Supervisor, adapters, collector, ledger cursor, last ingest, last verified checkpoint/export, and observation coverage.
  • Every node shows a human name, copyable immutable ID, engineering status, and runtime/observation status.
  • The node drawer contains Overview, Activity, Usage, Artifacts, Evidence, and Raw tabs.
  • EDA jobs appear under their owner and in the Jobs page.

Fixed pages:

  1. Command Center
  2. Departments
  3. Jobs
  4. Evidence
  5. Usage / Optimizer
  6. History
  7. System / Config

Search and filters cover text, ID, department, status, provider, model, depth, job, and evidence class. History reconstructs the projection at a selected company cursor.

Visibility

  • User and active Chief see the whole company.
  • Department leads see all descendants plus compact cross-department dependency summaries.
  • Workers see their authorized context, parent chain, and required dependencies.
  • Dashboard exposes no approve, stop, retry, answer, acknowledge, route, park/resume, or policy mutation endpoint.
  • The normal browser export is sanitized. Sensitive/raw export requires an explicit local CLI command.

Notifications

Windows notifications are limited to needs-user, critical failure, confirmed lost, claim conflict, high burn pressure, prolonged unknown, and observer/Supervisor failure. Clicking a notification opens the matching dashboard view and does not mutate company state.

AOI first attempts to return a needs-user question to the original Chief provider/session when that provider supports inbound steering. Otherwise it records an immutable pending item, emits a toast, and presents the item at the start of the next Chief turn.

Authority and lifecycle

Company binding

CompanyManifest binds the company to the Git common-dir identity, remote fingerprint, lock domain, and configuration digest. Clone, path move, or Windows/WSL migration requires an explicit rebind.

One Git common-dir maps to one company even when it has multiple linked worktrees. v0.4 migration therefore inventories every linked worktree before import. Each legacy source is bound to its worktree identity and imported byte-preservingly. A duplicate task/object ID with different bytes, or conflicting live authorities/claims, stops migration for explicit reconciliation; the current directory is never selected silently.

Company state is outside Git:

  • Windows: %LOCALAPPDATA%\AOI\companies\<company_id>
  • POSIX/WSL: $XDG_STATE_HOME/aoi/companies/<company_id>, or ~/.local/state/aoi/companies/<company_id>

Chief carrier

  • There is exactly one active logical Chief term.
  • Read-only discussion does not acquire mutation authority.
  • A newer Chief conversation attempts CAS takeover on its first mutation or dispatch intent only with a one-time, term-bound takeover capability produced by an explicit user action. Session IDs and same-user OS credentials alone are not proof of user-authored intent.
  • Exactly one concurrent contender wins. Losers become fenced read-only.
  • A late autonomous write from an older fenced turn cannot start another takeover generation. Takeover capabilities are single-use, expire, bind the contender carrier and expected term, and cannot be replayed after a crash.
  • In-flight agents and external jobs keep their IDs and execution ancestry. Takeover changes supervisory ownership, not the job.
  • Effect-unknown mutation freezes overlapping scope until reconciliation and is never automatically retried.
  • If the current carrier is lost while an approved objective remains, a pre-authorized standby may continue only inside that objective. It cannot broaden scope, publish, or answer needs-user.
  • A verified checkpoint/export is required before takeover, migration, restore, and release. A missing checkpoint blocks the action unless the user explicitly invokes break-glass.

Departments

Initial departments are rtl, dv, and pd.

  • DepartmentIdentity, charter, lead role, scope, and latest DepartmentSnapshot are durable.
  • A healthy carrier may resume; otherwise a new carrier uses the same department ID and snapshot.
  • Idle departments checkpoint and park, then lazy-wake on demand.
  • Only roles with can_delegate=true may create child work.
  • Delegation levels are Chief D0, working lead D1, worker D2, and reviewer D3. D4 is policy-invalid and admission fails closed.
  • The Chief carrier is displayed separately and does not consume subordinate capacity. At most four subordinate provider/model carriers may be active. Parked identities and external OS jobs do not count.
  • Maximum active direct children per manager: 4.
  • Capacity overflow queues explicitly and never masquerades as running.

Dispatch admission and capacity truth

DispatchRequest is a durable, revisioned execution intent. The dispatch_request_id and reservation relation remain stable, while every revision has a new transaction command_id, dispatch_revision_id, and event ID. Reusing a revision ID or event ID is accepted only for byte-exact replay; any divergent binding is corruption. The append-only read model retains every requested revision, including non-committed effect_unknown and reconcile_required receipts.

The Supervisor runs the same invariant reducer under the state-owner mutex before ledger append and again during projection/replay. It enforces depth 3, Chief-excluded subordinate capacity 4, manager fanout 4, organization relations, dispatch to execution bindings, and explicit uncertainty resolution. A rejected admission does not advance the authoritative ledger cursor.

An unresolved external effect is one immutable freeze-barrier row. It remains ahead of ordinary queued/admitted/in-flight work, suppresses the stale base request for the same reservation, occupies capacity conservatively, and blocks retry until an exact committed resolution names every uncertain source event. The read-only Command Center shows this queue separately from execution nodes; it never labels queued work as running.

Capacity is based on physical provider carriers, not names or logical actors:

  • CarrierBinding.actor_id identifies a logical actor and is never treated as an OrganizationNode.node_id.
  • A runtime-occupied ExecutionNode binds a carrier to its organization node for manager-fanout attribution.
  • One non-null (provider, session_id) is one physical carrier slot. The raw session ID remains sensitive and is not returned in capacity diagnostics.
  • Missing bindings, provider/model conflicts, a non-running binding with a running execution, one carrier spanning multiple organization nodes, or multiple logical carriers claiming one provider session all set capacity completeness to false. They conservatively occupy slots and block new admission; the UI reports available = null rather than inventing room.
  • Multiple active lifecycle nodes may share one carrier only when their provider/model binding and organization node agree.

DepartmentSnapshot stores externalized working state—charter, constraints, decisions, dissent, blockers, risks, backlog, active work, jobs, evidence, and handoff. It never stores chain-of-thought. Sensitive resume bindings live in a separately protected record; v0.5.0a1 does not claim encrypted recovery.

Data model and storage

AOI preserves three linked but distinct graphs:

  • Organization graph: department, role, reports-to, and visibility.
  • Execution graph: session, turn, carrier episode, spawn relation, job, and runtime state.
  • Artifact/evidence DAG: produces, consumes, derives, verifies, promotes, and invalidates.

Lane dependencies, coordination requests, and cross-lane sessions remain first-class semantics. Artifact edges do not replace technical coordination.

Authoritative ledger

The single Supervisor writer owns:

  • ledger.sqlite3: SQLite WAL, append-only CompanyTransaction rows, one hash chain, canonical JSON event payloads, and schema-enforced rejection of update/delete.
  • Logical streams: org, execution, evidence, usage, and alert.
  • One transaction may atomically append events to multiple streams.
  • readmodel.sqlite3: replaceable projection rebuilt entirely from the ledger.
  • Content-addressed blobs for logs, artifacts, and bounded raw provider data.
  • Periodic sealed checkpoints binding the verified cursor and blob manifest.

Adapters submit authenticated, idempotent observations through local IPC or a loopback control port. Same event ID/same payload is an exact replay. Same ID with different bytes is corruption. If the Supervisor is unavailable, adapters may use a bounded spool; overflow creates an explicit coverage gap.

Every control request, adapter event, spool member, Chief term, and mutation intent binds company_id, company_incarnation, and lock-domain generation. Restore or platform migration creates a new incarnation. Events from an old Supervisor, carrier, adapter, or pre-restore spool are rejected after the registry pointer changes.

All v0.5 mutating CLI commands are clients of the Supervisor control channel; they never open the company ledger directly. A legacy v0.4 command either routes through an explicit compatibility adapter or fails closed while a v0.5 company is active. Supervisor outage never falls back to direct .aoi or company-state writes.

Windows repositories use a Windows writer. WSL repositories use a WSL writer. Windows dashboard/notifier clients access WSL data only by HTTP/SSE and must never write company state through \\wsl$.

Versioned schemas

Required contracts:

  • CompanyManifest
  • CompanyTransaction
  • OrganizationNode
  • DepartmentIdentity
  • DepartmentSnapshot
  • ChiefTerm
  • CarrierBinding
  • ExecutionNode / ExecutionEvent
  • MutationIntent
  • ExternalJob
  • EvidenceRecord / ArtifactEdge
  • UsageEvent / RateCard
  • Alert / NeedsUser
  • RoutePolicy
  • OptimizerProposal / Canary
  • BackupEnvelope

Schemas use strict field sets, bounded depth/size/count, canonical encoding, explicit provenance, and explicit missingness. Unknown is never silently converted to zero, pass, completion, or loss.

Mutation intent

All repository writes, external jobs, policy changes, and publication use:

prepared
  -> admitted
  -> in_flight
  -> committed | failed_known | effect_unknown | reconcile_required | aborted

Same command ID and bytes are idempotent. Divergent bytes are corruption. Transport loss does not authorize retry. Runtime completion is not verified mutation; exact postconditions and evidence are separate.

Observation and usage

Status truth

AOI guarantees display for AOI-dispatched or registered agents. A provider agent without a dispatch binding becomes Orphan / Unattributed and raises a critical alert. Invisible bypass work is outside coverage and degrades the System coverage indicator.

Every execution node has:

  • engineering/task status
  • runtime/observation status

Stop, turn complete, SubagentStop, and process exit do not imply engineering completion. A healthy collector observing telemetry silence may revise only the runtime status to telemetry_silent; it does not change engineering state or automatically add the independent suspected_stalled SLA overlay. Recovery requires a durable, exact provider-telemetry join received strictly after the silence boundary. Confirmed loss requires active reconciliation across the execution-scoped provider registry identity, process fingerprint, terminal grace, and collector health.

Provenance vocabulary:

  • provider_client_emitted
  • adapter_receipt_persisted
  • collector_received
  • host_process_observed
  • agent_reported
  • AOI_verified

Hooks and OTel are not called provider-signed evidence.

Codex

The adapter normalizes thread start/status, turn start/completion, item start/completion, collaboration tool calls, subagent activity, model reroute, and thread token-usage updates. Parentage comes from AOI dispatch registration, not timing/name heuristics.

The v0.4 observed_starts=0 result must be re-tested against current Desktop app-server signals. AOI must distinguish provider exposure from controller wiring and hook trust.

Claude (post-v0.5.0a1)

Claude carrier and telemetry parity are deferred beyond v0.5.0a1. A later adapter may use corrected hook matcher coverage, SubagentStop/StopFailure, OTel, and beta trace only when actually supported. It must not assume token metrics include custom agent names, parent IDs, or workflow IDs, and OTEL_LOG_TOOL_DETAILS remains off by default.

Usage and relative burn

Raw usage dimensions:

  • input
  • cache read / cache creation
  • output
  • reasoning output
  • total

Every sample is exact, provider_estimate, proxy, or unknown. When a provider total exists:

attributed + unattributed = observed total

Time-window heuristic allocation is prohibited.

Measurement-readiness seam (not an evaluation implementation)

The company ledger preserves raw facts needed by a future independent recorder without making efficacy, ROI, benchmark, or paper claims:

  • globally stable task, packet, thread, turn, agent, execution, job, and receipt IDs with explicit parent linkage;
  • append-only versioned lifecycle events with start, stop, and engineering terminal timestamps kept distinct;
  • Codex raw token vectors and cumulative updates with thread/turn linkage, adapter occurrence identity, intake sequence, receipt time, and provider counter scope. Provider update ID, provider sequence, and observation window remain unavailable when the wire event does not expose them; AOI must not substitute collector coordinates;
  • provider, actual model, effort, role, and routing provenance, using explicit unknown rather than inferred values;
  • exact source, baseline, runner, config, and dependency digests;
  • verification category, completion-boundary coverage, reviewer outcome, and evidence strength;
  • telemetry missingness as source, quality, and reason; missing values are never encoded as zero;
  • a raw-event export/replay boundary so a future N-1 or external recorder can recompute metrics.

Raw cumulative samples are explicitly non_additive_cumulative. They are not UsageEvent, burn, cost, attribution, or a company total. Future thread token derivation must de-duplicate by a monotonic thread-level high-water reducer and must not sum the same cumulative update once per agent or (agent, turn). Until a live provider canary proves whether parent and child thread counters overlap, AOI does not add them into a company grand total. Final delta, attribution, metric, and rate-card calibration remain deferred.

Deferred design record (not runtime evidence or benchmark proof):

C:\Users\ryan529\Documents\Codex\2026-07-26\github-repo-chatgpt-conversation-6a65d58e-735c\outputs\AOI-v05-future-benchmark-metrics-plan-20260726.md
bytes: 16015
sha256: b8679a05c142f738fa9ca707f548527f9096447aa41b8f483c55c05b45cdadba

Existing ARISE task/packet traces are prospective engineering traces or failure-taxonomy inputs only. They are not retrospective controlled benchmarks.

RateCard starts with standard weight 1 and defines versioned relative weights by provider/model/effort/token dimension. Raw usage never changes; a new rate card creates a new derived burn revision. 70/90/100 percent thresholds warn only. If the provider does not expose subscription quota, AOI displays configured capacity pressure rather than invented remaining quota.

Local API and dashboard security

The frontend is TypeScript + React + Vite at build time. Compiled assets ship inside wheel and sdist; runtime does not require Node, CDN, analytics, or remote assets.

The browser port exposes only:

GET /api/v1/bootstrap
GET /api/v1/meta
GET /api/v1/company
GET /api/v1/departments
GET /api/v1/execution
GET /api/v1/execution/{id}
GET /api/v1/jobs
GET /api/v1/evidence
GET /api/v1/usage
GET /api/v1/optimizer
GET /api/v1/alerts
GET /api/v1/history?cursor=
GET /api/v1/snapshot?cursor=
GET /api/v1/events
GET /api/v1/export

Response envelope:

schema_version, company_id, cursor, generated_at,
completeness, warnings, data

SSE uses company cursor/Last-Event-ID, heartbeat, bounded replay, and reset_required when history is unavailable. Slow clients never block the writer.

Historical early Dashboard slice (implemented 2026-07-27)

That slice exposed this surface before full M6, with these boundaries:

  • the HTTP/SSE worker threads were permitted to read only an immutable in-memory snapshot cache; only the Supervisor/state-owner thread could query the read model and publish a new cache revision;
  • every Supervisor-owned committed transaction synchronously published the then-current snapshot when the Dashboard was active; a committed transaction followed by publication failure was reported as committed-with-Dashboard- refresh-failure and was not retried as if its effect were absent;
  • cached transaction cursors were required to be contiguous. History or SSE clients older than the bounded replay floor received reset_required. The browser kept its last received SSE cursor separate from the newer projection cursor and used the former for ordinary reconnect replay. It advanced that cursor only after receiving a contiguous transaction; after bounded replay expiry, it first recorded an explicit, pinned local history_gap, then reset to the then-current snapshot. A repeated cursor was ignored only when its fully validated transaction bytes exactly matched the last accepted transaction; a divergent same-cursor payload was a visible replay-contract failure;
  • concurrent browser refreshes could publish only a monotonic company cursor, and the recent-event panel retained only a bounded ID/type/cursor summary rather than unbounded raw event payloads;
  • the early /api/v1/snapshot exposed only the then-current projection; historical projection reconstruction was unavailable; and
  • /api/v1/export returned state=unavailable and sanitized=false because an actual sanitizer and verified plain checkpoint/export were not yet part of that slice. It did not return raw carrier/session fields while claiming a sanitized export.

The early frontend was a packaged, dependency-free HTML/JavaScript console that made company state visible during M3/M4. React/Vite, the seven-page information architecture, authentication bootstrap, role-scoped views, history reconstruction, and sanitized export were left as later M6 requirements. The API reported authentication=unavailable; this was an honest loopback operational preview, not a private or production-hardened Dashboard.

Historical operational-alpha Chief handoff slice (implemented 2026-07-27)

That slice implemented the first M3 authority layer and published it through the then-current early Command Center:

  • prepare_chief_takeover created a non-durable, fresh-user-intent capability bound to the exact company, current global head, logical Chief term/epoch, contender carrier observation, one transaction/command, scope, objective, nonce, issuance, and expiry. Head drift never refreshed that capability.
  • The attempt was one transaction containing the top-level capability and its embedded consumption receipt. A normal known-carrier success also contained only the new active ChiefTerm, new Chief AuthorityGrant, old-carrier fenced revision, an old-root-execution authority-fence revision, new active carrier, and new root carrier execution. The exact unknown-genesis first-bind exception described below had no old execution to revise and did not manufacture one. A losing attempt contained only the capability/receipt, a visible fenced contender carrier, and its read-only root execution.
  • ledger.sqlite3 had an append-only takeover_consumptions registry, written atomically with the transaction and event/reservation rows. Capability, consumption, transaction, and command IDs were all single-use. Exact whole- request replay returned the durable result; divergent reuse failed before commit. Full ledger verification checked registry membership and exact bytes.
  • The pure invariant reducer was shared by state preflight and read-model replay. A Chief mutation had to derive from a durable grant whose actor/carrier/term/epoch exactly matched the then-active ChiefTerm. Therefore an old Chief grant was rejected before the ledger cursor advanced. Old grant issuance remained immutable; the Dashboard derived its effective state as fenced.
  • Every takeover contender had to introduce a globally fresh durable CarrierBinding.carrier_id; an already-active or previously fenced carrier ID could not become current again. Takeover contract types, event types, streams, timestamps, and wrapper provenance were checked in the shared pre-ledger reducer, rather than being discovered only after COMMIT by the read model.
  • Authority fencing and runtime occupancy were separate. The old carrier binding became fenced immediately. In the same transaction, a live, nonterminal root ExecutionNode changed from engineering active to waiting with wait_reason=fenced_read_only; its provider-observed runtime state, heartbeat, current tool, and payload provenance remained unchanged. An already stopped, lost, completed, or cancelled prior execution preserved those status facts while still receiving the authority-fence event. Existing ExternalJob and execution ancestry records were not rewritten by takeover.
  • A fenced Chief runtime continued to consume its physical provider/session slot until a separate, typed provider observation positively confirmed execution_stopped. The root-stop receipt used null dispatch lineage rather than a fabricated dispatch ID, and atomically appended receipt, observed evidence, and a stopped runtime revision while engineering remained waiting/fenced_read_only. Exact replay was idempotent.
  • The generic runtime-observation path preserved the execution's lifecycle receipt_id, engineering status, wait reason, current tool, last known heartbeat, and SLA overlays when it recorded silence. A recovery could move telemetry_silent -> running only when its source_event_id named one already-durable provider telemetry receipt with an exact execution/carrier join, an allowed activity kind, and received_at strictly after the silence boundary and no later than the recovery observation. That receipt time advanced the execution heartbeat. Runtime source events were single-use.
  • confirmed_lost was an explicit runtime status, not an alias for stopped and not an engineering terminal. It required the typed composite matrix provider_registry=absent, host_process=absent, terminal_grace=elapsed, and collector_health=healthy; it appended bound runtime evidence plus an open critical confirmed_lost alert. Loss was scoped to one execution identity. A shared carrier remained active and capacity- occupied while any sibling execution was runtime-active; only loss of the last active sibling revised the carrier to lost/unavailable.
  • In that alpha slice the composite loss receipt was an AOI deterministic- observer assertion persisted with canonical raw bytes and replay checks. It was not provider-signed, and its individual registry/process/grace/collector probes were not separate cryptographically bound receipts. The claim therefore remained cooperative AOI verification, not hostile same-user isolation.
  • The takeover event wrapper used AOI_verified only for the governance transition. The revised ExecutionNode payload retained the provenance of its preserved provider/runtime observation; changing that payload provenance to AOI_verified would have overclaimed the unchanged runtime and heartbeat.
  • The early Command Center showed the then-current logical Chief term/epoch/carrier, effective Chief grants, recent consumed/fenced attempts, and current/fenced carrier badges. Then-current and recent-event projections recursively removed raw session IDs, thread IDs, user-action references, nonce values, and embedded raw takeover capabilities. The HTTP surface remained GET/SSE only.

Evidence for that earlier handoff-only slice was local Python runtime/integration evidence. On Windows, the company contract/ledger/read-model/state/Supervisor/view suite then passed 542 passed, 23 skipped; strict mypy passed for all 14 company source modules, and all company plus v0.5 test modules passed py_compile. The same-head and root-stop tests covered one takeover winner, a durable fenced loser, preservation of stopped prior facts, provider-confirmed fenced-root stop, capacity release from 2 to 1, exact replay after Supervisor reopen/read-model rebuild, divergent replay rejection, role-evasion/timestamp-split rejection, and current root evidence loss degrading health rather than becoming a false zero or PASS.

At that slice, a real installed Chrome session loaded the packaged Command Center with no console errors or failed requests. It showed the current Chief, fenced prior Chief, RTL active/running lead, DV queued wake, PD parked department, and one queued external job. Browser canaries observed SSE open, a seven-field versioned GET envelope, HTTP 405 for POST, and HTTP 404 for a nonexistent mutation route. The 134,120-byte screenshot recorded for that historical slice had SHA-256 5b2dea544c0107a38d53aeab55787c93de433f1e31bb9d32a2bb21ab0a980bd8.

Earlier independent packet p-m4-chief-cas-independent-review-r3 accepted an older bounded Chief handoff snapshot; its typed result SHA-256 was baf1872dae0de347e0195399a080be474106be6d8b2e201d12d156ca10048d4c. It predates the typed root-stop and provider-receipt hardening and therefore is historical evidence, not acceptance of the current bytes. A fresh independent review remains required. Those historical receipts do not complete M3 or make AOI-for-ARISE READY. Automatic standby failover, effect_unknown takeover reconciliation, a provider-native Codex carrier adapter, confirmed-lost reconciliation, and a production-authenticated Dashboard remain unimplemented. Claude parity is deferred. Those historical receipts do not establish hostile same-user isolation, fresh WSL qualification, or a general wall-clock-expiry guarantee for every authority grant.

Historical resident telemetry control slice (implemented 2026-07-27)

That slice accepted bounded provider observations without giving HTTP workers SQLite or Dashboard publication authority:

  • Runtime descriptor schema aoi.company.runtime-descriptor.v3 contained the administrative bearer only in its private on-disk form. Public status redacted that bearer and every capability path.
  • Codex app-server, Claude hook, and Claude OTel each received a separate source-bound aoi.company.telemetry-capability.v1 file and bearer. A telemetry client read only the one capability explicitly passed to it; an administrative descriptor or sibling telemetry capability could not authorize another route.
  • HTTP workers validated a strict, bounded, duplicate-key-free envelope and enqueued a typed command. Only the resident owner thread invoked CompanySupervisor.ingest_*_telemetry, committed the ledger, and refreshed the immutable Dashboard cache.
  • Enqueue, stop admission, and final pending-request drain shared one admission lock. A stop could not pass an empty drain and leave a later request without an owner. The queue was bounded; saturation was 503 ingest_busy, not running.
  • A transport timeout after enqueue was effect_unknown. A late owner-thread commit remained durable; only an exact transaction/command/bytes retry could return the original cursor as an idempotent replay.
  • Mutating responses were closed schemas. Error JSON was duplicate-key-free and reported known-no-effect only through an exact status/code/key matrix. committed required an allowlisted code plus a positive, non-boolean cursor. A success response required exact top-level and ProviderTelemetryIngestResult fields, strict types/domains, exact service/company/provider/transaction/command binding, and cursor == global_sequence. Any corruption remained effect_unknown.
  • A commit followed by Dashboard refresh failure reported committed_dashboard_refresh_failed; a commit followed by unrecoverable projection failure reported committed_projection_degraded. Both carried the durable cursor. A post-commit result-conversion fault remained conservatively effect_unknown; after the converter recovered, exact retry read the one durable transaction rather than duplicating it.
  • POSIX runtime directories were owner-only. Windows custom runtime roots were fail-closed against broad Allow ACLs; the probe invoked the absolute system Windows PowerShell executable and the validation cache was bound to directory file identity, so delete/recreate at the same pathname was rechecked.
  • The Dashboard continued to show sanitized telemetry receipts, coverage source/quality/reason, and raw non-additive cumulative token samples. Missing Claude usage remained unavailable, not zero. Provider-native relationship metadata was not promoted into AOI execution ancestry without an exact dispatch/registration join.

Historical exact local evidence recorded for the 2026-07-27 resident slice:

tests/company_v05: 397 passed, 4 skipped
strict mypy: 22 company source files, success
compileall: company source and company_v05 tests, success
git diff --check: success
service.py sha256:
  b7d790dd1ec570759026104276a859c2d1b241e33bb70a67ceb23e5a3048630c
test_company_service.py sha256:
  9b258d6cc00035749103900ce700fc0022684006f64718ee502681df01c9bc57

At that slice, exact-byte independent correctness/security/adversarial reviews accepted the then-recorded service and test bytes. Those hashes do not identify the current HEAD bytes. This is historical Windows local Python runtime, protocol, replay, and Dashboard-projection evidence. It is not a live nested Codex/Claude canary, installed-wheel readback, WSL qualification, hostile same-account isolation, or AOI-for-ARISE READY. Resident Chief takeover was implemented in the following historical slice. Department dispatch and external-job control routes were recorded as the next company control-plane slice; the browser surface in that slice remained GET/SSE only.

Historical resident Chief control and unknown-genesis first-bind slice (implemented 2026-07-27)

That slice exposed administrative-only /control/v1/chief-takeover/prepare and /control/v1/chief-takeover/consume routes. They were not Dashboard routes: the browser remained GET/SSE only, and a source-scoped telemetry capability could not authorize Chief control.

  • Prepare was non-mutating. The resident owner supplied the trusted issuance time, fixed capability lifetime to 15 minutes, and bound the contender, company incarnation, current global head, Chief term/epoch, fresh user action reference, scope, objective, nonce, transaction, and command.
  • Consume used a caller-stable canonical timestamp and a fixed 30-day alpha grant lifetime. A new request validated wall-clock freshness; an exact durable retry was resolved before freshness checks, so a response lost across restart could still return the one committed result after capability expiry. Different timestamps, grant expiry, carrier bytes, or capability bytes were a conflict and could not create a second mutation.
  • Before a same-head takeover, the owner created and verified a plain checkpoint plus sanitized export at the pre-takeover cursor. It then checked that the ledger head did not change before committing. A contender whose capability head was already stale was durably recorded as fenced without manufacturing a new checkpoint/export.
  • The control queue remained bounded at 64 entries and reserved four admission slots for administrative work. Stop had highest priority, Chief control preceded telemetry, and FIFO was preserved within each class. This avoided a Chief request waiting behind as many as 60 queued telemetry items; one telemetry operation already executing on the sole owner remained non-preemptible.
  • A company could intentionally bootstrap with an unknown provider carrier and no fabricated Chief execution. The first known carrier could bind through the same resident takeover protocol. The exception was limited to the deterministic genesis Chief/carrier IDs, term/epoch 1/1, canonical provider_session_unavailable shape, and zero prior executions. The governance event proved that AOI fenced the logical old carrier, but the carrier payload preserved its unknown provider/session observation and original last_observed_at; it was not upgraded to provider-observed truth.
  • The deterministic genesis constraint was enforced in the standalone CarrierBinding contract, the contextual transaction invariant, Supervisor construction, and durable replay. A reproduced counterexample that tried to persist a new arbitrary fenced-unknown carrier was rejected before the ledger advanced.
  • A normal known-carrier handoff fenced the prior root execution only in engineering/authority state. Its runtime observation remained unchanged. Existing queued or running external jobs kept their job ID, owner execution, command bytes, event hash, and execution ancestry across Chief handoff and Supervisor restart.

A Windows synthetic company canary exercised:

unknown genesis -> Claude Chief -> queued synthetic VCS job
                -> Codex Chief -> raw Codex usage receipt

The historical resident instance recorded for that slice reported cursor 5, Chief term/epoch 3/3, two consumed takeover attempts, one unchanged queued job, one non-additive cumulative usage sample, coverage=observed, completeness=complete, and no warnings. Installed Chrome rendered the actual Command Center with both Chief executions, the queued job, three parked departments, and raw usage; console errors and failed requests were both zero. The sanitized canary evidence JSON SHA-256 was 896d42c129b6d0b200190053f6dec0a9753728f5b5f30d9bfc131cef7e5b8427.

This was local synthetic Python/browser evidence. It was not a live Codex/Claude provider canary, ARISE work, EDA execution, an installed-wheel readback, WSL qualification, or AOI-for-ARISE READY. Because usage was ingested after the pre-handoff delivery, the Dashboard correctly labeled that checkpoint/export as stale at cursor 5. Prepare remained bound to the global ledger head in that slice: if a telemetry transaction committed between prepare and consume, the old capability was fenced and the user had to prepare from fresh intent. Also, a long workspace pathname reproduced the Windows legacy path-length limit during blob/checkpoint creation; the accepted canary therefore used the bounded %LOCALAPPDATA%\AOI\companies\cc-<id> state directory required by the Windows runtime design.

Security:

  • bind 127.0.0.1 only
  • reject unknown Host, cross-origin access, and mutation methods
  • aoi dashboard open places a one-time nonce only in the URL fragment, which browsers do not send to the server; frontend code exchanges it in the Authorization header of GET /api/v1/bootstrap
  • the bootstrap response sets an HttpOnly, SameSite=Strict cookie bound to one actor, role, company, visibility scope, and expiry; the nonce is single-use, short-lived, and never accepted in a URL/query
  • user and active Chief sessions receive full-company scope; lead/worker dashboard sessions exist only when explicitly opened by Chief/CLI and every GET, SSE, history, export, and direct-ID lookup enforces server-side scope
  • CSP and Cache-Control: no-store
  • no external assets or analytics
  • raw sensitive blobs require explicit local drilldown

A watchdog outside the Supervisor may report Supervisor death, but carries no company-state write authority.

Recovery

v0.5.0a1 requires a plain, repo-external, digest-bound checkpoint/export. The manifest binds company/incarnation, ledger cursor, source/config/dependency digests, member sizes, and hashes. It is cooperative handoff and rollback evidence, not confidential storage.

Checkpoint/export occurs on material terminal/handoff, before takeover, migration, release, restore, and graceful dirty shutdown. The alpha preserves the last verified checkpoint and pinned pre-migration/pre-release checkpoints; full cadence and retention policy are deferred.

Restore always targets a new state root:

  1. verify manifest, members, hash chain, repository, and platform binding
  2. replay ledger and rebuild projections
  3. stop all writers
  4. CAS-swap the registry pointer
  5. retain the old state
  6. create a new company incarnation and lock-domain marker
  7. reject old-incarnation commands and quarantined spool members

Any member, digest, replay, or binding failure leaves the current pointer unchanged. Encryption, recovery keys, DPAPI, and cross-machine confidential recovery are explicitly deferred beyond v0.5.0a1.

Release gate manifest

The release trust root is a versioned, machine-readable manifest stored outside the candidate's writable verification path. It pins the expected candidate commit, required gate IDs, receipt schemas, input/oracle digests, runner or provider class, evidence class, and the independently pinned auditor executable/environment digest. Unknown, missing, optionalized, or candidate-modified required gates fail closed. The final promotion receipt binds this manifest and every required receipt digest.

Optimizer and independent audit

The internal evaluator reads the ledger. A pinned external auditor runs in a different process/environment and reads immutable export/provider artifacts. The candidate cannot write its executable, metrics, input bundle, or verdict.

The optimizer only emits immutable proposals. A deterministic Policy Gate may admit, canary, promote, or roll back inside a pre-approved provider/model/effort envelope.

The optimizer cannot modify authority, evidence classes, evaluators, backup, retention, visibility, depth/carrier limits, mutation safety, or release gates.

Canary policy:

  1. At least 20 eligible external-oracle baseline terminal packets.
  2. Deterministic 10 percent assignment.
  3. At least 20 canary and 20 contemporaneous matched controls, at most 90 days.
  4. Change one routing dimension at a time.
  5. Roll back on any critical regression, lost dissent, fenced mutation escape, unknown mutation, or evidence downgrade.
  6. Correctness, completion, and rework must be non-inferior.
  7. Promote only for at least 10 percent median burn improvement with non-inferior latency, or at least 10 percent latency improvement with non-inferior burn.
  8. Insufficient evidence is inconclusive and preserves current policy.

The v0.5.0a1 release proves bounded feasibility, not general workflow superiority.

Staged implementation

M0: authority and baseline

  • Supersede the unpublished v0.4.0a4 task without tag/release/package.
  • Preserve and verify the exact e2d3082 state backup, complete Git bundle, tree identity, and 28-commit manifest.
  • Develop only in an isolated branch/worktree.
  • Retest Codex nested-agent/token capabilities. Record Claude hook/OTel as unavailable/deferred without making it an a1 implementation gate.

M1: contracts and ledger

  • Implement strict schemas, canonical encoding, append-only SQLite transactions, hash chain, idempotency, blob store, projection, and replay.
  • Gate on property, corruption, crash, race, and deterministic replay tests.

M2: company state and recovery

  • Implement repo-external registry/state, plain digest-bound checkpoint/export, non-in-place restore, rebind, platform marker, and read-only v0.4 import.
  • Inventory and byte-preservingly import every v0.4 state root belonging to the Git common-dir; conflicting IDs, claims, or Chief authorities require explicit reconciliation and never silently prefer the current worktree.
  • Gate on member/digest/tamper/replay/binding failures, pointer preservation, restore smoke, and rollback tests. Encrypted recovery is deferred.

M3: Supervisor and authority

  • Implement the sole writer, authenticated ingest, Chief CAS, carrier fencing, MutationIntent, ExternalJob, failover, effect-unknown reconciliation, and watchdog.
  • Require one-time user-action takeover capabilities and bind every command, adapter event, spool member, and intent to the current company incarnation.
  • Route all v0.5 and compatibility mutations through Supervisor; verify no legacy command can fall back to direct state writes.
  • Gate on two-Chief races, no duplicate mutation/job, and late-old-write denial.

M4: organization

  • Implement RTL/DV/PD departments, snapshots, park/resume, generic recursive topology, D0-D3 delegation, four Chief-excluded subordinate carriers, fanout 4, queue, subtree visibility, and three graphs.
  • Gate on D3/D4, subordinate capacity 4/5, ACL, and replacement-carrier tests.

M5: telemetry and alerts

  • Implement normalized Codex observations, dual status, coverage, raw non-additive usage samples, needs-user, and notification fallback. Claude remains explicitly unavailable in this release.
  • Extend the production Company OS after each telemetry slice; telemetry is not accepted until the user-visible projection shows its coverage, missingness, and handoff behavior.
  • Gate on missing/duplicate/reordered signals, raw receipt/sample integrity, needs-user handoff, and honest unknown. Rate-card revisions and derived burn do not block the ARISE-ready company core.

M6: read-only dashboard

  • Complete the GET/SSE API and expand the early Command Center into seven pages, history, exports, redaction, accessibility, packaged assets, and security headers. M6 is completion and hardening of an already usable Dashboard, not the first time company state becomes visible.
  • Gate on browser E2E, reconnect/reset, 100k-event replay, and proof that a Windows viewer writes no WSL company-state files.

M7: optimizer and auditor

  • Defer optimizer, benchmark, and automatic routing promotion beyond v0.5.0a1.
  • Retain a frozen N-1 release auditor and independent semantic reviewer. Gate on the absence of any candidate self-approval path.

M8: post-release ARISE dogfood

AOI v0.5 may govern its own development only under the frozen N-1 controller and independent release evaluator.

After public v0.5.0a1 readback, create a separate AOI-managed ARISE K task. It must pin current origin/main, use isolated source/output state, preserve exact compile/elaboration/runtime/numeric evidence boundaries, and never auto-start the EDA VM. The dogfood result is not a release receipt and cannot be retroactively promoted into v0.5.0a1 evidence.

M9: release

  • Pass Windows/Linux Python 3.11-3.14, fresh-ext4 WSL, typing, compileall, coverage, wheel/sdist, asset, schema, install, Codex provider canary, Company OS READY, and plain restore gates.
  • Verify every required result against the independently pinned release gate manifest; removing or modifying a required gate, oracle, auditor, or receipt fails closed.
  • Obtain deterministic audit and separate semantic evidence review.
  • Push the exact reviewed commit to main.
  • Require exact-main CI and documentation readback.
  • From a clean external worktree at that exact main commit, create the annotated v0.5.0a1 tag.
  • Run publish.yml with intent=rehearsal; only a successful rehearsal for that exact tag and commit permits intent=publish.
  • Publish GitHub prerelease/assets and PyPI through Trusted Publishing, then verify exact GitHub asset SHA-256 values, PyPI Integrity/Trusted Publishing provenance, public readback, fresh Windows/WSL installs, entry points, dashboard, onboarding, checkpoint/export, and restore.
  • Preserve frozen N-1 and rollback; ARISE adoption starts only after readback.

After publication, a defect uses a withdrawn/deprecated prerelease marker, runtime rollback, and reviewed v0.5.0a2 fix-forward. Published package bytes are never overwritten or deleted as a recovery tactic.

Acceptance targets

Correctness gates include:

  • strict schemas, hash sequence, collision, crash, replay, and quarantine
  • Chief takeover capability replay/forgery, fencing, failover, effect-unknown, and late result
  • multi-worktree v0.4 inventory, divergent-ID/claim conflict, and byte-preserved migration
  • old-incarnation Supervisor/carrier/spool rejection after restore
  • D3/D4, subordinate carriers 4/5 with Chief excluded, fanout 4, ACL, queue, and orphan detection
  • stop versus completion; silence/stall/unknown/lost distinctions
  • adapter duplicate/reorder/gap and coverage degradation
  • usage conservation, missingness, and rate-card history
  • checkpoint member/digest tamper, non-in-place restore, and Windows/WSL writer ownership
  • actor-scoped GET-only API, fragment/header bootstrap, nonce replay, Host/CORS/CSP/path traversal/redaction, ID guessing, and SSE cursor behavior
  • partial/detail-expired historical reconstruction without false completeness
  • watchdog, needs-user fallback, and auditor independence
  • candidate-resistant release gate manifest and provider-live Company OS READY

Performance values are targets until measured:

  • idle Supervisor below 1 percent of one core and below 150 MiB RSS
  • event receipt to UI p95 below 2 seconds
  • critical notification p95 below 5 seconds after observer receipt
  • current projection of 100k events below 2 seconds
  • full replay/rebuild of 100k events below 10 seconds
  • four active subordinate carriers plus the Chief and 20 events/second without missing events or blocking the sole writer

Completion boundary

The task is achieved only when:

  1. All hard gates pass and no mutation remains unreconciled.
  2. Independent auditor and semantic reviewer accept the alpha claim boundary.
  3. Company OS READY passes with production provider-live Chief handoff, RTL/DV/PD, all managed agents/jobs, needs-user, and coverage degradation.
  4. The exact reviewed commit is in main and exact-main CI succeeds.
  5. The clean-external-worktree tag, publish.yml rehearsal, and subsequent publish all bind the same exact-main commit; GitHub prerelease asset SHA-256 values, PyPI Integrity/Trusted Publishing provenance, and fresh Windows/WSL install readback all succeed.
  6. Plain checkpoint/export and non-in-place restore smoke pass while frozen N-1 rollback remains available.
  7. Dashboard truthfully displays managed execution, evidence, raw lower-bound usage, alerts, and coverage; unobservable state remains unknown/degraded.

ARISE K is a separate post-release dogfood task and is not part of this completion boundary.