Current operating model

This page summarizes the active operational baseline reconciled on 2026-08-21. Read the authoritative source.

Verified path today

flowchart LR
    Op[Operator<br/>human mandate] --> GI[GitHub Issue<br/>durable scope + evidence]
    GI --> L[workflow:* label]
    L --> D[Cortxt dispatcher + CLI]
    D --> RT[Replaceable external runtimes<br/>behind Cortxt adapters]
    RT --> EV[GitHub evidence or PR]
    EV --> REV{Independent review<br/>when required}
    REV -->|approved| APP[Operator approval]
    REV -->|blocked| GI

GitHub Issues are the durable source of truth for scope, evidence, review, and approval. Issue labels carry workflow state. Runtime task lists are execution ledgers, not independent backlogs.

Product boundaries

Per ADR-042 (accepted 2026-08-26) and ADR-044 (accepted 2026-08-28), Cortxt is work- and mandate-first: the durable Workstream and its authorized outcome are the product, not any one interface. Three interfaces expose that authority:

• Cortxt OS is the accepted general shell and first-party app runtime. Work is its first principal app (app ID work, route /work), not the identity of the OS. Both are in active development — not yet a finished product.
• The cortxt CLI remains the local, automation, bootstrap, diagnostic, and power-user interface, and today is the most complete verified one.
• cortxt mcp serve remains the external, mandate-protected integration surface.

Hermes, Pi, Codex, DSH, and other runtimes are replaceable execution resources behind Cortxt-owned adapters — keep the Workstream, replace the Run. The legacy web prototype was removed from the repository before the first public release (issue #225); Work Console is retired by ADR-044 with a bounded compatibility migration to Work, and Workspace keeps its execution-resource meaning (the optional Git branch/worktree attached to a Workstream). Only the human operator approves scope, irreversible effects, merge, publication, deploy, and final completion.

Verified capabilities

• Dispatcher claim/run identity and workflow-label transitions.
• Worker invocation adapters with injected subprocess boundaries.
• Daemon loop end-to-end proof of life.
• A read-only MCP tool slice with tier flags.
• Provider-neutral inference through InferencePort.
• A deterministic provider-assurance policy gate that fails closed on malformed evidence.

Current limits

The full unattended issue-to-result workflow is not yet the default, and operator approval remains the final gate. A successful experiment or smoke test must not be described as a finished production workflow.