Military-inspired command, control, and validation doctrine for operating LLM agents.
Cannae OS is a documentation-first framework for using LLMs and multi-agent systems with clearer intent, bounded authority, auditable handoffs, source discipline, and executable validation gates. It translates useful military operating patterns into AI work: commander's intent, OPORDs, FRAGOs, staff roles, CCIR, backbriefs, rehearsals, readiness checks, release review, and after-action learning.
The project is not a military operations manual. It is an operating model for complex knowledge work with AI agents.
Autonomous AI work and AI transformation are becoming urgent topics. As more teams ask LLMs to perform work with less direct supervision, the central problem becomes harder: how do we preserve context, suppress hallucination, prevent authority drift, and still let AI execute useful work?
This project started from a conversation with a friend in the military. While discussing that problem, he said: "Isn't that exactly the military?"
That landed immediately.
Military organizations bring many different people into one system where intent can move from the highest decision-maker down to actual execution without being casually distorted. Along the way, subordinate units adapt the plan to their scale, function, and operating conditions, then issue more specific orders downward.
That is possible because military systems are built around explicit authority, bounded autonomy, role classification, reporting lines, standard documents, rehearsals, backbriefs, and after-action correction. The system is designed to conserve resources and win under uncertainty.
Cannae OS began from a simple question: is this t 10BC8 he missing operating system for human-led AI teams?
Most LLM workflows fail in predictable ways:
- the user's intent gets diluted as work is delegated;
- agents read too much context, too little context, or the wrong context;
- authority boundaries are implicit;
- high-risk actions are approved too broadly;
- generated work is not tied to evidence;
- handoffs depend on chat memory instead of durable state;
- teams add more agents without clear roles, readiness, or sunset rules.
Cannae OS treats LLM work as a command-and-control problem:
intent -> orders -> role-bounded execution -> evidence -> validation -> release -> AAR
The goal is not to make agents more autonomous by default. The goal is to make delegated autonomy explicit, narrow, inspectable, and reversible where possible.
Cannae OS is moving toward a practical runtime discipline for AI teams:
- Doctrine: shared concepts, vocabulary, and operating principles.
- Structured documents: OPORD, WARNO, FRAGO, SITREP, AAR, backbrief, rehearsal, approval, risk, release, and handoff contracts.
- Runtime schemas: JSON contracts that make orders, authority, release, evidence, and readiness machine-checkable.
- Policy gates: local runners that block known unsafe or under-specified states.
- Skill routing: Codex and Claude Code skills that route huge documentation sets by user mode, role, department, authority, and need-to-know.
- Operational skill lifecycle: one fail-closed entry point that opens every wave, generates mandatory routing evidence, issues digest-bound context packs, records manifest-backed results, and converts AAR findings into bounded follow-on work.
- Bounded adaptation: campaign/checkpoint/decision contracts that let agents improve active work without self-authorizing scope, policy, or release.
- Future runtime: a tool-gated orchestrator with approval UI, evidence store, event replay, dashboards, and cryptographically verifiable learning evidence.
The current repository is strongest as a doctrine, schema, fixture, and prototype suite. It is not yet a complete production agent runtime.
-
Readiness And Authority Intersection: reference policy consumers preserve minimum readiness, prohibitions, exact scope, overlapping restrictions and expiry through approval/release composition. Declared ratings are not authenticated qualification or actual tool authority.
-
Codex Default Model Binding: bounded metadata-only host preparation freezes a concrete CLI model before exact owner transfer review. Selection is not account-access proof, inference consent or an automatic default upgrade.
-
Native Request Analysis: purpose-bound existing-Codex proposals consumed by the actual OPORD compiler, with separate owner transfer review and failed-analysis/publication acknowledgment. Proposed drafts remain uncalibrated and require human coverage/adoption; no self-granted task authority.
-
Subject-Bound Workload Controls: actual report admission scans exact report and work-evidence bytes in a bounded local worker, with a separate digest-only receipt. Framework fixture passes do not establish workload inspection; this core-pattern check is not release clearance or complete policy coverage.
-
Force Registry Enrollment: stable, versioned organization/capability/performer definitions with separate authenticated owner review and immutable history. Enrollment is unassessed, not qualification, standing activation or an operational grant.
-
Readiness Drop Reconciliation: retained exact role/task drops fence real dispatch/gateway calls and narrow old leases without blocking admitted-result settlement. This is not a complete capability registry, positive qualification or automatic restoration.
-
Semantic Omission Evaluation: source-bound existing-Codex collection with exact authenticated owner transfer review, one-use session-bound consent, signed original-journal binding and verified failed-transfer acknowledgment. Verdicts remain advisory; calibrated model admission, unknown-result recovery and automatic replanning remain open.
-
Bounded Structural Plan Synthesis: construct complete plans and policies from actual OPORD tasks and finite roster/policy/estimate bounds; preserve parent controls, remaining admission budgets and real revision/supersession gates. This zero-model structural generator is not calibrated semantic or strategic planning.
-
Requirement Inventory And Human Coverage Admission: source-accounted human review bound to the whole plan and actual adoption/context/next-call consumers. The owner preview compares source, requirements and real receivers without changing the exact approval subject through display filters. This separate review class is not calibrated model admission or proof of semantic completeness; legacy records remain readable without renewed execution permission.
-
Operational COP: authenticated, read-only Operations views replay actual wave/control history with freshness, exact evidence links and mission-bounded accounts. Display filters cannot hide authorized critical alerts. This is not worker liveness, tool authority or the complete reporting/CoS workflow.
-
Completion Backlog: the remaining program scope, dependencies, and evidence required for closure.
-
Implementation Candidate Registry: source-bound requirements, actual implementation mappings, and executable completion checks.
-
Request Intake And Order Drafts: retain exact requests, separate quotes from assumptions and proposals, and compile non-executable OPORD/task drafts with inherited constraints. Complete serialized drafts must fit the unchanged 8 MiB reader limit; excessive reference expansion is rejected before publication, never silently truncated.
-
Exact Order Adoption And Plan Binding: bind the complete plan, each agent's backbrief and rehearsal to one finite USER scope decision; recheck it at lifecycle and dispatch admission without granting release or bypassing other gates.
-
Order Revision And Supersession: review a full changed plan against its exact predecessor, prepare successor contexts, settle old execution and supersede before new tool authority.
-
Mandatory Intent Continuity: bind every new context to the plan's complete task commitments and USER-rooted delegation chain; deny missing tasks, widened child authority and legacy-context tool reuse while preserving admitted-result settlement.
-
Local Operator Console: real loopback login, mission-bounded evidence, exact order decisions and outcome replay, plus fresh authenticated terminal reconciliation. Confirm worker exit, retain exact cancellation/acknowledgment evidence and preserve original failures/expiry. Session browser checks reject delayed owner data after viewer login and inverted selections without bypassing auth limits. Broader tool approvals, operational COP and production protection remain open; adoption or reconciliation is not execution authority.
-
Military LLM Framework: the core command, authority, reporting, and AAR model.
-
Military Operating System: the layered operating system view of doctrine, SOP, intent, planning, orders, risk, liaison, assessment, and learning.
-
Agent Roles and Authority: role responsibilities, approval scope, reporting scope, autonomous action, and post-action controls.
-
Commander Handbook: how a human final decision-maker should issue intent, approve work, and manage risk.
-
Functional Domains: mapping military functional domains to AI work functions.
-
Mission Command Runtime Policy: a machine-checkable commander's intent that survives delegation across agent echelons.
-
Disciplined Initiative Rules: bounded initiative, drift classes, and mandatory stop or escalation behavior.
-
Chief of Staff Agent: staff integration, battle-rhythm ownership, and the authorities a CoS agent never owns.
-
Common Operational Picture State: an event-derived mission projection with staleness and need-to-know rules.
-
Reporting Threshold Policy: exception-first must-report, may-stay-silent, and must-not-report rules.
- Prompt Templates: OPORD, WARNO, FRAGO, SITREP, and AAR prompt structures.
- Orders Production Pipeline: request -> mission analysis -> OPORD -> task order -> backbrief -> rehearsal -> execution -> AAR.
- Backbrief and Rehearsal SOP: confirmation steps that reduce instruction distortion before execution.
- OPORD Annex Model: separation between command intent and specialist annexes.
- Personnel Continuity Model: succession, rotation, degraded mode, handoff, and vital records.
- Dry-Run Approval UI: commander dispositions and evidence requirements after rehearsal or dry run.
- Handoff Packet Template: mandatory transfer fields, triggers, and acceptance checks for continuity.
- LLM Agent Org Chart: command relationships, staff functions, RACI, and reporting lines.
- Agent Battle Rhythm: recurring status, decision, approval, and synchronization cadence.
- Interdepartment Collaboration Policy: supported/supporting relationships, liaison, handoff, and conflict routing.
- B2C2WG Operating Model: boards, bureaus, centers, cells, and working groups for multi-agent work.
- AI Special Operations TF: high-risk or high-uncertainty task force activation with independent review, enablers, and abort criteria.
- Force Structure Change Policy: when to create, expand, reduce, merge, deactivate, or disband roles, units, and task forces.
- Model Force Assignment Policy: mission-based allocation of deterministic, line, specialist, command, SOF, assurance, and reserve model capacity.
- Model Force v0.2 Operations: registry-to-compiler-to-routing-preflight procedure for dispatching heterogeneous agent forces.
- Bounded Self-Improvement Operations: evidence-driven improvement of active work and control-plane candidates with finite budgets, rollback, escalation, and human release authority.
- Guarded Supervisor Publication: fresh admission at challenge/order storage, exact reuse, and partial-issuance recovery.
- Explicit Campaign Stop: exact USER stop intake, immutable mission fencing, admitted-result retention, and explicit settlement/restart limits.
- Campaign Terminal Reconciliation: historical wave/dispatch/settlement replay and a current non-authorizing terminal inventory.
- Exact Campaign Successor Admission: full candidate proposals, fresh exact USER consent, held partial publication, immutable admissions and later-stop enforcement. Normal supervisor and dispatch gates still apply.
- Liaison Agent Model: bounded representation across external tools, teams, and agent frameworks.
- Partner Command Relationship: explicit external request, coordination, and authority relationships.
- Disciplined Method Runtime: reviewed exact-input alternatives, before/after SITREPs, canonical event order, actual drift fences/revocation and guarded completion/report consumers. Whole control-record copies are not task outputs. Novel methods, recovery and universal rollout remain open.
- Local Method Control Channel: reviewed method/channel policies, dormant stdio startup, exact initial and continuation enrollment, shared root budgets/deadline and three bounded agent metadata tools. Lost responses hold work; local enrollment is not native startup attestation or production isolation.
- Dispatch Issuance Recovery: freeze a new lease before supersession, finish only missing publications, and cancel unused issuance without restoring old authority. Pending issuance stays visible through task, report and terminal gates; legacy leases are result-only.
- Tool Use ROE: Green, Amber, Red, and Black tool-use boundaries.
- Approval Scope Policy: single-use approvals, expiry, rollback, evidence, renewal, revocation, and delegation.
- Risk Acceptance Authority: residual risk acceptance and commander-retained authority.
- Context Releasability Policy: role-based context release and final-output controls.
- Exact GitHub Release Authorization: one short-lived USER grant bound to the exact repository, tag, commit, main CI, notes, latest non-genesis monitor artifact, and verified receipt.
- GitHub Release Immutability: separately authorized repository policy activation and prospective immutable-state enforcement for future releases.
- GitHub Release Integrity Monitoring: continuous policy-drift and GitHub-signed release-attestation verification without mutation or release authority.
- Independent GitHub Release Verification: pinned TUF-chain replay, exact historical producer compatibility, and bounded brace/IPv6-zone dependency regressions without rewriting evidence or hiding unresolved advisories.
- GitHub Release Trust Checkpoint Continuity: monotonic prior-state comparison, stable run/attempt artifact lineage, rerun-fork rejection, and fail-closed rollback/equivocation detection.
- OPSEC Classification Model: EEFI, classification, releasability, and sensitive-output handling.
- Role Document Access Policy: document access by role, duty, authority, classification, and need-to-know.
- Sensitive Output Filter: digest-only detection, redaction, blocking, and escalation at output and tool boundaries.
- Interop Release Packet: the only approved boundary-crossing package for partner-facing information.
- Training Progression Model: crawl-walk-run progression and evidence-based promotion per METL task.
- Readiness-to-Authority Policy: readiness ceilings that never create approval, risk, or release authority.
- Sustainment Agent SOP: resource watches, endurance drills, and tool-outage response for the S4 agent.
- Resource Priority Policy: priority of support, preemption, starvation prevention, and FRAGO-controlled changes.
- Source Map: traceability between military doctrine sources and local framework artifacts.
- Research Compendium: research notes, interpretations, and open research gaps.
- Source Reliability Rubric: source quality, interpretation risk, and evidence handling.
- Multinational Doctrine Consistency Review: checks against US-only assumptions and terminology drift.
- Korean Military Sources and Korean Org Culture: localization notes and cultural adaptation.
- Schema Files: JSON Schema contracts for missions, orders, authority, approvals, risk, release, readiness, handoffs, routing receipts, and more.
- Sample Payloads: valid and invalid payloads for validator fixtures.
- Validator CLI Prototype: dependency-free local schema and semantic validation.
- Policy Engine Prototype: local policy decisions for tool requests.
- Reference Architecture: orchestrator, policy engine, tool gateway, evidence store, event log, and dashboard architecture.
- Runtime Automation Roadmap: path from manual doctrine docs to a tool-gated runtime.
- Skill Operational Mission Lifecycle: mandatory routing, control receipts, report/AAR handling, evidence-preserving termination, publication-time campaign checks, and retained unknown-effect holds. Terminal reconciliation and exact successor admission are separate operations; unsupported gateway containment remains open.
- Tool Effect Review: binds an unknown invocation, declared effect scope, observations, verification plan, and receipt into a non-authorizing packet. Evidence consistency is not USER consent or settled effects.
- Gateway Effect Review: classifies exact retained gateway history, preserves missing-input orphans, and binds admission/effect/containment/coordination inspection scope. It neither clears a hold nor grants execution authority.
- Gateway Effect Settlement: reconciles an exact orphan admission or signed-containment OCI reference outcome using execution-bound quorum and fresh USER judgement. Preserves original failure, consumes proof inputs once across settlement families, and requires separate post-settlement revocation. Other containment adapters and managed coordination remain open.
- Tool Effect Settlement: resolves one unknown hook outcome from an exact USER scope decision and execution-bound verifier quorum. A separate failed-agent marker survives legacy status and resume lineages; post-settlement revocation does not permit success reporting or resume. Gateway cleanup and full campaign restart remain separate.
- Enforced Dispatch And Resumable Execution: per-agent session leases, fail-closed tool admission, checkpoints, interruption, revocation, and explicit resume.
- Protected Tool Gateway Contract: identity-bound, idempotent transactions with gateway-owned admissions, exact commit correlation, and retained obligations that block hook/lease completion bypasses. Unknown gateway effect settlement remains open.
- Gateway Identity Admission: TLS 1.3 mTLS, SPIFFE X.509, signed one-use challenge, exporter-bound principal evidence, and replay-safe authenticated-reference admission.
- Protected Process Execution: policy-pinned executable/argv, signed pre-execution envelope, signed post-execution observation, exact gateway appraisal, and no-rerun recovery.
- Exact GitHub Release Authorization: terminal authorization and publication verification without widening any lower execution contract.
- GitHub Release Immutability: exact USER-authorized repository policy activation and future release immutability gate.
- GitHub Release Integrity Monitoring: tracked activation baseline, full/release-event observations, retained attestation evidence, and fail-closed scheduled monitoring.
- Independent GitHub Release Verification: complete GitHub TUF evidence, offline root replay, pinned bundle verification, and CLI-to-signed-statement cross-checks.
- GitHub Release Trust Checkpoint Continuity: USER genesis, monotonic TUF state, bounded artifact retention, publisher v0.5, and monitor v0.3.
- Verifier Execution Integrity: exact code, runtime, repository state, and execution-evidence assurance.
- GitHub Actions Native Verifier Adapter: manifest-pinned GitHub OIDC/JWKS appraisal for hosted reusable workflows.
- GitLab CI Native Verifier Adapter: manifest-pinned GitLab.com OIDC/JWKS appraisal for protected same-project pipelines.
- Verifier Pre-Dispatch Challenge: supervisor-issued nonce, liveness, deadline, and replay-resistant admission.
- Verifier Independence Assurance: provider, operator, control-plane, tenant, runner, infrastructure, region, and zone correlation.
- Transparency Operations: checkpoint consistency, witnesses, monitors, TUF root rotation, incidents, revocation, and continuous admission.
- Model Force v0.2 Fixtures: integrated registry, compilation, routing receipt, dispatch, and telemetry examples.
- Controls Doctrine Operator Skill: Codex skill for routing this corpus by task, role, department, authority, and validation surface.
- Claude Code Controls Doctrine Operator Skill: equivalent Claude Code project skill.
- AI CLI Skill Installer: installs the Codex and Claude Code skill entries.
When a human user invokes the framework directly, the human remains the final decision-maker. The AI can brief, recommend, draft, validate, and warn. It should not restrict the user's view of the repository just because an AI role would have limited access.
When an AI is acting as a role, department, staff section, or task force, it must operate within a declared boundary:
- role;
- department;
- authority scope;
- task;
- release target;
- risk level;
- need-to-know.
Delegated AI work should be routed through the Controls Doctrine Operator skill before execution.
The repository includes a routing receipt contract and preflight gate. A delegated wave should not start only because an agent says it routed its documents. It should produce a machine-checkable receipt.
Example:
node codex-skills/controls-doctrine-operator/scripts/route_controls_docs.js \
--receipt \
--scope=agent \
--mission=MIS-example \
--wave=W2 \
--agent=plans-agent \
--actor=ai \
--role=S3 \
--department=operations \
--authority=scoped-execution \
--capability-query="Define and validate the target mission capability" \
"plans-agent W2 execution planning" .Routing receipts distinguish document relevance from mission capability
coverage. If the mission objective has no specific corpus capability route,
the router returns capability_routing.status: gap_detected, assigns one
mission-scoped provisional capability cell, and opens a standing-department
candidate under the force-structure controls. The cell may analyze and draft
within the agent's existing authority; it cannot expand authority or activate
the standing department. Those decisions remain with the human USER through a
validated ForceStructureChangeOrder.
Preflight:
node agent-routing-preflight-runner.js agent-routing-preflight-fixtures/valid-wave-routing-bundle.jsonManual receipt commands remain useful for inspection and debugging. Delegated operational work should use the lifecycle controller so every expected receipt and context pack is generated and checked together:
node codex-skills/controls-doctrine-operator/scripts/operate_controls_mission.js \
open sample-payloads/valid-mission-wave-plan.json \
--repository . \
--artifact-root .cannae/artifactsThe controller returns context_dispatch_authorized: true only after routing,
optional model assignment, bounded campaign, context digest, and repository
artifact checks pass. It still returns tool_execution_authorized: false and
dispatch_authorized: false: opening a wave creates context, not executable
authority. It never grants release authority. See
Skill Operational Mission Lifecycle.
Mission open proves routing readiness; it does not authorize a tool call. Each
independently acting agent receives a separate deny-by-default policy and one
lease lineage bound to its repository, mission, wave, provider session, and last
checkpoint:
USER plan authorizes exact policy-draft digest
-> controller-compiled dispatch policy -> session lease
-> PreToolUse admission -> tool -> PostToolUse checkpoint
Hash the policy draft before opening the wave, place that digest in the
MissionWavePlan.dispatch_control.policy_authorizations row for the exact
agent/provider/policy tuple, then open, compile, and issue:
node install-dispatch-hooks.js --provider all --repository . --dry-run
node codex-skills/controls-doctrine-operator/scripts/operate_dispatch_runtime.js \
hash-input dispatch-tool-policy-draft.json --repository .
node codex-skills/controls-doctrine-operator/scripts/operate_controls_mission.js \
open mission-wave-plan.json --repository . --artifact-root .cannae/artifacts
node codex-skills/controls-doctrine-operator/scripts/operate_dispatch_runtime.js \
authorize-policy --repository . --artifact-root .cannae/artifacts \
--policy dispatch-tool-policy-draft.json
node codex-skills/controls-doctrine-operator/scripts/operate_dispatch_runtime.js \
issue --repository . --artifact-root .cannae/artifacts \
--policy-id DTP-example --session provider-session-id \
--provider-agent mainUnknown tools, replay, ambiguous rules, repository drift, expiry, and retained
actions deny by default. Complete the lease before reporting successful agent
work. resume, clear, and fork never restore authority from conversation
history; explicit checkpoint review and a lineage-continuation lease are
required. Project-local hooks cover supported local tool paths but are not a
non-bypassable security boundary. See
Enforced Dispatch And Resumable Execution.
Phase 17A adds a durable transaction around the Phase 16 dispatch admission. Phase 17B1 adds a manifest-backed authenticated principal. Phase 17B2A adds one policy-pinned ELF or Mach-O local process with signed before/after evidence. Phase 17B2B adds a measured OCI/Linux reference provider. Phase 17B2C1 composes that provider with independently appraised production admission:
TLS 1.3 mTLS + exact SPIFFE identity + one-use signed challenge
-> exporter-bound signed principal evidence
-> authenticated principal + trusted gateway config
-> exact lease/policy/checkpoint/repository/input binding
-> received -> authorized -> executing
-> signed pre-create envelope
-> immutable image + exact target + measured Docker configuration
-> kernel probe for privilege + mounts + cgroup + network
-> signed host/runtime/image/key/MAC/filesystem/network appraisal quorum
-> computed failure-domain diversity + exact deployment agreement
-> live external linearizable coordination + storage fencing
-> verified container cleanup + signed observation
-> committed receipt | aborted cancellation | recovery-required block
protected-tool-gateway.js never stores raw tool input in its ordinary audit
contracts. One idempotency key and transaction ID bind one canonical request,
and begin returns the exact execution-event reference needed by commit. An
authorized request that never started can be cancelled with the same raw input;
a crash-retained allow admission is cancelled or its lease is blocked, and an
executing request with an unknown outcome blocks the lease instead of claiming
success. Protected process and OCI sandbox inputs contain only one policy
reference and rule ID. The gateway reloads every retained policy, envelope,
probe, observation, and result binding before issuing ToolExecutionReceipt
v0.4. Once an envelope exists, retry never executes the transaction again.
The OCI reference provider uses an immutable image with an exact probe
entrypoint and directly extracts and hashes /cannae-probe before execution.
It applies
digest-pinned seccomp, non-root UID/GID, all capabilities dropped,
no_new_privs, private namespaces, read-only root and repository mounts,
cgroup v2 limits, and measured external IP egress denial. A static probe directly measures
the corresponding /proc, mount, cgroup, address, route, and connection state.
Cleanup requires a successful all-states listing excluding the exact container;
a failed inspect or unavailable daemon is not evidence of absence. A containment
retry never reruns the target or converts recovery_required into success.
The v0.2 envelope also binds the observed daemon ID. Recovery retains a separate
signed, fresh containment observation after checking the original daemon and
CLI on both sides of cleanup. This is reference evidence, not independent host
attestation, gateway settlement, or managed coordination proof.
Phase 17B2B alone remains reference execution and keeps production execution
false. Phase 17B2C1 raises production_execution_authorized only for a
request v0.3 whose exact OCI policy is covered by a current USER policy, fresh
independently signed appraisals from at least two computed failure domains, a
separately signed admission, and a live external coordinator whose identity
matches the appraised deployment. Admission, begin, commit, and recovery all
recheck that boundary. Terminal receipt v0.5 records whether the deployment
remained verified; release authorization remains false.
This repository validates and composes those claims. It does not operate the TPM/TEE, KMS/HSM, registry, hardened host, external coordinator, storage fencing, or installation-level side-path controls that make them true. The standalone gateway CLI therefore has no managed-production coordinator and denies that path. See Protected Tool Gateway Contract and Gateway Identity Admission, then Protected Process Execution and OCI Linux Sandbox Provider, followed by Production Sandbox Admission.
Model selection is a separate control from agent routing and authority. Define an immutable registry snapshot and mission billet request, compile only eligible profiles, then bind current-wave receipts and billets through the integrated preflight:
node model-assignment-compiler.js \
sample-payloads/valid-model-registry.json \
sample-payloads/valid-model-assignment-request.json
node integrated-mission-preflight-runner.js \
sample-payloads/valid-integrated-mission-preflight.jsonOnly a ready integrated projection emits dispatch rows. The model profile never inherits approval, risk acceptance, or release authority from its capability band.
For multi-repository campaigns, durable AI outputs are stored under a stable repository identity instead of a shared flat output directory:
.cannae/artifacts/repositories/<repository-key>/missions/<mission>/<wave>/<kind>/
Use repository-artifact-store.js, or pass --write-artifact --repository <target> to the model compiler and integrated preflight. Routing receipts use --write-artifact --target-repository <target>. See Repository Artifact Isolation Policy.
Substantial AI missions can maintain a finite improvement campaign around work already in progress:
campaign -> verifier workload proof -> runtime-policy admission -> finite cycle order -> candidate -> executed receipt/report -> execution evidence -> signed quorum -> decision -> next admission
verification-runner.js executes exact argument arrays without a shell and persists repository-state-bound receipts. A v0.3+ campaign additionally requires fresh Ed25519 DSSE receipt attestations from distinct trusted keys and policy-defined independence groups. For skill and runtime_control candidates, comparative-evaluation-runner.js executes one pre-persisted harness and one sealed evaluation set against isolated baseline and candidate worktrees, then applies campaign-owned absolute and non-regression thresholds. Schema v0.4 also requires comparative-evaluation-attestation-runner.js to bind a fresh multi-key, multi-group quorum to the exact persisted report, plan, evaluation set, baseline, candidate, evaluator invocation, campaign, and repository. Verifier keys can be purpose-limited, so receipt trust does not implicitly grant comparative-report signing authority. autonomous-improvement-controller.js reloads and recomputes the report and both quorums with the trust policy, accepted parent, and any consumed approval event before promotion.
Trust-policy v0.2 additionally requires a current manifest-backed VerifierIdentityEvidence for every verifier counted at dispatch; v0.3 can use native Sigstore bundles instead. campaign-supervisor.js independently verifies the selected workload adapter and emits ready only when authenticated verifier populations can form every purpose quorum.
Phase 12A trust-policy v0.4 also binds an exact VerifierRuntimePolicy. Every counted receipt or report attestation must cite fresh, manifest-backed VerifierExecutionEvidence dual-signed by a separate trusted builder and the registered verifier. It fixes the verifier code, immutable OCI image, dependency lockfile, harness, argv, tool allowlist, network and sandbox controls, provider claims, exact repository state and verification target. Phase 14 adds runtime-policy and execution-evidence v0.3 native adapters: GitHub-hosted reusable workflows and protected same-project GitLab.com pipelines can be admitted through strict manifest-pinned JWKS and OIDC signature/claim verification. Enterprise/self-managed providers, self-hosted runners, local hosts, and TEE appraisal remain futur
10BC8
e work. See Verifier Execution Integrity, GitHub Actions Native Verifier Adapter, and GitLab CI Native Verifier Adapter.
Phase 12B trust-policy v0.5 adds a supervisor-issued, single-use VerifierChallengeSet before every bounded dispatch. Each verifier must return fresh dual-signed workload identity evidence containing its exact nonce inside the deadline. Cycle-order v0.5 records exact challenge/response references and rejects missing, late, wrong-nonce, ambiguous, expired, replayed, or offline responders before quorum calculation. See Verifier Pre-Dispatch Challenge.
Phase 12C trust-policy v0.6 replaces declared independence labels with deterministic failure domains. Runtime-policy v0.2 records nine provider, operator, control-plane, account, project, runner, infrastructure, region, and zone identities; sharing any component correlates verifiers transitively. Execution-evidence v0.2 binds the observed identities under builder and verifier signatures, and receipt/report quorum uses computed VID-* domains. See Verifier Independence Assurance.
Phase 13 trust-policy v0.7 requires a current append-only TransparencyState before dispatch. Signed log checkpoints must connect through RFC 6962 consistency proofs and satisfy separate witness and monitor operator quorums; TUF root changes require old/new thresholds, USER activation, and retained expiry boundaries; incidents and revocations remain immutable history. The supervisor reconstructs the full state sequence and reloads every embedded evidence object from the repository manifest. See Transparency Operations.
Every decision and cycle order keeps release_authorized: false; trust-root changes, policy, authority, merge, push, and external release remain human decisions. See Bounded Self-Improvement Operations.
Use self-improvement-campaign-init.js to bind conservative campaign defaults to a target Git repository before the first adaptive wave.
node campaign-supervisor.js \
--repository ../target-repository \
--campaign SIC-example \
--artifact-root .cannae/artifacts \
--write-artifactDelegated agents may execute only a cycle order whose status is ready, execution_authorized is true, trust_policy_admission.satisfied is true, required identity_assurance.satisfied is true, and current time is earlier than its signed-campaign valid_until. Re-running the supervisor against unchanged campaign and admission state returns the existing order without advancing the manifest.
The comparative runner returns exactly promotable, rollback, or inconclusive. Even promotable sets both execution_authorized and release_authorized to false; it is evidence for the controller's working-state decision, not permission to merge, push, or release.
Artifact manifest v0.4 uses expiring namespace leases, monotonic fencing tokens, immutable no-overwrite history, a write-ahead journal, and hash-linked manifests. Run repository-artifact-verify.js --repository <target> --artifact-root <root> before accepting a wave or consuming its proof. The built-in shared-filesystem coordinator assumes coherent atomic filesystem operations and is not partition-tolerant.
The framework keeps these decisions out of ordinary agent autonomy:
- final or external release;
- high or critical residual risk acceptance;
- irreversible or destructive action;
- expansion of mission scope or authority;
- release of restricted or EEFI-bearing context;
- creation, expansion, reduction, or disbanding of force structure without a validated order.
Every mission, campaign, verifier, dispatch, gateway, process, sandbox, and
production artifact keeps release_authorized: false. After the USER
explicitly selects one release, the terminal publisher can issue a short-lived
GitHubReleaseAuthorization with release_authorized: true for only:
repository + stable tag + full commit + successful main CI + notes digest
+ enabled immutable-releases policy + exact GitHub release attestation
+ pinned GitHub TUF chain + independent Sigstore bundle verification
+ successful ready full-monitor observation
+ fresh monotonic trust checkpoint + exact retained root + provider lineage
The publisher rechecks those values, creates the tag/release from the full
commit SHA, reloads GitHub state, resolves the remote tag, compares the release
body, requires isImmutable: true, verifies and retains GitHub's signed
repository/tag/commit/asset statement, replays the complete pinned GitHub TUF
chain, independently verifies the bundle with pinned Sigstore code, and
records consumption in GitHubReleaseReceipt. Drift, expiry, a disabled
policy, a blocked or forged observation, a partial tag/release, stale trust
material, or a mismatched release or attestation blocks publication. The
publisher rechecks mutable state after lineage resolution and never creates a
second release while reconciling an exact post-create verification failure.
Repository policy activation uses a separate short-lived USER grant and never grants release authority:
node codex-skills/controls-doctrine-operator/scripts/operate_github_release_immutability.js \
authorize \
--repository-root . \
--repository <owner/repo> \
--run-id <successful-main-validate-run-id> \
--grant-id <USER-policy-grant-id> \
--output .cannae/release-policy/immutability/authorization.jsonnode codex-skills/controls-doctrine-operator/scripts/operate_github_release.js \
authorize \
--repository-root . \
--repository <owner/repo> \
--tag <vX.Y.Z> \
--name "<release name>" \
--notes <tracked-release-notes.md> \
--run-id <successful-main-validate-run-id> \
--grant-id <USER-grant-id> \
--trusted-root .cannae/releases/<tag>/github-trusted-root.json \
--trust-checkpoint .cannae/releases/<tag>/github-release-trust-checkpoint.json \
--output .cannae/releases/<tag>/authorization.jsonActive publication accepts only authorization v0.5. It must consume and verify the exact retained full observation, GitHub TUF root, and monotonic checkpoint with an explicit current UTC evaluation time, then prove the triplet and its successful provider run remain valid through the operation boundary before any release creation call.
Continuous read-only monitoring is separate from both authorities:
node codex-skills/controls-doctrine-operator/scripts/operate_github_release_integrity.js \
monitor \
--repository-root . \
--policy .github/release-integrity-policy.json \
--trusted-root-output .cannae/release-integrity/manual-root.json \
--trust-checkpoint-output .cannae/release-integrity/manual-checkpoint.json \
--output .cannae/release-integrity/manual.json \
--scope full \
--trigger manualIf the first provider runs retained exact blocked observation/root pairs but no checkpoint, Phase 19E offers one evidence-derived recovery command:
node codex-skills/controls-doctrine-operator/scripts/operate_github_release_integrity.js \
authorize-bootstrap-recovery \
--repository-root . \
--user-grant-id <exact-USER-grant> \
--granted-at <UTC-timestamp-after-all-failed-artifacts> \
--authorized-at <current-UTC-timestamp> \
--expires-at <at-most-60-minutes>It binds every exact failed run, artifact, observation, fresh genesis, root, and original policy-introduction boundary. It cannot skip missing evidence, consume a complete checkpoint, run from a rerun or offline caller, reset lineage, repair policy, or authorize release.
See GitHub Release Immutability and Exact GitHub Release Authorization for the activation/publish commands. See GitHub Release Integrity Monitoring for attestation, credential, schedule, and incident boundaries, and Independent GitHub Release Verification for TUF and bundle replay, and GitHub Release Trust Checkpoint Continuity for monotonic prior-state and artifact-lineage controls.
Requirements:
- Node.js for local runners and validators.
- OpenSSL 3.x for verifier workload-identity fixtures.
- Bash-compatible shell for the installer and validation loops.
- Python 3 only for optional Codex skill validation.
Install the exact lockfile dependencies in a clean checkout:
npm ci --ignore-scriptsRun the main validation suite:
node validator-cli-prototype/run-fixtures.js
for f in $(ls run-*.js | sort); do node "$f" || exit 1; done
node source-map-linter.jsCheck corpus routing coverage:
node codex-skills/controls-doctrine-operator/scripts/route_controls_docs.js --coverage .Install local AI CLI skills:
./install-ai-cli-skills.shRoute a user-facing framework question:
node codex-skills/controls-doctrine-operator/scripts/route_controls_docs.js \
--actor=user \
"How should I operate a multi-agent implementation campaign?" .Route a delegated AI operator:
node codex-skills/controls-doctrine-operator/scripts/route_controls_docs.js \
--actor=ai \
--role=S3 \
--department=operations \
--authority=scoped-execution \
"Prepare an execution plan for a bounded documentation update." .Open a delegated mission wave through the enforced lifecycle:
node codex-skills/controls-doctrine-operator/scripts/operate_controls_mission.js \
open sample-payloads/valid-mission-wave-plan.json \
--repository . \
--artifact-root .cannae/artifactsThe repository intentionally includes many small runners instead of one large runtime. Each runner verifies a narrow control boundary.
Important examples:
validator-cli-prototype/run-fixtures.js: schema and semantic validator regression suite.run-authority-integration-fixtures.js: scoped approval and risk acceptance composition.run-release-integration-fixtures.js: separation between execution approval and release review.run-release-gate-decision-fixtures.js: release gate event audit consistency.run-github-release-immutability-fixtures.js: exact USER policy grant, repository ADMIN/main-CI binding, one activation, post-action verification, prospective historical state, and idempotent retry gates.run-github-release-publisher-fixtures.js: exact USER grant, repository/tag/commit/main-CI/notes binding, ready artifact lineage, pre-create expiry/policy drift, trusted-root schema, post-create reconciliation, immutable publication, signed-attestation scope, receipt, and idempotency gates.run-github-release-integrity-fixtures.js: committed read-only policy baseline, credential uncertainty, stale repository state, immutable workflow source, full-observation replay, drift, mutable release, attestation substitution, missing historical state, release-event scope, and authority-boundary gates.run-github-release-independent-verification-fixtures.js: real GitHub release bundle, complete TUF replay, DSSE and CLI cross-checks, root/targets mutation, commit substitution, wrapper-rehash, and authority-boundary gates.run-github-release-trust-checkpoint-fixtures.js: monotonic TUF sequence, rollback/equivocation, root/retrieval continuity, bounded bootstrap, completed default-branch reruns, latest-artifact non-fallback, required observation/root/checkpoint ZIP members, producer binding, and archive-safety gates.run-document-access-fixtures.js: role, duty, authority, and need-to-know document access.run-doctrine-consistency-fixtures.js: non-US source-family coverage and US-only assumption blocking.run-sof-tf-fixtures.js: high-risk task force activation gates.run-force-structure-change-fixtures.js: organization change evidence, alternatives, readiness, handoff, and sunset gates.run-model-force-assignment-fixtures.js: task readiness, model routing, force composition, independent assurance, PACE, and authority-separation gates.run-model-force-v0.2-fixtures.js: registry eligibility, deterministic compilation, agent/billet/receipt binding, dispatch manifest, and usage telemetry gates.run-agent-routing-preflight-fixtures.js: routing receipt preflight for delegated agent waves.run-skill-mission-controller-fixtures.js: full open/report/close lifecycle, mandatory per-wave routing, context-versus-tool authority separation, exact one-policy-per-agent planning, settled dispatch-lineage reporting, model binding, bounded AAR improvement, and multi-repository isolation.run-dispatch-runtime-fixtures.js: plan-digest policy authorization, concurrent one-lineage issuance, ordered cross-agent repository handoff, exact tool admission and post-tool correlation, serial result checkpoints, replay, drift, interruption, same-session resume, revocation, expiry, retained-action, malformed-hook, cross-session, cross-agent, and cross-repository gates.run-protected-tool-gateway-fixtures.js: trusted principal/gateway binding, exact transaction/idempotency admission, execution-token commit, raw-input non-retention, operation-class substitution, cancellation, orphan-admission revocation, and unknown-outcome recovery.run-protected-process-executor-fixtures.js: real exact executable/argv execution, signed policy/envelope/observation binding, caller-result, shebang, and executable-drift rejection, timeout recording, forbidden repository-effect rejection, and no automatic rerun after an execution claim.run-oci-linux-sandbox-provider-fixtures.js: required-in-CI live probe compilation and scratch-image execution, signed pre-create/post-cleanup evidence, Docker and kernel control measurement, caller-result, profile/image/probe substitution rejection, timeout, unavailable-daemon and malformed-listing cleanup rejection, exact-name containment, both CLI recovery exits, and no-rerun recovery.run-production-sandbox-admission-fixtures.js: signed appraisal quorum, transitive failure-domain collapse, deployment agreement, exact OCI scope, foreign policy, expiry, tamper, and wrong-key rejection.run-production-sandbox-gateway-fixtures.js: Codex/Claude wrapper resolution, live TLS identity, exact production admission, mandatory external coordination, foreign-repository handle rejection, recovery, v0.5 receipt projection, and release separation.run-repository-artifact-isolation-fixtures.js: repository identity, namespace separation, file/JSON persistence, overwrite, and traversal gates.run-repository-artifact-concurrency-fixtures.js: 24-writer serialization, monotonic fencing, foreign-host lease expiry, and stale-writer rejection.run-repository-artifact-recovery-fixtures.js: journal recovery, reserved-history finalization, history reconciliation, and artifact/manifest tamper detection.run-self-improvement-fixtures.js: executed receipts, parent lineage, approval consumption, rollback, completion, and proof-store integration.run-signed-self-improvement-fixtures.js: backward compatibility plus two-key/two-group quorum, signature tamper, duplicate signer, and trust-policy expiry gates.run-verification-runner-fixtures.js: shell/inline-code prohibition, stale-plan rejection, exact argv receipts, and repository-mutation detection.run-verification-attestation-fixtures.js: Ed25519 DSSE signatures, persisted/self-digest binding, quorum diversity, replay expiry, signer-purpose policy, and private-key file controls.run-comparative-evaluation-fixtures.js: real baseline/candidate worktrees, campaign-bound sealed fixtures, absolute and non-regression thresholds, pre-persisted plans, cross-mission rejection, harness mismatch, report tamper, and manifest custody.run-comparative-evaluation-attestation-fixtures.js: signed report-artifact binding, two-key/two-group quorum, replay expiry, origin and signer-purpose policy, lineage/evaluator/repository rebinding, CLI portability, and private-key file controls.run-verifier-identity-evidence-fixtures.js: real SPIFFE X.509 chains, dual key-possession signatures, evidence freshness, exact URI SAN, transparency checkpoint, and Merkle inclusion adversarial cases.run-workload-identity-admission-fixtures.js: manifest-backed supervisor admission with valid, missing, and invalid workload identities.run-verifier-independence-fixtures.js: declared-label bypass, shared-component and transitive correlation, dual-signed domain evidence, mutation, and quorum-diversity gates.run-document-routing-fixtures.js: Codex/Claude natural-language route parity, human final-authority mode, and bounded delegated-AI routing.validation-suite-runner.js: one shell-independent entry point for routing, corpus, validator, runner, source-map, syntax, and whitespace gates.
docs/ Doctrine, policies, source map, roadmap, operating models
schema-files/ JSON Schema contracts
sample-payloads/ Valid and invalid validator payloads
*-fixtures/ Bundle-level regression fixtures
*-runner.js Focused policy, projection, or preflight runners
validator-cli-prototype/ Dependency-free validator prototype
policy-engine-prototype/ Tool-use policy prototype
dispatch-*-controller.js Session lease and covered-tool admission runtime
codex-skills/ Codex Controls Doctrine Operator skill
.claude/skills/ Claude Code Controls Doctrine Operator skill
Cannae OS is currently a doctrine and prototype repository.
Working today:
-
mandatory plan-bound intent commitments and multi-echelon boundary checks in context generation, report admission, policy compilation, leases and covered-tool admission; legacy contexts remain historical rather than silently upgraded;
-
structured doctrine and policy documents;
-
schema contracts and sample payloads;
-
local semantic validator;
-
focused policy and projection runners;
-
document routing skill for Codex and Claude Code;
-
routing receipt and preflight model for delegated agent waves;
-
operational Codex/Claude mission lifecycle with automatic receipts, digest-bound context packs, manifest-backed reporting, AAR closeout, and bounded follow-on work;
-
manifest-backed per-agent dispatch policies, short-lived session leases, covered-tool admission events, serial post-tool checkpoints, revocation, interruption, and explicit resume for Codex and Claude Code hooks;
-
manifest-backed protected-tool requests, decisions, append-only transaction events, executor-bound receipts, exact cancellation, and unknown-outcome recovery;
-
deterministic manifest-backed campaign supervision with finite cycle and retry orders;
-
authenticated verifier workload admission with short-lived SPIFFE X.509 evidence and transparency inclusion;
-
native Sigstore workload admission with manifest-pinned TrustedRoot material, exact Fulcio identity/issuer policy, Rekor/CT verification, and dual binding to the static verifier key;
-
verifier execution-integrity contracts with exact runtime-policy admission, dual-signed in-toto execution evidence, immutable OCI/code/dependency/harness bindings, repository-state and target-digest checks, and fail-closed quorum integration;
-
supervisor-issued pre-dispatch verifier challenges with exact dispatch binding, dual-signed nonce responses, deadline enforcement, single-use replay checks, and cycle-order v0.5 admission;
-
computed verifier failure-domain assurance with strict component identities, transitive correlation, dual-signed execution observations, and cycle-order v0.6 admission;
-
exact USER-authorized repository release-immutability activation with verified prospective policy state and no release-authority widening;
-
continuous immutable-policy and GitHub-signed release-attestation monitoring with explicit credential uncertainty and no mutation authority;
-
independent retained-bundle verification with complete pinned GitHub TUF evidence, Sigstore replay, and CLI-to-signed-statement cross-checking;
-
provider-retained monotonic GitHub TUF checkpoints with rollback, equivocation, fork, full-observation replay, immutable workflow source, artifact, producer, and bootstrap controls;
-
short-lived exact GitHub release authorization and independently attestation-bound terminal receipts, with all lower runtime artifacts retaining release false;
-
regression fixtures for authority, approval, release, handoff, readiness, force structure, SOF TF, and document access controls.
Not complete yet:
- production-grade orchestrator;
- persistent event store;
- production approval UI;
- provider-operated managed-exclusive tool gateway adapters and side-path isolation for real external systems;
- authenticated multi-user permissions;
- operation of a production SPIFFE Workload API, Fulcio, Rekor, CT log, TUF root service, monitor, witness, or gossip network;
- formal compliance certification;
- automatic hallucination elimination.
Cannae OS is an operating framework, not a guarantee of correct outputs.
- It does not make LLMs hallucination-free.
- It does not replace source verification, domain review, legal review, security review, or human judgment.
- It does not provide military, legal, medical, financial, or safety-critical advice.
- It should not be used to plan, enable, or optimize violence, surveillance, coercion, or illegal activity.
- Military terminology is used as an organizational metaphor and control vocabulary, not as operational battlefield instruction.
- Many documents are research drafts and should be treated as evolving doctrine, not final standards.
- The runtime code is prototype-grade and optimized for transparent local validation, not production performance.
- Trust-policy v0.4+ verifies a separate builder's signed claim that exact code and declared isolation controls produced the evidence. It does not make a compromised builder truthful, natively enforce the declared sandbox, or establish protected key hardware. Trust-policy v0.5 proves bounded liveness at challenge response time. Trust-policy v0.6 blocks known shared failure domains, but still depends on honest native adapters and cannot prove absence of every upstream common-mode dependency.
- The provider-neutral X.509 verifier is intentionally bounded and does not implement full RFC 5280 policy/revocation processing or the SPIFFE Workload API. The native Sigstore adapter verifies official bundle and TrustedRoot formats through pinned libraries, but it does not operate or globally monitor Fulcio, Rekor, CT logs, TUF, witnesses, or gossip.
- Phase 13 verifies supplied checkpoint, consistency, observer, root, incident, and revocation evidence but does not poll Rekor, discover shards, operate TUF metadata services, or provide a witness/monitor/gossip network. A withheld split view still requires external independent observers to expose it.
- The shared-filesystem lease backend is not a consensus system. Partition-tolerant multi-host operation requires an external linearizable coordinator and storage-side fencing enforcement.
- The campaign supervisor issues and persists bounded, time-limited cycle orders; it does not execute agent work, create checkpoints, produce evidence, resolve an escalation, or grant release authority.
- Project-local Codex and Claude hooks are bypassable client-side guardrails and do not cover every provider execution path. Strict concurrent isolation requires separate repository-scoped sub-missions/worktrees and top-level sessions followed by an integration wave, plus managed controls, an OS sandbox, or an independently protected tool gateway. Codex's documented hook payload also does not provide a unique identity for internal subagents.
- The Phase 17A gateway core is a transaction/reference controller. Phase 17B2B can invoke one measured OCI/Linux reference provider but does not prove its own deployment. Phase 17B2C1 verifies independently signed deployment claims, exact OCI scope, computed failure-domain quorum, and an injected external coordinator before production execution can become true. It still depends on honest provider adapters and does not itself operate protected hardware, registry policy, the coordinator, storage fencing, or side-path isolation. Release remains fixed to false.
- The exact GitHub release authorization uses a canonical integrity digest, not
a USER digital signature. It trusts the authenticated
ghaccount, local operator environment, configured GitHub workflow, and platform controls; it does not provide signed tags or credential isolation. Repository immutability protects only releases created after Phase 19A activation; historicalv0.2.0remains non-immutable. Phase 19B monitors platform state, and Phase 19C independently replays retained bundles and the complete GitHub TUF chain with pinned Sigstore code. Phase 19D compares each refresh with the prior GitHub Actions observation/root/checkpoint artifact, executes the pinned default-branch workflow source, and requires a successful ready observation before release admission, but that artifact can expire or be deleted and is not an independent archive or witness. GitHub still operates the signer, Fulcio/TSA services, policy service, workflow artifact service, and TUF repository; two verifiers in one job are not independent infrastructure failure domains. Phase 19E can recover only an unestablished initial sequence from exact retained two-file failures under a short-lived USER contract; it is not an established-lineage reset and does not make a blocked monitor ready. Full policy monitoring also needs a separately scoped Administration-read credential. - Campaign v0.1 supervision does not resume past an
escalatedecision automatically. Resumption needs a future explicit, manifest-backed human-resolution contract or a new bounded campaign. - Source mappings are useful traceability aids, but they do not prove that an interpretation is universally valid.
- US doctrine is not treated as universal; multinational and local adaptation remain required.
Generated reports, local settings, and transient dashboard projections should not be treated as durable source of truth unless explicitly checked in as fixtures. The repository's .gitignore excludes local reports, caches, logs, editor state, environment files, and non-skill Claude local settings.
Durable truth should live in:
- doctrine documents;
- schemas;
- fixtures;
- runners;
- source-map entries;
- committed skill instructions.
Contributions should preserve the framework's control discipline.
Start with:
Before opening a change:
- Route the change through the Controls Doctrine Operator skill if the affected surface is unclear.
- Update the relevant document and index together.
- If a runtime contract changes, update schema, valid sample, invalid sample, validator map, semantic rules, and fixture runner together.
- Add a regression fixture for every unsafe case that the change is meant to block.
- Run the smallest relevant validation first, then broaden.
Recommended full local check:
node codex-skills/controls-doctrine-operator/scripts/route_controls_docs.js --coverage .
node validator-cli-prototype/run-fixtures.js
for f in $(ls run-*.js | sort); do node "$f" || exit 1; done
node source-map-linter.js
git diff --checkNear-term:
- exercise enforced dispatch in additional real Codex/Claude multi-session campaign trials and harden managed-hook installation;
- tighten public documentation and contribution structure;
- continue removing generated artifacts from source control;
- improve source-map coverage and source interpretation notes;
- expand fixture coverage around routing, release, and authority mismatches;
- extend native provider adapters beyond the implemented GitHub Actions and GitLab.com OIDC paths to enterprise/self-managed providers, self-hosted runners, cloud, local-host, and TEE evidence;
- implement provider adapters that collect Rekor checkpoints, consistency proofs, shard metadata, witness signatures, and monitor reports for v0.7;
Mid-term:
- define a persistent event model for missions, approvals, releases, handoffs, and AARs;
- deploy the protected policy gateway behind independently operated identity, admission, coordination, and storage-fencing providers as the only side-effect path;
- connect approval scope and release gates to that gateway;
- implement authenticated self-hosted runner, local sandbox, and TEE execution-evidence adapters;
- operate production transparency polling, witnesses, monitors, gossip, TUF distribution, and incident response around the implemented Phase 13 verifier;
- operate independently durable release-trust checkpoint storage and cross-provider liveness monitoring around Phase 19D;
- build a useful command-post dashboard from event projections;
- formalize an evidence store for claims, sources, reliability, and interpretation.
Long-term:
- make Cannae OS a reusable control plane for human-led AI teams;
- support different organizational cultures and doctrine families without hard-coding US assumptions;
- support measurable agent readiness and authority delegation;
- close the loop from AAR findings to SOP, policy, and readiness updates.
This repository is open source under a dual-license model:
You may use, copy, modify, and distribute this project under either license, at your option.
SPDX-License-Identifier: Apache-2.0 OR MIT