Protocol evolution

Roadmap

The long-term path for OpenThymos as governed cognition infrastructure.

Roadmap

This roadmap tracks runtime semantics and infrastructure maturity for OpenThymos as a unified Rust execution runtime, framework, and sandbox for coding agents. The root roadmap is maintained in ../ROADMAP.md.

Phase I - Unified Deterministic Runtime

Architectural goal: stabilize the Intent -> Proposal -> Commit cycle and make the ledger the source of execution truth across CLI, VS Code, terminal, and web surfaces.

Runtime capabilities:

• signed capability writs
• typed capability contracts
• programmable capability manifests
• path-confined coding sandbox and worker-backed shell/HTTP fabric
• deterministic proposal compilation
• local replay verification
• world projection by ledger fold
• effect-ceiling enforcement (tool effect class checked against the writ before execution)
• auditable commits (originating intent id, policy trace, and policy-set hash recorded per commit)
• optional ed25519-signed commits with replay-side verification
• secret redaction of tool observations before ledger persistence
• model-spend budgeting (cognition token/USD usage debited against the writ budget)
• fork-proof append (unique (trajectory, seq) invariant under an immediate transaction)
• replay drift detection (compiler version, policy-set hash, commit signatures)
• writ revocation (compiler stage, one-level child cascade) + anti-replay nonce
• idempotency (exactly-once execution for External/Irreversible tools per proposal)
• multi-party (M-of-N) approval quorum + irreversible/non-compensable approval gate
• compensation / saga rollback (incl. cross-trajectory) with recorded compensations
• external Merkle anchoring of the ledger; pluggable (attestable) clock
• declarative signed JSON policy bundles (policy-language-v1, implemented)
• routing-evidence (Proposal Contract v1, Option 2) + safe pull-based feedback export

Execution guarantee: no tool execution without a staged or approved proposal, and no effect beyond the writ’s effect ceiling.

Scaling implication: correctness remains local and inspectable before distributed concerns are introduced.

Most of the original Phase I “later” list has shipped (above). What remains (see STATUS.md for the precise, adversarial line):

• Postgres as the HTTP runtime path — the async backend is implemented and tested in isolation, but the server still uses the synchronous SQLite path until the runtime/ledger trait refactor lands.
• routing_evidence is recorded verbatim (not redacted) — provider metadata, never read for authority; a redaction pass over it is an optional follow-up.

Phase II - Multi-Agent Coordination

Architectural goal: represent delegation as explicit runtime structure.

Runtime capabilities:

• signed child writs
• child trajectories
• delegation DAG projection
• coordination policies

Execution guarantee: child authority is a strict subset of parent authority.

Scaling implication: concurrent work becomes possible without losing lineage.

Phase III - Distributed Execution Ledger

Architectural goal: separate ledger protocol from storage backend and support multi-node ingestion.

Runtime capabilities:

• Postgres-backed ledger mode
• ledger export and import
• hash-chain audit proofs
• snapshot-assisted replay

Execution guarantee: replay result is independent of storage backend.

Scaling implication: the runtime can move from local history to distributed history without changing execution semantics.

Phase IV - Runtime Federation

Architectural goal: allow independent runtimes to exchange authority and execution records.

Runtime capabilities:

• federated writ verification
• remote trajectory references
• cross-runtime audit queries
• importable policy bundles

Execution guarantee: federation cannot bypass local policy.

Scaling implication: cooperation does not require one global control plane.

Phase V - Autonomous Governance Layers

Architectural goal: allow governance agents to propose policy, writ, and runtime changes while remaining subordinate to protocol rules.

Runtime capabilities:

• governance proposal queues
• policy simulation against historical ledgers
• writ issuance workflows
• governance audit projections

Execution guarantee: governance actions are themselves proposal, approval, and commit events.

Scaling implication: OpenThymos becomes an institutional runtime substrate, not merely an execution loop.