Mission Guardian

Status

Main product direction for agentic execution guardrails.

Field	Value
Server routes	mission-guardian
Use cases	core/use-cases/mission-guardian
Maturity	beta
Active first-party pack	deck-guardian — draft_for_validation (as of 2026-05-27, P0-2)

Deck Guardian readiness

Deck Guardian passes the extended runtime cohesion checks at load time:

• structural validator (validateGuardianPackDefinition including event-policy xrefs and runtime-role xrefs);
• findOrphanPackTools(toolPolicy, runtimeExposedTools) returns [];
• findUnsupportedPackRoleEntries(toolPolicy) returns [];
• a stderr diagnostic is emitted by FsGuardianPackCatalog if a future pack fails either check, and the diagnostic is also exposed via FsGuardianPackCatalog.getLastCohesionDiagnostic(packId).

Promotion to validated is held until the upcoming CapabilityRegistry lot: a few governance actions referenced by the pack (notably mission_guardian.assess_impact, mission_guardian.request_audit, mission_guardian.reference_existing_concept, mission_guardian.request_run_validation) live in tool_policy.pending_capabilities.future_capabilities_for_capability_registry and are not injected into agents until the registry is implemented. Human validation actions (validate_concept, validate_run, validate_cloture_*) are intentionally routed through cards and the backend POST /api/projects/:id/agent-action-cards/:cardId/select, not through tool_policy.mode_tools.

Role

Mission Guardian covers gate decisions tied to missions, leader, QA and orchestration transitions. It makes blockers explicit, traceable and actionable before an agent or a leader continues a mission.

Mission Control is the runtime-facing view exposed to agents: it summarizes the active flowmap, current mode, blockers and expected next documents. Mission Guardian remains the gate authority; Mission Control is the operational reading surface.

Mission Control is injected into every visible agent session. In solo mode, the agent receives gates/events/flowmap without squad or orchestration concepts. In team mode, the leader receives audited orchestration tools; workers, QA and observers receive the same gates/events/flowmap frame, but without dispatch rights.

Dispatch rights are not prompt-only: orchestration write tools are session-bound and rejected by the system unless the current agent is the active squad leader. The generic project MCP arka_runtime does not publish these write commands.

Surfaces

Surface	Detail
Server routes	mission-guardian (Fastify route groups)
Core use cases	core/use-cases/mission-guardian
Runtime prompts	Local Mission Control bundle installed into Cortex Lite; Cortex Public feed planned for phase 2
Runtime MCP	mission_guardian_explain_events, mission_control_read_flowmap, ArkaDoc/squad/tasks tools through arka_runtime according to role
Integrations	squad-leader via transition guards, squad-orchestration via the mission pipeline
UI view	GuardianPackAdminView (Mission Control, guardian pack administration, flowmap and rules)
Event Lab	Registry, project stream, binding inspector, pack validator and dry-run scenarios for module events
Runtime compiler	guardian-runtime-compiler compiles active artifacts into an agent injection packet

Event Lab

Event Lab is a pre-governance control surface inside Mission Guardian. It lists the events declared by modules, shows the events observed for a project, explains how the active guardian pack matches them, and dry-runs scenarios without mutating runtime state.

V1 covers the declared event catalogs for ArkaDoc, memory, workers, providers, project connectors/MCP, and action cards. The real producers wired to the module bus are ArkaDoc status changes, memory notes/rollups, action-card validations, project MCP status changes, completed/failed worker runs, and provider failures attached to a project session. Local HTTP routes:

• GET /api/event-lab/catalogs
• GET /api/projects/:projectId/event-lab/stream
• POST /api/projects/:projectId/event-lab/inspect
• POST /api/projects/:projectId/event-lab/scenarios/dry-run
• GET /api/projects/:projectId/event-lab/pack-validator
• GET /api/projects/:projectId/event-lab/scenarios
• POST /api/projects/:projectId/event-lab/scenarios

The UI exposes five tabs: Registry, Stream, Inspector, Validator, and Scenarios. A dry-run can be saved as a project scenario, then replayed later to verify a guardian pack after changes. The inspector also reports invalid pack bindings even when the currently inspected event does not match them, so typos in event type, facets or predicate operators are visible before runtime.

The event registry uses a self-declaration contract: each module or addon can provide a ModuleEventCatalogProvider exposing its event catalogs without modifying Event Lab. The pack validator reads the active guardian pack from Cortex Lite, checks every binding against those declared catalogs, and shows declaring providers, ready effects, blocking errors and schema mistakes before a real event opens a card or transition.

Dry-run scenarios force payload.synthetic = true and do not publish to the runtime EventBus, create cards, or advance modes. If no guardian pack is active in Cortex Lite, Event Lab remains usable for registry/stream reading and returns GUARDIAN_PACK_UNAVAILABLE for pack-dependent inspection.

Runtime Injection

Mission Guardian injection goes through guardian-runtime-compiler. The runtime first builds a deterministic Mission Control packet (current mode, role, flowmap, obligations, events, and allowed tools), then the compiler assembles the due layers from the active pack artifacts.

The preview GET /api/projects/:projectId/mission-control/runtime-packet-preview lets developers inspect the compiled packet for a given role (solo_agent, team_leader, team_worker, team_qa, team_observer) without launching an agent session.

The CI guard npm run guardian:runtime:check verifies that long texts from guardian pack JSON files are not copied into runtime source code. Rules and prompts live in packs; the system reads, compiles, and applies them.

Recommended public framing

• “Mission Guardian enforces mission guardrails and makes refusals visible.”
• Do not promise complete autonomous Mission Control embedded in arka-deck — Mission Guardian covers mission gates, not every operating policy.

Boundaries

• Automatic CR integration is still in progress.
• Consumed evidence and its schemas are defined by use cases; consuming addons must not create parallel routes.
• Dispatch gates require ArkaDoc task document ids. A business task_id stored inside a task payload is only an alias and must not be used as the dispatch id.
• dispatch_ready exists as a derived capability for one or more dispatchable tasks. It is no longer a global modeId: the mode remains tasking, and dispatch starts only when the runtime accepts the requested scope.
• Cortex Lite is the source of truth for the active guardian pack artifacts. arka-deck no longer carries a hardcoded base pack in the core runtime; each governance pack includes its own mode registry, transitions, tools, complete rules, mini rules, mode rules, flowmap, event policy, UI card templates, prompt layers and document requirements.
• Guardian pack runtime packets apply to every runtime role: solo_agent, team_leader, team_worker, team_qa and team_observer.
• A project can run with zero or one guardian pack. Business packs provide their own dedicated guardian pack instead of overriding a shared base pack.
• Event Lab is not a governance engine. It observes and simulates; Mission Guardian and the active guardian pack remain the authority for runtime decisions.

Going further

• Squad Orchestration: ./squad-orchestration