Citadel Roadmap: From Harness to Operations Platform

Citadel now has the local platform spine that the previous twelve-month roadmap described: typed operations, outcome Packs, durable recovery, verifiable receipts, actionable Mission Control, team policy, a Relay seam, and privacy-safe reliability analysis. The next milestones are no longer feature-count milestones. Citadel 1.3 adds runtime-replaceable operations through Operation Fork. The remaining milestones are adoption, interoperability, and trust milestones.

What ships locally in 1.3

• One objective can execute through isolated Claude Code and Codex worktrees under one immutable objective, scope, policy, budget, workflow, and verifier contract.
• Branch receipts, evidence coverage, diff metadata, duration, and available cost feed an honest comparison. Missing evidence stays unknown and equal verified outcomes stay tied.
• Revision-bound selection is separate from a clean-target, confirmation-bound local landing.
• Mission Control shows the comparison and records selection but cannot land code.
• A deterministic redacted replay exposes operation lineage without prompts, source, repository identity, paths, raw revisions, credentials, reasons, or signer material.

What ships locally in 1.2

• A conventional citadel CLI with packaged install, doctor, update, rollback, and uninstall.
• Operations Protocol v0.1 with six strict contracts and deterministic conformance reports.
• One workflow compiled across local, Codex, and GitHub targets with artifact-derived semantic proof.
• Three first-party outcome Packs with permissions, dependencies, certification, journeys, and receipts.
• Durable journals, idempotent recovery, fault injection, and Ed25519 execution receipts.
• A narrow read-only GitHub verification Action and provenance-ready package publishing workflow.
• Typed MCP controls and local Mission Control actions for pause, resume, stop, and retry.
• Hierarchical team policy, a five-operator and ten-repository pilot simulator, encrypted local Relay envelopes, external milestone gates, and held-out reliability analysis.

These capabilities are verified locally. They do not manufacture human adoption, outside authors, independent adapters, hosted demand, or representative production evidence.

Milestone A: Prove retained use

Collect the first mature opt-in activation cohort through the read-only Discussion collector.

Gate	Target
Mature shared installations	25
Verified handoff rate	at least 40%
Resume rate	at least 25%
Seven-day return rate	at least 15%
Installer interviews	enough to explain failures, not just count them

The report remains awaiting_external_evidence until independent submissions satisfy the exact schema and maturity window. Fixtures cannot promote this milestone.

Milestone B: Open the Pack ecosystem

Publish the signed registry contract, contributor ownership rules, and three first-party Packs as the reference bar. Recruit outside authors only after the local registry verifier, revocation path, dependency safety, and certification receipts all pass.

Exit criteria:

• At least three Packs authored outside the maintainer account.
• At least two Packs show repeated installation or journey evidence.
• Ownership, key rotation, revocation, incident response, and transfer rules have named maintainers.
• Registry publication never upgrades unexecuted verification or missing evidence to passed.

Milestone C: Earn Operations Protocol 1.0

Protocol 1.0 is a compatibility promise, not a version-number exercise. Promote v0.1 only after:

• A documented compatibility window and migration policy exist.
• Migration fixtures cover every supported contract version.
• At least one independent adapter passes the six-contract conformance suite.
• Local, Codex, and GitHub projections retain at least 90% of the shared semantic contract.
• Receipt, cancellation, failure, and unknown behavior are verified from generated artifacts.

Until then, the public protocol remains v0.1 even when Citadel itself releases 1.3.

Milestone D: Prove team operations

Run the real five-person, ten-repository, thirty-day pilot using the shipped simulator schema and policy contracts. Measure discovery loss, reassignment latency, conflict rate, resume success, approval latency, and policy denials. Publish negative results and operator friction.

The simulator proves contract behavior only. It is not evidence that a real team adopted Citadel.

Milestone E: Decide whether Relay should exist

The local encrypted envelope and outage-safe outbox are complete. A hosted Relay remains gated on either ten recurring team requests or two hundred qualified waitlist entries. If demand clears the gate, start with encrypted state transport and push notifications. Do not add remote execution.

Milestone F: Turn evidence into reliability intelligence

The analyzer requires at least one hundred consented runs, twenty opaque repositories, two runtimes, and twenty held-out runs. Below that threshold it returns unknown and no recommendation. Above it, recommendations remain explainable and never auto-apply.

Exit criteria:

• Representative data clears every sufficiency gate.
• Held-out evidence supports the recommendation with explicit counts and confidence.
• Privacy review confirms no prompts, source, repository identity, paths, credentials, or URLs leave the allowed schema.
• A maintainer explicitly approves every resulting configuration change.

Sequencing

1. Ship and verify 1.3 locally, including Operation Fork recovery and landing boundaries.
2. Collect retained-use evidence while recruiting Pack authors.
3. Use outside Pack and adapter experience to stabilize Protocol 1.0.
4. Run the real team pilot.
5. Start hosted Relay only if the demand gate clears.
6. Enable reliability recommendations only after the representative-data gate clears.

The project site stays on GitHub Pages for now. Reliability remains the product principle: missing evidence is unknown, simulations are labeled, and external milestones stay open until external people create the evidence.