Modules and Packs

arka-deck combines three families that should not be confused:

• a system module provides a native application capability;
• an addon adds a first-party capability that can be enabled or administered;
• a pack brings versioned content applied to a project: rules, profiles, documents, flowmap, cards, prompts and event policies.

This page is the product map for understanding what is installed, what is enabled per project, and what becomes the runtime source of truth.

---

Overview

Element	Nature	Role	Runtime source of truth
Cortex Lite	Local runtime module / sidecar	Local project graph, agent context, arka_runtime MCP	Local SurrealDB + materialized artifacts
ArkaDoc	Document module	Work documents, tasks, decisions, reports, QA verdicts	Project documents + Cortex Lite index
Project Documentation	Product view	Read ArkaDoc deliverables and navigate by index	Documentation routes + ArkaDoc
Mission Guardian	First-party addon	Administers and applies governance packs	Active pack materialized in Cortex Lite
Deck Guardian Lite	Guidance pack	Alpha build-in-public guidance for agents	Project governance setting + prompt injection
Deck Guardian	First-party governance pack	Default mission frame for an arka-deck project	Pack artifacts in Cortex Lite
Guardian Runtime Compiler	Technical addon	Compiles active pack artifacts into compact agent injection	Active pack + runtime state
Expert Panel	Capability addon	Expert Pack infrastructure not exposed in this release	No pack published by default
Squad Leader	First-party addon	Composes a squad and identifies the leader	Project state + profiles
Squad Orchestration	First-party addon	Runs audited multi-agent work	ArkaDoc tasks + squad + gates
Memory Local	First-party addon	Captures and consolidates useful memory	Project memory + Cortex Lite
Event Lab	Mission Guardian surface	Observes, inspects and simulates module events	Event catalogs + active pack

---

Cortex Lite

Cortex Lite is the project’s local runtime. It runs as an HTTP sidecar and uses SurrealDB to materialize a local graph.

Its role is not to store files. It links the runtime objects:

• project;
• ArkaDoc documents;
• memory;
• profiles and squads;
• rules, modes, flowmaps and governance packs;
• module events;
• MCP tools exposed to agents.

Agents do not need to infer project state by walking the filesystem. They resolve structured context through local routes and the arka_runtime MCP.

If Cortex Lite is unavailable, arka-deck’s local runtime capabilities are unavailable: Mission Guardian, orchestration, structured memory, materialized ArkaDoc and project injections must not be simulated.

---

ArkaDoc

ArkaDoc is arka-deck’s document module. It moves agentic work out of chat and makes it governable.

Document types

Type	Usage
brief	Framing, context, objective, constraints, open questions
spec	Functional or technical specification
task	Work assignable to an agent or worker
cr	Production report
qa_verdict	QA verdict for a task or mission
decision	Traceable human or system decision

Statuses

Status	Product meaning
draft	Draft, not ready to be consumed
ready	Ready: can be validated, dispatched or used depending on type
submitted	Submitted by an agent or worker, waiting for review
accepted	Accepted
rejected	Needs rework
archived	Removed from the active flow

For a task, the UI exposes simple human actions: Draft, Ready and Abort. Abort archives the task: it remains traceable but no longer counts for dispatch.

Identifiers

The ArkaDoc document id is the stable runtime identifier. A task may contain a business task_id in its payload, but dispatch commands use the ArkaDoc id exposed as dispatch_task_id.

Relations

An ArkaDoc can reference another document, memory entry, mission, run, session or attachment. These relations let Cortex Lite build a navigable graph without reading every full document.

---

Project Documentation

Project Documentation is the readable view over ArkaDoc deliverables. It is not a static library or a mock: it reads the project’s real documents.

Each document can be consulted through:

• human view;
• raw data;
• tags and summary;
• token estimate;
• blocks;
• relations.

The goal is to let agents and humans find the right deliverable without injecting the whole project history into every turn.

---

Mission Guardian

Mission Guardian administers governance packs and applies their runtime decisions.

It carries:

• pack administration UI;
• pack activation or deactivation on a project;
• generic validation UI cards;
• Event Lab;
• active pack reading from Cortex Lite;
• runtime gates visible to users and agents.

Mission Guardian must not decide instead of the pack. The active pack describes governance; the runtime executes, traces and refuses when a rule is not satisfied.

---

Deck Guardian Lite

Deck Guardian Lite is the alpha default for public build-in-public projects. It is a guidance_pack, not a runtime guardian_pack.

It provides:

• a short conduct checklist injected into agent turns;
• an explicit UI badge/status: Guidance only;
• transparent limits: no runtime cards, no executable modes, no event policy and no tool gate.

It must never be materialized as mission_guardian_active_pack and it does not replace the Mission Guardian runtime track. Lite reduces agent drift by instruction and transparency; it does not enforce governance at runtime.

Mission Guardian full remains beta/experimental until the runtime diagnostic surface and pack/runtime validation are complete.

---

Deck Guardian

Deck Guardian is the default first-party governance pack. It frames a standard arka-deck project. No specialized Expert Pack ships in this release.

Status as of 2026-05-27 — draft_for_validation. Deck Guardian is structurally consistent and passes the extended runtime cohesion checks (validator + findOrphanPackTools + findUnsupportedPackRoleEntries all green). However, the pack is not yet flagged validated because: (a) some governance actions still live in pending_capabilities waiting for the upcoming CapabilityRegistry lot, (b) human action commands are routed through cards (not through tool_policy.mode_tools), (c) mission_guardian.assess_impact (mandatory under DG-QA-IMPACT-MANDATORY) requires the CapabilityRegistry to be implemented. Promotion to validated will follow the next stabilization lot.

It includes:

• mode registry;
• allowed transitions;
• flowmap;
• complete rules;
• mini rules;
• mode-specific rules;
• event policy;
• tool policy;
• prompt layers;
• UI card templates;
• required documents;
• injection preview;
• pack JSON source.

Deck Guardian is installed when a governed project starts, then materialized in Cortex Lite. After materialization, Cortex Lite becomes the runtime source of truth. The core must not carry a hardcoded copy of the pack to decide in its place.

A project can also run without a guardian pack, in free mode. In that case, agents do not receive the modes, gates, cards and expected-document frame.

---

Expert Packs and Dedicated Guardian Packs

Expert Packs are not exposed in this public release. This section describes the target contract: an expert pack will only ship once its dedicated governance is validated end-to-end.

An Expert Pack installs a specialized work environment on a project: fixed squad, profiles, skills, methods, documents, workers and business rules.

An Expert Pack does not override Deck Guardian. It brings its own dedicated guardian pack.

Principle:

1 expert pack -> 1 dedicated governance -> 1 target project

Trajectory examples, not shipped in the current release:

• Expert Panel may provide a dedicated guardian pack for each published pack.
• A private client pack such as LeadRadar must carry its own guardian pack, for example leadradar-guardian.

This separation prevents Deck Guardian from becoming a universal pack inflated with conflicting business rules.

---

Expert Panel

Expert Panel is the capability infrastructure intended to install Expert Packs. In this release, its runtime catalog is empty by default and the UI does not offer Expert Pack activation.

When a future validated pack is enabled:

• activation is scoped to the project;
• the pack’s complete squad is installed;
• the pack leader opens the session;
• expected documents and workflows become available;
• the dedicated guardian pack is materialized in Cortex Lite;
• agents receive injections matching the real role of their session.

The user does not choose profiles one by one during activation: the pack defines the complete team.

---

Event Lab

Event Lab helps understand and test events before they trigger real governance.

A module produces its events. The bus broadcasts them. Mission Guardian receives them and the active pack decides what they mean through event_policy.bindings.

Event Lab lets you:

• see event catalogs declared by modules;
• read the project event stream;
• inspect whether an event matches the active pack;
• validate pack bindings;
• create dry-run scenarios.

A dry-run scenario does not change mode, create a card or publish to the runtime bus.

---

Simple Responsibility Map

To know where a responsibility lives:

Question	Owner
Where are documents?	ArkaDoc
Where are runtime relations?	Cortex Lite
Who administers governance?	Mission Guardian
Who defines governance?	Active guardian pack
Who compiles agent injection?	Guardian Runtime Compiler
Who will enable validated expert packs?	Expert Panel
Who coordinates a squad?	Squad Leader + Squad Orchestration