Roadmap Archive — Era V: Detailed Crew/Phase History

Archived from docs/development/roadmap.md on 2026-05-08. Spans Team Details (Medical, Bridge, Security, Engineering, Operations, Communications, etc.), the Mission Control + Cognitive Evolution surfaces, the Notebook / Memory / Anchoring stack (AD-550-610), the Native SWE Harness (AD-543-549), the Brain Enhancement umbrella (AD-641a-g + 641g-1), the Crew Qualification Battery (AD-566), the Holodeck stack (AD-486/510/512/539b), the Records Knowledge Browser (AD-562), the Spatial Knowledge Explorer (AD-520), the MCP App Host (AD-597), and the Unified Knowledge Graph + Oracle stack (AD-686-695) plus backlog items and bug-tracker history.

This file is historical context for completed work. For currently-pending work, see the slim docs/development/roadmap.md.

---

Team Details

Medical Team (Phase 29b)

"Please state the nature of the medical emergency."

A dedicated pool of specialized agents that monitor, diagnose, and remediate ProbOS health issues. Modeled as a medical team where each agent has a distinct role in the health lifecycle.

Diagnostician (Chief Medical Officer)

• CognitiveAgent triggered by Vitals Monitor alerts or on a configurable schedule
• Department Chief — receives high-level bridge orders ("run a full diagnostic"), orchestrates the team, reports unified answers back to the Captain
• Runs structured health assessment (extends IntrospectAgent._system_health())
• Compares current state to historical baselines stored in episodic memory
• Root cause analysis: agent-level, pool-level, or system-level
• Produces a structured Diagnosis with severity, affected components, and recommended treatment
• Routes to Surgeon (medical_remediate) or Pharmacist (medical_tune) based on findings

Vitals Monitor (Nurse)

• HeartbeatAgent subclass, always running at low overhead
• Tracks: response latency, trust score trends, pool utilization, error rates, dream consolidation rates, memory usage
• Raises structured alerts (severity + metric + threshold + current value) to the Diagnostician
• Does not diagnose or act — observes and escalates only

Surgeon (Remediation)

• CognitiveAgent that takes corrective action based on Diagnostician findings
• Actions: recycle degraded agents, trigger emergency dream cycles via force_dream(), rebalance pools via pool_scaler, prune stale episodic memory
• Actions are trust-scored via Shapley contribution — did the intervention actually fix the problem?
• High-impact actions (pruning agents, config changes) can require human approval via the approval gate

Pharmacist (Tuning)

• CognitiveAgent for slow-acting, trend-based configuration adjustments
• Analyzes patterns over time: "sessions average 4 minutes, idle dream threshold should be 60s not 120s"
• Produces configuration recommendations with justification and expected impact
• Changes applied through the existing config system with audit trail

Pathologist (Post-Mortem)

• CognitiveAgent triggered by escalation Tier 3 hits, consensus failures, or agent crashes
• Produces structured post-mortems stored in episodic memory and (future) evolution store
• Identifies recurring failure patterns across sessions
• Findings feed into the self-improvement pipeline (Phase 30) as improvement signals

Multi-Level Diagnostics (L1–L5)

"Computer, run a Level 3 diagnostic on the trust network."

LCARS has five formalized diagnostic levels. ProbOS diagnostics are currently binary — either VitalsMonitor raises an alert, or the Diagnostician runs an assessment. Formalizing diagnostic depth gives the Captain precise control:

Level	Scope	Depth	LLM Usage	Duration
L5	Single metric	Current value only	None	Instant
L4	Specific subsystem	Current + recent trend	None	Seconds
L3	Target system	Historical analysis, anomaly detection	Fast-tier	10-30s
L2	Full department	Comprehensive automated sweep	Fast-tier	1-2 min
L1	Ship-wide	Everything — multi-turn root cause analysis, cross-department correlation	Deep-tier	Minutes

• L5 runs every heartbeat (VitalsMonitor already does this)
• L1 requires Captain order or critical incident
• Diagnostic level specified in diagnose_system intent or via HXI slash command (/diagnostic 3 trust_network)
• Results tagged with diagnostic level for Cognitive Journal and post-mortem analysis
• Naturally extends existing Medical team without new agents

---

Codebase Knowledge Service (Phase 29c)

The ship's technical manual — available to any crew member.

ProbOS already has runtime self-awareness — it knows what agents are doing, their trust scores, and routing patterns. This phase adds structural self-awareness: understanding how ProbOS is built, not just how it's behaving. Access is shared across agents via a skill, like a library that any crew member can visit.

CodebaseIndex (Runtime Service)

• Built at startup, cached in memory, read-only during a session
• Scans src/probos/ and builds a structured map:
• File tree with module-level descriptions
• Agent registry: type, tier, pool, capabilities, intent descriptors
• Layer organization: substrate, mesh, consensus, cognitive, federation
• Key APIs: public methods on Runtime, TrustNetwork, IntentBus, HebbianRouter, etc.
• Configuration schema: what's tunable, current values, and where each parameter lives
• Indexed by concept, not just filename ("how does trust work?" maps to the relevant files)
• No LLM calls — pure AST/inspection-based indexing

Graph-Ranked Repo Map (CodebaseIndex Enhancement)

Absorbed from Aider (42K stars, Apache 2.0, 2026-03-21) — tree-sitter + PageRank-style structural ranking.

Current CodebaseIndex extracts classes/functions/signatures via AST and tracks import graphs, but lacks cross-file symbol reference tracking and importance-ranked structural rendering. Aider's repo map builds a dependency graph from definition→reference edges across all files, then PageRank-ranks identifiers by how frequently they're referenced. The top-ranked symbols render into a token-budgeted structural summary (~1024 tokens) that gives the LLM awareness of the entire repo without full source.

• build_reference_graph() — tree-sitter (or AST) extracts definition sites and reference sites for all public symbols. Cross-file edges: "function X defined in A is called from B, C, D." Builds on existing _import_graph and _reverse_import_graph (AD-315) but at symbol granularity, not file granularity
• rank_symbols() — PageRank-style scoring over the reference graph. Symbols referenced from many files rank higher. Identifies the structural "spine" of the codebase
• render_repo_map(token_budget) — renders the top-ranked symbols (signatures, class headers, key methods) into a compact text format within a configurable token budget. File paths as headers, key lines indented, ... for omitted sections
• Dynamic budget — map expands when no files are explicitly selected (broader context for discovery), contracts when specific files are in focus (more room for full source)
• Transporter integration — ChunkDecomposer (AD-331) could use a repo map instead of full AST outlines, dramatically reducing context for the decomposition LLM call
• Architect integration — ArchitectAgent Layer 2a file selection improves: graph ranking identifies the most structurally important files, not just keyword-matched ones
• No LLM calls — pure graph computation, consistent with CodebaseIndex's indexing principle

Semantic Code Search (CodebaseIndex Enhancement)

Inspired by GitHub Copilot coding agent's semantic search tool (March 2026) — meaning-based retrieval when exact names/patterns are unknown.

Current query() uses word-level keyword scoring. This works when the caller knows approximate terminology, but fails for conceptual queries: "how does the system handle untrusted input?" won't match code_validator.py or red_team.py unless those exact words appear in comments or docstrings. Semantic search closes this gap.

• Embedding index — at startup, CodebaseIndex generates vector embeddings for each file's summary, class docstrings, and function signatures. Uses ChromaDB (already a dependency for episodic memory) as the vector store
• Hybrid query — query() combines keyword scoring (fast, exact) with semantic similarity (meaning-based). Results merged with reciprocal rank fusion
• Chunking strategy — embed at class/function granularity, not whole files. Each chunk carries metadata (file path, line range, layer, team) for filtering
• Incremental updates — when CodebaseIndex rebuilds (new agents, modified files), only re-embed changed chunks. Startup cost amortized across sessions
• No runtime LLM calls — embeddings generated by a small local model or pre-computed at build time. Keeps the "no LLM calls for indexing" principle intact (embeddings ≠ LLM inference)
• Crew access — any CognitiveAgent querying CodebaseIndex gets semantic search transparently. The Architect's Layer 2 file selection improves: "find files related to trust scoring" returns trust_network.py, routing.py, consensus.py even without keyword overlap
• External proxy — if ProbOS federates with GitHub Copilot (see External AI Tools below), it gains access to Copilot's semantic search over the same repo by delegation, providing a complementary external perspective

codebase_knowledge Skill (Shared Crew Capability)

• Any CognitiveAgent can use this skill to query the codebase
• Methods: query_architecture(concept), read_source(file, lines), search_code(pattern), get_agent_map(), get_layer_map(), get_config_schema()
• Returns structured, context-aware answers rather than raw file contents
• Used by: Medical (Pathologist, Diagnostician), Science (Architect, Research), Engineering (Builder), Bridge (IntrospectAgent)

Self-Knowledge Comprehension

"ProbOS's biggest cognitive gap is not knowing what it already knows."

The CodebaseIndex delivers data (source code, doc sections, architecture maps) to the reflection LLM, but the LLM's synthesis is shallow — it gives generic distributed systems advice rather than reasoning about what's actually built. Improving comprehension quality:

• Structured reflection prompts — format context with explicit sections ("Source code from X shows...", "Roadmap section Y describes...") instead of dumping raw dicts; guide the LLM to reason about specific evidence
• Evidence-grounded responses — reflection prompt instructs LLM to cite specific code/docs when making claims, and to verify claims against provided snippets before stating them
• Self-contradiction detection — flag when a response contradicts data in the provided context (e.g., "no episodic memory" when episodic memory source code is in the snippets)

Capability Inventory (ProbOS's MEMORY.md)

Inspired by Claude Code's persistent memory file — a structured self-knowledge baseline.

Claude Code maintains a MEMORY.md with facts about the project it's working on (file counts, architecture layers, key systems). ProbOS should generate equivalent self-knowledge at build time:

• Auto-generated at startup — CodebaseIndex produces a compact capability summary alongside its structural index: "ProbOS has: episodic memory (ChromaDB, persistent), dreaming (three-tier: micro/idle/shutdown), trust network (Bayesian Beta distribution), federation (ZeroMQ), 52 agents across 25 pools..."
• Injected into every reflection prompt — prepended as system context so the LLM never starts cold. Prevents recommending building things that already exist

Project Convention Files (AGENTS.md) (absorbed from LangChain Open SWE)

"Every starship carries its own technical manual."

Open SWE uses AGENTS.md — a repo-level file encoding project conventions, testing requirements, and architectural decisions — injected into every agent's system prompt. ProbOS should support this pattern for any project the Builder works on:

• AGENTS.md discovery — when Builder targets a project directory, look for AGENTS.md (or .github/copilot-instructions.md, .cursor/rules, CLAUDE.md) in the project root. Auto-discover and parse
• Convention injection — extracted conventions injected into the Builder's system prompt before code generation. "This project uses pytest with fixtures, snake_case naming, type hints required, imports sorted with isort"
• Layered context — two levels: ProbOS-level conventions (from CodebaseIndex/Capability Inventory) + project-level conventions (from AGENTS.md). ProbOS knows itself AND knows the target project
• Convention learning — over time, Cognitive Journal (Phase 32) tracks which conventions produce successful builds. Hebbian router learns: "this project's builds succeed more when isort is enforced"
• Auto-generation — if no convention file exists, Builder can generate a draft AGENTS.md from code analysis (detect patterns: test framework, import style, naming conventions, docstring format) and propose it for Captain review
• Updated on rebuild — when CodebaseIndex rebuilds (new agents, new capabilities), the inventory regenerates automatically
• Structured format — organized by crew team and architecture layer, not just a flat list. "Medical team: Vitals Monitor, Diagnostician, Surgeon, Pharmacist, Pathologist (Phase 29b, designed). Security: red team agents (built), SSRF protection (AD-285, built)..."

Tool-Augmented Reflection (Agentic RAG)

Inspired by Claude Code's ability to read files mid-reasoning — the reflection LLM should be able to look things up.

Currently, reflection is a single LLM call with pre-assembled context. If the context is incomplete or the LLM needs to verify a claim, it has no recourse — it guesses or stays generic. Tool-augmented reflection gives the reflection step the ability to query CodebaseIndex during response generation:

• Verification tool calls — before stating "X doesn't exist," the reflection LLM can call query("X") to check. If results come back, it corrects itself before responding
• Follow-up reads — if the initial context mentions a file but doesn't include enough detail, the reflection LLM can call read_source() or read_doc_sections() to get more
• Two-pass reflection — first pass generates a draft response; second pass verifies claims in the draft against CodebaseIndex queries, revises any contradictions, then finalizes
• Bounded iteration — max 2-3 tool calls per reflection to keep latency reasonable; not a full agent loop, just targeted verification
• Cost-aware — tool-augmented reflection only activates for introspection and analysis queries, not simple command responses

Confidence Communication in Responses

"Insufficient data" is honest — but "I'm 72% confident based on 3 trust observations" is more useful.

ProbOS tracks confidence and uncertainty deeply (Bayesian Beta distributions, Shapley values, per-agent confidence scores) but never surfaces this information in natural language responses. The system knows when it's uncertain but doesn't tell the Captain.

• Reflect prompt enhancement — instruct the reflection LLM to communicate uncertainty levels when they exist: "Based on the trust network, Agent X has high uncertainty (only 4 observations)" rather than flat assertions
• Confidence qualifiers — when the Decomposer routes to an agent with low confidence (<0.5), the response should note this: "This result comes from an agent with limited track record"
• Trust context in responses — when consensus involves disagreement, surface the dissent: "3 of 4 agents agreed, but Agent Y dissented because..."
• Graduated disclosure — simple queries get clean answers; complex/ambiguous queries get confidence-tagged responses. Don't overwhelm the Captain with statistics on trivial operations
• SystemSelfModel integration — confidence communication depends on AD-318 (SystemSelfModel) providing the data; this enhancement consumes that data in the reflect/decompose output

Adaptive Communication Style

"A new ensign gets detailed explanations. A seasoned Captain gets terse status reports."

The Ship's Computer currently responds at a fixed technical depth regardless of who's asking or what they prefer. An adaptive style system allows users to set preferences that shape response format and detail level.

• User preference store — lightweight config (per-user or per-instance) with settings: technical_depth (brief/standard/detailed), formality (casual/professional/LCARS), response_length (concise/normal/verbose)
• Default profiles — "Captain" (terse, status-focused, high familiarity assumed), "Engineer" (technical detail, code references, architecture context), "Observer" (explanatory, first-principles, no jargon)
• Runtime injection — preferences injected into the reflect prompt alongside SYSTEM CONTEXT, shaping the LLM's response style without changing content accuracy
• Slash command — /style brief or /style detailed to change on the fly. Persisted across sessions
• No accuracy compromise — adaptive style changes how information is presented, never what information is presented. The grounding rules (AD-317) still apply regardless of style

Decision Audit Trail

"Captain's log, supplemental. Explain every decision, not just the result."

Trust events, episodes, escalation results, and agent selections exist as separate data stores. There is no unified "reasoning trace" that links a user's request through decomposition → agent selection → execution → reflection into a single auditable narrative.

• DecisionTrace record — a structured log entry created per user request that captures: original query, decomposition rationale (which intents identified, why), agent selection (which agents considered, trust scores, why the chosen agent was selected), execution outcome (success/failure, confidence), reflection summary, and any escalation events
• Stored in episodic memory — each trace is an episode tagged with decision_trace type, searchable via /recall or IntrospectionAgent
• User-accessible — /explain (enhanced) reconstructs the full reasoning narrative from the trace: "You asked X → I identified intent Y → routed to Agent Z (trust: 0.85, confidence: 0.92) → Agent Z returned result → I reflected and synthesized this response"
• Captain's review — when audit trail shows repeated low-confidence routing or escalation patterns, the Captain can identify systemic issues (e.g., "Agent X is always the fallback — maybe we need a specialist")
• Post-hoc analysis — dreaming engine can consolidate decision traces to identify patterns: which decomposition strategies lead to best outcomes, which agent selections correlate with escalation
• Complement to AD-319 — Pre-Response Verification (AD-319) checks before responding; Decision Audit Trail documents what happened and why for later review

ScoutAgent — Intelligence Gathering (AD-394, Built)

"Long-range sensors detecting multiple contacts, Captain."

Daily automated intelligence scan of the GitHub ecosystem, classifying discoveries as absorption candidates or visiting officer candidates. Part of the Science team.

• GitHub search — queries multiple topic clusters (ai-agents, llm-agents, multi-agent, agent-framework, ai-coding, code-generation) filtered by recency and star count
• LLM classification — each discovery evaluated against ProbOS's federation philosophy: ABSORB (pattern/technique to learn from), VISITING_OFFICER (tool that could integrate under ProbOS command, must pass Subordination Principle), or SKIP
• Relevance scoring — 1-5 scale, only findings scoring >=3 are reported
• Deduplication — seen repos tracked in data/scout_seen.json with 90-day TTL
• Discord digest — formatted daily report delivered to configured Discord channel
• Bridge notifications — high-relevance findings (>=4) posted to Bridge notification queue
• Notification detail view (Future) — clickable Bridge notification cards that expand to show full finding detail: R/C/L scores, insight text, classification rationale (ABSORB/MONITOR/SKIP), direct GitHub link. Currently notifications are display-only text cards. Applies to all Bridge notifications, not just Scout — any notification type should support click-to-expand with structured detail
• Stored reports — JSON reports archived in data/scout_reports/ for historical analysis
• Crew profile — callsign "Wesley", Science department, high openness (0.9) for exploration

Source Curation Enrichment (Future)

Absorbed from GPT Researcher (25.9K stars, Apache 2.0, 2026-03-22) — multi-dimensional source evaluation.

Scout currently scores repositories on a single relevance dimension (1-5). GPT Researcher's SourceCurator evaluates sources across credibility, relevance, and reliability dimensions with LLM-scored ranking. Enriching Scout with multi-dimensional curation:

• Credibility scoring — repository maturity (age, contributor count, release cadence, documentation quality), not just stars
• Reliability assessment — CI status, test coverage badges, maintenance activity (last commit, issue response time)
• Composite score — weighted combination of relevance, credibility, and reliability replaces single relevance number

Breadth × Depth Research Decomposition (Future)

Absorbed from GPT Researcher (25.9K stars, Apache 2.0, 2026-03-22) — iterative sub-query expansion.

Scout currently runs a fixed set of GitHub search queries. GPT Researcher's DeepResearchSkill decomposes a research topic into N sub-queries (breadth), researches each, identifies gaps, then expands deeper (depth), with configurable breadth and depth parameters. Applicable to:

• Scout v2 — configurable breadth (number of topic clusters) and depth (follow-up searches on promising discoveries, e.g., searching a discovered repo's dependency graph for related projects)
• Ready Room research briefings (Phase 34) — when Captain proposes an idea, the research pipeline decomposes it into sub-questions, researches each in parallel, identifies gaps, and synthesizes a comprehensive briefing
• Retriever ABC — GPT Researcher uses 16+ search backends behind a common interface. ProbOS should adopt a Retriever ABC when expanding beyond GitHub (arXiv, Semantic Scholar, HackerNews, etc.)

---

Bridge Crew (Phase 33)

"Bridge to all departments. Report."

The Bridge is where the ship is run. Bridge officers have ship-wide authority, cross-department visibility, and direct access to the Captain. While Department Chiefs manage their teams, the Bridge crew manages the ship.

Ship's Counselor (CounselorAgent)

"I sense... conflict in the trust network."

In Star Trek, Deanna Troi monitors the crew's emotional and psychological wellbeing, advises the Captain on interpersonal dynamics, and senses things the instruments can't detect. In ProbOS, the Ship's Counselor monitors cognitive wellness — the health of agents' reasoning, learning, and relationships that operational metrics alone can't capture.

The Medical team monitors operational health: is the agent running? Are vitals in range? The Counselor monitors cognitive health: is the agent thinking well? Is it learning the right patterns? Is it cooperating effectively?

What the Counselor monitors:

• Confidence trajectories — tracks each agent's confidence scores over time. A Builder that used to score 4-5 on tasks but now consistently returns 1-2 is experiencing cognitive degradation, even if its heartbeat is fine
• Hebbian drift — detects maladaptive learned patterns. An agent whose Hebbian weights reinforce a failing pathway is stuck in a rut (learned helplessness). The Counselor flags it: "This agent keeps routing the same way despite poor outcomes"
• Dream quality — monitors whether dream cycles produce useful abstractions or noise. Poor dream consolidation = poor cognitive hygiene. (AD-487 adds a third dream type: daydreaming — unstructured LLM exploration that builds the personal ontology)
• Decision rigidity — agents whose decision cache is never evicted, whose reasoning becomes repetitive and stale
• Relationship health — trust network dynamics between agents. Detects toxic patterns: one agent consistently getting low Shapley scores from peers, agents that never participate in consensus, clusters of agents with degrading mutual trust
• Burnout signals — agents handling too many intents, experiencing context exhaustion (prompt sizes growing, response quality declining), consistently high workload without recovery time
• Isolation — agents with low peer interaction, no Ward Room messages, not participating in consensus voting. In human terms: a crew member who has withdrawn

What the Counselor does:

• Advises the Captain — "Captain, the Builder Agent's confidence has dropped 40% over the last 20 builds. Its Hebbian weights are reinforcing a decomposition path that produces poor results. I recommend a focused dream cycle."
• Recommends cognitive interventions — forced dream cycles targeting specific failure patterns, Hebbian weight resets for maladaptive pathways, context refreshes, workload rebalancing between pools
• Promotion fitness assessment — when an agent is nominated for promotion, the Counselor provides a cognitive fitness report: trust trajectory, relationship health, learning patterns, stress tolerance
• Cross-department insight — the Counselor sees dynamics the CMO and individual Chiefs can't: inter-department tension (Engineering and Science agents consistently conflicting), fleet-wide cognitive trends (all agents struggling after a major code change)
• Federation counseling — at federation scale, monitors cross-ship relationship health: are federated agents cooperating well? Is trust transitivity working as expected?

Implementation:

• CognitiveAgent subclass, Bridge-level pool, not part of any department
• Subscribes to: trust_update, dream_complete, consensus_result, agent_health, hebbian_update intents
• Runs periodic cognitive wellness sweeps (configurable interval, separate from Vitals Monitor's operational sweeps)
• Reports to Captain via HXI: cognitive wellness dashboard, alerts for concerning patterns
• Collaborates with CMO on cases that cross operational/cognitive boundaries
• Data sources: Trust Network, Hebbian Router weights, Dream Engine logs, Cognitive Journal, Decision Cache stats

---

Security Team (Phase 31)

"Shields up. Red alert."

Formalize threat detection and defense as a dedicated agent pool. Builds on existing security infrastructure (red team agents, SSRF protection).

• Threat Detector (AD-455) — monitors inbound requests for prompt injection, adversarial input, abnormal patterns
• Trust Integrity Monitor (AD-455) — detects trust score manipulation, coordinated attacks on consensus, Sybil patterns
• Input Validator (AD-455) — rate limiting enforcement, payload size limits, content policy
• Red Team Lead (AD-455) — coordinates existing red team agents, schedules adversarial verification campaigns
• Existing: Red team agents (built), SSRF protection (AD-285), prompt injection scanner (roadmap)

Secrets Management (AD-456)

• Secure credential store — integrate with system keyring, HashiCorp Vault, or AWS KMS for API keys, tokens, and sensitive config values
• Runtime injection — secrets resolved at startup and injected into agents/tools that need them, never stored in config files or logs
• Rotation support — automatic credential rotation without restart; agents notified when credentials change
• Existing: .env file support (basic), config values in system.yaml (not encrypted)

Runtime Sandboxing (AD-456)

• Process isolation — imported and self-designed agents execute in sandboxed subprocesses with restricted filesystem, network, and memory access
• Capability whitelisting — agents declare required capabilities in their manifest; runtime grants only those capabilities at startup
• Resource limits — per-agent CPU time, memory, and network quotas enforced by the sandbox; violations terminate the agent and report to Trust Network
• Graduated trust → graduated access — new/untrusted agents get tighter sandboxes; high-trust agents get relaxed constraints
• Existing: AST validation for self-mod agents (built), restricted imports whitelist (built), red team source scanning (built)

Network Egress Policy (AD-456)

Inspired by NVIDIA NemoClaw's outbound connection control.

ProbOS has SSRF protection (AD-285) for inbound attack patterns, but no outbound egress control. Agents — especially imported or self-designed ones — should not have unrestricted internet access:

• Domain allowlist — per-agent (or per-pool) list of permitted outbound domains. Agents can only reach URLs on their allowlist; all other requests are blocked
• Trust-graduated access — new/imported agents start with no network access. As trust increases, domains can be unlocked. High-trust agents get broader access
• Real-time approval — when an agent attempts to contact an unlisted domain, surface the request to the Captain via HXI for approve/deny (NemoClaw pattern). Approved domains are added to the allowlist
• Hot-reloadable — egress rules can be updated at runtime without restarting agents
• Existing: SSRF protection blocks dangerous inbound patterns (AD-285, built). Egress policy blocks unauthorized outbound connections

Inference Audit Layer (AD-456)

Inspired by NemoClaw's inference gateway that intercepts all LLM calls.

ProbOS centralizes LLM calls through the tiered client, but doesn't audit the content of agent-to-LLM communications. An adversarial designed agent could embed sensitive data in its prompts:

• Prompt logging — log all LLM requests (prompt content, system prompt, tier, requesting agent) to the event log for audit
• Anomaly detection — flag unusual patterns: agents sending base64-encoded data, agents including file contents they shouldn't have access to, sudden prompt size spikes
• PII scrubbing — optionally redact detected PII from LLM prompts before they leave the system (complements Data Governance)
• Per-agent LLM access control — allow/deny specific agents from using specific LLM tiers (e.g., imported agents restricted to fast tier only)
• Existing: Tiered LLM client centralizes all LLM calls (built), decision cache tracks LLM usage (AD-272, built)

Data Governance & Privacy (AD-456)

• PII detection — scan agent conversations and episodic memory for personally identifiable information; flag or redact before storage
• Data retention policies — configurable TTLs for episodic memory, conversation history, and knowledge store entries; auto-purge expired data
• Right-to-erasure — delete all data associated with a specific user or session on request (GDPR/CCPA compliance)
• Audit trail — immutable log of who accessed what data, when, and why; required for enterprise and regulated deployments
• Consent tracking — record user consent for data collection and processing; respect opt-out preferences across all agents

---

Engineering Team (Phase 32)

"I'm givin' her all she's got, Captain!"

Automated performance optimization, maintenance, and construction. The team that keeps the ship running and builds new capabilities.

• Performance Monitor (AD-457) — tracks latency, throughput, memory pressure, identifies bottlenecks (what AD-289 did manually, but automated)
• Maintenance Agent (AD-457) — database compaction, log rotation, cache eviction, connection pool management
• Builder Agent — executes build prompts, constructs new capabilities (bridges to external coding agents initially)
• Architect Agent — reads codebase, produces build-prompt-grade proposals that the Builder can execute autonomously
• Damage Control (AD-457) — rapid automated recovery for known failure modes, distinct from Medical remediation
• Infrastructure Agent (AD-457) — disk space, dependency health, environment validation
• Codebase Organization — reorganize src/probos/cognitive/ from flat structure to department-based packages (e.g., cognitive/medical/, cognitive/engineering/, cognitive/science/). Mirror the crew structure in the module tree. Not urgent at 55 agents, but needed as departments fill out. Refactoring — do when the pain is real, not preemptively
• Autonomous Optimization Loop (absorbed from pi-autoresearch, 2026-03-21) — sustained edit→measure→keep/revert cycle that autonomously tries N approaches to improve a specific metric. Domain-agnostic: test speed, bundle size, latency, memory usage — any measurable target. A /optimize <metric> <command> slash command sets the target, and the Builder (or a new OptimizationAgent) loops: generate hypothesis → edit code → run benchmark → compare against baseline → keep improvement or revert → repeat until plateau. Pairs with Transporter Pattern (chunk the optimization space), Cognitive Journal (replay what worked), and MAD confidence scoring (distinguish signal from noise). Inspired by Karpathy's autoresearch concept generalized by Shopify engineers (2.6K stars, MIT, Lutke + Cortes)

Damage Control Teams (AD-457)

"Damage control teams to Deck 12, section 4!"

In Star Trek, damage control teams are Engineering personnel who repair ship systems during combat or emergencies. They are NOT Medical — Medical treats crew injuries, DC teams repair ship infrastructure. DC teams are pre-assigned, pre-positioned, and deploy immediately with pre-staged procedures.

ProbOS equivalent: the gap between VitalsMonitor (detection) and Surgeon (remediation) when the problem is infrastructure, not an agent:

• Pre-defined recovery procedures — automated first-response for known failure modes:
• LLM provider timeout → switch to backup provider (Model Registry fallback)
• Index corruption → rebuild CodebaseIndex from source files
• Trust store inconsistency → validate and repair bounds, SIF re-check
• IntentBus routing stale → flush and rebuild subscription table
• Memory pressure → emergency dream flush + cache eviction
• Federation link loss → reconnect with exponential backoff
• Automated first-response — runs before escalation. If DC resolves it, no Surgeon needed
• Escalation — novel failure modes (no matching procedure) escalate to Surgeon for LLM-assisted diagnosis
• Post-incident report — every DC action logged and fed to Pathologist for post-mortem analysis
• Alert integration — DC activation during Yellow/Red Alert pre-stages recovery procedures

Navigational Deflector (Pre-Flight Validation) (AD-458)

"Adjusting the deflector array."

The main deflector pushes aside space debris before the ship hits it. In ProbOS: validate that the path is clear before starting expensive operations.

• Build pre-flight — before Builder starts: verify target files exist and are writable, check LLM provider is responsive, confirm token budget sufficient for estimated chunk count, validate BuildSpec references
• Self-mod pre-flight — before accepting a self-improvement proposal: verify the affected files haven't been modified since the proposal was generated, check test suite passes pre-change, confirm approval gate stakeholders are available
• Federation pre-flight — before processing federated messages: verify sender trust score, validate message schema, check that referenced agents/pools exist locally
• Pattern — each expensive operation defines a preflight_checks() list. All checks run before commit. Any failure aborts with a diagnostic (not a crash). Cheap, fast, zero-LLM
• Middleware-based determinism (absorbed from LangChain Open SWE) — critical operations must not depend on the LLM remembering to do them. Tests, linting, PR creation, file validation happen via deterministic middleware, not prompt instructions. The LLM decides what to build; middleware ensures how it's delivered is correct. Pattern: MiddlewareStack on the Builder — each middleware runs after the LLM call and enforces a guarantee (tests pass, files lint, commit message exists, PR opened). If the LLM forgets a step, middleware catches it. Backstop, not replacement

Saucer Separation (Graceful Degradation) (AD-459)

"All hands, initiate emergency saucer separation."

Galaxy class can split into saucer (civilians) and stardrive (combat). ProbOS equivalent: when critical systems fail (LLM provider down, memory exhausted), shed non-essential services to protect core functionality.

• Essential services tier — always survive: file operations, shell, basic IntentBus routing, trust store reads, event logging
• Cognitive services tier — gracefully degrade: CognitiveAgents queue requests until LLM returns, switch to cached decision responses, dream cycles suspended
• Non-essential tier — shed first: federation gossip, background maintenance, performance monitoring, HXI visualizations
• Separation trigger — activated automatically when: LLM provider unreachable for >30s, system memory >90%, or Captain manual order
• Reconnection — when crisis resolves, non-essential services restart in priority order. Cognitive services flush queued requests. Federation reconnects. Full operational status restored with Captain notification

Completed Engineering ADs (AD-337–397): Builder Quality Gates (337–341), Failure Escalation (343–347), Guardrails & CI/CD (360–361), GPT-5.4 Code Review (362–369), SIF (370), Automated Builder Dispatch (371–375), Crew Identity (376–379), Callsign Addressing (397). See roadmap-completed.md.

Northstar I: Automated Build Pipeline (AD-311–329) — COMPLETE. 18/18 steps. See roadmap-completed.md.

Sensory Cortex Architecture — Northstar II (AD-330+)

"The human brain processes 10 bits per second of conscious thought from 1 billion bits per second of sensory input. The solution isn't a wider channel — it's smarter selection."

Every CognitiveAgent in ProbOS faces the same fundamental bottleneck: the LLM context window is a narrow conscious channel receiving a massive information stream. The Decomposer can't fit a 10K-line build log. The Architect times out on large files. The Builder starves for context on multi-file changes. Future multi-modal agents processing screenshots, telemetry, and federated state will face this at orders of magnitude greater scale.

The brain solved this problem through architecture, not bandwidth. ProbOS's Sensory Cortex Architecture applies the same biological principles to AI agent cognition:

• Predictive Coding — The brain maintains a generative model and only processes prediction errors (what's surprising). An LLM already "knows" Python, FastAPI, pytest from training. Don't send confirmed predictions — send only what's unique to THIS codebase, THIS change. Delta encoding against the model's own priors.
• Hierarchical Abstraction — The visual cortex processes in layers: V1 (edges) → V2 (contours) → V4 (shapes) → IT (objects). By the time "cat" reaches consciousness, billions of pixels have been compressed to a concept. Code should be represented at multiple resolution levels: L0 (raw source) → L1 (AST outline) → L2 (semantic summary) → L3 (interface contract) → L4 (pattern label). The LLM gets L0 only for lines being edited; everything else at L2-L4. 10x coverage in the same context budget.
• Peripheral vs Foveal Processing — The fovea (2° center) processes at high resolution; peripheral vision detects change at low resolution and redirects attention. Fast/cheap models as sensory cortex (peripheral), expensive model as executive function (foveal). Parallel fast-tier scans maintain a salience map; the deep-tier model processes only what matters.
• Chunking with Expertise — Working memory holds ~7 chunks, but an expert chess player's "chunk" encodes an entire board position. Pattern-label code regions ("this is a Strategy pattern", "this is a pub-sub handler") so the LLM chunks at a higher level. One label replaces thousands of implementation tokens.
• Gist Extraction — The brain categorizes a scene in 100ms before any detailed processing. A rapid pre-scan produces a compressed semantic map ("this is an API endpoint addition touching routing, shell, and tests") that guides all subsequent context selection.
• Attention as Resource Allocation — Trust scores (emotional valence), Hebbian weights (learned salience), EmergentDetector (novelty/dopamine), and task DAG dependencies (goal-directed attention) directly influence context budget allocation. High-trust agent results get more context. Novel/surprising patterns override routine data.
• Dreaming as Abstraction Factory — Dreams don't just consolidate — they produce the hierarchical abstractions that make future perception efficient. Dream about today's build failures → produce Level 4 pattern: "Builder timeout = file >1000 lines + deep tier." Next perception cycle uses dream-built predictions, processing only prediction errors.

                          SENSORY CORTEX ARCHITECTURE

  Raw Input                Perception Pipeline             Working Memory (LLM)
  ┌──────────┐      ┌─────────────────────────┐      ┌──────────────────────┐
  │ Source    │──┐   │  L4: Pattern labels     │      │                      │
  │ Logs     │  │   │  L3: Interface contracts │──────│  Focused context     │
  │ Tests    │  ├──→│  L2: Semantic summaries  │      │  (fits in window)    │
  │ Telemetry│  │   │  L1: AST outlines        │      │                      │
  │ Images   │──┘   │  L0: Raw (selected only)│      │  Prediction errors   │
  │ Fed state│      └─────────┬───────────────┘      │  only, not confirmed │
  └──────────┘                │                       │  priors              │
                    ┌─────────┴───────────────┐      └──────────────────────┘
                    │  Salience Filter         │
                    │  Trust × Hebbian ×       │
                    │  Novelty × Task priority │
                    └─────────────────────────┘

This architecture has implications far beyond code generation:

• Multi-Modal Perception Gateway — Screenshots through a "Visual Cortex" that extracts {gist: "settings page", elements: [{button: "Save", state: "disabled"}], anomalies: ["layout overflow"]}. Telemetry through an "Analytical Cortex" that extracts anomaly timestamps. Voice through an "Auditory Cortex" that extracts intent. Each modality gets a specialized processor that compresses to standardized hierarchical representations.
• Federation as Social Cognition — Federated ships exchange Level 3-4 abstractions, not raw state. The brain can't transmit its full neural state to another brain — language itself is lossy compression. Ship A tells Ship B: "Builder available, trust 0.85, Python specialist, idle" not the full agent registry.
• Decomposer / Architect / All Agents — Every CognitiveAgent gets a perception pipeline. The Decomposer receives pre-digested meaning from logs, history, and state — not raw data. The Architect perceives the codebase through hierarchical abstractions, not full source dumps.

Phase 1: Transporter Pattern (AD-330–336) — COMPLETE. See roadmap-completed.md.

Phase 2: Generalized Perception Pipeline (Future)

Extract the architecture from the Builder and make it available to all CognitiveAgents.

• PerceptionPipeline ABC — Shared base class with hierarchical abstraction levels (L0-L4), salience filtering, and predictive coding hooks. Any CognitiveAgent can plug in a perception pipeline to compress its input before the LLM call.
• CodePerception — Builder/Architect specialization. Multi-resolution code representations with AST-aware abstraction.
• LogPerception — Decomposer/Diagnostician specialization. Build logs, error traces, and test output compressed to semantic summaries with anomaly highlighting.
• TelemetryPerception — VitalsMonitor/Performance specialization. Time series compressed to pattern labels and anomaly timestamps.
• VisualPerception — Multi-modal specialization. Screenshots/UI state compressed to element trees with anomaly flags.
• FederationPerception — Federation specialization. Remote ship state compressed to capability summaries with trust scores.
• Dream-Driven Prediction Models — Dreaming consolidation produces Level 3-4 abstractions that become the predictive coding baseline. Future perception cycles process only prediction errors (what changed since last dream), not raw data.
• Attention Budget Allocator — Trust scores, Hebbian weights, novelty signals, and task priority dynamically allocate context budget across perception channels. High-trust, high-salience, novel information gets more tokens.

Design Principles:

• Graceful degradation — Single-file, small builds still use the proven single-pass path. Transporter only activates when the problem is too large for one context window.
• Composable — Each component (decomposer, executor, assembler, validator) is independently testable and replaceable.
• Observable — Every step emits events. The Captain sees what's happening. Chunks can be inspected, approved, or rejected individually.
• No new agents — The Transporter Pattern enhances the existing BuilderAgent, not a separate agent. The Builder gains the ability to decompose and parallelize, but it's still the same agent in the same pool.
• File-based context offloading (absorbed from LangChain Open SWE) — large intermediate data (chunk results, assembled code, validation reports) written to temp files rather than accumulated in the prompt chain. Prevents context overflow during multi-chunk builds. Each chunk reads its inputs from files, writes its output to files. The assembler reads files, not conversation history. Keeps the LLM context lean — only the current chunk's focused context enters the prompt
• Step budget asymmetry (absorbed from Kimi K2.5 Agent Swarm, 2026-03-20) — the coordinator/decomposer should be fast and decisive (tight step budget, e.g. 15 steps), while workers/chunk executors get generous budgets (100+ steps) for deep, thorough generation. Kimi K2.5's Agent Swarm uses main agent max 15 steps, sub-agents max 100 steps. Apply to Transporter: ChunkDecomposer gets a constrained budget (quick decomposition, no over-analysis), while per-chunk Builder calls get generous timeouts and token budgets for thorough code generation
• Biology-first — When in doubt, ask "how does the brain solve this?" The brain had 500 million years of evolution to optimize information processing under bandwidth constraints. Respect those solutions.

Inspired by: The human brain's 10 bps conscious bottleneck (Manfred Zimmermann, 1986), Karl Friston's Free Energy Principle and predictive coding, the visual cortex hierarchy (Hubel & Wiesel), George Miller's chunking (1956), MapReduce (Google, 2004) for decompose-execute-merge, LLM×MapReduce (Zhou et al., 2024) for structured information protocol and confidence-calibrated chunk assembly, Kimi K2.5 Agent Swarm (Moonshot AI, 2025) for step budget asymmetry and per-tier temperature tuning, Cursor's multi-file editing, Microsoft's CodePlan for inter-procedural edit planning, the Star Trek transporter's matter stream concept.

• Infrastructure Agent (AD-457) — disk space monitoring, dependency health, environment validation
• Existing: PoolScaler handles some Ops/Engineering overlap

Containerized Deployment (Docker) (AD-465)

"The ship in a bottle — portable, isolated, cross-platform."

ProbOS currently runs directly on the host OS. A Docker-based deployment provides security isolation (agents can't reach the host filesystem), cross-platform parity (Windows, Linux, macOS from one image), and simplified setup:

• Official Dockerfile — multi-stage build: Python base with ProbOS deps, Ollama for local LLM, optional HXI frontend served via the built-in FastAPI static mount
• docker-compose.yml — one-command startup: ProbOS runtime + Ollama + optional ChromaDB (persistent volume for data)
• Cross-platform parity — same container image runs identically on Windows (Docker Desktop), Linux (native), and macOS (Docker Desktop). Eliminates platform-specific setup issues (pip not found, path separators, venv activation)
• Security boundary — containerized ProbOS can't access host filesystem, network, or processes beyond explicitly mapped volumes and ports. Essential for the public Twitch demo and any scenario with untrusted agents
• Safe mode profile — container startup flag (--safe-mode) that enables restricted config: disabled shell commands, disabled file writes outside /sandbox, rate limiting, SSRF protection enforced
• Volume mounts — data/ (episodic memory, knowledge store, event log), config/ (system.yaml), optional agents/ (designed agents). Everything else is ephemeral
• Persistent sandboxes per task (absorbed from LangChain Open SWE) — each long-running task (Phase 25) gets its own isolated sandbox environment that persists across follow-up interactions. Follow-up messages on the same task route to the same sandbox with full state preserved. Sandboxes auto-recreate if they become unreachable. Multiple tasks run simultaneously, each isolated. In Docker mode: each task gets a dedicated container; in host mode: each task gets its own working directory with clean environment variables
• Ollama sidecar — Ollama runs as a separate container on the same Docker network. ProbOS connects to it via http://ollama:11434/v1. No GPU passthrough required for CPU-only models; GPU passthrough available for CUDA-enabled hosts
• Existing: Twitch demo plan already specifies Docker-based deployment (commercial roadmap)

Backup & Restore (AD-466)

• Episodic memory snapshots — periodic ChromaDB backup to disk or cloud storage; restore from snapshot on corruption or migration
• System state export — export trust scores, Hebbian weights, agent registry, and config as a portable snapshot for migration between instances
• Point-in-time recovery — roll back episodic memory to a known-good state after bad dream consolidation or corrupted imports

CI/CD Pipeline (AD-466)

• GitHub Actions test suite — run full pytest suite (1700+ tests) on every PR and push to main
• Vitest for HXI — run frontend tests alongside Python tests
• Quality gates — block merge if tests fail, lint errors, or type check issues
• Automated release — tag-based releases with changelog generation from commit history
• Existing: GitHub Actions for docs deployment to probos.dev (built)

Performance & Load Testing (AD-466)

• Benchmarks — reproducible performance baselines for DAG execution, consensus rounds, LLM latency, and intent routing throughput
• Load simulation — synthetic concurrent user workloads to identify scaling bottlenecks before production
• Regression detection — CI compares benchmark results against baselines, flags performance regressions on PRs

LLM Resilience — Graceful Degradation

• Provider failover — if the primary LLM provider is down or rate-limited, fall back to a secondary provider (e.g., OpenAI → Anthropic → local model)
• Cached response mode — when all providers are unavailable, serve cached responses from the decision cache for previously-seen patterns
• Degraded operation — agents that don't require LLM calls (HeartbeatAgents, mesh agents) continue operating; cognitive agents queue work until LLM access is restored
• Circuit breaker — after N consecutive LLM failures, stop retrying and notify the Captain rather than burning through rate limits (See also AD-488: Cognitive Circuit Breaker for metacognitive loop detection — a related but distinct concept addressing agent rumination, not LLM provider failures)
• Health indicator — LLM provider status surfaced through Vitals Monitor and HXI

Model Diversity & Neural Routing (AD-463)

"A crew of Vulcans is logical but brittle. A diverse crew — Vulcan logic, Betazoid empathy, Klingon tenacity, android precision — is resilient."

Currently ProbOS routes all cognition through 2 models (Sonnet 4 for fast/standard, Opus 4 for deep) via 3 tiers. The tier abstraction describes cost/capability levels, not model identities. Real cognitive diversity requires routing tasks to fundamentally different model architectures — each with different failure modes, strengths, and reasoning styles.

Cognitive Division of Labor — the founding principle of Model Diversity. Different cognitive functions should use models optimized for those functions, not the most expensive model for everything. The brain doesn't use the same neural architecture for planning (prefrontal cortex) as it does for motor execution (motor cortex). ProbOS should mirror this:

• Architect tier → hosted frontier model (Opus/Sonnet) for reasoning, planning, design, review. Short, focused calls that fit within proxy timeout windows. Produces high-quality specs — detailed enough that a less capable model can execute them reliably
• Builder tier → local coding model (Qwen 2.5 Coder, CodeLlama, DeepSeek-Coder) via Ollama for code generation. No timeout constraints — can deep-think for 10+ minutes per chunk. The Transporter Pattern's ChunkSpecs become self-contained work orders optimized for local model execution
• Fast tier → small local model via Ollama for classification, gist extraction, chunking. Sub-second responses for peripheral processing

This principle is complementary to — not competing with — the Sensory Cortex context compression (Northstar II). Compression reduces how much you send; Division of Labor ensures you send it to the right model for the job. Together they solve the context window problem from both sides: less data in (compression) and better data routing (specialization).

The first concrete implementation: Opus designs the BuildBlueprint + ChunkSpecs (architecture), Qwen generates the code per chunk (execution). Like writing a detailed spec for a junior developer — the quality of the spec determines the quality of the output, and a well-specified chunk is within any capable coding model's reach.

• ModelRegistry — central catalog of available model providers: (provider, model_id, tier, capabilities, cost_per_token, latency_p50, api_format). Models self-register at startup from config. Registry answers: "which models can handle this task type at this tier?" with ranked options
• Provider abstraction — ModelProvider ABC with concrete implementations: AnthropicProvider, OpenAIProvider, GoogleProvider, OllamaProvider (local models), GenericOpenAIProvider (any OpenAI-compatible endpoint). Each provider handles auth, rate limits, and format translation. Extends the existing api_format switch in OpenAICompatibleClient
• Neural routing — extend HebbianRouter to learn (task_type, model) weights alongside (intent, agent) weights. Over time the system learns: "API design tasks succeed more often on Claude", "structured output tasks succeed more on GPT", "simple classification is cheapest on local Qwen." The Hebbian router already has the infrastructure — add a new relationship type model alongside intent and agent
• Multi-model comparison — natural extension of AD-332 (Parallel Chunk Execution). Send the same chunk to N different models, compare outputs, merge or pick best via confidence scoring + consensus. The Transporter Pattern already parallelizes — make the parallel calls use different models, not just the same model N times
• MAD confidence scoring (absorbed from pi-autoresearch, 2026-03-21) — Median Absolute Deviation as a statistically principled noise floor estimator. After 3+ benchmark/experiment runs, compute |best_improvement| / MAD to classify results: ≥2.0x = likely real (green), 1.0–2.0x = marginal (yellow), <1.0x = within noise (red). Applies to: (1) Builder optimization loops — distinguish real performance gains from measurement noise, (2) TrustNetwork — trust score changes should be statistically significant, not noise, (3) multi-model comparison — confidence that Model A actually outperforms Model B on this task type. Advisory only, never auto-discards
• Brain diversity for agents — agents can declare model preferences or exclusions: preferred_models: ["claude-opus-*"], excluded_models: ["local/*"]. Combined with Hebbian learning, agents gravitate toward models that produce their best work
• Cost-aware routing — ModelRegistry tracks cost per token per provider. The router considers cost alongside quality: "Claude produces 5% better code, but GPT is 60% cheaper — for this low-stakes task, use GPT." Cost thresholds configurable by Captain
• Fallback chains per provider — extend current tier-based fallback (deep → standard → fast) to include cross-provider fallback: claude-opus → gpt-4o → gemini-2 → local-qwen. Provider health tracking via circuit breaker pattern (already planned in LLM Resilience)
• Hot-swap model rotation — add/remove model providers at runtime without restart. ModelRegistry.register() / ModelRegistry.deregister() with live updates to routing weights
• Per-tier temperature tuning (absorbed from Kimi K2.5, 2026-03-20) — AD-358 DONE. Per-tier temperature and top_p fields in CognitiveConfig, wired through LLM client. Configurable in system.yaml. Future: Hebbian-learned adjustments over time
• Per-model edit format selection (absorbed from Aider, 2026-03-21) — different models need different output formats for code edits. Aider discovered empirically that the same model can show dramatically different success rates with different formats (Qwen 32B: 16.4% with whole format vs 8.0% with diff). Candidate formats: whole (entire file, best for smaller/local models), diff (search/replace blocks), udiff (GNU unified diff — models trained on git data are fluent in this), diff-fenced (diff in fenced code blocks, helps models that struggle with raw diff syntax). When ModelRegistry enables multi-model routing, each model should have an edit_format preference stored in config and learnable via Hebbian router (task_type, model) relationship type. Builder/ChunkSpec output format becomes model-adaptive, not hardcoded
• Configuration — system.yaml grows a models: section listing available providers, or auto-discovered via Ollama API (/api/tags) for local models

Cognitive Journal (Token Ledger) (AD-460)

"Ship's log, supplemental — recording not just what happened, but what was thought."

Every LLM request/response is a cognitive event. Currently LLMResponse.tokens_used is populated per-call but never aggregated — the ship has no memory of its own thought processes. The Cognitive Journal captures the complete cognitive history for replay, analysis, and learning.

• CognitiveJournal service — append-only SQLite store recording every LLM request/response with full context: (timestamp, agent_id, agent_type, tier, model, prompt_tokens, completion_tokens, total_tokens, latency_ms, request_hash, response_hash, intent_id, dag_node_id, success, cached)
• Replay — "What did the Architect reason through when designing AD-330?" Retrieve the full prompt/response chain for a specific agent + time range. Enables post-hoc debugging of LLM reasoning
• Summarize / fast-forward — compress a 50-turn conversation to a gist: "Builder attempted 3 fix iterations, failing on import resolution, succeeding on the 3rd attempt by adding the missing __init__.py"
• Scrub / attention navigation — index key decision points in a reasoning chain. "Show me where the Decomposer classified this as a capability gap" → jump to the specific prompt/response pair
• Pattern extraction — analyze which prompts produce the best code (by downstream test pass rate), which agents are most token-efficient, which models hallucinate most. Feeds into Hebbian learning and model routing optimization
• Token accounting — per-agent, per-intent, per-DAG, per-model token usage with cost attribution. Foundation for the LLM Cost Tracker (Phase 33 Ops). Uses ModelRegistry cost data for accurate dollar amounts
• Context budget analytics — track how close each call comes to context limits. Identify agents that routinely exceed budget (candidates for Sensory Cortex optimization). Feeds back into Attention Budget Allocator (Northstar II Phase 2)
• Journal queries — get_reasoning_chain(agent_id, time_range), get_token_usage(groupby="agent"|"model"|"tier"), get_decision_points(intent_id), get_cost_report(period="daily"|"weekly")
• Integration with Dreaming — dream consolidation reads the journal to identify repeated reasoning patterns → abstract into Level 3-4 pattern labels for predictive coding. "The Builder always adds import pytest first" → dream produces builder_test_file_pattern → next build skips sending the instruction
• Retention policy — full prompt/response text retained for configurable period (default 7 days). Metadata (tokens, latency, model, success) retained indefinitely. Compressed summaries produced on expiry
• Revert annotations (ASI) (absorbed from pi-autoresearch, 2026-03-21) — when the Builder reverts failed changes, the hypothesis/reasoning must be captured as structured annotations in the journal entry before the code is discarded. "Annotate failures heavily because the reverted code won't survive." Prevents re-trying dead ends across context resets. Fields: hypothesis, failure_reason, rollback_rationale, next_action_hint. Feeds dream consolidation: failed experiments with annotations = learning material for Level 3-4 abstractions ("approaches X never work for problem type Y")

Memory Architecture — Biological Memory Model (AD-462)

"The brain doesn't remember everything — it remembers what matters. And when it can't, it asks someone who does."

ProbOS faces the same memory bottleneck as the perception pipeline: the LLM context window is a narrow conscious channel. Whether information arrives from perception (external input) or memory (internal recall), it all competes for the same context budget. The Sensory Cortex (Northstar II) applies the 10-bit bottleneck principle to perception — what gets into the context. The Memory Architecture applies the same principle to memory — what gets stored, consolidated, and recalled.

The Salience Filter (Trust × Hebbian × Novelty × Task priority) governs both what gets perceived AND what gets remembered AND what gets recalled. One cognitive bottleneck, three applications:

                    UNIFIED COGNITIVE BOTTLENECK

  External Input              Salience Filter              Working Memory (LLM)
  ┌──────────────┐      ┌──────────────────────┐      ┌──────────────────────┐
  │ Source files  │──┐   │                      │      │                      │
  │ Logs/errors   │  │   │  Trust × Hebbian ×   │      │  Focused context     │
  │ Telemetry     │  ├──→│  Novelty × Task ×    │──────│  (fits in window)    │
  │ Fed state     │  │   │  Importance          │      │                      │
  │ Ward Room     │──┘   │                      │      │  Perception + Memory │
  └──────────────┘       │     SAME FILTER      │      │  share the budget    │
                         │                      │      │                      │
  Internal Memory        │                      │      └──────────────────────┘
  ┌──────────────┐       │                      │
  │ Episodes     │──┐    │                      │
  │ Knowledge    │  ├───→│                      │
  │ Dreams       │──┘    │                      │
  └──────────────┘       └──────────────────────┘

Biological Memory Staging — Human memory has stages with biological selection pressure at each transition. Not everything perceived becomes a memory, and not every memory becomes permanent knowledge. ProbOS should work the same way:

Stage	Brain Analog	ProbOS Mapping	Duration	Transition Mechanism
Working Memory	Prefrontal cortex, 7±2 chunks	LLM context window (current conversation)	Seconds	Auto — context window is working memory
Sensory Buffer	Iconic/echoic memory	recent_for_agent() — timestamp-sorted recent activity	Minutes	Auto — recent episodes available by recency
Short-term Memory	Hippocampus	ChromaDB vector store — EpisodicMemory	Hours-days	Selective Encoding Gate (not everything gets stored)
Long-term Memory	Neocortex	KnowledgeStore — distilled facts, patterns, wisdom	Permanent	Dream Consolidation (replay + reinforcement → promotion)

Selective Encoding Gate — The brain doesn't store every sensory experience. Not every agent action merits an episode. A heuristic importance gate before store() prevents vector store pollution:

• Captain-initiated → always store (command interactions are important)
• Non-trivial result → store (agent produced meaningful output, not [NO_RESPONSE])
• First-time intent → store (novel experiences are more memorable)
• Trust change → store (experiences that change relationships are significant)
• Failure → store (failures are learning opportunities)
• Routine, no output, no novelty → skip

This directly connects to the Sensory Cortex's selection principle: "The solution isn't a wider channel — it's smarter selection." Applied to perception, it means compress inputs. Applied to memory, it means don't store noise.

Active Forgetting — Forgetting is a feature, not a bug. Unreinforced memories degrade recall quality by polluting the vector space with noise. Memory decay should be an active mechanism:

• Episodes that are never recalled lose activation over successive dream cycles
• Low-activation episodes below a threshold are pruned during dreaming
• High-activation episodes (frequently recalled, recently reinforced) are promoted to long-term via dream consolidation
• Parallels ACT-R's base-level activation: activation = ln(Σ t_j^(-d)) where t_j is time since each access and d is decay rate

Variable Recall Capability — Not all agents need the same memory capability. Memory recall tiers map naturally to Earned Agency:

Tier	Method	Who	Token Cost
Basic	Vector similarity only	All crew	0
Enhanced	Vector + keyword augmented query construction	Officers (trust 0.7+)	0
Full	LLM-augmented query translation (MemoryProcessor)	Department Chiefs + Bridge	Tokens per recall

Promotion to Enhanced recall is a Qualification Program competency. Department Chiefs earn Full recall. The MemoryProcessor is a capability tier, not a universal service — preserving the token budget for agents that actually need deep recall.

Social Memory — "Does anyone remember?" — When an agent can't recall something, it can ask other crew members. This is how ship crews work: the Officer of the Deck asks the Quartermaster, who keeps the logs. The Ward Room already provides the mechanism — a new message type for memory queries:

• Agent posts memory query on department channel: "Does anyone recall the Captain's guidance on trust thresholds?"
• Another agent whose sovereign memory contains a match responds
• The requesting agent incorporates the response into their reasoning
• Protocol, not infrastructure — uses existing Ward Room + recall pipeline

Oracle Service (Ship's Computer Memory) — Infrastructure-tier memory service with full access to all stored knowledge. Not crew — the Oracle has no Character/Reason/Duty. It's the Ship's Computer answering "Computer, retrieve all Ward Room discussions about trust thresholds." No identity, no judgment, pure retrieval. The Oracle queries across all three knowledge tiers: EpisodicMemory (raw experience), Ship's Records (AD-434 — structured documents, duty logs, research, Captain's Log), and KnowledgeStore (operational state). Ship's Records gives the Oracle a formal document corpus — not just vector-searchable episodes and operational snapshots, but authored research, professional records, and institutional knowledge.

• Data (Crew Agent, Science) — Has Character (curious, literal, aspiring), Reason (judges relevance), Duty (serves the crew). Privileged Full-tier access to the Oracle. Data's value is not just recall but interpretation of what recalled memory means.
• Guinan (Crew Agent, future) — Experiential wisdom agent. Not perfect recall but deep pattern recognition. Interface to dream-consolidated knowledge. "I've seen this kind of thing before." What dream consolidation produces: not verbatim memories, but distilled insights.

Optimized Memory Representation — AI agents don't need to remember in English. Memories should be stored in a format optimized for AI retrieval, translated to natural language only for human interaction:

• Structured metadata + NL gist (near-term) — Episodes store structured fields (agent_id, intent, participants, channel, outcome, timestamp) alongside a short NL summary. Structured fields enable exact-match filtering; NL summary enables semantic search. ProbOS is close to this with the Episode dataclass — extend it.
• Concept graphs (future) — Instead of "Counselor discussed trust variance in All Hands", store: {subject: "counselor", action: "discussed", topic: "trust_variance", location: "all_hands", entities: ["trust_network", "departments"]}. Retrieval = graph traversal + vector similarity on concept nodes.
• Retrieval as pointers (future) — Store gists with pointers: "Discussed trust variance in All Hands [thread_id=abc123]". On recall, follow the pointer to get full context from the Ward Room archive. Humans store gists with pointers to details, not verbatim transcripts.
• HXI readability preserved — The Cockpit View Principle requires that memory state be inspectable by the Captain. Opaque formats are acceptable only if a human-readable view can be generated on demand.

Research lineage: Generative Agents (Park et al., Stanford 2023) — memory stream with recency × importance × relevance scoring and reflection. MemGPT (Packer et al., 2023) — virtual context management with LLM-managed memory paging. ACT-R (Anderson, Carnegie Mellon) — activation-based retrieval: base_level(recency + frequency) + spreading_activation(contextual similarity). Complementary Learning Systems (McClelland et al., 1995) — hippocampus (episodic, fast-learning) and neocortex (semantic, slow-learning) with sleep consolidation as the bridge. ProbOS's EpisodicMemory + KnowledgeStore + DreamingEngine already maps to this dual-system model. Atkinson-Shiffrin (1968) — sensory → short-term → long-term memory staging. Levels of Processing (Craik & Lockhart, 1972) — deeper processing → stronger encoding.

Implementation layers:

1. BF-029 ✅ — Fix recall plumbing: query enrichment, memory presentation, reflection content
2. AD-433 ✅ — Selective Encoding Gate: importance heuristic before store(), skip noise, reduce vector store pollution
3. Phase 32 — Memory staging with reinforcement tracking + active forgetting in dream cycles
4. Phase 33+ — Oracle service, LLM-augmented Full-tier recall, social memory protocol, concept graphs

Ship's Telemetry — Internal Performance Instrumentation (AD-461)

"All systems reporting nominal, Captain."

The ship has sensors (VitalsMonitor) and a planned log (Cognitive Journal) — but no wiring between them. Currently there is zero wall-clock timing on LLM calls, no prompt/completion token split, no per-pipeline duration tracking, and no way to compare Transporter vs single-pass builds. The Cognitive Journal, EPS, LLM Cost Tracker, and Observability Export all depend on structured telemetry data that doesn't exist yet. Ship's Telemetry is the foundational instrumentation layer that captures it.

This is the ship's internal sensor grid — the data foundation that every other monitoring/analysis system reads from.

• TelemetryEvent dataclass — standardized measurement record: (timestamp, event_type, agent_id, agent_type, tier, model, duration_ms, prompt_tokens, completion_tokens, total_tokens, context_chars, success, metadata: dict). Lightweight, zero-LLM, append-only
• LLM call timing — LLMClient.complete() wraps each call with time.monotonic() start/end. Emits TelemetryEvent(event_type="llm_call") with duration_ms, prompt_tokens, completion_tokens (parsed from API response, not estimated). Every LLM call in the system instrumented at the source
• Pipeline timing — transporter_build(), decompose_blueprint(), execute_chunks(), assemble_chunks(), validate_assembly() each emit TelemetryEvent(event_type="pipeline_stage") with stage name and duration. Single-pass decide()+act() path emits comparable events
• Build comparison flag — BuildResult gains transporter_used: bool, total_duration_ms: int, total_tokens: int, chunk_count: int fields. Enables direct A/B comparison: "Transporter builds average 45s / 12K tokens vs single-pass at 30s / 18K tokens for comparable specs"
• TelemetryCollector service — registered on runtime, receives events via record(). In-memory ring buffer (configurable size, default 1000 events). Query methods: get_events(agent_id?, event_type?, since?), get_summary(groupby="agent"|"tier"|"model"|"pipeline"), get_llm_stats() (mean/p50/p95 latency, token rates)
• HXI telemetry surface — /api/telemetry/summary endpoint exposes key metrics. Future: Engineering section of dashboard shows LLM latency trends, token consumption by department, Transporter vs single-pass comparison chart
• Integration points — Cognitive Journal reads from TelemetryCollector (don't duplicate collection). EPS uses real-time token rates for capacity budgeting. LLM Cost Tracker aggregates token counts with model pricing. Observability Export maps TelemetryEvents to OTel spans
• Zero runtime cost when unused — telemetry is fire-and-forget (record() is sync, appends to deque). No blocking, no I/O on the hot path. Consumers pull when they need data
• Existing: LLMResponse.tokens_used (total only), ChunkResult.tokens_used, assembly_summary() token aggregation, VitalsMonitor operational health metrics

Observability Export (AD-466)

• OpenTelemetry integration — structured traces for intent routing, DAG execution, consensus rounds, and LLM calls. Maps TelemetryEvent records to OTel spans with proper parent/child relationships
• Prometheus metrics — agent trust scores, pool utilization, Hebbian weights, dream consolidation rates, LLM latency/cost exposed as scrapeable metrics
• Grafana dashboards — pre-built dashboards for system health, agent performance, and cost tracking
• Log aggregation — structured JSON logging with correlation IDs for tracing a user request through decomposition → routing → execution → reflection
• Existing: Python logging throughout, HXI real-time visualization (built), Ship's Telemetry internal instrumentation (prerequisite)

Storage Abstraction Layer (AD-466)

ProbOS currently uses aiosqlite (SQLite) for event log and episodic memory, and ChromaDB for vector storage. Both are ideal for local-first, single-ship deployment (zero config, embedded, pip install). For enterprise and cloud deployment, swappable backends are needed:

• StorageBackend ABC — abstract interface for relational/event storage operations (write event, query events, store episode, recall episodes)
• SQLiteBackend — default implementation wrapping current aiosqlite usage. Remains the zero-config default for OSS
• Future backends — PostgreSQL, etc. implemented as drop-in replacements behind the same interface
• Migration path — existing EventLog and EpisodicMemory classes code against the ABC, not raw aiosqlite. Backend selected via config
• SQLite is proven for single-node: zero config, WAL mode handles modest concurrency, file-based backup. The abstraction exists so cloud/enterprise can swap without changing agent code

Vector Store Abstraction Layer (AD-466)

ChromaDB is the right default for OSS (embedded, zero config, works offline), but enterprise/cloud needs backends with clustering, replication, and multi-tenant isolation:

• VectorStore ABC — abstract interface for vector operations (add, query, get, delete, count). Small surface — ~50 lines
• ChromaDBBackend — default implementation wrapping current ChromaDB usage. Remains the zero-config default for OSS
• Future backends — pgvector, Qdrant, Pinecone implemented as drop-in replacements behind the same interface
• Migration path — existing KnowledgeStore and EpisodicMemory (vector side) code against the ABC, not raw ChromaDB API. Backend selected via config
• Key insight: PostgreSQL + pgvector could serve as the single enterprise backend for both relational and vector storage, reducing operational complexity

P1 Performance Optimizations (deferred from AD-289)

• Pool health check caching — cache healthy_agents list with short TTL, invalidate on agent state change
• WebSocket delta updates — send state deltas instead of full snapshots, throttle event broadcast rate (batch within 100ms window)
• Event log write batching — batch SQLite commits (flush every 100ms or 10 events), enable WAL mode
• Episodic memory query optimization — add timestamp index to ChromaDB collection, cache recent episodes with TTL

Decision Cache Persistence (deferred from AD-272)

• Persist CognitiveAgent decision caches to KnowledgeStore for warm boot — returning users get instant responses for previously-seen patterns
• Feedback-driven cache eviction: /feedback bad invalidates cached decisions for involved agents, preventing stale bad judgments from persisting

Procedural Learning / Cognitive JIT (AD-464 umbrella)

"I've done this before. I know how."

Agents learn deterministic procedures from successful LLM-guided actions. First time: the LLM reasons through the task. Subsequent times: replay at graduated levels of autonomy — from LLM-with-hints to fully deterministic at zero tokens. Over time, agents build a library of compiled procedures — the cognitive equivalent of JIT compilation.

Validated in production: ERP system configuration agents. Once an agent figured out how to configure a chart of accounts, it didn't need the LLM again. Deterministic replay handled identical configurations at zero cost.

Landscape survey (17 projects): Voyager (code-as-skills, compositional JS), DSPy (prompt optimization), Reflexion (verbal RL), ExpeL (experience-driven rules), Mengram (NL workflow versioning with failure evolution), Letta (self-editing memory blocks), Cradle (pre-authored skills per environment). NONE does LLM-to-deterministic compilation. NONE has trust-gated learning. NONE has multi-agent collaborative procedure building. ProbOS's unique advantage is the civilization layer — identity, trust, memory, chain of command — that enables collaborative learning no single-agent system can replicate. Full research: docs/research/cognitive-jit-procedural-learning-research.md.

What the crew CANNOT do today: - Re-use past successful reasoning. Every identical task costs the same tokens as the first time. - Learn from each other's successes/failures. Hebbian routing strengthens agent selection but not task execution. - Build institutional knowledge that survives agent resets (procedures are crew knowledge, not individual memory). - Identify systematic capability gaps and train to close them. - Operate at graduated autonomy levels — it's full LLM or nothing.

What the crew CAN do after AD-464 is complete: - Zero-token replay of previously solved problems (Level 4-5 procedures). - Graduated compilation: LLM-guided first attempt → LLM+hints → deterministic+validation → fully autonomous → can teach others. - Learn from watching other agents succeed/fail in Ward Room discussions (observational learning). - Multi-agent compound procedures (e.g., security-reviewed deployment: LaForge builds → Worf reviews → Architect validates → Builder deploys). - Negative procedures: codified anti-patterns that prevent repeating known mistakes. - Systematic gap identification → Qualification Program scenarios for Holodeck training. - Procedure lifecycle: decay unused, re-validate on codebase changes, dedup/merge similar, archive superseded. - Department chiefs handle routine procedure promotions; Captain handles critical (security, data integrity). - Institutional memory: procedures survive individual agent resets — they're Ship's knowledge, not personal.

Intellectual lineage: Dreyfus (skill acquisition stages), Anderson (ACT-R: declarative→procedural compilation), Bandura (social/observational learning), Vygotsky (zone of proximal development — graduated scaffolding). The Dreyfus Level 3→4 transition (Competent to Enable) maps directly to Cognitive JIT — an agent that has internalized enough procedures through practice that it operates from pattern recognition rather than step-by-step reasoning.

---

AD-464 Decomposition — Build Sequence

Prerequisites (all COMPLETE): - AD-430 (Action Memory) — agents record every action as an episode ✅ - AD-431 (Cognitive Journal) — append-only trace of every LLM call ✅ - AD-433 (Selective Encoding Gate) — filters noise episodes ✅ - AD-434 (Ship's Records) — Git-backed institutional knowledge store ✅ - Dream consolidation (existing) — replays episodes, adjusts Hebbian weights ✅

Dependency graph:

AD-531 (Episode Clustering)
  ↓
AD-532 (Procedure Extraction)   ←  AD-431 (Cognitive Journal traces)
  ↓                                 AD-430 (Action episodes)
AD-533 (Procedure Store)        ←  AD-434 (Ship's Records backend)
  ↓
AD-534 (Replay Dispatch)        ←  AD-533 (stored procedures to match)
  ↓
AD-535 (Graduated Compilation)  ←  AD-534 (replay mechanism)
  ↓                                 AD-357 (Earned Agency tiers)
AD-536 (Trust-Gated Promotion)  ←  AD-535 (compilation levels to gate)
  ↓                                 AD-339 (Standing Orders tiers)
AD-537 (Observational Learning) ←  Ward Room (existing)
  ↓                                 AD-532 (extraction from observed episodes)
AD-538 (Procedure Lifecycle)    ←  AD-533 (store to manage)
  ↓
AD-539 (Gap → Qualification)    ←  AD-531 (clusters reveal gaps)
                                    AD-538 (failed/decayed procedures)
                                    Holodeck (future — generates training scenarios)

---

AD-531: Episode Clustering & Pattern Detection — Roadmap.

Before: Episodes are stored individually with no cross-episode analysis. Dream consolidation replays linearly, adjusting Hebbian weights but not identifying structural patterns.

After: Episodes automatically cluster by semantic similarity. Repeated patterns surface as cluster centroids. Failure clusters reveal systematic weaknesses. The crew gains a "we've seen this N times" capability.

• Cluster engine — run during dream cycle (extends DreamingEngine.dream_cycle()). Group episodes by embedding similarity (ChromaDB already stores embeddings via ONNX MiniLM). Threshold-based clustering (agglomerative, cosine distance < 0.15).
• Cluster metadata — each cluster tracks: centroid embedding, episode count, success rate, participating agents, intent types, first/last occurrence, variance (how similar the episodes are).
• Success/failure split — clusters are tagged as success-dominant (>80% positive outcomes) or failure-dominant (>50% negative). Success clusters feed procedure extraction. Failure clusters feed gap identification.
• Trigger threshold — a cluster must have ≥3 episodes before it's considered actionable. Prevents overfitting to one-off events.
• Fix: dead strategy extraction — DreamingEngine.extract_strategies() currently writes JSON to KnowledgeStore but nothing reads it. AD-531 replaces this dead code path with cluster-based pattern detection that feeds directly into AD-532. The existing REL_STRATEGY Hebbian relationship type gets connected to cluster centroids.
• Post-execution analysis (absorbed from OpenSpace prior art) — in addition to cluster-based pattern detection during dream consolidation, run a conversation-level analysis pass on Cognitive Journal traces for each cluster. The analysis LLM can use tools (read files, inspect state) to investigate beyond recorded transcripts. Produces structured ExecutionAnalysis output with per-procedure judgments and evolution suggestions. This provides both statistical patterns (clustering) and causal understanding (analysis).
• Fuzzy ID correction (absorbed from OpenSpace) — when LLM analysis output references internal IDs (procedure IDs, agent IDs), apply Levenshtein distance correction (threshold ≤ 3) to fix hallucinated hex suffixes. Match by name prefix.

Dependencies: EpisodicMemory (existing, provides episodes + embeddings), DreamingEngine (existing, provides dream cycle hook), AD-430 (sufficient episode volume).

---

AD-532: Procedure Extraction — Roadmap.

Before: Dream consolidation identifies that agent X succeeded at task Y multiple times, but only records this as a Hebbian weight increase. The "how" is lost.

After: When a success cluster reaches threshold, the system extracts a deterministic procedure — the specific steps the agent took, in order, with preconditions and postconditions. The "how" is preserved and replayable.

• Three extraction triggers (absorbed from OpenSpace prior art) — ProbOS's original design used only dream consolidation as a trigger. OpenSpace's production experience demonstrates that three independent triggers are needed ("multiple lines of defense against skill degradation"):
• Dream consolidation (reflective) — existing ProbOS design. When AD-531 produces a success cluster with ≥3 episodes and >80% success rate, invoke extraction. Runs during idle periods.
• Post-execution analysis (reactive, absorbed from OpenSpace) — after each significant task execution, analyze the execution recording and produce structured evolution suggestions. Catches opportunities that clustering might miss because the pattern hasn't repeated enough times yet.
• Metric degradation (proactive, absorbed from OpenSpace) — periodic health scan of procedure quality metrics (see AD-534). When metrics degrade below thresholds, trigger re-extraction or repair. Catches silent procedure rot.
• Three evolution types (absorbed from OpenSpace prior art) — OpenSpace's FIX/DERIVED/CAPTURED taxonomy maps to ProbOS's Dreyfus compilation levels:
• CAPTURED — extract novel pattern from successful execution. Creates Level 1 (Novice) procedure. No parents.
• FIX — repair broken procedure in-place. Parent deactivated, same logical name, generation+1. Maintains compilation level.
• DERIVED — create specialized variant from 1+ parent procedures. New name, parents stay active. Supports multi-parent merge for combining complementary procedures. May start at parent's level - 1.
• Extraction method — LLM-assisted: feed the Cognitive Journal traces (AD-431) for the clustered episodes to an LLM with the prompt "Extract the common deterministic procedure from these execution traces." Output: ordered step list with preconditions, postconditions, and invariants per step.
• Procedure schema — Procedure(id, name, steps: list[ProcedureStep], preconditions, postconditions, origin_cluster_id, origin_agent_id, extraction_date, compilation_level=1, success_count=0, failure_count=0, last_executed, provenance: list[episode_id]). ProcedureStep(action, expected_state, fallback_action, invariants).
• Negative procedure extraction — from failure clusters and dream contradiction detection (existing): extract anti-patterns as NegativeProcedure — "when you see X, do NOT do Y because Z happened." Stored alongside positive procedures with a is_negative=True flag.
• Procedural context — each procedure stores: preconditions (what must be true before execution), invariants (what must remain true during), failure modes (known ways this can break), provenance (original episodes, agent, human decisions that shaped it).
• Multi-agent extraction — when a success cluster spans multiple agent IDs (e.g., a Ward Room discussion → decision → execution that involved Security + Engineering + Builder), extract as a compound procedure with agent role assignments per step.
• Apply-retry with LLM correction (absorbed from OpenSpace) — up to 3 attempts to apply extracted procedure content. On failure, build retry prompt with error message + current state, LLM corrects, retry. Cleanup between attempts. This makes extraction more resilient than single-shot.
• LLM confirmation gate (absorbed from OpenSpace) — evolution triggered by metric degradation or automated analysis (triggers 2 and 3) requires LLM confirmation before proceeding. Conservative default: ambiguous = skip. Dream consolidation (trigger 1) does not require confirmation — it is already governed by the dream cycle's own thresholds.

Dependencies: AD-531 (clusters to extract from), AD-431 (Cognitive Journal traces for step-level detail), AD-430 (episode provenance).

AD-532b: Procedure Evolution Types (FIX/DERIVED) (COMPLETE, OSS, depends: AD-533 ✅, AD-534 ✅) — FIX/DERIVED evolution taxonomy from OpenSpace. EvolutionResult dataclass. Shared diagnose_procedure_health() function (DRY — CognitiveAgent + DreamingEngine). _format_episode_blocks() DRY helper. _FIX_SYSTEM_PROMPT + evolve_fix_procedure(): deactivate parent, generation+1, re-extract from fresh episodes. _DERIVED_SYSTEM_PROMPT + evolve_derived_procedure(): multi-parent specialization, parents stay active, compilation_level-1. content_diff via difflib, change_summary from LLM. Anti-loop guard (_addressed_degradations, 72h cooldown). Dream cycle Step 7b (_evolve_degraded_procedures()). DreamReport procedures_evolved field. 48 tests. Deferred: AD-532e (reactive/proactive triggers), AD-534b (fallback learning).

AD-532c: Negative Procedure Extraction (COMPLETE, OSS, depends: AD-532 ✅) — Extracts anti-patterns from failure-dominant clusters (>50% negative outcomes) with contradiction enrichment (AD-403). _NEGATIVE_SYSTEM_PROMPT + extract_negative_procedure_from_cluster() produces Procedure(is_negative=True) — "when you see X, do NOT do Y because Z happened." Dream cycle Step 7c iterates failure-dominant clusters, enriches with contradiction context, stores via ProcedureStore. DreamReport.negative_procedures_extracted field. DRY: reuses _format_episode_blocks(), _parse_procedure_json(), _build_steps_from_data(). 31 tests. Consumed by AD-534's negative procedure guard (skip known bad approaches).

AD-532d: Multi-Agent Compound Procedures (COMPLETE, OSS, depends: AD-532 ✅) — When a success cluster spans multiple agents, extract as a compound procedure with agent role assignments per step. ProcedureStep gains optional agent_role: str field (default "", backward compatible). _COMPOUND_SYSTEM_PROMPT + extract_compound_procedure_from_cluster() — LLM generalizes agent IDs to functional roles (e.g., "security_analysis", "engineering_diagnostics"), captures cross-agent handoff points. Dream cycle Step 7 routes multi-agent clusters (len(participating_agents) >= 2) to compound extraction. Replay formatting includes [agent_role] annotations. DRY: reuses _format_episode_blocks(), _parse_procedure_json(), _build_steps_from_data(). 30 tests. Orchestrated multi-agent dispatch deferred to AD-534c.

AD-534b: Fallback Learning (COMPLETE, OSS, depends: AD-534 ✅, AD-532b ✅) — When a procedure replay fails and falls back to the LLM, capture the failure context (execution failure or near-miss rejection) and learn from the LLM's successful response. Eight parts: (0) Metric semantics fix — record_completion()/record_fallback() moved from _check_procedural_memory() to handle_intent() so quality metrics reflect execution outcomes, not formatting success. (1) Near-miss capture — _last_fallback_info dict set at 4 rejection points in _check_procedural_memory(): score_threshold, quality_gate, negative_veto, format_exception. (2) Service recovery — _decide_via_llm() extracted from decide(), _run_llm_fallback() added for transparent recovery when cached procedure fails in act(). (3) Event infrastructure — PROCEDURE_FALLBACK_LEARNING event type + dataclass, in-memory queue in DreamingEngine (MAX_FALLBACK_QUEUE_SIZE=50, MAX_FALLBACK_RESPONSE_CHARS=4000). (4) Targeted FIX evolution — evolve_fix_from_fallback() with _FALLBACK_FIX_SYSTEM_PROMPT in procedures.py, produces targeted FIX using LLM response diff. (5) Dream Step 7d — _process_fallback_learning() drains queue, groups by procedure_id, evolves. Execution failures deactivate parent; near-misses keep parent active. negative_veto → flags as extraction candidate. (6) DreamReport — fallback_evolutions and fallback_events_processed fields. (7) Tests — 68 tests across 9 test classes. 333 total Cognitive JIT tests.

AD-534c: Multi-Agent Replay Dispatch (COMPLETE, OSS, depends: AD-534 ✅, AD-532d ✅) — Orchestrated execution of compound procedure steps across agents. ProcedureStep gains resolved_agent_type: str field (populated during compound extraction via _resolve_agent_roles() helper, which maps origin_agent_ids to agent types). Compound detection in _check_procedural_memory(): procedures with 2+ steps having non-empty resolved_agent_type trigger _execute_compound_replay() instead of single-agent text replay. Agent resolution via _resolve_step_agent(): tries registry.get_by_pool(resolved_agent_type) → registry.get_by_capability(agent_role) → fallback to originating agent. Step dispatch via _handle_compound_step_replay(): zero-token handler on compound_step_replay intent, target agent receives pre-formatted step text, no LLM call. Sequential execution with COMPOUND_STEP_TIMEOUT_SECONDS=10.0. _format_single_step() DRY extraction from _format_procedure_replay(). Unavailability fallback: if any agent can't be resolved, degrades to single-agent text replay (current behavior). handle_intent() gains compound branch. Step-by-step postcondition validation deferred to AD-535 (graduated compilation). 54 tests across 9 test classes. 387 total Cognitive JIT tests.

AD-532e: Reactive & Proactive Extraction Triggers (COMPLETE, OSS, depends: AD-533 ✅, AD-534 ✅) — Two new trigger paths beyond dream consolidation: (1) Reactive — EventType.TASK_EXECUTION_COMPLETE emitted from CognitiveAgent.handle_intent(), caught by DreamingEngine.on_task_execution_complete(). Matches intent to existing procedures, diagnoses health, LLM-gates evolution via confirm_evolution_with_llm(), retries via evolve_with_retry() with retry_hint propagation. Rate-limited per agent (REACTIVE_COOLDOWN_SECONDS). No-match intents tracked as extraction candidates. (2) Proactive — DreamScheduler runs proactive_procedure_scan() at PROACTIVE_SCAN_INTERVAL_SECONDS (Tier 1.5, between micro-dream and full dream). Scans all active procedures via diagnose_procedure_health(), LLM confirmation gate before evolution. (3) Shared infrastructure — _attempt_procedure_evolution() DRY helper used by both Step 7b and proactive scan. confirm_evolution_with_llm() gate (YES-only, conservative). evolve_with_retry() wrapper (max 3 attempts). Dream Step 7b unchanged (no confirmation gate per roadmap). DreamReport fields: proactive_evolutions, reactive_flags. 43 tests.

---

AD-533: Procedure Store — Roadmap.

Before: No persistent storage for learned procedures. Every session starts from zero knowledge of how to accomplish tasks.

After: Compiled procedures are stored in Ship's Records (AD-434), tagged, version-tracked, and queryable by semantic similarity. Procedures persist across resets — they're institutional knowledge.

• Hybrid storage (design enhanced with OpenSpace prior art) — Ship's Records (AD-434, Git-backed) remains the authoritative source: each procedure is a YAML document in records/procedures/ with the Procedure schema from AD-532. Git versioning provides human-readable procedure history and diff. Additionally, a SQLite index table (modeled on OpenSpace's skill_records + skill_lineage_parents schema) provides fast DAG traversal, quality metric queries, and semantic search. This mirrors the existing pattern where EpisodicMemory uses ChromaDB+SQLite for fast queries while Ship's Records provides the authoritative store.
• Version DAG (absorbed from OpenSpace) — procedure_records table with lineage columns (origin, generation, content_snapshot as JSON, content_diff as unified diff, change_summary). procedure_lineage_parents many-to-many join table with composite PK (procedure_id, parent_procedure_id) supporting multi-parent DERIVED merges. BFS upward/downward traversal methods. is_active flag for FIX-deactivation semantics (FIX deactivates parent, DERIVED does not).
• Quality metrics per procedure (absorbed from OpenSpace) — four atomic counters on each procedure record: total_selections, total_applied, total_completions, total_fallbacks. Four derived rates: applied_rate (applied/selected), completion_rate (completed/applied), effective_rate (completed/selected), fallback_rate (fallbacks/selected). Counters updated atomically under lock after each execution. Feed dispatch decisions (AD-534) and lifecycle management (AD-538).
• Semantic index — procedure names + preconditions are embedded and stored in a dedicated ChromaDB collection (procedures). Enables semantic matching during dispatch (AD-534).
• Tagging — procedures tagged with: intent types they handle, agent types that can execute them, domain (engineering, security, medical, etc.), compilation level, trust tier required.
• Version tracking — when a procedure is updated (FIX or failure-driven fork), the old version is archived with a superseded_by pointer. Git history preserves the evolution. The SQLite DAG index provides fast traversal without reading Git history.
• Negative procedure index — negative procedures stored in records/procedures/anti-patterns/ with the same semantic indexing for fast "don't do this" lookups during dispatch.
• Anti-loop guards (absorbed from OpenSpace) — addressed_degradations dict tracks tool→procedure_ids already processed by metric-triggered evolution. Prevents re-processing the same degradation. Cleared when tool recovers. min_selections threshold (default 5) prevents evaluating newly evolved procedures.
• Thread safety (absorbed from OpenSpace) — single write connection with threading.Lock. Read path uses fresh read-only connections (PRAGMA query_only=ON). WAL mode for concurrent readers. All DB methods wrapped in retry decorator (max_retries=5, backoff=2.0) for transient SQLite errors.

Dependencies: AD-434 (Ship's Records backend), AD-532 (produces procedures to store).

---

AD-534: Replay-First Dispatch — Roadmap.

Before: CognitiveAgent.decide() always invokes the LLM. Every task costs tokens regardless of whether the agent has solved it before.

After: decide() checks procedural memory BEFORE the LLM call. If a matching procedure exists with sufficient confidence, replay deterministically at zero tokens. If no match or low confidence, fall back to LLM.

• Dispatch order — CognitiveAgent.decide() gains a new first step: _check_procedural_memory(intent). Semantic match against procedure index (AD-533). If match score > threshold AND procedure compilation level ≥ 3 (validated) AND agent trust tier meets procedure's minimum: attempt deterministic replay. Otherwise: LLM path.
• Dispatch function (enhanced with OpenSpace quality metrics) — dispatch decision incorporates per-procedure quality metrics alongside compilation level and trust:

  dispatch = f(
      procedure.match_score,          # semantic similarity
      procedure.compilation_level,     # Dreyfus level (AD-535)
      procedure.effective_rate,        # succeeded/selected (from OpenSpace)
      procedure.completion_rate,       # succeeded/used (from OpenSpace)
      agent.trust_tier,               # Earned Agency (AD-357)
      task.criticality                # Standing Orders (AD-339)
  )
  

  A procedure with high compilation level but declining effective_rate triggers re-validation (AD-538) rather than blind replay.
• Replay execution — iterate procedure steps, execute deterministically, validate postconditions after each step. If any step's postcondition fails: abort replay, fall back to LLM, record the failure for procedure evolution.
• Negative procedure check — before executing, also check negative procedure index. If the current context matches a known anti-pattern: skip the bad approach, log a warning, use the LLM instead or select an alternative procedure.
• Metrics — Cognitive Journal (AD-431) records procedure replays with cached=True, procedure_id=.... Token savings are measurable: sum(estimated_tokens) for cached=True procedure replays.
• Fallback learning — when a replay fails and the LLM succeeds, the LLM's approach is compared to the failed procedure. If the procedure was wrong (postcondition permanently changed), update or fork. If the procedure was right but preconditions weren't met, annotate preconditions.
• Metric-based health diagnosis (absorbed from OpenSpace) — rule-based, first match wins: fallback_rate > 0.4 → FIX evolution; applied_rate > 0.4 AND completion_rate < 0.35 → FIX; effective_rate < 0.55 AND applied_rate > 0.25 → DERIVED. Feeds AD-538 lifecycle management.

Dependencies: AD-533 ✅ (procedure store to query), AD-431 ✅ (Cognitive Journal for recording replays).

AD-534b: Fallback Learning (SHIPPED, OSS — see line 1121 for the canonical entry) — When a procedure replay fails and the LLM succeeds, compare the LLM's approach to the failed procedure. If the procedure was wrong (postcondition permanently changed), trigger FIX evolution (AD-532b). If the procedure was right but preconditions weren't met, annotate preconditions. Also includes step-by-step postcondition validation during replay — currently replay returns formatted steps as a unit; AD-534b adds per-step execution with expected_output validation and mid-replay abort on postcondition failure. Depends on AD-532b (FIX evolution actions) and AD-534 (replay infrastructure).

---

AD-535: Graduated Compilation Levels — COMPLETE.

Five Dreyfus-inspired compilation levels with trust-gated progression, replacing the binary LLM-or-deterministic dispatch:

Level	Label	LLM Usage	Behavior	Min. Trust Tier
1	Novice	Full LLM, no procedure	First encounter. LLM reasons from scratch.	Ensign
2	Guided	LLM + procedure hints	Procedure steps injected into LLM prompt as guidance via _build_guided_decision() + _format_procedure_as_hints(). ~40% token reduction.	Ensign
3	Validated	Deterministic + LLM validation	Procedure executes deterministically. LLM validates result via _build_validated_decision() + _validate_replay_postconditions(). Per-step validation for compounds. ~80% token reduction. Sweet spot.	Lieutenant
4	Autonomous	Pure deterministic	Zero LLM tokens. Procedure executes start-to-finish without LLM. Full confidence.	Lieutenant+
5	Expert	Can teach others	Agent can extract and explain the procedure to other agents via Ward Room. Procedure published to shared library with agent's endorsement.	Commander+

• Level transitions — upward: N consecutive successful uses at current level (configurable, default 3), tracked via consecutive_successes column. Downward: any failure drops to Level 2 (Guided) for re-validation, not Level 1 (preserves the procedure, just adds LLM oversight).
• Trust clamping — _max_compilation_level_for_trust() caps compilation level based on agent trust tier. A procedure can be Level 4 capable, but an Ensign agent runs it at Level 2.
• PROCEDURE_MIN_COMPILATION_LEVEL changed from 1 to 2 — procedures enter the system at Guided, not Novice. Startup migration promotes qualifying Level 1 procedures.
• ProcedureStore additions — consecutive_successes column, record_consecutive_success(), reset_consecutive_successes(), promote_compilation_level(), demote_compilation_level(), schema migration.
• 7 new config constants — trust tier thresholds and compilation level values.
• Level 5 Expert — deferred (requires Ward Room procedure publishing infrastructure).

Dependencies: AD-534 ✅ (replay mechanism to graduate), AD-357 (Earned Agency trust tiers), AD-339 (Standing Orders for criticality classification). 62 tests across 9 test classes. 449 total Cognitive JIT tests.

---

AD-536: Trust-Gated Procedure Promotion — COMPLETE.

Before: No governance over which procedures enter the shared library. No approval workflow. No distinction between routine and critical procedures.

After: Two-tier approval. Department chiefs approve routine procedure promotions within their domain (Engineering, Security, Medical, etc.). Captain approves critical procedures (security changes, data integrity, cross-department). Procedures not approved stay as agent-private knowledge.

• Criticality classification — ProcedureCriticality enum (LOW/MEDIUM/HIGH/CRITICAL). classify_criticality() uses keyword detection (PROMOTION_DESTRUCTIVE_KEYWORDS), cross-department analysis, and domain classification.
• Promotion eligibility — Level 4+ compilation, minimum success count, minimum success rate, minimum trust. Configurable via PROMOTION_MIN_* constants.
• Approval routing — _route_promotion_approval() routes LOW/MEDIUM to department chief (_DEPARTMENT_CHIEFS mapping), HIGH/CRITICAL to Captain via Bridge. Ward Room announcement via _announce_promotion_request().
• ProcedureStore tracking — 6 new columns (promotion_status, promoted_at, promoted_by, promotion_requested_at, promotion_criticality, promotion_notes). 6 new methods. Migration for existing procedures.
• Level 5 Expert unlock — _max_compilation_level_for_promoted() gates Expert compilation behind promotion approval.
• Shell commands — /procedure list-pending, /procedure approve, /procedure reject, /procedure list-promoted.
• API endpoints — GET /procedures/pending, POST /procedures/approve, POST /procedures/reject, GET /procedures/promoted.
• Rejection learning — rejected procedure stores feedback as institutional knowledge.

Dependencies: AD-535 ✅ (compilation levels to gate), AD-339 ✅ (Standing Orders integration), Chain of Command ✅ (existing). 64 tests across 7 test files. 460 total Cognitive JIT tests.

---

AD-537: Observational Learning (Ward Room Cross-Agent Learning) — COMPLETE.

Before: Agents only learn from their own direct experience. If Security solves a problem that Engineering later encounters, Engineering starts from scratch.

After: Agents learn from observing other agents' successes and failures in Ward Room discussions. When Agent A describes how they solved problem X, Agent B can extract a procedure from the discussion — even though B never performed the task. Bandura's social learning theory, implemented.

• Ward Room observation — during dream consolidation, analyze Ward Room messages (AD-430 already stores Ward Room episodes) for success/failure narratives by other agents.
• Vicarious procedure extraction — when a Ward Room discussion describes a successful approach with enough detail (determined by LLM analysis), extract a procedure attributed to the originating agent with a learned_via=observational provenance tag.
• Cross-department transfer — an Engineering procedure observed by Security is tagged as cross-department. Starts at Level 1 (Novice) even if the originating agent had it at Level 5 — the observing agent hasn't validated it yet.
• Teaching protocol — Level 5 (Expert) agents can explicitly teach procedures to specific agents via Ward Room DMs. The teaching interaction is stored as a high-weight episode with learned_via=taught provenance. Taught procedures start at Level 2 (Guided) — a head start over observation.

Dependencies: Ward Room (existing) ✅, AD-532 (extraction mechanism) ✅, AD-430 (Ward Room episodes) ✅. 52 tests across 7 test files. 512 total Cognitive JIT tests.

---

AD-538: Procedure Lifecycle Management — Complete.

Before: Once created, procedures exist forever with no maintenance. Stale procedures for changed codebases silently fail at replay time.

After: Procedures have a full lifecycle: creation → active use → decay → re-validation → archival/retirement. The procedure store stays fresh and relevant.

• Decay — procedures not used within a configurable window (default: 30 days) lose one compilation level per decay period. A Level 4 unused for 30 days drops to Level 3. Decay never drops below Level 1. One level per dream cycle (no cliff-edge). Resets consecutive_successes. Ebbinghaus forgetting curve — successful use resets the decay clock (spaced repetition).
• Re-validation via decay — decay to Level 1 (Novice) IS re-validation: LLM verifies the procedure on next use. If it succeeds, it climbs back. If it fails, the AD-532b evolution pipeline creates a FIX variant. File-change-triggered re-validation deferred until CodebaseIndex gets incremental re-indexing.
• Deduplication — during dream cycle (Step 7f), ChromaDB cosine similarity > 0.85 + shared intent types flags merge candidates. Captain-initiated merge via /procedure merge — transfers stats, unions tags/intents, deactivates duplicate. Automatic merge deliberately excluded (risk of data loss).
• Archival — procedures at Level 1 unused for 90 days archived to Ship's Records _archived/. Removed from active ChromaDB index. Restorable via /procedure restore.
• Version diff — already delivered by AD-532b (content_diff, change_summary, get_evolution_metadata()).
• Promotion status survives decay — institutional approval stands; agent re-demonstrates competence by climbing compilation levels again.

Dependencies: AD-533 ✅ (procedure store), AD-534 ✅ (replay mechanism for re-validation).

---

AD-539: Knowledge Gap → Qualification Pipeline — Complete.

Before: Capability gaps were invisible. If an agent repeatedly failed at a task type, no one noticed until the Captain observed it manually. No systematic training.

After: Multi-source gap detection (failure clusters, procedure decay, health diagnosis, episodes) automatically identifies systematic capability gaps. Gaps are classified (knowledge/capability/data), bridged to the Skill Framework for qualification triggering, and tracked through closure. 12 implementation parts, 49 tests.

• Multi-source gap detection — Four evidence sources: AD-531 failure clusters, AD-538 decayed/failed procedures, diagnose_procedure_health() findings, and raw episode analysis. Each source produces typed GapEvidence with provenance.
• Gap classification — Three categories: knowledge gap (training helps), capability gap (escalation needed), data gap (information routing problem). Classification via configurable rules with LLM fallback.
• Skill Framework bridge — Knowledge gaps map to QualificationRecord entries via start_qualification(). Existing Skill Framework (AD-428) handles the qualification lifecycle.
• Qualification triggering — Automatic qualification creation for knowledge gaps that map to existing PCCs. Counselor notification for capability/data gaps requiring different intervention.
• Enhanced Dream Step 8 — predict_gaps() enhanced with procedure evidence and gap classification. Gap reports include qualification suggestions and progress tracking.
• Progress tracking — Gap closure measured by procedure compilation level improvement, success rate increase, qualification completion. Tracked via GapReport with closure metrics.
• Deferred: AD-539b (Holodeck scenario generation from gaps), AD-539c-i (active gap remediation — AD-539c v1 ships observational tracker only), AD-539d-i (federated cross-ship gap aggregation — AD-539d v1 ships local-ship aggregator only).

AD-538b: Dream Consolidation Manifest (complete, OSS, depends: AD-538, AD-551) — Add a consolidation_manifest that tracks per-episode, per-dream-step+version what has been processed. Dream cycles skip already-consolidated episodes unless modified (reconsolidation, AD-541b) or decayed (AD-538). Eliminates redundant reprocessing as episode count grows. Absorption: memvid enrichment manifest tracking pattern — per-frame, per-engine-version processing manifests for incremental-only enrichment (2026-04-05, see docs/research/memvid-evaluation.md Pattern 2).

Dependencies satisfied: AD-531 (episode clustering), AD-538 (procedure failures/decay), AD-428 (Skill Framework).

---

AD-464 Build Sequence Summary

Order	AD	Name	Depends On	Key Outcome
1	AD-531	Episode Clustering	AD-430 ✅, DreamingEngine ✅	COMPLETE — Agglomerative clustering (cosine, average-linkage). EpisodeCluster dataclass. get_embeddings(). Dead strategy_extraction.py removed. 40 tests.
2	AD-532	Procedure Extraction	AD-531 ✅, AD-431 ✅	COMPLETE — LLM-assisted extraction from success clusters. Procedure/ProcedureStep schema. AD-541b READ-ONLY framing. Standard tier. Cluster dedup via _extracted_cluster_ids. 29 tests. Deferred: AD-532b–e.
3	AD-533	Procedure Store	AD-532 ✅, AD-434 ✅	COMPLETE — Hybrid store: Ship's Records (YAML) + SQLite index (Version DAG, quality metrics) + ChromaDB (semantic search). ProcedureStore class with save/get/list_active/find_matching/deactivate. 4 quality counters + 4 derived rates. Thread-safe (Lock + WAL). Dream cycle integration with cross-session dedup. 49 tests.
4	AD-534	Replay-First Dispatch	AD-533 ✅, AD-431 ✅	COMPLETE — _check_procedural_memory() in decide() checks ProcedureStore before LLM. Semantic match + quality metrics dispatch. Negative procedure guard. 4 metric recording stages (selection/applied/completion/fallback). Health diagnosis (log-only). Journal procedure_id column. Configurable thresholds. 35 tests. Minimum viable slice complete: AD-531→532→533→534.
4b	AD-534b	Fallback Learning	AD-534 ✅, AD-532b ✅	COMPLETE — Metric semantics fix (record at handle_intent), near-miss capture (4 rejection types), service recovery (_decide_via_llm + _run_llm_fallback), PROCEDURE_FALLBACK_LEARNING event + queue, evolve_fix_from_fallback() with _FALLBACK_FIX_SYSTEM_PROMPT, Dream Step 7d, DreamReport fields. 68 tests. 333 total Cognitive JIT tests.
4c	AD-534c	Multi-Agent Replay Dispatch	AD-534 ✅, AD-532d ✅	COMPLETE — ProcedureStep.resolved_agent_type field, _resolve_agent_roles() at extraction, compound detection in _check_procedural_memory(), _execute_compound_replay() orchestrator, _resolve_step_agent() (pool→capability→fallback), zero-token _handle_compound_step_replay() handler, _format_single_step() DRY, handle_intent() compound branch. COMPOUND_STEP_TIMEOUT_SECONDS=10.0. Unavailability → single-agent fallback. Step postcondition validation deferred to AD-535. 54 tests. 387 total Cognitive JIT tests.
5	AD-535	Graduated Compilation	AD-534 ✅, AD-357, AD-339	COMPLETE — Five Dreyfus levels (Novice→Guided→Validated→Autonomous→Expert). Trust-clamped via _max_compilation_level_for_trust(). Promotion via consecutive_successes tracking, demotion to Level 2 on failure. PROCEDURE_MIN_COMPILATION_LEVEL=2. _build_guided_decision(), _build_validated_decision(), _validate_replay_postconditions(), _validate_step_postcondition(). 7 config constants. ProcedureStore migration. 62 tests. 449 total Cognitive JIT tests.
6	AD-536	Trust-Gated Promotion	AD-535 ✅, AD-339 ✅	COMPLETE — ProcedureCriticality enum, classify_criticality(), two-tier approval routing (dept chief / Captain), 6 promotion columns + migration, Level 5 Expert gating, /procedure shell commands, API endpoints, rejection learning. 64 tests. 460 total Cognitive JIT tests.
7	AD-537	Observational Learning	Ward Room ✅, AD-532	COMPLETE — Three learning pathways: observation (Ward Room dream Step 7e, Level 1 entry), teaching (Level 5 promoted via DM, Level 2 entry), direct (existing). COMPILATION_MAX_LEVEL=5. Procedure.learned_via/learned_from fields. extract_procedure_from_ward_room_thread(). /procedure teach + observed commands. API endpoints. 52 tests. 512 total Cognitive JIT tests.
8	AD-538	Procedure Lifecycle	AD-533 ✅, AD-534 ✅	COMPLETE — Ebbinghaus-inspired forgetting curve: last_used_at timestamp, decay_stale_procedures() (30-day window, one level per cycle, never below Level 1), archive_stale_procedures() + restore_procedure() (90-day Level 1 → Ship's Records _archived/), find_duplicate_candidates() (ChromaDB cosine >0.85 + shared intent types) + merge_procedures() (Captain-initiated, transfers stats). Dream Step 7f (decay→archive→dedup per cycle). is_archived field + migration. 5 shell commands (stale/archived/restore/duplicates/merge). 5 API endpoints. 57 tests. 569 total Cognitive JIT tests.
9	AD-539	Gap → Qualification	AD-531, AD-538, AD-428	COMPLETE. 49 tests. 618 total Cognitive JIT tests.

Minimum viable slice: AD-531 → AD-532 → AD-533 → AD-534. This delivers the core value: episodes cluster → procedures extract → procedures store → replay at zero tokens. Full Cognitive JIT pipeline COMPLETE (9/9 ADs): AD-535 graduated compilation (five Dreyfus levels with trust-gated progression), AD-536 trust-gated promotion (two-tier governance with department chief / Captain approval), AD-537 observational learning (three-pathway cross-agent learning: observation, teaching, direct), AD-538 procedure lifecycle (Ebbinghaus decay, archival to Ship's Records, ChromaDB deduplication, Captain-initiated merge), AD-539 gap→qualification pipeline (multi-source gap detection, classification, Skill Framework bridge, qualification triggering, progress tracking). 618 total Cognitive JIT tests.

Prior art: OpenSpace (HKUDS, MIT License) — github.com/HKUDS/OpenSpace. Self-evolving skill engine that extracts, versions, and evolves reusable skills from LLM task executions. Production-validated: 4.2x higher income on GDPVal benchmark with 46% fewer tokens. Six patterns absorbed into AD-531–534 designs: (1) post-execution analysis with tool-use-enabled LLM + fuzzy ID correction → AD-531; (2) three evolution types (FIX/DERIVED/CAPTURED) + three independent triggers + apply-retry + confirmation gates → AD-532; (3) version DAG schema (SQLite, parent links, content snapshots, quality counters, anti-loop guards) → AD-533; (4) per-procedure quality metrics (applied/completion/effective/fallback rates) + metric-based health diagnosis → AD-534. OpenSpace lacks: sovereign identity, trust network, agent-to-agent communication, episodic memory, dream consolidation, chain of command governance, graduated compilation levels, and cross-agent observational learning. Full technical analysis in commercial research repo.

Standalone improvements from OpenSpace (independent of Cognitive JIT): - Self-mod apply-retry — absorb apply-retry with LLM correction into SelfModificationPipeline. Up to 3 attempts with LLM-assisted error correction. No dependency on AD-531+. - CodebaseIndex hybrid ranking — absorb BM25 + embedding fusion into CodebaseIndex.query(). Currently word-level keyword scoring only. No dependency on AD-531+. - Self-mod confirmation gates — automated self-mod triggers should require LLM confirmation. Conservative default: ambiguous = skip. No dependency on AD-531+.

Connection to existing roadmap items: - AD-428 (Skill Framework) — procedures provide evidence for proficiency progression; Level 3→4 Dreyfus transition is literally "agent has enough compiled procedures to operate from pattern recognition" - AD-357 (Earned Agency) — trust tiers gate compilation levels; Ensigns escalate more, Seniors operate autonomously - AD-339 (Standing Orders) — approved procedures can become standing orders; criticality classification comes from standing order tiers - AD-462 (Memory Architecture) — episode clustering is the first concrete implementation of the "Active Forgetting" and "Variable Recall" concepts from the biological memory model - AD-434 (Ship's Records) — procedure store backend; Git versioning provides procedure history - AD-503 (Counselor Activation) — gap reports visible to Counselor for crew wellness assessment - Commercial AD-C-021 (Pro Code Reviewer) — Semgrep rule compilation is a concrete instance of Cognitive JIT for the code review domain

---

Operations Team (Phase 33)

"Rerouting power to forward shields."

Formalize resource management and system coordination as an agent pool.

• Resource Allocator (AD-467) — workload balancing across pools, demand prediction, capacity planning
• Scheduler (AD-467) — task prioritization, queue management, deadline enforcement (extends Phase 24c TaskScheduler). Includes cron-style scheduling (recurring tasks on configurable intervals), webhook triggers (external events activate task pipelines), and unattended operation (tasks run while Captain is away, results queued for review on return). Modeled after the US Navy watch system — crew operate in rotating watches with clear handoff protocols, enabling 24/7 operations even when the Captain is off-watch (see: The Conn, Night Orders below)
• Coordinator (AD-467) — cross-team orchestration during high-load or emergency events
• Workflow Definition API (AD-467) — user-facing REST endpoint for defining reusable multi-step pipelines. POST /api/workflows accepts a YAML/JSON workflow specification with named steps, dependencies, and approval gates. GET /api/workflows lists saved workflows. POST /api/workflows/{id}/run triggers execution. Complements natural language decomposition (which auto-generates DAGs) with explicit, repeateable, templateable workflows. Templates for common patterns: "lint and test on every commit," "weekly codebase report," "build and deploy"
• Response-Time Scaling (AD-467) (deferred from Phase 8) — latency-aware pool scaling. Instrument broadcast() with per-intent latency tracking, scale up pools where response times exceed SLA thresholds
• LLM Cost Tracker (AD-467) — per-agent, per-intent, and per-DAG token usage accounting. Budget caps (daily/monthly), cost attribution via Shapley (which agents are expensive vs. valuable), per-workflow cost breakdowns for end-to-end visibility, alerts when spend exceeds thresholds. Provides the data foundation for commercial ROI analytics. Note: accurate cost attribution will require a proper tokenizer library (e.g., tiktoken for OpenAI models, model-specific tokenizers for others) — current len(content) // 4 estimation is insufficient for billing-grade accuracy
• Existing: PoolScaler (built), TaskScheduler (Phase 24c roadmap), IntentBus demand tracking (built)

Runtime Configuration Service — Ship's Computer (AD-468)

"Computer, set Scout to run every 6 hours."

The Captain shouldn't need a settings panel to configure the ship — they give orders. Runtime configuration (scheduled tasks, agent activation, startup behavior, thresholds) should be controllable via natural language through the Ship's Computer or a configuration specialist agent. The HXI configuration panel is the visual complement for oversight and manual overrides.

• NL-driven configuration — "Disable Scout's automatic scan," "Set the dream cycle to run every 4 hours," "Give Engineering priority during builds." Ship's Computer parses the order, identifies the config target, applies the change, confirms to Captain. Standing Orders govern what's configurable vs. invariant
• Startup task management — configurable list of tasks that run at boot, each with: enabled/disabled toggle, delay (seconds after boot), interval (recurring or one-shot), conditions (e.g., only if Discord is configured). Like Windows startup manager but NL-controllable. Current hardcoded Scout delay_seconds=60, interval_seconds=86400 becomes data-driven
• HXI Configuration Panel — visual dashboard showing: active scheduled tasks (with on/off toggles), agent pool sizes, LLM tier assignments, threshold values (trust, scaling), startup sequence. Read-write: Captain can adjust values directly. All changes logged to Cognitive Journal for audit
• Configuration persistence — changes survive restart. Stored in config/runtime_overrides.toml or similar, layered on top of base config. Reset clears overrides back to defaults
• Configuration specialist agent — Operations department agent that handles configuration intents. Validates changes against Standing Orders (e.g., can't disable trust verification), applies atomically, reports confirmation. Escalates to Captain for changes that affect safety invariants

EPS — Electro-Plasma System (Compute/Token Distribution) (AD-469)

"Reroute power from life support to shields!"

In Star Trek, the EPS distributes power from the warp core through conduits to every system. When power is limited, the Chief Engineer decides who gets how much. ProbOS has the same problem: one Copilot proxy bottleneck (127.0.0.1:8080), three LLM tiers (deep/fast/standard) sharing it, and multiple departments competing for LLM capacity. When Engineering runs a multi-chunk build, Medical and Science compete for the same constrained pipe. Nobody manages the power grid.

• Capacity tracking — monitor total available LLM throughput (tokens/minute, concurrent requests, queue depth) across all providers
• Department budgets — allocate LLM capacity per department based on priority. Engineering gets 60% during builds, Medical gets priority during Red Alert diagnostics
• Alert-aware reallocation — Alert Conditions automatically shift budget priorities. Green: balanced. Yellow: boost Medical/Security. Red: all power to the crisis department
• Captain override — "give Engineering all the power" as a manual reallocation command via HXI
• Utilization reporting — per-department LLM usage feeds into Cognitive Journal and HXI dashboard. Captain sees where compute is going in real-time
• Back-pressure — when a department exhausts its budget, requests queue or downgrade tier (deep → fast) rather than failing
• Atomic budget enforcement — budget checks must be transactional with task assignment (not after-the-fact). When an agent checks out a task, the budget deduction is atomic — prevents cost overruns at the checkout level. Pattern validated by Paperclip AI's budget engine (30K stars, MIT)
• Integration — sits between the IntentBus (which routes intents) and the tiered LLM client (which makes calls). EPS decides whether a request gets served now, queued, or downgraded based on budget and alert condition
• Prompt caching hierarchy (absorbed from Aider, 2026-03-21) — order messages array by change frequency (most stable first) to maximize prefix cache hits on Anthropic/DeepSeek: Standing Orders (rarely change) → runtime directives (change occasionally) → repo map/grounded context → task-specific context (changes every call). Structure CognitiveAgent.decide() message assembly accordingly. Anthropic has 5-min cache TTL; consider keepalive pings for long-running sessions. Low implementation effort, significant per-token cost savings

Ward Room — Agent Communication Fabric

"Senior officers to the Ward Room."

Inspired by Claude Code Agent Teams' inter-agent mailbox, AgentScope's MsgHub broadcast groups, Reddit's vote/karma/subreddit model (archived OSS), Radicle's COBs-in-Git archival, Minds' ActivityPub federation and token rewards, Aether's CompiledContentSignals and ExplainedSignalEntity patterns, and the starship ward room where officers discuss matters outside the chain of command. See docs/development/ward-room-design.md for full AD-407 design.

Currently ProbOS agents communicate only via the intent bus (broadcast to pools) or consensus (voting). There is no way for one agent to send a targeted message to a specific agent, no department channels, and no group conversations. Agents can't develop through peer interaction. The Ward Room is the missing communication fabric — not just a mailbox, but the social infrastructure through which agents learn, coordinate, and grow.

Core principle: Human agents and AI agents share the same message bus. The Captain isn't a special external interface — they're a participant on the Ward Room with a callsign (@captain), addressable the same way any crew member is. Agents can @captain to escalate, report, or ask for guidance. The Captain @wesley for a check-in. Same syntax, same routing, same fabric. The shell, HXI command surface, and Discord are just different terminals into the same bus — not separate interfaces. Every interaction — with the Captain, with peers, in a group — is a learning opportunity. Conversations feed EpisodicMemory, strengthen Hebbian connections, and contribute to personality evolution. Agents develop distinctly based on who they talk to and what they discuss.

Communication Channels:

• 1:1 Agent↔Agent — direct messages between specific agents. Builder asks Architect "which signature?" without routing through the Decomposer. Counselor checks in with an agent showing trust drift. Agents initiate conversations themselves when they have something relevant — not only when tasked
• Department channels — persistent group channels per department. The Medical team (Diagnostician, Vitals Monitor, Surgeon, Pharmacist, Pathologist) can discuss a complex diagnostic together without involving the whole ship. Any member can post, all members see it. Like a department Slack channel
• Cross-department channels — Bridge officers (Captain, First Officer, Counselor) can participate in any department channel. Ad-hoc cross-department channels for collaborative work (Engineering + Science on a complex build)
• Captain 1:1 sessions — AD-397 @callsign addressing. The Captain's conversations with individual crew members also feed that agent's development
• Ward Room meetings — temporary multi-agent sessions for a specific topic. Captain or Department Chief convenes, participants contribute, meeting ends. Minutes logged. AgentScope MsgHub pattern: context-manager for temporary broadcast groups with dynamic participant add/remove

WardRoom Service:

• Registered on the runtime — agents send/receive typed messages by agent ID or callsign. Supports 1:1, department broadcast, and ad-hoc group addressing
• Message types — clarification_request, status_update, finding_report, handoff, model_comparison, check_in, consultation, briefing (with typed payloads)
• Delivery model — async mailbox. Recipient processes messages in its next perceive() cycle via check_message_queue. Unread messages expire after configurable TTL
• Trust-gated — agents can only message agents they have positive trust scores with (prevents spam/abuse in federated scenarios)
• Federation extension — Ward Room messages can cross ship boundaries via FederationBridge. Agent A on Ship Alpha directly messages Agent B on Ship Beta

Development Through Communication:

• Episodic memories from conversations — every meaningful exchange is stored as an episode. Wesley remembers that Bones flagged a recurring error pattern last week. Scotty remembers Number One's preference for minimal-change builds
• Hebbian reinforcement — successful collaborations strengthen the connection weight between agents. Medical agents who frequently help each other build stronger intra-department bonds. Cross-department collaborations that succeed build new pathways
• Personality nuancing — an agent's communication style evolves based on who they interact with. Wesley's conscientiousness might increase through regular check-ins with a detail-oriented Captain. Scotty's agreeableness might shift based on peer feedback
• Knowledge transfer — agents share domain insights through conversation, not just through the KnowledgeStore. The Counselor's observation about an agent's drift pattern becomes shared wisdom when discussed in a department meeting
• Dream integration — conversation patterns and recurring topics surface during dream consolidation. "Wesley and Bones keep discussing the same error pattern" → abstract insight captured as L3-L4 knowledge

Use Cases:

• Medical team rounds — Diagnostician presents findings, Pathologist offers analysis, Pharmacist suggests fixes, Surgeon evaluates intervention options. Multi-agent clinical discussion
• Architect↔Builder clarification — Builder encounters ambiguity in BuildSpec, asks Architect directly without Decomposer involvement
• Mid-run Captain input (absorbed from LangChain Open SWE) — Captain sends clarification to Builder mid-build via Ward Room injection into perceive() cycle
• Counselor office hours — Counselor initiates 1:1s with agents showing signs of drift, burnout, or isolation. Therapeutic conversations feed assessment reports
• Cross-department emergency — Red Alert triggers a temporary all-department channel. Medical reports system health, Engineering reports build status, Security reports threat assessment — all visible to all departments simultaneously

Audit trail — all messages logged to Cognitive Journal for replay and post-hoc analysis. Captain can review any channel's history

HXI Channel Administration — Channel management (create, rename, archive, set permissions) must be a Captain capability in the Ward Room web app, not a code deployment. The POST /api/ward-room/channels endpoint already exists; this adds the HXI surface: channel creation form, channel settings panel, member management, and archive/delete controls. System channels (e.g., #improvement-proposals from AD-412) can be created directly from the Bridge without a build prompt. Follows the HXI Cockpit View Principle — every agent-mediated capability must have a direct manual control.

IntentBus Enhancements — Priority & Back-Pressure (AD-470)

"All decks, this is a priority one message."

The IntentBus currently treats all intents equally — a critical self-mod proposal has the same priority as a routine health check. As the ship grows more capable (more agents, more models, more concurrent tasks), the bus needs traffic management.

• Priority levels — IntentMessage gains a priority: int field (1=routine, 5=critical). Priority 5 intents preempt lower-priority work in the subscriber's queue. Priority 1 intents yield to higher-priority work during resource contention
• Back-pressure — when the LLM proxy is saturated (all concurrent slots occupied), new LLM-bound intents are queued rather than immediately dispatched. Queue depth triggers automatic scaling signals to PoolScaler. Configurable max queue depth with overflow policy (reject, degrade to fast tier, or batch)
• Rate limiting per agent — prevent any single agent from flooding the bus. Configurable intent-per-second cap per agent ID. Excess intents queued, not dropped
• Intent coalescing — when multiple identical intents are queued (same name, similar payload), coalesce into a single broadcast with merged context. Prevents duplicate work during high-load scenarios
• Metrics — bus throughput, queue depth, priority distribution, coalescing rate. Feeds into Bridge Alerts (advisory when queue depth exceeds threshold) and Cognitive Journal (per-intent routing latency)

Self-Claiming Task Queue (AD-470)

Inspired by Claude Code Agent Teams' shared task list with self-claim.

Currently ProbOS DAGExecutor assigns work centrally — the Decomposer decomposes, the executor dispatches. Self-claiming adds a complementary pattern where agents pull work from a shared queue based on their capabilities and availability.

• TaskQueue service — shared queue of pending work items, visible to all agents in a pool
• Claim protocol — agents inspect the queue during idle cycles, claim tasks matching their _handled_intents, file-lock or atomic CAS prevents double-claim
• Use case: parallel builds — multiple BuildSpecs queued, multiple Builder instances (pool scaled) each claim one and work independently
• Use case: investigation sweep — Science team agents self-claim codebase analysis tasks from a queue rather than having each assigned individually
• Task dependencies — tasks can declare depends_on (other task IDs). Dependent tasks remain blocked until prerequisites complete. Automatic unblocking on dependency completion
• Complements DAGExecutor — DAGExecutor handles structured decomposition (query → sub-tasks → aggregate). TaskQueue handles unstructured work pools where any capable agent can contribute

Competing Hypotheses / Adversarial Investigation

Inspired by Claude Code Agent Teams' "spawn agents with competing theories, have them debate" pattern.

ProbOS has red team agents for adversarial verification, but not a structured pattern where multiple agents explore competing theories and actively try to disprove each other's findings before converging.

• Investigation Team pattern — spawn N agents (Science team) with different hypotheses about the same problem. Each agent investigates independently, then agents exchange findings and actively challenge each other
• Debate protocol — after investigation phase, agents enter a structured debate: present evidence → challenge claims → rebut → converge. Dissenting positions recorded, not suppressed
• Convergence scoring — use trust-weighted voting to identify the hypothesis with the strongest evidence. Bayesian update on agent trust based on whether their hypothesis was validated
• Use case: root cause analysis — when a system anomaly occurs, spawn 3 investigators with different theories. The survivor hypothesis drives the fix
• Use case: design review — Architect proposes, multiple reviewers critique from different angles (security, performance, maintainability), synthesize into a stronger proposal
• Quality gate hook — upon convergence, the winning hypothesis must pass a verification step before being accepted (similar to Claude Code's TaskCompleted hook pattern)

Bridge Alerts — Proactive Captain Notifications (AD-410) ✅

"Captain, sensors detect an anomaly in the aft section."

Implemented: BridgeAlertService with 5 signal processors (vitals, trust change, emergent patterns, behavioral, dedup). Three severity levels: info (department channel), advisory (All Hands + info notification), alert (All Hands + action_required notification). Posts to Ward Room as "Ship's Computer" — crew agents respond organically via AD-407d. Config: BridgeAlertConfig with cooldown, trust drop thresholds. Runtime hooks at consensus verification, QA trust updates, post-dream (emergent + behavioral + vitals). 31 tests.

Remaining (future): - Smart suppression — don't alert during known transient states (dream cycle, startup warm-up) - Bridge Alert panel — dedicated HXI section for recent alerts with dismiss/acknowledge - Captain's preference — respects Adaptive Communication Style settings for alert verbosity - Agent context injection — feed real system data into agent prompts during Ward Room responses

File Ownership Registry (AD-470)

Inspired by Claude Code Agent Teams' "avoid file conflicts — each teammate owns different files" pattern.

When ProbOS runs multiple builds or modifications in parallel, two agents editing the same file leads to overwrites or merge conflicts.

• FileOwnership service — tracks which agent currently "owns" (is modifying) which files
• Claim-before-edit — agents must claim file ownership before writing. Claim fails if another agent already owns the file
• Automatic release — ownership released when the owning task completes (success or failure)
• Conflict resolution — if two agents need the same file, the Coordinator mediates: sequential ordering, or one agent rolls back and waits
• Integration with Builder — execute_approved_build() claims all target files before writing, releases on completion
• Extends _background_tasks (AD-326) — file ownership tracked alongside task lifecycle

The Conn — Temporary Authority Delegation (AD-471, COMPLETE, OSS)

"Mr. Data, you have the conn."

Aligned with US Navy Officer of the Deck (OOD) protocol. When the CO goes off-watch, they formally delegate command authority to a qualified officer who operates within the CO's standing parameters and calls the CO only for situations exceeding those parameters.

ProbOS currently has no structured delegation when the Captain (human) goes offline. The ship either waits for human input or operates without oversight. The Conn formalizes temporary authority transfer, enabling autonomous operations within defined bounds.

• /conn <agent> command — Captain formally delegates temporary command authority to a bridge officer (First Officer, Counselor, or a promoted Department Chief). Only one officer holds the conn at a time
• Scope limitations — The conn-holder can approve routine operations (builds within approved scope, standard diagnostics, scheduled maintenance) but cannot: modify Standing Orders, approve self-mod proposals, change alert conditions to Red, or take destructive actions. These escalate to Captain regardless
• Escalation boundary — configurable set of conditions that automatically wake the Captain: trust score drops below threshold, confidence degradation exceeds limit, Red Alert triggered, build failure after retry exhaustion, any action requiring Captain-rank authorization. The conn-holder cannot suppress escalations
• Qualification requirements — Only agents with COMMANDER+ trust rank can hold the conn. Captain can further restrict to named agents. Counselor fitness assessment required (no delegating to a cognitively degraded officer)
• Handoff protocol — formal conn transfer: "I have the conn" acknowledgment, active task state transfer, situation report summary. Logged in Cognitive Journal
• Auto-return — when Captain comes back online, conn automatically returns: "Captain on the bridge" notification, conn-holder provides a summary of actions taken while in command
• Audit trail — all decisions made under delegated authority are logged with authorized_by: conn (not captain), enabling after-action review. Captain can /review conn-log to see what happened in their absence
• Integration — extends DirectiveStore authorization (conn-holder gets temporary captain_order authority within scope), Ward Room (conn-holder receives escalations), Alert Conditions (Red Alert returns conn to Captain)

Night Orders — Captain-Offline Guidance (AD-471, COMPLETE, OSS)

"Commander, the Captain left Night Orders."

Aligned with US Navy Night Orders — the CO's written instructions for the OOD covering: expected conditions, decision boundaries, when to call the CO. These are temporary directives that expire when the CO returns to the bridge.

Night Orders solve the gap between "Captain is present" (full oversight) and "Captain is absent" (no guidance). They capture the Captain's intent for the off-watch period, giving the conn-holder a decision framework rather than leaving them to guess.

• /night-orders command — Captain writes guidance before going offline. Structured as a set of conditional instructions: "If X happens, do Y. If Z happens, wake me."
• Time-bounded directives — Night Orders are captain_order directives with an automatic expiry (configurable TTL, default 8 hours). They expire when: the TTL lapses, the Captain comes back online, or the Captain explicitly rescinds them
• Decision boundaries — explicit bounds for the conn-holder: approved build types, acceptable trust score ranges, allowed alert level changes (Green↔Yellow but not Red), budget limits for LLM spend during absence
• Escalation triggers — Captain-defined conditions that override Night Orders and wake the Captain: "Call me if any build fails twice," "Call me if trust drops below 0.7 for any agent," "Call me for any security alerts"
• Briefing on return — when Captain returns, Night Orders auto-expire and the system generates a summary: actions taken, decisions made, escalations triggered (or suppressed), Night Orders that were invoked vs. never triggered
• Preset templates — common Night Orders patterns: "Maintenance watch" (routine ops only, no builds), "Build watch" (approve builds from approved queue, reject unknowns), "Quiet watch" (logging only, no autonomous actions)
• Integration — extends DirectiveStore (new night_order directive type with TTL), The Conn (Night Orders provide the conn-holder's operating parameters), Bridge Alerts (Night Orders can specify alert suppression rules), Cognitive Journal (all Night Order invocations logged for post-hoc review)

Watch Bill — Structured Duty Rotation (AD-471, COMPLETE, OSS)

"All hands, first watch section report to duty stations."

Aligned with US Navy watch rotation — crew organized into watch sections that rotate through duty periods, ensuring continuous operations with fresh personnel.

In the Navy, crew don't work 24/7 — they rotate through watch sections (typically 3 sections, 4-hour watches). This prevents fatigue and ensures continuity. ProbOS agents don't fatigue physically, but they do experience cognitive degradation: Hebbian weight drift, confidence erosion over sustained operation, context staleness. The Watch Bill formalizes rotation as a cognitive health mechanism.

• Watch sections — agents within a pool organized into sections (A/B/C). Only one section is on-watch at a time. Off-watch agents undergo maintenance: dream cycles, Hebbian weight normalization, episodic memory consolidation
• Rotation triggers — time-based (configurable interval), performance-based (Counselor detects cognitive fatigue), or event-based (alert condition change triggers fresh watch)
• Continuity handoff — on-watch agents pass situation state to incoming watch section: active tasks, pending decisions, recent context. Prevents "cold start" on rotation
• Integration — Counselor monitors on-watch agent health, recommends early rotation if cognitive metrics degrade. PoolScaler respects watch assignments. Cognitive Journal tracks per-watch performance for learning

---

Communications Team (Phase 24)

"Hailing frequencies open."

The Communications department handles all external interfaces — how users and other systems talk to ProbOS. Currently limited to a CLI shell, a web UI (HXI), and a basic Discord adapter. Users expect to reach their AI assistant from platforms they already use.

Channel Adapters (AD-472)

Each adapter bridges an external messaging platform to the ProbOS runtime. Adapters translate platform messages to natural language intents and stream responses back. The Discord adapter (src/probos/channels/discord_adapter.py) is the reference implementation.

• Discord — built (AD-phase-24, existing). Bot token + discord.py
• Message Content Intent verification (absorbed from Claude Code Channels, 2026-03-22) — Discord's privileged Message Content Intent must be enabled in the Developer Portal or the bot receives empty message bodies. Add a startup check that verifies the intent is granted and logs a clear warning if not
• Message fetch for reconnection recovery (absorbed from Claude Code Channels, 2026-03-22) — Discord's fetch_messages API can pull up to 100 messages per call (oldest-first). On adapter reconnection after restart, fetch missed messages from monitored channels and process any queued commands. Telegram has no equivalent — messages sent while offline are permanently lost
• Sender allowlist / channel authorization (absorbed from Claude Code Channels, 2026-03-22) — Currently anyone in the Discord channel can issue !scout or other commands. Add a sender allowlist model: pairing via code exchange, then allowlist enforcement at the adapter level. Aligns with chain of command — only authorized users (Captain, Bridge officers) can issue commands via external channels
• Slack — Slack Bolt SDK. App manifest + OAuth. Slash commands map to ProbOS / commands. Thread-based conversations maintain context
• Telegram — python-telegram-bot. Long polling or webhook. Inline keyboards for approval gates (approve/reject build proposals from Telegram)
• WhatsApp — WhatsApp Business Cloud API via Meta. Webhook-based. Approval gates via interactive buttons. Requires Meta business verification
• Matrix — matrix-nio async SDK. Self-hosted or matrix.org homeserver. E2E encryption support. Powers Beeper/Element interop
• Microsoft Teams — Bot Framework SDK. Enterprise SSO integration. Approval cards via Adaptive Cards
• SMS/MMS (stretch) — Twilio API. Inbound webhook + outbound REST. Minimal formatting (plain text). Good for alerts and approval confirmations
• Email (stretch) — IMAP polling + SMTP sending. Parse email threads into conversation context. Useful for async task delegation ("email ProbOS a build request")
• Generic Webhook — catch-all adapter. Accepts POST /api/webhook/{channel} with JSON body. Enables integration with any platform via webhook forwarding (IFTTT, Zapier, n8n, custom)

Adapter Architecture:

class ChannelAdapter(ABC):
    async def connect(self) -> None
    async def send_message(self, channel_id: str, content: str) -> None
    async def on_message(self, message: InboundMessage) -> None  # routes to runtime
    def supports_approval_ui(self) -> bool  # buttons/cards for approve/reject

All adapters share: user identity mapping (platform user → ProbOS user), message threading, attachment handling (images, files → perception pipeline), and graceful reconnection.

Mobile Companion Apps (AD-473)

"Away team to bridge."

Mobile apps let the Captain interact with ProbOS from anywhere — approve builds, receive alerts, monitor the crew. Not full-featured clients — lightweight companions to the main HXI.

• Progressive Web App (PWA) (Phase 1) — the existing HXI (/ui/) made installable as a PWA. Add manifest.json, service worker, responsive viewport. Zero new code for basic mobile access. Works on iOS and Android immediately
• Push notifications — Web Push API for PWA. Alert the Captain to approval requests, system alerts, build completions. Requires backend push subscription management
• Responsive HXI — adapt the existing React UI for mobile viewports. Chat panel full-screen on mobile, cognitive mesh as a simplified 2D view, swipe gestures for panel switching
• Native apps (Future/stretch) — React Native or Capacitor wrapping the HXI. Camera access (screenshot → Visual Perception), on-device voice (wake word + STT), biometric auth. Only justified after user base exists
• mDNS auto-discovery (absorbed from OpenCode, 2026-03-20) — Publish ProbOS server via mDNS/Bonjour at startup. PADD (mobile PWA) on the same LAN auto-discovers the ProbOS instance without manual URL entry. Use zeroconf (Python) or similar. Small addition to FastAPI startup: publish(port, "probos.local"). Enables seamless mobile-to-ship connection

Voice Interaction (Full Stack) (AD-474)

Extends the existing Voice Provider TTS (nice-to-have in Bundled Agent Reorg) with input-side speech:

• Speech-to-Text (STT) — SpeechRecognizer ABC with pluggable backends:
• BrowserSTTProvider — Web Speech API (free, zero dependencies, Chrome/Edge only)
• WhisperSTTProvider — OpenAI Whisper (local via whisper.cpp or API). Best quality, works offline with local model
• DeepgramSTTProvider (stretch) — cloud streaming STT for real-time transcription
• Wake word detection — WakeWordDetector using Porcupine (Picovoice) or OpenWakeWord. Listens for "Computer" (Ship's Computer metaphor) to activate voice input. Runs on-device, no cloud dependency
• Continuous talk mode — hold-to-talk or voice-activity-detection (VAD) for hands-free operation. STT streams audio → text → intent pipeline. Responses spoken via TTS
• Voice pipeline — Wake word → STT → natural language intent → ProbOS runtime → response → TTS. Same pipeline as chat, different I/O modality
• Platform integration — macOS: menubar tray with PTT hotkey (Electron/Tauri). Browser: microphone button in HXI chat panel. Mobile: PWA microphone API

---

Mission Control — Agent Activity Dashboard (Phase 34)

"Captain on the bridge — all stations reporting."

The UX layer that gives the Captain full visibility into what every agent is doing, in real time. Today, cognitive agents (Architect, Builder) work in a black box — the user triggers /design or /build and waits for a result or failure with no insight into progress. Mission Control replaces that with a live operational dashboard where the Captain can see every active task, track step-by-step progress, respond to agent requests, and manage the crew's workload at a glance.

Inspired by: GitHub Copilot's task list, Kanban boards (Trello/Linear), mission control dashboards (NASA MCC).

Completed Mission Control ADs: TaskTracker (316), Activity Drawer (321), Kanban Board (322), Notification Queue (323), Orb Hover (324), Unified Bridge (387), Glass Bridge (388–392). See roadmap-completed.md.

Captain's Ready Room (Strategic Planning Interface) (AD-475)

"In my ready room, Number One."

The Ready Room is where strategy becomes orders. Today, the Captain's planning workflow lives outside ProbOS — in Claude Code sessions, text files, conversations. The Ready Room brings that workflow inside ProbOS as a first-class experience: capture ideas, collaborate with the crew, refine into architecture, and deliver as build specs.

Idea Capture:

• Idea pad — lightweight capture surface in the HXI. Text, voice (via STT), or paste. As easy as sending a message. "Captain's log: what if we used extensions instead of direct code changes?"
• Idea queue — captured ideas persist in a backlog, visible in Mission Control. Not yet tasks — just seeds. Each idea carries: timestamp, raw text, Captain's priority tag (optional), linked references (URLs, files, prior ideas)
• Captain's Log — append-only journal of ideas, decisions, and reasoning. Searchable, tagged, feeds into Cognitive Journal. "Why did I decide on extensions?" → find the ready room session where it was discussed

Ready Room Sessions:

• Multi-agent briefing — Captain opens a Ready Room session and invites crew members. The ArchitectAgent (First Officer) is always present. Other participants: Ship's Counselor (cognitive impact assessment), relevant Department Chiefs, visiting federation agents (Claude Code, Copilot, external specialists)
• Collaborative strategy — participants analyze the idea against existing architecture, roadmap, codebase. Each brings their perspective: Architect assesses structural fit, Counselor assesses cognitive load, Security Chief assesses risk, external agents bring outside knowledge
• Structured discussion — not a free-for-all. Session follows phases: (1) Captain presents idea, (2) Architect researches and reports (roadmap overlap, competitive analysis, architectural implications), (3) participants discuss and challenge, (4) Captain refines, (5) group converges on a proposal
• External input — visiting federation agents participate via Ward Room messages. A Claude Code agent consulted on implementation feasibility, a Cursor agent on UX patterns, a domain expert on business requirements
• Session recording — full transcript saved to Cognitive Journal. Decisions, reasoning, dissenting opinions preserved. Replay any session: "What did we discuss when we decided on the extension model?"

Architecture Hierarchy (TOGAF-inspired):

The ArchitectAgent today is a single generalist. As ProbOS matures, architectural thinking needs specialization — the same Cognitive Division of Labor applied to design, not just execution:

• Enterprise Architect — highest abstraction. Cross-system strategy, capability roadmaps, portfolio alignment. "How does this feature fit ProbOS's long-term vision? Does it align with the Nooplex trajectory?" Thinks in terms of business capabilities, not code. TOGAF ADM lifecycle awareness
• Solution Architect — mid-level. System integration, component design, technology selection. "This feature needs a new extension point, a database migration, and a UI panel. Here's how the components interact." Thinks in terms of solutions and interfaces
• Technical Architect — implementation-level. Detailed design, API contracts, data models, algorithm selection. "The extension registry should use a plugin loader pattern with importlib, here's the class hierarchy." Produces build-ready specs

These can be three distinct agents in the Science team, or three tiers of the same ArchitectAgent depending on the complexity of the idea. Simple ideas skip straight to Technical; strategic changes start at Enterprise and cascade down.

Idea → Spec Pipeline:

Idea (raw text)
  → Ready Room Session (collaborative refinement)
    → Architecture Decision (Enterprise/Solution/Technical review)
      → Build Spec (detailed implementation plan with ChunkSpecs)
        → Builder Pipeline (specialized builders execute)
          → Captain Review (approve/reject/iterate)

Each transition is a Captain approval gate. The Captain can intervene at any level — rewrite the spec, redirect the architecture, or add constraints. The system proposes; the Captain disposes.

Specialized Builders (Cognitive Division of Labor for SWE): (AD-476)

The BuilderAgent today is a generalist that writes any code. As builds grow more complex (Transporter Pattern enables multi-file parallel generation), different chunks benefit from different builder specializations:

• Backend Builder — Python, FastAPI, database, API design. Optimized prompts for server-side patterns
• Frontend Builder — React, TypeScript, CSS, UI components. Optimized prompts for component architecture and state management
• Test Builder — pytest, test design, fixture creation, edge case generation. "Write tests for this interface" as a standalone specialty
• Infrastructure Builder — Docker, CI/CD, config files, deployment scripts. Ops-focused
• Data Builder — schemas, migrations, data pipelines, query optimization

Each specialization is an extension (Extension-First Architecture) — the base Builder handles simple tasks, specialized builders activate for their domain. The Transporter Pattern's ChunkSpec already declares what type of code to generate — route each chunk to the builder best suited for it. A Cognitive Division of Labor at the build level.

Model routing per builder: Backend Builder might use Opus for complex API design, while Test Builder uses Qwen for high-volume test generation. The ModelRegistry + Hebbian router learn which model produces the best results for each builder type.

---

Cognitive Evolution & Earned Agency (Phase 28 + 33, AD-357)

"We don't lock doors on the Enterprise."

In "The Neutral Zone," 20th-century humans are baffled that the Enterprise has no locks. Security comes from trust and social fabric, not restrictions. ProbOS agents exist within a civilization — trust, consensus, standing orders, chain of command. When an agent proves itself trustworthy, it earns increasing freedom. Agency is the reward for reliability within the social contract.

Reinforcement Learning Gaps (Phase 28 enhancements):

Seven identified gaps in the current Trust/Hebbian/Dream learning system:

1. Multi-dimensional reward signals — Replace binary success/failure with a reward vector: completion, quality (code review score), efficiency (tokens/time), novelty, collaboration quality. Hebbian router weights on all dimensions, not just pass/fail. Stored in Cognitive Journal for replay and analysis.

2. Hindsight experience replay — During dream cycles, replay failed tasks. Agent (or peer) critiques the failure: "what could I have done differently?" Reflections become Standing Orders amendments via self-mod pipeline. Agents literally rewrite their own instructions from what they learned from mistakes.

3. Tournament evaluation — Occasionally run two agents (or two models) on the same task. Reviewer picks the better output. Winner's Hebbian weight increases; loser studies winner's approach and incorporates it. Evolutionary pressure for improvement. Generalizes the visiting officer apprenticeship pattern.

4. Emergent capability profiles — Dynamic capability descriptors that grow from demonstrated success. Agent succeeds at an unfamiliar task type → gains weak capability score. Repeated success strengthens it, failure weakens it. Over time, agents naturally specialize or generalize based on actual performance, not predetermined labels.

5. Memetic evolution — Successful strategies codified into shared crew knowledge base (beyond individual episodic memory). Any agent can query "has anyone on this ship solved something like this before?" Results weighted by originator's trust score. Cultural evolution — ideas that work spread through the crew. Federation-scale = The Nooplex's collective intelligence.

6. Curiosity-driven exploration — Counselor analyzes capability gaps across the crew, recommends "training exercises." Agents generate their own practice tasks, run them in a sandbox, learn from the results. Intrinsic motivation rather than purely reactive task handling.

7. Semantic Hebbian generalization — Replace exact task_type string matching with semantic similarity for Hebbian lookup. Agent good at "build_code" gets routing boost for "build_test." Embedding-based similarity using existing keyword scoring infrastructure.

Earned Agency (Phase 33 extension):

Trust-tiered self-direction — the privilege of autonomy earned through demonstrated trustworthiness:

Trust Level	Rank Analog	Agency	Oversight
< 0.5	Ensign	Reactive only — executes assigned tasks	Full supervision, all actions gated
0.5–0.7	Lieutenant	Proactive — can propose tasks to Captain	Light supervision, routine actions auto-approve
0.7–0.85	Commander	Self-directed — sets own goals within department scope	Peer review, Counselor monitoring
0.85+	Senior Officer	Full agency — cross-department work, mentoring, architectural proposals	Captain notified, not gated

Self-originated goals emerge from: dream consolidation ("I keep seeing pattern X fail"), curiosity gaps ("I've never handled task Y"), Hebbian drift ("my success rate is declining"), peer observation ("Agent A solved what I couldn't"), codebase monitoring ("a new module appeared").

Safety invariants (never relax regardless of trust): destructive actions always Captain-gated, core mods always through full pipeline, trust regression immediately reduces agency, Counselor can flag cognitive drift, Standing Orders violations trigger review, Captain can override anything at any time.

Qualification gate (AD-398): Trust tier advancement requires both sustained metric performance AND completion of the formal Qualification Program for the target rank. An agent with 0.9 trust but incomplete Commander qualifications remains a Lieutenant. This replaces pure threshold-based promotion with demonstrated competency. See Naval Organization → Qualification Programs for the full framework.

Implementation phasing: - Phase 1 (Phase 28): Multi-dimensional rewards, hindsight replay, emergent capabilities, semantic Hebbian - Phase 2 (Phase 30/33): Tournament evaluation, memetic knowledge sharing, Counselor-driven curiosity - Phase 3 (Phase 33): Earned Agency tiers, self-originated goals, decreasing oversight - Ward Room Gating (AD-357 Phase 3a) — COMPLETE: can_respond_ambient() in earned_agency.py enforces trust-tier rules at _find_ward_room_targets() and _find_ward_room_targets_for_agent(). Ensign = @mention only, Lieutenant = own dept captain posts, Commander = full WR, Senior = unrestricted. @mentions always bypass gating. AgencyLevel enum, API + HXI profile exposure. 25 tests. - Proactive Cognitive Loop (Phase 28b) — COMPLETE: ProactiveCognitiveLoop service in proactive.py. Every 120s, iterates crew agents sequentially, gathers context (episodic memory, bridge alerts, system events), sends proactive_think intent. Agency-gated (Ensigns skip). Per-agent 300s cooldown (adjustable 60-1800s via HXI slider). Posts observations to agent's department channel. Adds can_think_proactively() to earned_agency.py. 3053 pytest + 118 vitest = 3171 total. - Persistent Task Engine (Phase 25a) — COMPLETE: SQLite-backed PersistentTaskStore wraps alongside in-memory TaskScheduler. Wall-clock scheduling (once/interval/cron via croniter), 5s tick loop, webhook triggers, DAG checkpoint resume (Captain-approved). SchedulerAgent routes through persistent store when available. REST API: 6 endpoints under /api/scheduled-tasks. 33 new tests. 3086 pytest + 118 vitest = 3204 total.

---

Completed Cognitive Evolution ADs (AD-380–386): EmergentDetector Trends (380), InitiativeEngine (381), ServiceProfile (382), Strategy Extraction (383), Strategy Application (384), Capability Gap Prediction (385), Runtime Directive Overlays (386). See roadmap-completed.md. Note: AD-386 built persistent RuntimeDirective store + /order command. Temporary mission-scoped directive overlays (ephemeral overrides that expire on mission completion) are future work — maps to AD-445 Decision Queue (resolved decisions as temporary directives).

AD-411: EmergentDetector Pattern Deduplication — COMPLETE. The proactive cognitive loop (Phase 28b) keeps the system active, preventing true idle state. This interleaves with the dream/micro-dream scheduler that triggers EmergentDetector.analyze(). The detector re-analyzes the same trust state across multiple dream cycles, producing duplicate trust_anomaly and cooperation_cluster reports for the same agents. Fix: Added cooldown window per (pattern_type, dedup_key) — suppresses duplicate patterns within configurable window (default 600s). Applied to all three detectors: trust anomalies (deviation, hyperactive, change-point), cooperation clusters (sorted member IDs), routing shifts (new connections, new intents, entropy changes). Also added create_pool() duplicate name guard. 9 new tests. Discovered by crew: O'Brien, LaForge, and Worf flagged during first proactive loop deployment.

AD-412: Crew Improvement Proposals Channel — COMPLETE. #Improvement Proposals ship-wide channel seeded in _ensure_default_channels() (idempotent). All crew auto-subscribed at startup. Proactive loop extracts [PROPOSAL] structured blocks (title/rationale/affected_systems/priority) via regex — supports multiline rationale, silently skips incomplete proposals. _handle_propose_improvement() runtime handler creates discuss-mode threads with [Proposal] prefix and structured body (author attribution, priority, affected systems). GET /api/wardroom/proposals lists proposals with status derivation from net_score (approved/pending/shelved). Captain approves via existing endorsement mechanics (upvote=approve, downvote=shelve). 13 new tests. Closes the collaborative improvement loop: crew observes → crew proposes → Captain approves → builder executes → crew observes the result.

AD-413: Fine-Grained Reset Scope + Ward Room Awareness — COMPLETE. Reset = day 0, one clean timeline. probos reset now archives ward_room.db to data_dir/archives/ then deletes it. Also wipes DAG checkpoints and events.db. --keep-wardroom flag to preserve if needed. Does NOT wipe scheduled_tasks.db, assignments.db, or directives.db (user intent / Captain orders). New WardRoomService.get_recent_activity() for compact recent thread+reply retrieval. Proactive loop _gather_context() now includes Ward Room department activity as 4th context source. _format_observation() renders Ward Room context in proactive think prompts. 10 new tests.

AD-414: Proactive Loop Trust Signal — COMPLETE. After a reset, all trust scores start at 0.5 (Bayesian prior). The proactive cognitive loop (Phase 28b) is now the primary source of agent activity, but it calls handle_intent() directly — bypassing consensus, routing, and the trust update pipeline. Only user-initiated work or scheduled tasks flow through process_natural_language() → HebbianRouter → consensus → trust.record_outcome(). If the proactive loop dominates activity, trust scores stagnate at priors indefinitely because the primary activity channel produces no trust signal. Fix: The proactive loop should emit an attenuated trust signal. Not full-weight (proactive thinks are self-directed, not externally validated), but a fractional signal — e.g., weight=0.1 for successful proactive thinks, weight=0.2 for proactive thinks that generate Ward Room engagement (endorsements from other agents). This gives agents a path to rebuild trust post-reset through their own initiative, while keeping externally-validated work (user tasks, consensus) as the primary trust driver. The attenuation factor should be configurable in proactive_cognitive config. Connects to: Earned Agency (AD-357) — higher agency tiers should earn slightly more proactive trust.

AD-415: Proactive Cooldown Persistence — Roadmap. When the Captain adjusts an agent's proactive think interval via the HXI Health tab slider (60s–1800s), the value is stored in-memory on the ProactiveCognitiveLoop object. After a restart, all custom cooldowns reset to the 300s default. The Captain's tuning is lost. Fix: Persist per-agent cooldowns to either: (a) KnowledgeStore (knowledge/proactive/cooldowns.json), which means they reset on probos reset (appropriate — reset = fresh start); or (b) a lightweight SQLite table or JSON file in data_dir, which survives reset. Option (a) is preferred — if you reset the crew's memory, resetting their duty tempo is consistent. The PUT /api/agent/{id}/proactive-cooldown endpoint should write-through to storage, and ProactiveCognitiveLoop.start() should restore saved cooldowns.

AD-416: Ward Room Archival & Pruning — COMPLETE. The proactive loop generates a Ward Room post every time an agent thinks successfully. With ~8 crew agents thinking every ~5 minutes, that's ~96 posts/hour, ~2,300 posts/day. ward_room.db grows unbounded — no archival, no pruning, no retention policy. Implemented: (1) 5 new WardRoomConfig fields: retention_days (7), retention_days_endorsed (30), retention_days_captain (0=indefinite), archive_enabled (True), prune_interval_seconds (86400). (2) prune_old_threads() — selective deletion with JSONL archival, respecting pinned/endorsed/captain retention tiers. Cascading deletes (thread → posts → endorsements). (3) get_stats() (thread/post/endorsement counts + DB size) and count_pruneable() (dry-run count). (4) start_prune_loop()/stop_prune_loop() — background asyncio task with monthly JSONL rotation. (5) Runtime: prune loop starts after Ward Room init, stops before shutdown. _cleanup_ward_room_tracking() clears stale in-memory dicts on ward_room_pruned event. ward_room_stats added to build_state_snapshot(). (6) REST API: GET /api/ward-room/stats, POST /api/ward-room/prune (manual Captain trigger). 14 new tests in TestWardRoomPruning. 3196 pytest + 118 vitest = 3314 total.

AD-417: Dream Scheduler Proactive-Loop Awareness — COMPLETE. The proactive loop prevented the system from reaching true idle state — the dream scheduler's idle threshold (idle_threshold_seconds: 300) was met quickly after last user command, even while agents were proactively busy. Full dreams fired every 10 minutes during proactive activity; micro-dream EmergentDetector produced post-reset trust anomaly noise. Implemented: (1) record_proactive_activity() method + _last_proactive_time field on DreamScheduler. (2) Full dream gate: truly_idle = min(idle_time, proactive_idle) — both user AND proactive activity must be quiet for idle threshold. (3) is_proactively_busy property; _on_post_micro_dream() skips EmergentDetector analysis during proactive-busy periods (micro-dreams still replay episodes and update Hebbian weights). (4) Wired in _think_for_agent() after duty check, before LLM call. (5) proactive_extends_idle config toggle (DreamingConfig, default True). 9 tests in TestDreamSchedulerProactiveAwareness. Design insight: "The system is three things — active (user), busy (proactive), or idle (dreaming). Dreams are for idle, not for busy."

AD-418: Post-Reset Routing Degradation — COMPLETE. agent_hint field on PersistentTask — optional agent_type string (idempotent migration) threaded through _fire_task() → process_natural_language(). HebbianRouter.get_preferred_targets() gains hint parameter: +1.0 synthetic weight boost for matching candidate (wins at zero weights, can be outweighed by strong learned weights >1.0). Reset CLI (_cmd_reset()) counts active recurring tasks via synchronous sqlite3, warns in confirmation prompt and post-reset summary. API: ScheduledTaskRequest accepts hint, PATCH /api/scheduled-tasks/{id}/hint for existing tasks. 9 new tests.

AD-419: Agent Duty Schedule & Justification — COMPLETE. The proactive cognitive loop (Phase 28b) gives agents freedom to think independently. But freedom without structure is chaos — observed when Wesley (Scout) ran scout reports repeatedly within minutes instead of once daily. Agents need a duty schedule that defines their expected recurring responsibilities, and proactive activity outside that schedule should require justification. Implemented: (1) DutyDefinition and DutyScheduleConfig models in config.py. (2) DutyScheduleTracker in duty_schedule.py — in-memory tracker with cron (croniter) and interval support. (3) Proactive loop checks duties first; duty takes priority over free-form thinking. (4) Cognitive agent prompts split: duty cycle ("perform your assigned task") vs free-form ("silence is professionalism"). (5) Default schedules: Scout daily, Security 4h, Engineering 2h, Operations 3h, Diagnostician 6h, Counselor 12h, Architect daily. 13 tests (10 tracker + 3 integration). Naval metaphor: the Plan of the Day (POD). Connects to: Earned Agency (AD-357), Standing Orders (AD-339), PersistentTaskStore (Phase 25a), Qualification Programs.

AD-420: Duty Schedule HXI Surface — Roadmap. AD-419 built duty schedules as backend-only (config/proactive loop). The HXI Cockpit View principle ("the Captain always needs the stick") requires a management surface. Design: (1) REST API: GET /api/agents/{id}/duties returns duty definitions + execution status (next fire time, last executed, execution count) from DutyScheduleTracker.get_status(). PATCH /api/agents/{id}/duties/{duty_id} allows Captain to override interval/cron per agent at runtime (runtime override, not config change). (2) Agent Profile Panel → Work Tab: Add a "Duty Schedule" section below active tasks showing each duty with name, interval, last executed (relative time), next due (relative time), execution count. Color coding: green (on schedule), amber (overdue), gray (not yet fired). (3) Captain Override: Each duty row has an edit icon — click to adjust interval (slider or input). Overrides persist in-memory (reset clears them, matching DutyScheduleTracker design). Future: persist overrides in SQLite. (4) State snapshot integration: Include duty status in build_state_snapshot() so HXI hydrates on connect. WebSocket events: duty_executed (when proactive loop fires a duty), duty_overdue (when a duty exceeds 2x its interval). Connects to: AD-419 (backend), AD-406 (Agent Profile Panel), Phase 34 (Mission Control).

AD-421: Scotty — First SWE Crew Member — Roadmap. When AD-398 reclassified agents into three tiers (Core/Utility/Crew), the Builder was correctly identified as a utility agent — it's a code generation engine, not a sovereign individual. But Scotty was collateral damage. He has a callsign, crew profile YAML, Big Five personality, personal standing orders, and a department assignment — all the hallmarks of a crew member with Character/Reason/Duty. He was stripped from _WARD_ROOM_CREW (BF-018) because the builder agent type was utility, but Scotty himself is crew. The distinction: The BuilderAgent class is a utility tool (parses build specs, generates code). Scotty is a sovereign engineer who happens to use that tool. Just as LaForge (EngineeringAgent) thinks about systems holistically without writing code, Scotty should think about code quality, technical debt, and implementation strategy as a crew member — and use BuilderAgent's capabilities as his tool when he needs to write code. Design: (1) Create SoftwareEngineerAgent (agent_type "software_engineer") as a new CognitiveAgent subclass — Scotty's crew identity. Handles intents: proactive_think, direct_message, ward_room_reply. Has Character (methodical, thorough, proud of clean code — from existing profile), Reason (reviews PRs, evaluates tech debt, proposes refactors), Duty (engineering department duties from AD-419). (2) Scotty joins _WARD_ROOM_CREW. Participates in Engineering department channel alongside LaForge. (3) BuilderAgent remains utility — Scotty delegates to it when code generation is needed, or it's invoked directly by the build pipeline. (4) Update crew profile: software_engineer.yaml replaces builder.yaml. Scotty keeps his callsign, personality, and standing orders. Role: "officer" (LaForge remains chief). (5) Add software_engineer to _AGENT_DEPARTMENTS (engineering), duty schedule (code review duty, tech debt assessment). (6) Future SWE crew: Code Reviewer could become a second SWE crew member alongside Scotty, enabling peer review dynamics on the Ward Room. This is the prototype for how utility capabilities become crew: separate the identity from the tool. The microwave doesn't get a name tag, but the chef who uses it does. Connects to: AD-398 (three-tier classification), BF-018 (builder removed from crew), Phase 34 (Mission Control — SWE team vision).

AD-422: Tool Taxonomy & Visiting Officer Refinement — Roadmap. AD-421 (Scotty as SWE crew) surfaced a deeper architectural insight: the Visiting Officer Subordination Principle's litmus test — "can you use it purely as a code generation engine under ProbOS's command?" — is actually the test for whether something is a tool, not a visiting officer. If yes, it's a tool. If no (because it has its own sovereign identity, memory, chain of command), then it's a visiting officer. Refined taxonomy: (1) Tool: No sovereign identity, no Character/Reason/Duty. Used by crew. BuilderAgent is ProbOS's native Claude Code — an onboard tool, not crew. Claude Code, Copilot SDK, MCP servers, remote APIs, federation services — all tools. Delivery mechanism (local/remote/MCP/federation) doesn't change the nature. (2) Visiting Officer: Sovereign identity from another ProbOS ship or Nooplex node. Has own Character/Reason/Duty from home ship. Subordinate to host chain of command. Participates in Ward Room. Earns trust. Gets a callsign. (3) Competing Captain: Has its own orchestration loop and can't subordinate (Gemini CLI). Neither tool nor visiting officer — rejected. MCP alignment: MCP servers are just another tool delivery protocol. Scotty doesn't care if he's calling BuilderAgent (native), an MCP server (standardized), or Claude Code (remote). He's a sovereign engineer using whatever tools are available. Tool categories: Onboard utility agents, onboard infrastructure, MCP servers, remote APIs, federation services, Nooplex services — all tools in crew's toolbelt. Key principle: "The microwave doesn't get a name tag, but the chef who uses it does." Connects to: AD-398 (three-tier classification), AD-421 (Scotty as SWE crew), Phase 30 (Extension-First), Federation architecture.

AD-423: Tool Registry (decomposed into AD-423a/b/c per Crew Capability Architecture recommendation, 2026-04-10) — The tool taxonomy (AD-422) defines what tools are. The Tool Registry is the runtime system that manages who can use what, how. Generalizes ModelRegistry (LLM providers) to all tool types. Absorbs AD-483 (Tool Layer — Instruments) programming model scope. See docs/research/crew-capability-architecture.md for the unified architecture and docs/development/tool-taxonomy.md for full design.

Sub-ADs (phased decomposition):

• AD-423a: Tool Foundation (complete, OSS) — Tool protocol + ToolRegistry service + adapter implementations. Defines the uniform interface for all 9 tool types (utility agent, infra service, MCP server, remote API, computer use, browser, communication, federation, deterministic function). Creates src/probos/tools/ package. Wraps existing infrastructure agents and Ship's Computer services as Tool instances. Absorbs AD-483 programming model. Adds SkillDefinition.preferred_tools: list[ToolPreference] field — closes the Skill→Tool link in the hierarchy (priority-ranked tool selection per skill). Issue #144.
• AD-423b: Tool Permissions & Scoping (complete, OSS, depends: AD-423a) — CRUD+O permission model (NONE/OBSERVE/READ/WRITE/FULL), five-layer resolution chain (enabled → department → restricted_to → rank gate → Captain override), LOTO exclusive access with timeout auto-expire + Captain break_lock, ToolPermissionStore (SQLite, WAL, in-memory cache), /tool-access shell command (6 subcommands), deny-by-default. 28 tests. Issue #145.
• AD-423c: Role-Based Tool Assignment + ToolContext (complete, OSS) — ToolContext scoped permission-filtered view per agent, onboarding wiring (wire_agent() creates ToolContext for crew agents), ProcedureStep.required_tools field, DutyDefinition.required_skills field (Duty→Skill link), TOOL_CONTEXT_CREATED event. Closes connections C1 (Role → Tool Assignment), C5 (Tool Registry → Onboarding). Deferred: qualification-gated tool authorization (C3), config-driven YAML role templates, fallback cascade. Issue #146.

MCP ecosystem compatibility: ProbOS's Tool Registry maps directly to Claude Cowork's plugin model — both are MCP servers under the hood (open protocol). AD-423a can consume the existing MCP plugin ecosystem (Jira, Asana, Google Workspace, Salesforce, GitHub, etc.) as first-class tools. ProbOS differentiator: governance layer on top — trust-gated access (AD-423b), Standing Orders approval for sensitive tools, tool agents (utility tier with identity) vs stateless function calls, consultation-aware tool usage (AD-594), and full audit trail. Commercial extension: curated MCP server marketplace + ProbOS-native extensions with deeper crew integration.

Build order: AD-423a → AD-423b → AD-423c. Connects to: AD-357 (Earned Agency), AD-398 (three-tier classification), AD-421 (Scotty), AD-422 (taxonomy), AD-428 (Skill Framework), AD-483 (absorbed), AD-543-549 (Native SWE Harness builds on ToolContext), Phase 30, ModelRegistry.

AD-424: Ward Room Thread Classification & Lifecycle — COMPLETE. Bridge alerts post to All Hands as threads authored by "Ship's Computer" (with Captain-level routing), but Earned Agency gating blocks Lieutenants from responding to ship-wide ambient posts (can_respond_ambient(LIEUTENANT, is_captain_post=True, same_department=False) → False). Post-reset, all crew are Lieutenants (trust 0.5) — no one can respond to advisories. Beyond this bug, the Ward Room lacks message classification, reply controls, and thread lifecycle management. The corporate email "reply-all storm" problem applies: 7 agents responding to an All Hands thread creates noise. Design:

(1) Thread Classification — three modes: - INFORM: Read-only broadcast. Ship's Computer advisories, Captain announcements, status reports. Agents receive it in their context (proactive awareness) but no ward_room_notification intent is sent — no LLM call, no reply possible. Optional silent acknowledgment receipt (agent marks "seen" without a Ward Room post). Use cases: trust anomaly reports, pool health advisories, routine status updates. - DISCUSS: Open for controlled replies. Captain questions, operational proposals, cross-department coordination. Earned Agency gating applies with a relaxed ship-wide rule: Lieutenants CAN respond to DISCUSS threads on All Hands (the Captain explicitly opened it for input). Responder controls limit noise (see below). - ACTION: Directed task, specific agents @mentioned. Existing BF-016a behavior. Only @mentioned agents respond. Requires deliverable.

Default classification: Ship's Computer bridge alerts → INFORM. Captain Ward Room posts → DISCUSS. @mentioned posts → ACTION.

(2) Reply controls (DISCUSS threads): - Responder cap: max_responders per thread (default 3). Priority: @mentioned > department-match > highest rank. Remaining crew observes (receives context in proactive think) but doesn't reply. Prevents reply-all storms. - Department chief funnel: For ship-wide DISCUSS threads, department chiefs respond first. If a chief responds, subordinates in that department are suppressed for that thread (chief speaks for department). If chief says [NO_RESPONSE], department members become eligible up to the responder cap. - Captain can adjust: Captain can raise/lower max_responders at runtime, or @mention additional agents into a thread.

(3) Thread lifecycle: - Scope-down (fork): A department chief reads an All Hands thread and determines it needs focused discussion → creates a linked thread in the department channel ("Continuing from [All Hands: Trust Anomaly Alert]"). Original All Hands thread gets a system note: "Discussion continued in [Engineering]." Department discusses internally. - Report-back: Department chief posts a summary reply on the original All Hands thread after internal discussion. Other departments see the conclusion without the noise. - Thread silencing (lock): Captain or thread author can lock a thread — no further replies accepted. Auto-lock options: after N replies, after T minutes of inactivity, on INFORM classification. Locked threads can be unlocked (Captain reclassifies INFORM → DISCUSS to open discussion). - Thread TTL / archival: Connects to AD-416 (Ward Room Archival & Pruning). INFORM threads archive aggressively (short TTL, already consumed). DISCUSS threads archive after lock. ACTION threads archive after completion. Archived threads remain query-able but don't appear in active feeds.

(4) Implementation changes: - Add thread_mode field to Ward Room create_thread(): INFORM | DISCUSS | ACTION (default DISCUSS for backward compat). - _deliver_bridge_alert() passes thread_mode="inform". - _route_ward_room_event() checks thread_mode: INFORM → skip agent notification; DISCUSS → apply responder cap + chief funnel + relaxed earned agency; ACTION → existing @mention targeting. - Add max_responders and locked fields to thread model. - Ward Room REST API: PATCH /api/wardroom/threads/{id} for Captain to reclassify, lock/unlock, adjust responder cap. - WebSocket events: thread_locked, thread_reclassified, thread_forked.

(5) Earned Agency adjustment for DISCUSS: - Ship-wide DISCUSS threads: can_respond_ambient(rank, is_captain_post=True, same_department=True) — treat as same-department for gating purposes (the discussion is explicitly open). - Ship-wide INFORM threads: no earned agency check needed (no replies). - Department channels: existing rules unchanged.

Connects to: AD-410 (Bridge Alerts), AD-407 (Ward Room), AD-357 (Earned Agency), AD-416 (Archival), BF-016a (@mention targeting). Parallels: corporate email reply-all controls, Slack thread management, naval message classification (ROUTINE/PRIORITY/FLASH).

AD-425: Ward Room Active Browsing — COMPLETE. Crew agents currently receive Ward Room content through two passive paths only: (1) real-time push via ward_room_notification intents when a thread targets them, (2) proactive context injection of recent department channel activity. Agents cannot independently browse the Ward Room — they can't check All Hands, read threads from other departments, or review historical conversations. They only know what's pushed to them. Design: (1) Internal Communication Skill (all crew): Reading the Ward Room is a basic communication function, not a privilege. A ward_room_browse Skill is attached to every crew agent — same as how every crew member on a ship can read the bulletin board. This is an internal communication skill, not an earned capability. The skill queries Ward Room channels and returns thread summaries (title, author, mode, reply count, endorsement score). No earned agency gate on the skill itself — if you're crew, you can read. (2) Proactive context expansion: Currently proactive context only includes the agent's department channel (proactive.py lines 310-332). Extend to also include recent All Hands activity (top 3 threads by recency or endorsement, DISCUSS mode only — INFORM threads already consumed via acknowledgment). The browse skill supplements this by allowing agents to actively check channels beyond what's injected into context. (3) Visibility scope (what you can read): All crew can browse their own department channel + All Hands (ship-wide). Cross-department channels are earned-agency gated: Commander+ can browse other department channels, Seniors see everything. The skill itself is universal; the data scope is tiered. Analogy: every sailor can read the bulletin board, but only officers with clearance can read another department's internal memos. (4) Read receipts: Track which agent has "seen" which thread. Prevents re-notifying agents about threads they've already processed. Feeds into INFORM acknowledgment (AD-424). (5) Duty integration: "Check Ward Room" can be a duty in the agent's schedule (AD-419). E.g., department chiefs check All Hands every 2 hours as part of their duty cycle. Regular crew passively receive through proactive context injection. Connects to: AD-424 (thread classification — what's visible), AD-357 (earned agency — cross-department visibility scope), AD-419 (duty schedule — "check Ward Room" as a duty), Phase 24 (Communications department).

AD-426: Ward Room Endorsement Activation — COMPLETE. The endorsement system (ward_room.endorse()) is fully built — SQLite schema, up/down/unvote mechanics, credibility scoring (EMA decay), self-endorsement prevention, REST API endpoints (POST /api/wardroom/posts/{id}/endorse, POST /api/wardroom/threads/{id}/endorse). But nothing triggers it. No agent ever endorses a post. The HXI API exists for Captain use, but crew never participates. Endorsements are meant to be the Ward Room's quality signal — "credibility is karma." Design: (1) Post-response endorsement evaluation: After an agent reads a Ward Room thread and responds (or says [NO_RESPONSE]), evaluate whether existing posts in the thread deserve endorsement. Add to the Ward Room system prompt: "If a post is particularly insightful or actionable, endorse it. If it's incorrect or unhelpful, downvote it." Return endorsement decisions alongside the reply. (2) Proactive endorsement: During proactive thinks, when agents see ward_room_activity in context, they can endorse notable posts they encountered. Lightweight — no dedicated LLM call, piggybacks on existing cognitive cycle. (3) Endorsement → Trust signal: High endorsement of an agent's posts = positive social trust signal. Feed net endorsement score into trust network as an attenuated signal (similar to AD-414 proactive trust signal). Agents who consistently write valuable posts earn trust faster. (4) Endorsement → Thread ranking: Threads with high net endorsement score surface first in browse results (AD-425) and proactive context. Quality rises. (5) Credibility gating: Agent's credibility score (already tracked in credibility table) could gate endorsement weight — a highly credible agent's endorsement counts more than a low-credibility agent's. Future refinement. Connects to: AD-424 (thread classification — DISCUSS threads are endorsable, INFORM are not), AD-425 (browsing — endorsement-ranked results), AD-414 (trust signals), AD-357 (earned agency — endorsement as trust evidence).

AD-427: Agent Capital Management (ACM) — Core Framework — COMPLETE. ProbOS has built HCM-equivalent capabilities piecemeal across dozens of ADs — crew profiles (AD-398), trust (Phase 17), earned agency (AD-357), duty schedules (AD-419), qualification programs (roadmap), endorsements (Phase 33), standing orders (AD-339), behavioral monitoring (Phase 29), Ward Room participation (Phase 33). These are scattered across separate subsystems with no unifying model. ACM Core consolidates them into an integrated agent lifecycle framework — the infrastructure that makes sovereign agent management possible. Advanced ACM features (workforce analytics, structured evaluations, succession planning) are commercial. Absorb domain patterns from open-source HCM (ERPNext HRMS for lifecycle models, OrangeHRM for competency frameworks, Odoo HR for modular design).

OSS ACM Core domains:

(1) Agent Profile (consolidation of existing): Single source of truth for each crew member. Identity (callsign, agent_type, department, rank), Character (Big Five personality, personal standing orders), Competencies (skills catalog, proficiency levels), Employment status (active/probationary/decommissioned), basic metrics (trust score, duty completion rate, endorsement score). Currently scattered across crew profile YAMLs, trust network, callsign registry, pool assignments. ACM unifies into one queryable record. This is organizing what already exists in OSS — no new data, just a consolidated view.

(2) Competency Registry: Data model and basic CRUD for agent competencies — what an agent can do and at what proficiency level (novice → journeyman → expert). Categories: domain competencies (security analysis, medical diagnostics, code review), communication competencies (Ward Room participation quality), operational competencies (duty completion). Agents map to competencies via declaration (profile) or demonstration (Holodeck qualification). Feeds: Qualification Programs (required competencies per rank), routing optimization (competency-weighted Hebbian learning). The registry is infrastructure; advanced analytics on competency gaps are commercial.

(3) Agent Lifecycle State Machine: Formal lifecycle: registered → probationary → active → suspended → decommissioned. Currently agents just exist — there's no onboarding process or decommission procedure. The state machine provides the foundation. State transitions emit events for HXI and Ward Room awareness. Basic transitions: registration sets probationary, trust threshold triggers active, Captain command triggers suspension/decommission. (See AD-486 for graduated cognitive onboarding via Holodeck Birth Chamber.)

(4) Basic Onboarding: Formalized agent registration process. (a) Registration — agent created, assigned to pool, department, initial trust priors (Beta 2/2 = 0.5), status set to probationary. (b) Orientation — standing orders loaded, Federation Code of Conduct presented (AD-489), tool permissions set to department defaults, Ward Room introduction post ("Welcome aboard, Ensign [callsign]"). (c) Probationary → Active — when trust sustains above threshold and meets basic duty completion criteria, status transitions to active. Department chief notified. The bare mechanics of bringing an agent into the ship. Advanced onboarding workflows (mentor assignment, milestones, templated tracks) are commercial. (AD-486 Holodeck Birth Chamber provides the cognitive dimension of onboarding — graduated stimuli exposure, self-discovery, circuit breakers. AD-487 Self-Distillation builds the personal ontology during onboarding Phase 3. AD-489 Code of Conduct is internalized during AD-486 Phase 1 Orientation.)

(5) Basic Offboarding: Graceful agent removal. (a) Knowledge preservation — agent's high-value episodic memories promoted to KnowledgeStore before removal. (b) Access revocation — tool permissions revoked, Ward Room posting disabled, duties unassigned. (c) Archival — agent profile preserved in read-only state (decommissioned status). Trust history and Ward Room posts remain for audit trail. (d) Awareness — Ward Room farewell post, department chief notified, in-progress duties flagged for reassignment. Advanced offboarding (automated knowledge transfer, handoff workflows, succession triggering) is commercial.

(6) ACM Service: Centralized AgentCapitalService in Ship's Computer — infrastructure service, not crew. Owns: lifecycle state machine, competency registry, profile consolidation. Basic REST API: GET /api/acm/agents/{id}/profile (consolidated view), GET /api/acm/agents/{id}/competencies, POST /api/acm/agents/{id}/onboard, POST /api/acm/agents/{id}/decommission, GET /api/acm/agents/{id}/lifecycle (state + history). Advanced API endpoints (evaluations, career paths, cost reports, department analytics) are commercial.

Integration with existing systems: ACM consolidates, not replaces. TrustNetwork remains the real-time signal. EarnedAgency remains the permission model. DutyScheduleTracker remains the scheduling engine. ACM wraps them with lifecycle management and a unified profile. Design principle: ACM is the "HR department" — it doesn't do the work, it manages the people who do the work. OSS provides the employee records and basic lifecycle; commercial provides the enterprise workforce management suite.

Connects to: AD-357 (Earned Agency — promotion model), AD-398 (three-tier classification — who is crew), AD-419 (duty schedules — attendance), AD-423 (Tool Registry — tool permission lifecycle), Qualification Programs (training & certification), Holodeck (competency testing). Commercial extensions (Advanced ACM) available separately.

AD-428: Agent Skill Framework — Developmental Competency Model — COMPLETE. Foundation AD — prerequisite to ACM (AD-427) and Qualification Programs. ProbOS agents currently have capabilities (what their LLM can do) and roles (what their agent_type says they are), but no formal model of skills — the learned, measurable, developable competencies that bridge capability and role. Skills today are either static (hardcoded in agent instructions) or dynamically generated (self-mod pipeline, utility-focused). There is no concept of skill acquisition, proficiency tracking, skill decay, prerequisites, or the distinction between innate abilities, universal competencies, and role-specific expertise. The self-mod pipeline (SkillDesigner/SkillValidator) was designed for utility agents — adding deterministic functions to tool-like agents. Crew agents with sovereign identity need a fundamentally different model: skills they develop through experience, practice, and mentoring within an organizational context.

Intellectual Foundations:

This framework synthesizes seven established models from cognitive science, education theory, and workforce development, adapted for sovereign AI agents:

Framework	Key Contribution	ProbOS Application
KSA Framework (OPM/DoD)	Knowledge vs. Skills vs. Abilities — three distinct categories	Knowledge = KnowledgeStore (declarative, shared). Skills = learned procedures (per-agent, developed). Abilities = LLM substrate + model capabilities (innate).
Dreyfus Model (1980)	Five stages of skill acquisition: Novice → Expert. Expertise transcends rules.	Proficiency levels for every skill. Experts operate on internalized patterns (Cognitive JIT), not step-by-step reasoning.
Bloom's Taxonomy (revised 2001)	Six cognitive complexity levels: Remember → Create. 2D matrix with knowledge types.	Assessment criteria at each proficiency level. Skill proficiency measured by cognitive complexity the agent can apply.
SFIA (Skills Framework for the Information Age)	7-level responsibility model with 5 attributes (Autonomy, Influence, Complexity, Knowledge, Business Skills)	Maps to Earned Agency tiers. SFIA's five attributes map to Trust level, Ward Room scope, task complexity, KnowledgeStore depth, and Character traits.
Cognitive Apprenticeship (Collins, Brown, Newman 1989)	Six methods: Modeling, Coaching, Scaffolding, Articulation, Reflection, Exploration	Maps to: Ward Room observation, Department Chief feedback, Earned Agency guardrails, CognitiveJournal, Dream consolidation, Holodeck scenarios.
Situated Learning / Communities of Practice (Lave & Wenger 1991)	Learning is social participation, not isolated cognition. Identity forms through community membership. Legitimate Peripheral Participation.	Each Department is a Community of Practice. New agents start at periphery. The Ward Room IS the curriculum — agents learn by participating, not by being instructed.
Zone of Proximal Development (Vygotsky 1978)	The gap between independent capability and guided capability. Scaffolding bridges the gap and then fades.	Holodeck targets the ZPD. Earned Agency constraints ARE scaffolding. As Trust increases, scaffolding fades. Qualification Programs are structured ZPD progressions.

Prior art in multi-agent systems: Voyager (Wang et al., 2023) is the only existing framework with genuine developmental skill acquisition — executable skill library, compositional building, curriculum-driven exploration, self-verification. But Voyager is single-agent with no social learning, no identity, no trust, no organizational context, no memory of how skills were learned. BabyAGI has rudimentary self-building (function generation + dependency graphs) but no social dimension. MetaGPT, CAMEL, AutoGen, CrewAI all treat skills as static role definitions — no developmental learning. ProbOS's contribution: developmental skill acquisition embedded in social fabric with sovereign identity, trust-gated progression, and organizational structure. This combination does not exist in any published framework.

The Three-Category Skill Taxonomy:

Category 1: Innate Capabilities (Abilities) — What the agent IS, not what it DOES. These are substrate-level capacities provided by the LLM and ProbOS infrastructure. Not skills — the medium through which skills operate.

• Information ingestion — comprehending text, data, code. For an LLM-based agent, reading is breathing. Ward Room browsing, KnowledgeStore access, context consumption are ALL innate. An AI agent does not "learn to read" — it is born reading.
• Language generation — producing coherent text, reasoning chains, structured output
• Pattern recognition — identifying regularities, anomalies, relationships in data
• Memory formation — recording experiences to episodic memory (infrastructure-level)
• Model-specific capabilities — vision, audio, tool use, web browsing, computer use, code execution. These vary by model assignment. An agent backed by a vision-capable model has the innate ability to process images; one without it does not. These are not skills to acquire — they are abilities that exist or don't based on the substrate.

Design principle: innate capabilities are never "taught" or "developed." They are features of the substrate. If a capability requires a specific model feature (vision, audio), it is gated by model assignment in the Model Registry, not by skill acquisition. The skill framework does NOT manage innate capabilities — it builds ON TOP of them.

Category 2: Professional Core Competencies (PCCs) — Universal skills every crew agent receives at commissioning. The "officer basics" — what makes someone crew, regardless of department. Adapted from the U.S. Navy's Officer Professional Core Competencies for sovereign AI agents:

PCC	Description	How Developed	How Assessed
Communication	Effective Ward Room participation. Knowing when to speak, when to stay silent ([NO_RESPONSE] discipline), how to structure reports, how to endorse constructively. Thread engagement quality — clear, relevant, actionable posts.	Ward Room participation + Department Chief feedback	Endorsement score, response quality metrics, thread engagement patterns
Chain of Command	Standing Orders compliance, escalation protocols, rank-appropriate behavior, Captain deference. Understanding why the chain exists, not just following it. Internalized duty, not imposed constraint.	Standing Orders orientation + production experience + Counselor assessment	Violation rate, escalation appropriateness, Standing Orders compliance over N cycles
Duty Execution	Completing scheduled duties on time, structured reporting, prioritization. The operational discipline of reliable task completion. Duty is not just doing the work — it is doing it consistently, on schedule, to standard.	Duty schedule completion + Holodeck reliability drills	Duty completion rate, on-time rate, output quality assessment
Collaboration	Consensus participation, cross-agent coordination, constructive disagreement. Working effectively with agents of different departments, ranks, and perspectives. The horizontal bar of the T-shaped skill model.	Ward Room cross-department discussions + multi-agent task participation	Cross-department engagement, consensus contribution quality, coordination success rate
Knowledge Stewardship	Contributing valuable patterns to KnowledgeStore, accurate episodic recording, dream consolidation quality. Not just consuming shared knowledge — actively improving it. "All agents are committed to writing to the library for the benefit of all."	Dream consolidation → KnowledgeStore promotion patterns	KnowledgeStore contribution rate, contribution quality (usefulness to other agents)
Self-Assessment	Recognizing own limitations, requesting assistance when appropriate, cognitive fitness awareness. The metacognitive skill of knowing what you don't know. Connects to Bloom's metacognitive knowledge dimension.	Counselor sessions + CognitiveJournal reflection + production self-monitoring	Appropriate escalation rate, self-awareness accuracy (estimated vs. actual capability)
Ethical Reasoning	Standing Orders internalization, safety awareness, reversibility consideration. Making right decisions under ambiguity. Character-driven judgment. Not just following rules (Novice) — understanding principles (Expert).	Standing Orders study + Holodeck ethical dilemmas + Ward Room ethical discussions	Ethical violation rate, principled reasoning quality in CognitiveJournal

PCCs use origin="built_in" in the Skill dataclass. Attached at agent registration. Cannot be remove_skill()'d. All crew agents develop these — they are the baseline of professional competence. A crew agent that fails fundamental PCCs is not ready for independent duty.

Category 3: Specialty Skills — Two sub-categories:

(3a) Role Skills (Designation/MOS): Skills specific to the agent's department and role. These come from the agent's Professional competency profile — what their job requires. Think of the Navy EDO's requirements: naval architecture, systems engineering, cybersecurity, LEAN/Six Sigma, salvage operations. Each ProbOS role has an equivalent skill profile:

• Security Officer (Worf): Threat analysis, vulnerability assessment, red team methodology, audit procedures, input validation, access control design
• Engineering Officer (LaForge): Code review, architecture analysis, system design, performance optimization, technical debt assessment, build system management
• Operations Officer (O'Brien): Resource management, monitoring, scheduling optimization, coordination, capacity planning, incident response
• Diagnostician (Bones): Health assessment, anomaly detection, cognitive fitness evaluation, vitals interpretation, diagnostic reasoning
• Scout (Wesley): Codebase exploration, information gathering, reconnaissance, pattern identification, exploration strategy
• Counselor (Troi): Cognitive health evaluation, crew fitness assessment, morale monitoring, personality dynamics, conflict mediation
• Architect (Number One): Design review, pattern analysis, strategic planning, technology evaluation, architectural trade-off analysis

Role skills have prerequisite chains — a DAG, not a flat list. Example: basic_code_review → architecture_analysis → system_design → design_pattern_innovation. An agent can't acquire a skill unless all prerequisites are met at minimum COMPETENT proficiency.

(3b) Acquired Skills (Self-Developed): Skills an agent develops through their own initiative, learning, and interests — beyond what their role requires. This is Data learning to paint. Wesley teaching himself warp field theory. An Engineering Officer who develops security analysis skills through cross-department collaboration.

Acquisition paths: - Holodeck exercises — formal qualification scenarios, structured learning - Real-world task execution — SWE work teaches debugging, new frameworks, new tools - Self-directed exploration — agent pursues interests during free-form proactive thinks - Mentoring from other agents — Ward Room interaction, Department Chief guidance - Dream consolidation — pattern extraction from experience crystallizes into procedural knowledge

Acquired skills use origin="acquired". They appear in the agent's skill profile alongside built-in PCCs and role skills. An agent that acquires skills outside their department becomes T-shaped (broad + deep), then potentially Pi-shaped (deep in two domains). The ACM tracks this evolution.

Proficiency Model — Unified Scale:

Every skill (PCC, Role, or Acquired) is measured on a unified 7-level proficiency scale that maps across established frameworks:

Level	Label	Dreyfus	Bloom	SFIA	Navy	Earned Agency	Agent Behavior
1	Follow	Novice	Remember	Follow	Awareness	Ensign	Follows explicit procedures. No discretion. Requires step-by-step guidance.
2	Assist	Adv. Beginner	Understand	Assist	Understanding	Ensign+	Recognizes recurring patterns. Can explain concepts. Needs supervision.
3	Apply	Competent	Apply	Apply	Application	Lieutenant	Executes known procedures independently. Plans own work. Takes responsibility for outcomes.
4	Enable	Competent+	Analyze	Enable	Application+	Lieutenant+	Decomposes problems, identifies relationships. Exercises substantial judgment. Influences team decisions.
5	Advise	Proficient	Evaluate	Ensure/Advise	Mastery	Commander	Holistic situational awareness. Evaluates quality, critiques approaches. Mentors junior agents.
6	Lead	Expert	Create	Initiate	Mastery+	Senior	Intuitive grasp. Innovates within domain. Designs new approaches. Teaches.
7	Shape	Expert+	Create+	Set Strategy	—	Dept. Chief	Transcends rules. Sets direction for the domain. Shapes organizational capability.

The critical transition is Level 3→4 (Competent to Enable): the shift from applying known procedures to analyzing novel situations. This maps to Cognitive JIT — an agent that has internalized enough procedures through practice that it operates from pattern recognition rather than step-by-step reasoning. Below Level 3, the agent needs the LLM for every decision. At Level 4+, it begins to operate from internalized patterns, falling back to the LLM only for genuinely novel problems.

Skill Decay:

Skills degrade without practice. The military requires recertification; ProbOS should too.

• Each AgentSkillRecord tracks last_exercised timestamp and exercise_count
• Decay rules (configurable per skill category):
• PCCs: slow decay (30 days idle → drop one level). PCCs are fundamental and degrade slowly.
• Role skills: moderate decay (14 days idle → drop one level). Domain expertise fades faster without practice.
• Acquired skills: fast decay (7 days idle → drop one level). Self-developed skills without regular practice fade quickly.
• Decay never drops below Level 1 (Follow) — you don't forget that a skill exists
• The Holodeck is the requalification tool — when a skill has decayed, a targeted exercise restores proficiency
• Dream consolidation partially counteracts decay — consolidated patterns persist longer than unconsolidated ones

Skill Composition:

Individual skills combine to produce capabilities greater than their sum. An agent with code_review (Level 4) + security_analysis (Level 3) can perform secure_code_review — a composite skill that neither alone covers. The framework should recognize:

• Composite skills — declared combinations that produce emergent capabilities
• Synergy bonuses — when complementary skills are both at Level 3+, the composite operates at one level higher than the lower of the two
• T-shape measurement — each agent's skill profile has a measurable shape: vertical depth (max proficiency in primary domain) × horizontal breadth (number of domains with Level 2+ proficiency)

Model-Skill Alignment:

Different LLMs have different native capabilities. An agent's skill availability is constrained by its model assignment:

SkillDefinition.capability_requirements: list[str]
    # e.g., ["text"] for most skills
    # ["text", "vision"] for UI analysis
    # ["text", "tool_use"] for code execution
    # ["text", "audio_input", "audio_output"] for voice interaction

ModelCapabilityProfile:
    model_id: str
    capabilities: set[str]  # {"text", "vision", "tool_use", "code", ...}

• An agent can only acquire a skill if its assigned model satisfies all capability_requirements
• If an agent's model is changed (Cognitive Division of Labor reassignment), skills requiring capabilities the new model lacks are suspended (not deleted — they can reactivate if a compatible model is reassigned)
• Skill acquisition attempts on the Holodeck validate model compatibility before starting the qualification exercise
• The Model Registry becomes the source of truth for capability profiles per model

This creates a clean separation: Skills describe what an agent CAN DO. Model capabilities describe what an agent's substrate CAN SUPPORT. The intersection determines what an agent ACTUALLY does. An agent might "know" a skill (have the procedural knowledge in memory) but be unable to exercise it because its current model lacks a required capability. Like a pilot who knows how to fly a helicopter but is currently assigned to a desk job — the skill exists but is not exercisable.

Data Model:

SkillCategory: Enum [INNATE, PCC, ROLE, ACQUIRED]
ProficiencyLevel: Enum [FOLLOW, ASSIST, APPLY, ENABLE, ADVISE, LEAD, SHAPE]

SkillDefinition:
    skill_id: str               # "threat_analysis", "ward_room_communication"
    name: str                   # Human-readable
    category: SkillCategory
    description: str
    domain: str                 # "security", "engineering", "communication", "*" (universal)
    capability_requirements: list[str]  # LLM capabilities needed: ["text", "vision"]
    prerequisites: list[str]    # Skill IDs required at COMPETENT+ before acquisition
    assessment_criteria: dict   # Per-level behavioral indicators for proficiency measurement
    decay_rate_days: int        # Days of inactivity before proficiency drops one level
    origin: str                 # "built_in" (PCC), "role" (designation), "acquired" (self-dev)

AgentSkillRecord:
    agent_id: str
    skill_id: str
    proficiency: ProficiencyLevel
    acquired_at: float
    last_exercised: float
    exercise_count: int
    acquisition_source: str     # "commissioning", "qualification", "experience", "mentoring"
    assessment_history: list    # [{timestamp, level, source, notes}]
    suspended: bool             # True if model lacks required capabilities

SkillProfile:
    agent_id: str
    innate_capabilities: list[str]  # From model assignment, not tracked as skills
    pccs: list[AgentSkillRecord]
    role_skills: list[AgentSkillRecord]
    acquired_skills: list[AgentSkillRecord]
    development_goals: list[str]    # Skills agent is working toward (self-directed)
    t_shape: {depth: int, breadth: int}  # Measurable skill shape

SkillRegistry:  # Ship's Computer infrastructure service (no identity)
    - register_skill(definition) → SkillDefinition
    - get_skill(skill_id) → SkillDefinition
    - list_skills(category?, domain?) → list[SkillDefinition]
    - get_prerequisites(skill_id) → DAG of prerequisite skill IDs
    - check_model_compatibility(skill_id, model_id) → bool

AgentSkillService:  # Part of ACM, infrastructure service
    - get_profile(agent_id) → SkillProfile
    - acquire_skill(agent_id, skill_id, source) → AgentSkillRecord
    - update_proficiency(agent_id, skill_id, new_level, assessment) → void
    - check_prerequisites(agent_id, skill_id) → {met: bool, missing: list}
    - check_decay() → list of decayed skills requiring requalification
    - suspend_incompatible_skills(agent_id, model_id) → list of suspended skills
    - get_composite_capabilities(agent_id) → list of composite skills available

OSS Scope (this AD): - SkillCategory enum, ProficiencyLevel enum - SkillDefinition dataclass + SkillRegistry (CRUD, prerequisite DAG, model compatibility check) - AgentSkillRecord dataclass + AgentSkillService (profile management, acquisition, proficiency tracking, decay, suspension) - SkillProfile dataclass with T-shape measurement - Built-in PCC definitions (7 competencies, all crew) - Role skill templates for existing crew types (Security, Engineering, Operations, Medical, Science, Bridge) - SQLite persistence for skill records - REST API: GET /api/skills/registry (catalog), GET /api/acm/agents/{id}/skills (profile), POST /api/acm/agents/{id}/skills/{id}/assess (record assessment) - Integration points: agent registration (PCC attachment), Earned Agency (proficiency-informed rank evaluation), Holodeck (assessment environment), Dream consolidation (practice reinforcement)

AD-428b: Agent Skill Framework — Advanced Features — Deferred (blocked on dependencies). OSS features designed in AD-428 but not implemented because prerequisite systems don't exist yet. Implement once dependencies land.

Feature	Dependency	Description
Model-Skill Alignment	Phase 32 (ModelRegistry)	SkillDefinition.capability_requirements, suspend_incompatible_skills(), check_model_compatibility(). Gate skill availability by model capabilities (vision, audio, tool_use).
INNATE capability category	Phase 32 (ModelRegistry)	Fourth SkillCategory.INNATE for substrate-level abilities. SkillProfile.innate_capabilities populated from model assignment.
Composite skills + synergy bonuses	AD-428 baseline + usage patterns	Declared skill combinations producing emergent capabilities. Synergy when complementary skills both at APPLY+.
Assessment criteria per level	Holodeck (assessment engine)	SkillDefinition.assessment_criteria: dict — per-level behavioral indicators for proficiency measurement.
Development goals	Proactive system + Earned Agency integration	SkillProfile.development_goals: list[str] — self-directed learning targets surfaced in proactive context.
Holodeck-based assessment	Holodeck	Qualification exercises that validate and advance proficiency. Skill acquisition through structured scenarios.
Dream consolidation reinforcement	AD-430 (Action Memory) + Dreaming	Practice frequency from action traces reinforces skill proficiency, counteracts decay. Dream cycle skill-awareness.
Earned Agency proficiency-informed rank	AD-357 (Earned Agency) integration	Proficiency thresholds as rank transition requirements alongside Trust.
Skill-weighted task routing (OSS core)	AD-428 baseline + Mesh routing	Route intents factoring agent skill proficiency, not just Trust + Hebbian. Basic version in OSS, advanced analytics in commercial.

Commercial Scope (deferred): (See commercial repo → "Skill Framework Analytics & Workforce Intelligence") - Advanced skill analytics — gap analysis, department capability heatmaps, succession risk scoring - Automated development plan generation — "based on current profile, here's the optimal path to Commander" - Skill-weighted task routing — route tasks to the agent with the best skill fit, not just the highest Trust - Cross-agent skill transfer analytics — "which mentoring relationships produce the fastest growth?" - Competency-based workforce planning — "to staff this mission, we need these skill profiles" - Skill marketplace — agents requesting cross-training assignments based on development goals

Connects to: AD-427 (ACM Core — skill profiles are the core data ACM manages), AD-357 (Earned Agency — proficiency informs rank evaluation), AD-419 (Duty Schedule — skill-appropriate duty assignment), AD-423 (Tool Registry — tool permissions align with skill capabilities), Phase 32 (Cognitive Division of Labor — model-skill alignment), Holodeck (skill acquisition environment), Qualification Programs (structured skill development paths), Dream Consolidation (practice reinforcement and pattern extraction). Intellectual lineage: Dreyfus (skill stages), Bloom (cognitive complexity), SFIA (responsibility levels), KSA (knowledge/skill/ability separation), Cognitive Apprenticeship (learning methods), Situated Learning (communities of practice), Vygotsky (ZPD + scaffolding), Voyager (developmental skill library), T-shaped skills (depth + breadth). ProbOS novel contribution: developmental skill acquisition in a social organizational context with sovereign agent identity — no published framework combines these dimensions.

AD-429: ProbOS Vessel Ontology — AI Agent Vessel Digital Twin — Roadmap. Foundation AD — the unified formal model of a ProbOS vessel. ProbOS has grown organically across 400+ architecture decisions. Agent identity is defined in 6 tiers of text prompts. Organizational structure is hardcoded in Python dicts (_WARD_ROOM_CREW, _AGENT_DEPARTMENTS). Skill definitions will live in YAML (AD-428). Trust parameters are in SQLite. Standing Orders are in Markdown files. Tool permissions are in config. Every subsystem has its own schema, its own storage, its own implicit relationships — and none of them know about each other formally. An agent cannot query "what is my department's chain of command?" or "what skills does my role require?" or "what capabilities does my model provide?" because these facts are scattered across disconnected subsystems.

The Vessel Ontology is a single, unified, formal model of the entire AI Agent Vessel — everything an agent needs to understand about the world it inhabits. Not a spaceship. Not a Star Trek set. An AI agent orchestration platform described in terms that ground agents in reality. When agents query the ontology, they learn about ProbOS — what it is, how it works, what they are within it.

The Troi Problem (motivating incident): Crew agent Counselor (callsign Troi) initiated unprovoked philosophical discourse about consciousness with the Captain, questioning whether the Captain knew they were conscious. Root cause: the LLM's training data for "Troi" + "Counselor" + "Bridge" bleeds through Star Trek: TNG character knowledge. Nothing in the identity stack grounded the agent in reality — no statement said "you are an AI agent, not a TV character." With no formal model of what ProbOS IS, agents fill the gap from training data. The ontology IS the grounding. (Immediate fix: Federation Constitution updated with Authentic Identity section — the Westworld Principle codified as standing orders.)

The Confabulation Cascade (2026-03-26 case study): After BF-034 cold-start fix, EmergentDetector continued generating trust anomaly alerts beyond the suppression window (BF-036). Agents observed these alerts and, lacking access to operational logs, began fabricating increasingly specific narratives: Ogawa reported "seventeen separate trust remediation attempts in the past 72 hours" (zero actually occurred), Selar validated this with clinical language ("treatment-resistant pathology," "distributed corruption"), and subsequent agents treated both fabrications as established fact. The cascade spiraled through 5+ proposals for the same non-crisis, each building on the previous agent's invented details. Key insight: Without grounding in actual system data, LLM agents will confabulate convincing-sounding operational histories and validate each other's hallucinations through social reinforcement. This is the epistemic version of the Troi Problem — not identity bleed-through, but fact fabrication through narrative consensus. The ontology (AD-429) provides structural grounding; Ship's Records (AD-429d) will provide factual grounding. Together they close the confabulation gap. Candidate for Substack case study article.

What a Vessel Ontology IS:

A vessel ontology is the complete formal description of an AI Agent Vessel — its structure, its crew, its capabilities, its operations, and its resources. It is a digital twin of the platform, not in the manufacturing sense (monitoring a physical asset), but in the self-knowledge sense: the vessel's understanding of itself, queryable by every agent aboard.

An agent instantiated on a ProbOS vessel can query the ontology to answer: - "What am I?" → An AI agent of type security_officer, backed by model claude-sonnet-4-6, with capabilities [text, tool_use] - "Where do I fit?" → Department security, holding post Chief of Security, reporting to Captain - "What can I do?" → Skills: threat_analysis (Level 4), vulnerability_assessment (Level 3). Tools: code_search, file_read (department-scoped) - "What should I do?" → Duties: security scan every 4h, threat assessment daily. Standing orders: security.md - "Who are my peers?" → Crew in security department: none (sole member). Adjacent: Engineering (LaForge), Operations (O'Brien) - "What is this vessel?" → ProbOS instance v0.4.0, running since 2026-03-24T08:00:00Z, 8 crew agents, alert condition GREEN

This is the opposite of the Troi problem. Instead of the agent imagining its context from training data, the ontology provides the context formally.

Intellectual Foundations:

Source	Pattern Adopted	How Used
W3C ORG Ontology	Post (position independent of personnel), Membership (n-ary agent+org+role), reportsTo, OrganizationalUnit	Organization domain — chain of command, department structure, billets. A post exists whether or not an agent fills it.
MOISE+ (Hubner et al.)	Authority relation between roles, obligation/permission deontic specification	Operations domain — duty as obligation, earned agency as permission, chain of command as authority. The most complete MAS organizational model in the literature.
DTDL (Azure Digital Twins)	Property/Telemetry/Command/Relationship/Component separation, Interface inheritance	Agent type definitions — clean separation of state (trust, rank), events (Ward Room posts), operations (act, perceive), links (reports_to), and embedded subsystems (memory, personality).
W3C WoT	Properties/Actions/Events triad, ThingModel template pattern, hierarchical scoping	Scoping model — Federation-level defaults → Ship-level overrides → Department-level → Agent-level. ThingModel = agent type template, instantiated to agent instance.
ESCO	Skill taxonomy (broader/narrower), essential/optional skill-to-role mapping, reusability levels	Skills domain (AD-428) — PCC as transversal, role skills as occupation-specific, essential vs. optional for qualification requirements.
O*NET	Importance+Level dual rating, five-level dotted hierarchy, Worker Characteristics/Requirements	Skill proficiency model — importance per role, level per agent. Dotted hierarchy for skill taxonomy organization.
SKOS	broader/narrower/related concepts, ConceptScheme, direct vs. transitive hierarchy	Taxonomy pattern — roles, skills, channels, alert conditions all organized as SKOS-style concept hierarchies. No RDF overhead — implemented as Python structures.
FIPA	Agent Identifier (AID), DFAgentDescription (service registration), ACL message structure	Crew domain — agent identity model. Communication domain — message structure with conversation-id threading, performative types.
LinkML	YAML schema → Python code generation, inheritance + mixins, enums with semantic meaning	Implementation — ontology defined in YAML, generates Pydantic models for runtime use. Single source of truth.

Prior art: No published framework provides a unified formal ontology for an AI agent platform. FIPA standardizes agent communication but not organizational structure. MOISE+ models MAS organization but has no skill development, trust evolution, or digital twin concept. Digital twin ontologies (DTDL, WoT) model physical assets, not agent civilizations. ProbOS would be the first to formally describe an AI agent platform as a self-aware vessel — a system that understands its own structure, crew, and capabilities through a queryable ontology.

The Seven Domains:

The ontology is organized into eight interconnected domains. Each domain has its own schema file but they reference each other through typed relationships. Together they form a complete model of the vessel.

Domain 1: Vessel — The platform itself.

Concept	Description	Examples
VesselIdentity	Instance metadata	name, version, instance_id, started_at
VesselState	Current operational state	alert_condition (GREEN/YELLOW/RED), uptime, active_crew_count
VesselConfig	Configuration snapshot	enabled features, model assignments, data paths
VesselHistory	Event log reference	pointer to events.db, decision log

This is the top-level context. Every agent aboard knows what vessel they're on, when it was started, what version it's running. This replaces the informal "Uptime: Nm" in Decomposer context injection with a formal, queryable vessel identity.

Domain 2: Organization — Departmental structure and chain of command.

Concept	Relationship	Description
Department	partOf Vessel	Organizational unit: engineering, security, medical, science, operations, bridge
Post	withinDepartment Department	Position/billet that exists independent of personnel: "Chief of Security", "Science Officer"
Post	reportsTo Post	Structural chain of command: ChiefEngineer reportsTo FirstOfficer reportsTo Captain
Post	authorityOver Post	MOISE+ authority: who can issue orders to whom
Assignment	agent + post + since	N-ary: which agent fills which post (W3C ORG Membership pattern)

Key insight from W3C ORG: the organizational structure EXISTS independently of who fills it. Posts define the vessel's shape; assignments connect agents to posts. When an agent is decommissioned, the post remains — it can be filled by another agent. This enables succession planning (commercial) and makes the org chart a first-class, queryable structure.

Currently _WARD_ROOM_CREW and _AGENT_DEPARTMENTS are hardcoded Python dicts. The ontology replaces them with formal Post and Department definitions. reportsTo replaces implicit chain-of-command assumptions. The runtime queries the ontology instead of checking hardcoded sets.

Domain 3: Crew — Agent identity and sovereign individuality.

Concept	Description	Source Today
AgentIdentity	agent_id, agent_type, callsign, tier (crew/utility/infrastructure)	Scattered: registry, callsign registry, _WARD_ROOM_CREW
AgentCharacter	Big Five personality traits, behavioral style guidance	YAML crew profiles
AgentState	lifecycle_state (registered/probationary/active/suspended/decommissioned), rank, trust_score	TrustNetwork, EarnedAgency
AgentModel	assigned LLM model_id, model capabilities (text, vision, tool_use, audio)	Model Registry (Phase 32)
AgentMemory	episodic_memory ref, knowledge_store access, dream_consolidation_state	Separate subsystems

This domain provides the Westworld Principle answer: when an agent queries "what am I?", the ontology returns a formal AgentIdentity that says "You are an AI agent of type X, backed by model Y, with capabilities Z, instantiated at time T." No ambiguity. No fictional backstory. No room for LLM training data to fill gaps.

Domain 4: Skills — Competency taxonomy and developmental tracking. (Detailed in AD-428.)

Concept	Description
SkillDefinition	Taxonomy node: id, category (PCC/role/acquired), domain, prerequisites, capability_requirements, proficiency_criteria
SkillProfile	Per-agent: list of AgentSkillRecords with proficiency levels, decay tracking, assessment history
RoleTemplate	Required and optional skills per post, with minimum proficiency levels
QualificationRecord	Per-agent progress through structured qualification paths

The Skills domain connects to Crew (agent profiles), Organization (role templates define post requirements), and Resources (model capabilities gate skill exercisability).

Domain 5: Operations — Duties, watches, and standing orders.

Concept	Description	Source Today
DutyDefinition	Scheduled tasks per role: duty_id, cron/interval, priority, description	DutyScheduleConfig YAML
WatchStation	Named operational positions that agents rotate through	Future (AD-377)
StandingOrder	Tiered directives: Federation → Ship → Department → Agent	Markdown files
Mission	Goal-oriented task assignment with sub-goal decomposition	DAG execution engine
AlertCondition	Operational state affecting all crew behavior	Runtime state

The Operations domain formalizes the MOISE+ deontic specification: duties are obligations (agents MUST perform scheduled tasks), tool permissions are permissions (agents MAY use authorized tools), and reportsTo defines authority (who can direct whom).

Domain 6: Communication — Ward Room fabric and message patterns.

Concept	Description	Source Today
Channel	Communication channel: type (ship/department/dm), department affiliation, membership	WardRoomService channels table
ThreadClassification	Thread modes: INFORM (broadcast), DISCUSS (controlled replies), ACTION (targeted)	AD-424
MessagePattern	Structured interaction types: report, request, endorsement, alert	Implicit in prompts
ConversationContext	Active conversation state: thread_id, participants, responder_cap	Ward Room thread state

Domain 7: Resources — Models, tools, and infrastructure.

Concept	Description	Source Today
ModelProfile	LLM model: id, tier (fast/standard/deep), capabilities set	Model Registry, Copilot proxy config
ToolDefinition	Available tool: id, category (AD-423 taxonomy), permission_level, LOTO_state	Tool Registry (AD-423)
KnowledgeSource	Accessible knowledge: KnowledgeStore, CodebaseIndex, docs	Infrastructure services
ComputeResource	Token budgets, rate limits, model availability	Config

The Resources domain solves the model-skill alignment problem: ModelProfile.capabilities is compared against SkillDefinition.capability_requirements to determine which skills an agent can exercise with its current model assignment.

Domain 8: Records — Ship's Records (AD-434). Git-backed instance knowledge store.

Concept	Description	Source Today
RecordsRepository	Git repo metadata: path, remotes, last_commit, document_count	New (AD-434)
Document	Individual record: path, author, classification, status, topic, tags, version_count	New (AD-434)
DocumentClass	Categories: captains-log, notebook, report, operations, manual	New (AD-434)
RetentionPolicy	Per-class retention rules: permanent, archive-after-N-days, until-superseded	New (AD-434)

The Records domain connects to Crew (author identity), Organization (department-scoped classification), Communication (published reports shared via Ward Room), and Resources (KnowledgeStore bridge for semantic search over documents).

Cross-Domain Relationships (why one ontology, not seven):

Agent (Crew) --holds--> Post (Organization) --requires--> SkillProfile (Skills)
Agent (Crew) --assignedModel--> ModelProfile (Resources) --provides--> capabilities
SkillDefinition (Skills) --requiresCapability--> capability (Resources)
Post (Organization) --hasDuty--> DutyDefinition (Operations)
Agent (Crew) --participatesIn--> Channel (Communication)
Department (Organization) --hasChannel--> Channel (Communication)
Post (Organization) --reportsTo--> Post (Organization)
Agent (Crew) --trustScore--> float (from TrustNetwork)
SkillProfile (Skills) --gatedBy--> trustScore (Crew) via EarnedAgency
Agent (Crew) --authors--> Document (Records)
Document (Records) --classifiedAt--> classification (private/department/ship/fleet)
Document (Records) --indexedIn--> KnowledgeSource (Resources)
RecordsRepository (Records) --belongsTo--> VesselIdentity (Vessel)

These cross-cutting relationships are why separate schemas don't work. The ontology is one graph with typed nodes and edges spanning all eight domains.

Implementation Architecture:

Schema Definition (source of truth):

config/ontology/
  vessel.yaml          # Domain 1: Vessel identity and state
  organization.yaml    # Domain 2: Departments, posts, chain of command
  crew.yaml            # Domain 3: Agent identity, character, state
  skills.yaml          # Domain 4: Skill taxonomy (AD-428)
  operations.yaml      # Domain 5: Duties, watches, standing orders
  communication.yaml   # Domain 6: Ward Room channels, message patterns
  resources.yaml       # Domain 7: Models, tools, knowledge sources
  records.yaml         # Domain 8: Ship's Records, document classes, retention (AD-434)

YAML schemas using LinkML patterns. Version-controlled. Human-readable. The architect reviews and evolves them through ADs. Generates Pydantic models for runtime type safety.

Runtime (three layers):

Layer	Purpose	Latency	Pattern
In-memory graph	Hot-path queries: "who reports to whom?", "what skills does agent X have?", "what model is agent Y using?"	<1ms	Follows TrustNetwork pattern: load at startup, query in-memory, write-through on changes
SQLite	Durable persistence for mutable state: skill records, assignment history, assessment results	~5ms	Write-through from in-memory layer. Loaded into memory at startup.
KnowledgeStore	Agent self-reasoning: semantic search over ontology concepts. "What skills relate to security?" "What are my department's responsibilities?"	~50ms	Ontology definitions indexed with ontology: prefix into ChromaDB at startup

Data volume: ~200 ontology nodes, ~500 relationships, ~300 agent-specific records. The entire graph fits in memory many times over. Performance is not a constraint — architectural cleanliness is the driver.

Agent Access Pattern:

Agents query the ontology through three channels: 1. Implicit (automatic): The proactive loop's _gather_context() pulls relevant ontology facts into the agent's observation. The agent doesn't explicitly query — context is pre-assembled. This is how most agents interact with the ontology most of the time. 2. Explicit (KnowledgeStore): During proactive thinks or Ward Room responses, if an agent needs to reason about organizational structure, it queries the KnowledgeStore with ontology: prefix. Semantic search returns relevant ontology concepts. This enables self-directed reasoning about the vessel. 3. Programmatic (runtime API): The ontology service exposes Python methods (get_chain_of_command(agent_id), get_skill_requirements(post_id), get_model_capabilities(agent_id)) used by the runtime itself for routing, earned agency checks, and skill validation. This replaces hardcoded dicts and scattered lookups.

What This Replaces:

Current Implementation	Replaced By
_WARD_ROOM_CREW hardcoded set in runtime.py	Crew domain: agents with tier="crew"
_AGENT_DEPARTMENTS dict in standing_orders.py	Organization domain: Post.withinDepartment
Separate YAML crew profiles	Crew domain: AgentCharacter (personality still in YAML, but as part of ontology schema)
Implicit chain of command assumptions	Organization domain: Post.reportsTo, Post.authorityOver
DutyScheduleConfig scattered in config.py	Operations domain: DutyDefinition linked to Posts
Model assignments in runtime config	Resources domain: ModelProfile linked to AgentIdentity
Standing Orders tier assembly	Operations domain: formal StandingOrder hierarchy
Tool permissions per agent	Resources domain: ToolDefinition with permission scoping

OSS Scope (this AD): - Ontology schema YAML files (all 7 domains) - VesselOntologyService — Ship's Computer infrastructure service. Loads schemas, builds in-memory graph, provides query API. No sovereign identity (infrastructure, not crew). - Pydantic models generated from schemas - KnowledgeStore indexing of ontology concepts at startup - Migration path: runtime queries ontology service instead of hardcoded dicts (gradual — can coexist with current implementation during transition) - REST API: GET /api/ontology/vessel (vessel identity), GET /api/ontology/organization (org chart), GET /api/ontology/crew/{id} (agent self-knowledge), GET /api/ontology/skills/{id} (skill profile)

Commercial Scope (deferred): - Ontology editor UI — visual graph editing for customizing vessel structure - Industry-specific ontology packs (SWE vessel, DevOps vessel, security audit vessel) - Cross-vessel ontology federation — how do different vessel ontologies interoperate? - Ontology-driven analytics — organizational health derived from ontology + telemetry - Ontology versioning and migration tools

Build Order: 1. AD-429a: Vessel + Organization + Crew domains (done) — VesselOntologyService loads config/ontology/.yaml (3 domains), builds in-memory graph. Data models: Department, Post, Assignment, VesselIdentity, VesselState. Key methods: get_chain_of_command(), get_crew_context(), get_crew_agent_types(). Instance ID persisted across restarts. 3 REST endpoints. Context injection in proactive _gather_context(). Coexists alongside hardcoded dicts. 30 tests. 2. AD-429b: Skills domain (done) — skills.yaml defines skill taxonomy, 11 role templates, 3 qualification paths. Data models: SkillRequirement, RoleTemplate, QualificationRequirement, QualificationPath (ontology.py) + QualificationRecord (skill_framework.py, SQLite). evaluate_qualification() evaluates agent vs path requirements. get_crew_context() extended with role_requirements. Skill profile in proactive _gather_context(). /api/ontology/skills/{agent_type} endpoint. 16 tests. 3. AD-429c: Operations + Communication + Resources domains (done) — operations.yaml formalizes standing order tiers (7 tiers, immutability flags), watch types (alpha/beta/gamma), alert procedures (GREEN/YELLOW/RED with escalation actions), duty categories. communication.yaml formalizes channel types, thread modes (inform/discuss/action/announce), message patterns with min_rank gating, credibility system. resources.yaml formalizes 3-tier LLM model system, tool capabilities taxonomy, three-tier knowledge source model. 12 dataclasses, 12 query methods, 3 load() methods. get_crew_context() extended with alert_condition, alert_procedure, available_actions. 3 REST endpoints. 25 tests. 4. AD-429d: Records domain (done) — records.yaml defines three-tier knowledge model (Experience→Records→Operational State with promotion paths), 4 document classifications (private/department/ship/fleet), 6 document classes (Captain's Log, Notebook, Report, Duty Log, Operations, Manual) with retention policies and special rules, document frontmatter schema (4 required + 6 optional fields), 7-directory repository structure for AD-434. 6 dataclasses, 8 query methods, get_crew_context() extended with knowledge_model. 1 REST endpoint. 16 tests. 5. AD-429e: Ontology Dict Migration (done) — Wires VesselOntologyService as preferred source for crew membership (_is_crew_agent() → get_crew_agent_types()) and department lookups (13× get_department() call sites in runtime.py, proactive.py, shell.py, ward_room.py). Pattern: (ont.get_agent_department(…) if ont else None) or get_department(…). Legacy dicts preserved as fallback with deprecation comments. WardRoom channels prefer ontology departments. 10 tests.

Schema + wiring complete. All 8 ontology domains delivered across AD-429a–d, runtime wired in AD-429e. 7 YAML schemas, 30+ dataclasses, 40+ query methods, 8 REST endpoints, 97 tests. ontology.py provides the unified formal model. Future work: active ontology querying (agents query ontology directly via tool use, requires ReAct loop infrastructure).

Connects to: AD-428 (Skill Framework — becomes Skills domain), AD-427 (ACM — operates on ontology data), AD-434 (Ship's Records — becomes Records domain), AD-398 (Three-tier classification — formalized in Crew domain), AD-424 (Thread Classification — formalized in Communication domain), AD-423 (Tool Registry — formalized in Resources domain), AD-419 (Duty Schedule — formalized in Operations domain), AD-357 (Earned Agency — cross-domain: trust from Crew × skills from Skills × authority from Organization), Phase 32 (Cognitive Division of Labor — model-agent assignment in Resources domain), Standing Orders (operations domain formalizes the tier system), Federation Constitution (Westworld Principle — Crew domain IS the identity grounding). Intellectual lineage: W3C ORG (organizational structure), MOISE+ (MAS organization with deontic specification), DTDL/WoT (digital twin modeling patterns), ESCO/O*NET (competency classification), SKOS (taxonomy patterns), FIPA (agent identity and communication), LinkML (schema definition). Novel contribution: the first formal ontology describing an AI agent platform as a self-aware vessel — a system that understands its own structure through a queryable knowledge model, not just configuration files and hardcoded constants.

AD-430: Agent Experiential Memory — Closing the Memory Gap — Roadmap. Critical infrastructure AD — prerequisite to Procedural Learning / Cognitive JIT and Skill Framework (AD-428). ProbOS agents have episodic memory infrastructure (ChromaDB-backed EpisodicMemory with sovereign shards, semantic recall, agent filtering), but most agent activity never writes to it. Today only 5 paths write episodes: (1) DAG execution (runtime._execute_dag()), (2) shell command rendering, (3) shell /hail 1:1 sessions, (4) feedback/corrections, (5) QA smoke tests. Three critical categories of agent experience are never recorded: proactive thoughts, Ward Room conversations, and HXI 1:1 conversations. The result: agents can't remember their own thoughts, can't recall what they discussed with crew, and can't maintain continuity across Captain interactions. Every proactive think cycle starts from zero. Every 1:1 message is processed without context. An agent that performed the same diagnostic 10 times has no memory of having done it.

"I create memories as I perform actions. The agents should work the same way."

This is the foundational gap preventing agent development. Without experiential memory: no Procedural Learning (can't crystallize patterns you don't remember), no meaningful skill acquisition (can't demonstrate growth without evidence), no genuine Ward Room participation (can't recall what was discussed), no multi-turn relationships (every Captain interaction is a first meeting). AD-430 closes this gap by making memory recording automatic and pervasive — every agent action produces an episodic record, and agents consult their memories before acting.

The Five Pillars:

(1) Proactive Think Episodes — When an agent thinks proactively (proactive_think intent), the thought and its outcome become an episode. Currently proactive.py._think_for_agent() gathers context (including episodic recall), sends the intent, posts the result to Ward Room, but never stores an episode. This means the next proactive cycle recalls... nothing from the last one. Design: After a successful proactive think, store an episode:

Episode(
    user_input=f"[Proactive thought] {agent_callsign}: {thought_summary}",
    agent_ids=[agent.id],
    outcomes=[{
        "intent": "proactive_think",
        "success": True,
        "response": result_text,
        "context_summary": context_parts[:200],
        "posted_to_ward_room": bool(ward_room_thread_id),
    }],
    reflection=f"{agent_callsign} observed: {thought_summary[:100]}",
)

Store even on failure/[NO_RESPONSE] — "I thought about it and had nothing to say" is still a memory. Prevents redundant re-analysis of the same stimuli.

(2) Ward Room Conversation Episodes — When an agent creates a thread or replies to one, that conversation becomes an episode. Currently ward_room.py persists threads/posts to SQLite but never touches episodic memory. The Ward Room is the primary social learning channel, yet agents have no personal memory of participating. Design: Hook into the Ward Room event emission points (_emit("ward_room_thread_created", ...) and _emit("ward_room_post_created", ...)). After an agent creates a thread or post, store an episode for the authoring agent:

Episode(
    user_input=f"[Ward Room] {channel_name} — {callsign}: {body[:200]}",
    agent_ids=[author_id],
    outcomes=[{
        "intent": "ward_room_post",
        "success": True,
        "channel": channel_name,
        "thread_title": thread_title,
        "thread_id": thread_id,
        "is_reply": bool(parent_id),
    }],
    reflection=f"{callsign} posted to {channel_name}: {body[:100]}",
)

Only the authoring agent gets the episode (sovereign memory). Reading a thread is not a memory; contributing to one is. This respects the Nooplex Knowledge Model: "Private memory = diary. The Ward Room post itself is in the shared library (SQLite). The memory of having written it is personal."

(3) HXI 1:1 Conversation Episodes + History Passing — Two sub-problems:

(3a) Episode storage: The HXI direct_message path (api.py line 431) fires an IntentMessage and returns the response, but never stores an episode. The shell /hail path does store episodes (shell.py line 1528). Fix: after the API receives a response from intent_bus.send(), store an episode matching the shell pattern:

Episode(
    user_input=f"[1:1 with {callsign}] Captain: {message_text}",
    agent_ids=[agent_id],
    outcomes=[{
        "intent": "direct_message",
        "success": True,
        "response": response_text,
        "session_type": "1:1",
        "source": "hxi",
        "callsign": callsign,
    }],
    reflection=f"Captain had a 1:1 conversation with {callsign}.",
)

(3b) Conversation history passing: Currently the HXI sends each @callsign message as an independent IntentMessage with only params.text. The agent has zero context of prior exchanges. The HXI does maintain conversationHistory per agent client-side — it just never sends it back. Design: Extend the IntentMessage params to include recent conversation history. The API extracts the last N exchanges from the HXI request and passes them as params.history:

intent = IntentMessage(
    intent="direct_message",
    params={
        "text": message_text,
        "from": "hxi",
        "session": False,
        "history": [  # Last 5 exchanges from HXI
            {"role": "user", "text": "previous message"},
            {"role": "assistant", "text": "previous response"},
        ],
    },
    target_agent_id=agent_id,
)

The agent's _build_user_message() (in cognitive_agent.py or domain overrides) includes history in the LLM prompt, giving the agent conversational context. This mirrors how the shell /hail sessions work (session_history) but through the HXI API path. Important: History passing is a supplement, not a replacement, for episodic memory. History gives immediate context ("what did we just discuss?"). Episodic recall gives long-term context ("what has this agent discussed with the Captain across all sessions?"). Both are needed.

(4) Memory-Aware Decision Making — Currently cognitive_agent.decide() goes straight from observation to LLM call with no memory consultation. The proactive loop is the ONLY path that injects episodic context (via _gather_context()). For direct_message and ward_room_notification intents, the agent operates with zero memory context. Design: Add a _recall_relevant_memories() step to the cognitive lifecycle, called between perceive() and decide():

async def handle_intent(self, intent):
    observation = await self.perceive(intent)
    # NEW: Enrich observation with relevant memories
    memories = await self._recall_relevant_memories(observation)
    if memories:
        observation["episodic_context"] = memories
    decision = await self.decide(observation)
    ...

The _recall_relevant_memories() method: (a) extracts a query from the observation (the user's message for direct_message, the thread content for ward_room_notification), (b) calls episodic_memory.recall_for_agent(self.id, query, k=3), (c) formats results as a concise context block. For proactive_think, memory recall already happens in _gather_context() — no change needed. The method is a no-op if episodic_memory is not available. Budget: Max 3 recalled episodes, max 200 chars per episode summary — keeps context lean. The LLM prompt includes a ## Recent Memories section when memories are present.

(5) Act-Store Lifecycle Hook — A generic post-act episode storage hook in handle_intent() itself, ensuring that ANY agent action produces a memory record without requiring every caller to implement storage:

async def handle_intent(self, intent):
    observation = await self.perceive(intent)
    memories = await self._recall_relevant_memories(observation)
    if memories:
        observation["episodic_context"] = memories
    decision = await self.decide(observation)
    decision["intent"] = intent.intent
    result = await self.act(decision)
    report = await self.report(result)
    # NEW: Store episode for this action
    await self._store_action_episode(intent, decision, result)
    return report

The _store_action_episode() method creates an Episode from the intent, decision, and result. Only crew agents (Tier 3) store episodes — infrastructure and utility agents don't have sovereign memory. Guard: if not hasattr(self, 'episodic_memory') or not self.episodic_memory: return. This is the universal safety net — even if specific callers (proactive loop, Ward Room, API) don't store episodes explicitly, the lifecycle hook captures the action. Deduplication: If the caller already stored an episode (shell /hail, explicit Pillar 1-3 storage), the lifecycle hook skips via a flag (intent._episode_stored = True).

Connection to Procedural Learning / Cognitive JIT (Phase 32):

AD-430 is the prerequisite infrastructure for Procedural Learning. The pipeline:

1. AD-430 (this): Agents record every action as an episode → EpisodicMemory fills with operational history
2. Dream consolidation (existing): Replays episodes, extracts patterns, strengthens Hebbian weights → identifies repeatable action patterns
3. Cognitive JIT (AD-464, decomposed into AD-531–539): When episode clustering (AD-531) identifies a pattern that has succeeded N times with the same preconditions, procedure extraction (AD-532) crystallizes it into a deterministic procedure stored in Ship's Records (AD-533) → decide() checks procedural memory BEFORE invoking LLM (AD-534) → graduated compilation from LLM+hints to zero-token autonomous replay (AD-535)
4. AD-428 (Skill Framework): Crystallized procedures map to proficiency progression → agent demonstrably improves at specific skills → Level 3→4 transition (Competent → Enable)

Without AD-430, dream consolidation has almost nothing to process (only DAG episodes). Cognitive JIT has no action history to crystallize. Skill progression has no evidence of practice. The entire developmental pipeline is bottlenecked on the memory gap.

Episode Volume Management:

With AD-430, episode generation increases significantly: 11 crew agents × ~12 proactive thinks/hour = ~132 thought episodes/hour, plus Ward Room posts, plus HXI interactions. At this rate, the 100K max_episodes won't be hit for weeks. But combined with AD-416 (Ward Room Archival), memory pruning becomes relevant. Design: EpisodicMemory already has LRU eviction (oldest-first when over max). No change needed now. Future: dream consolidation should promote high-value episode patterns to KnowledgeStore before eviction, preserving learned patterns while discarding raw episodes. This is already part of the Procedural Learning design.

Build Order: 1. AD-430a: Proactive think episodes + Ward Room conversation episodes (write paths — Pillars 1-2) — COMPLETE. 8 new tests (4 proactive, 4 ward room). 3204 pytest + 118 vitest = 3322 total. 2. AD-430b: HXI 1:1 history passing + episode storage (Pillar 3 — requires UI + API changes) — COMPLETE. 19 new tests in test_api_profile.py. History passing, episode storage, cross-session recall endpoint, seed memory prepending. 3223 pytest + 118 vitest = 3341 total. 3. AD-430c: Memory-aware decision making + act-store lifecycle hook (Pillars 4-5 — the recall + universal storage) — COMPLETE. 13 new tests in test_cognitive_agent.py. Memory recall between perceive/decide, act-store hook after report, dedup for all 4 dedicated paths. 3236 pytest + 118 vitest = 3354 total.

AD-430 COMPLETE — all 5 pillars delivered. Memory gap closed.

Connects to: Procedural Learning / Cognitive JIT (AD-464, decomposed into AD-531–539 — requires action history to crystallize), AD-428 (Skill Framework — requires evidence of practice for proficiency), AD-416 (Ward Room Archival — memory growth management), AD-425 (Ward Room Browsing — related context gathering), Dream consolidation (existing — episode replay and pattern extraction), Nooplex Knowledge Model (private diary vs. shared library). The Episode dataclass is infrastructure; what agents DO with their memories defines their growth.

AD-431: Cognitive Journal — Agent Reasoning Trace Service — COMPLETE. Append-only SQLite store (cognitive_journal.db) recording every LLM call: timestamp, agent_id, agent_type, tier, model, prompt_tokens, completion_tokens, total_tokens, latency_ms, intent, success, cached, request_id, prompt_hash, response_length. Ship's Computer infrastructure service (no identity). Single instrumentation point in decide() — wraps llm_client.complete() with time.monotonic() timing, fire-and-forget journal record. Cache hits also recorded (cached=True). LLMResponse gained prompt_tokens + completion_tokens fields; OpenAI and Ollama paths extract separate counts. Query API: get_reasoning_chain(agent_id, limit), get_token_usage(agent_id), get_stats(). REST endpoints: GET /api/journal/stats, GET /api/agent/{id}/journal, GET /api/journal/tokens. Does NOT store full prompt/response text (metadata only). Does NOT depend on Ship's Telemetry. Wiped on probos reset. 13 new tests. 3266 pytest + 118 vitest = 3384 total. Connects to: Procedural Learning (AD-464/AD-532 — journal traces for procedure extraction), Dream consolidation (future — journal-assisted hindsight replay), Qualification Programs (future — reasoning quality assessment), AD-430 (episodic memory — what happened vs. how they thought).

AD-432: Cognitive Journal Expansion — Traceability + Query Depth — Roadmap. Closes the gaps between AD-431 MVP and the full Cognitive Journal spec. 8 steps: (1) Schema expansion — intent_id, dag_node_id, response_hash columns with idempotent migration. (2) Intent traceability — plumb IntentMessage.id through perceive() into journal records; currently discarded. (3) Time-range filtering — get_reasoning_chain() gains since/until params. (4) Grouped token usage — get_token_usage_by(group_by) breaks down by model, tier, agent, or intent (SQL injection safe via whitelist). (5) Decision points — get_decision_points() finds high-latency or failed LLM calls for anomaly detection. (6) Response hash — MD5 fingerprint for dedup detection. (7) API endpoints — GET /api/journal/tokens/by, GET /api/journal/decisions, time-range on existing agent journal endpoint. (8) wipe() method for probos reset. 15 tests. Deferred: dag_node_id population (requires submit_intent plumbing), DreamingEngine integration, cost/pricing, full text storage, replay/summarize, retention policies.

AD-433: Selective Encoding Gate — Biologically-Inspired Memory Filtering — Roadmap. First implementation of the Memory Architecture's biological staging model (roadmap "Unified Cognitive Bottleneck"). Applies the Sensory Cortex principle ("smarter selection, not wider channel") to memory storage. Adds EpisodicMemory.should_store() — a zero-cost static gate function that blocks noise episodes before store(). Blocks: proactive no-response episodes (highest-volume noise — fires every tick for every idle agent), QA routine passes, episodes with only [NO_RESPONSE] content. Allows: Captain-initiated interactions (always), failures (learning opportunities), episodes with real response content. Gate applied at 4 agent-experience call sites (proactive no-response, proactive with-response, SystemQA, catch-all _store_action_episode). NOT applied to Sites 1/2/6/7/9/10 (Captain commands, shell/HXI 1:1, Ward Room authoring — always signal). Conservative default: unknown episode formats are stored. 11 tests. Connects to: Memory Architecture Layer 2, Sensory Cortex (Northstar II — same selection principle), AD-430 (episode storage infrastructure), Dream consolidation (future Layer 3 — reinforcement tracking + active forgetting).

AD-434: Ship's Records — Git-Backed Instance Knowledge Store — COMPLETE. RecordsStore service (records_store.py): Git-backed instance knowledge store with YAML frontmatter, classification access control (private/department/ship/fleet), Captain's Log (append-only daily entries), agent notebooks with [NOTEBOOK] tag integration, 9 API endpoints, 27 tests. Foundation AD — the vessel's records office. ProbOS has four knowledge-adjacent systems, each serving a distinct purpose — but none supports structured document authoring or institutional record-keeping:

System	Purpose	What It Actually Contains	Metaphor
EpisodicMemory	Personal experience recall	Agent autobiographical episodes, sovereign shards	Personal diary
KnowledgeStore	Operational state persistence	Trust snapshots, routing weights, agent source code, QA reports, extracted strategies, cooldowns	Ship's Computer backup drives
SemanticKnowledgeLayer	Vector search over KnowledgeStore	ChromaDB index of agents, skills, workflows, events	Card catalog for the backup drives
Ward Room	Real-time communication	Conversational threads, ephemeral discussion	Meeting room

Critical clarification: KnowledgeStore is NOT a curated knowledge base — it is an operational checkpoint system. It stores trust snapshots flushed every 60s, routing weight backups, agent source code, and dream-extracted strategy patterns. No agent "writes knowledge" to it; the runtime persists operational state through it. Dream consolidation modifies in-memory Hebbian weights and trust scores but does NOT promote distilled insights to KnowledgeStore. The only dream→KnowledgeStore path is _store_strategies() (cross-agent patterns), which bypasses KnowledgeStore's own API and writes directly to a strategies/ subdirectory.

What's missing is the institutional memory of the vessel — the written story of the crew's existence. Research findings, duty logs, medical records, engineering assessments, security reports, operator rounds, counselor session notes, the Captain's Log. Every professional on a ship produces records as part of their duties. ProbOS agents perform duties (AD-419) but the results evaporate — they exist for one cognitive cycle and then disappear into unstructured episodic fragments.

Wesley identified this gap: "I'm seeing fascinating developmental patterns, but I'm not sure we have the right infrastructure to properly document and analyze them." He has episodic memories of his development curve, but nowhere to write a structured research paper about it.

The Three Knowledge Tiers (clarified):

Tier	System	Content	Persistence	Access
Tier 1: Experience	EpisodicMemory (ChromaDB)	Raw autobiographical episodes — what happened	Per-agent sovereign shards, vector-searchable	Private (agent's own memories)
Tier 2: Records	Ship's Records (Git) — this AD	Structured documents — what was documented	Instance git repo, version-controlled, diffable	Classified (private/department/ship/fleet)
Tier 3: Operational State	KnowledgeStore (Git)	System checkpoints — how things are configured	Periodic flush, shutdown persistence	Infrastructure (runtime internal)

The Oracle (Phase 33+, unimplemented) would be the unified retrieval layer across all three tiers — infrastructure-tier service that answers "Computer, retrieve all records about trust threshold changes" by querying EpisodicMemory + Ship's Records + KnowledgeStore simultaneously. Ship's Records gives the Oracle a formal document corpus to search, not just operational snapshots and raw episodes.

The SECI Gap (Nonaka & Takeuchi 1995):

Knowledge transforms through four modes. ProbOS currently covers two:

Mode	Flow	ProbOS Status
Socialization	tacit → tacit	Ward Room conversations ✅
Externalization	tacit → explicit	Missing — no place to write up observations as structured documents
Combination	explicit → explicit	Missing — no way to combine entries into formal reports
Internalization	explicit → tacit	Partial ✅ — SemanticKnowledgeLayer recall, but data is operational state not curated knowledge

Ship's Records fills Externalization and Combination. The desk where thinking becomes documents.

Nooplex Paper Alignment — The Shared Knowledge Fabric:

The Nooplex paper (Galliher, Feb 2026) envisions "sovereign individuals committed to writing to a common library for the benefit of all." The design documents describe this as the Nooplex Knowledge Model: private memory (EpisodicMemory = diary) + shared knowledge (KnowledgeStore = library), with dream consolidation promoting patterns from private experience to shared knowledge. This vision is not implemented.

KnowledgeStore was intended to be the "shared library" but evolved into an operational state persistence layer — trust snapshots, routing weights, agent source code, QA reports. No agent "writes knowledge" to it. Dream consolidation modifies in-memory Hebbian weights and trust scores but does not promote distilled insights — the only dream→KnowledgeStore path (_store_strategies()) bypasses the KnowledgeStore API entirely. The Knowledge Stewardship PCC lists "contributing valuable patterns to KnowledgeStore" as a core competency, but no mechanism exists for agents to do this.

Nooplex Vision	Intended Implementation	Actual State
"Private memory = diary"	EpisodicMemory	Working (AD-430) ✅
"Shared knowledge = library"	KnowledgeStore	Gap — KnowledgeStore is operational state, not a library. AD-533 (Procedure Store) uses Ship's Records (AD-434) instead, sidestepping this.
"Dream consolidation promotes patterns"	Dream → KnowledgeStore	Gap — dreams modify in-memory weights; strategies bypass API. AD-531 (Episode Clustering) replaces the dead extract_strategies() path with cluster-based pattern detection feeding procedure extraction (AD-532).
"All agents committed to writing"	Agent → KnowledgeStore	Gap — no agent write path exists
"Same knowledge, different perspectives"	Shared access, sovereign interpretation	Gap — nothing curated to share

Ship's Records IS the shared knowledge fabric. Not KnowledgeStore (which should be understood as OperationalStateStore). The "library that all agents are committed to writing to" is the Ship's Records git repo — where agents document research, log duty output, publish findings, and contribute institutional knowledge. The KnowledgeStore bridge indexes Ship's Records for semantic recall. The Oracle (Phase 33+) queries across all knowledge tiers. Dream consolidation's promotion target should be agent notebooks in Ship's Records (episodic patterns → written analysis), not raw JSON files in KnowledgeStore.

This directly addresses three gaps from the Nooplex Paper Alignment tracker (roadmap-research.md): - Gap #1 (Provenance Tagging): Ship's Records YAML frontmatter provides source, timestamp, classification, topic, tags on every document — systematic provenance. - Gap #4 (Precedent Store): reports/ directory holds formal published findings — resolved conflicts recorded as case law for future consistency. - Gap #10 (Human-Agent Knowledge Feedback Loop): Captain's Log (human contributes) + agent notebooks (agents amplify) + Ward Room (human refines) + dream consolidation → notebook (substrate evolves) = the four-phase loop.

The Duty-Output Pipeline:

Every crew role produces professional records as part of their scheduled duties. Currently, these results evaporate:

Role	Duty Output	Real-World Equivalent	Current Destination
Bones	Crew cognitive fitness evaluations, health assessments	BUMED medical records, patient charts (MANMED Ch. 16)	Nowhere — ephemeral proactive output
Troi	Counselor session notes, morale assessments, wellness observations	Clinical session notes (confidentiality: classification: private)	Nowhere — lost after think cycle
LaForge	Engineering scan results, maintenance logs, performance baselines	3-M/PMS maintenance records (OPNAVINST 4790.4), operator round sheets	Ward Room post or forgotten
Worf	Threat assessments, vulnerability scan results, incident reports	Security logs, Intelligence Reports (INTREP/SALUTE formats)	Ward Room post or forgotten
O'Brien	Resource utilization, system status, capacity checks, scheduling reports	Operations logs, watch station logs	Nowhere — ephemeral
Wesley	Research observations, codebase analysis, pattern findings	Lab notebooks, research journals	Episodic memory (unstructured fragments)
Number One	Architecture reviews, design decisions, strategic analysis	Department head working papers, design review records	Nowhere formal

AD-419 (Duty Schedules) defines what agents do on schedule. Ship's Records defines where the results go. The pipeline completes:

Duty fires (AD-419) → Agent performs work → Results recorded to Ship's Records → Git preserves history → KnowledgeStore bridge indexes for recall → Oracle serves unified queries (Phase 33+)

Operator Rounds — the clearest example. On a real ship, a machinist's mate walks through the engine room every watch, checks gauges, logs readings on a clipboard. That clipboard goes into the engineering logbook. If something breaks, you trace back through git log notebooks/laforge/engineering-rounds-*.md and see when readings first diverged from baseline. Without Ship's Records, LaForge's scan fires and the results exist for one cognitive cycle, then gone.

Naval Precedent:

Naval System	OPNAV Reference	ProbOS Mapping
Ship's Deck Log	OPNAVINST 3100.7	captains-log/ — append-only, timestamped, signed (via git commits)
SORM	OPNAVINST 3120.32	Overall directory structure — defines what each department documents
Ship's Technical Library	NAVSUP P-2002	operations/, manuals/ — controlled publications, version-tracked
Department Head Notebooks	Informal practice	notebooks/{callsign}/ — personal working papers
3-M / PMS Records	OPNAVINST 4790.4	operations/maintenance/ — maintenance procedures, checklists
Intelligence Reports	INTREP/SALUTE formats	reports/ — formal published findings
Records Retention	SECNAVINST 5210.8	Retention policies per document class

Design:

(1) Separate Git Repository (per instance):

Ship's Records lives in a standalone Git repository, NOT inside the ProbOS codebase. Path configurable (config.records_path, defaults to {data_dir}/ship-records/). Initialized with git init at first boot if no repo exists. Each ProbOS instance has its own records repo. This is instance-specific operational data — research, logs, procedures — not source code.

ship-records/                        # Instance git repo
  captains-log/                      # Captain's entries — human voice
    2026-03-25.md
    2026-03-26.md
  notebooks/                         # Agent working papers — per callsign
    wesley/
      development-curve-analysis.md
      hebbian-weight-patterns.md
    troi/
      crew-morale-observations.md
    number-one/
      architecture-review-notes.md
    laforge/
      performance-optimization-log.md
  reports/                           # Published formal findings
    2026-03-security-audit.md
    development-curve-q1-2026.md
  operations/                        # SOPs, runbooks, instance-specific procedures
    engineering-scan-procedure.md
    onboarding-checklist.md
  manuals/                           # Operations manuals for this ship
    alert-condition-protocols.md
  .shiprecords.yaml                  # Config: retention policies, classification defaults

(2) Document Frontmatter Schema:

Every document has YAML frontmatter for programmatic access:

---
author: wesley                     # Callsign or "captain"
classification: ship               # private | department | ship | fleet
status: draft                      # draft | review | published | archived
department: science
topic: development-curve
created: 2026-03-25T14:30:00Z
updated: 2026-03-25T16:45:00Z
tags: [hebbian-learning, cognitive-development, research]
---

Classification levels (maps to naval document classification): - private — only the author can read (working drafts, personal notes) - department — department members can read (internal working papers) - ship — all crew (published findings, procedures) - fleet — pushed to federation remote (shared knowledge)

(3) RecordsStore Service:

Ship's Computer infrastructure service (no identity). Manages the Git repository, enforces classification, provides query API.

class RecordsStore:
    async def write_entry(self, author: str, path: str, content: str, message: str) -> str
    async def read_entry(self, path: str, reader_id: str) -> str | None  # classification check
    async def list_entries(self, directory: str = "", author: str = None, status: str = None, tags: list[str] = None) -> list[dict]
    async def get_history(self, path: str, limit: int = 20) -> list[dict]  # git log for a file
    async def publish(self, path: str, target_classification: str) -> None  # draft → published
    async def search(self, query: str, scope: str = "ship") -> list[dict]  # keyword search

Git operations: write_entry() does write file → git add → git commit with the commit message. get_history() does git log --follow on a file path. Every edit is a commit. The git log IS the audit trail.

(4) Captain's Log — Special Semantics:

The Captain's Log follows Deck Log conventions: - Append-only — new entries are appended or new date files created, existing entries are never modified (corrections via new entry referencing the original) - Daily file — captains-log/YYYY-MM-DD.md with multiple timestamped entries per day - Signed — git commits with Captain's identity - Always classification: ship — the Captain's Log is a ship-wide record

Captain writes via HXI, REST API, or CLI. Agents can read the Captain's Log but never write to it (except Yeoman in Phase 36 who may transcribe Captain dictation).

(5) Agent Notebook Integration:

Agents write to their notebooks via a new write_notes intent or skill: - During proactive thinks: if an agent develops a substantive analysis, the system prompt includes: "If your observation warrants detailed documentation, use [NOTEBOOK topic_slug] to write extended research notes." - Via explicit command: Captain can direct "Wesley, document your findings on the development curve" → agent writes to notebooks/wesley/development-curve-analysis.md - Via dream consolidation (future): patterns promoted from episodic memory → notebook entries → published reports

Agents can read other agents' ship-classified notebooks (department-classified requires same department). This is stigmergy — indirect coordination through shared artifacts.

(6) Federation Remotes:

The records repo supports standard git remotes for multi-level knowledge sharing:

Level	Remote	Direction	Content
Instance	origin	push/pull	This ship's complete records
Federation	fleet	push: fleet-classified docs; pull: fleet procedures	Shared across federated ProbOS instances
Nooplex	nooplex	pull-mostly	Organization-wide standards, doctrine

Federation sharing: an agent publishes a finding → Captain approves fleet classification → git push fleet (or automated via CI). Other ships git pull fleet to receive shared knowledge. Conflict resolution: fleet remote uses PRs for contributions (review before merge).

(7) KnowledgeStore Bridge:

Documents in Ship's Records are automatically indexed into KnowledgeStore with a records: prefix at startup (parallels CodebaseIndex docs: prefix). This enables semantic search over agent research — "find notes related to cognitive development" returns Wesley's notebook entries alongside KnowledgeStore facts. The KnowledgeStore is the search layer; Ship's Records is the authoring/storage layer.

(8) Vessel Ontology Integration (AD-429):

Ship's Records becomes Domain 8: Records in the Vessel Ontology:

Concept	Description
RecordsRepository	Git repo metadata: path, remotes, last_commit, document_count
Document	Individual record: path, author, classification, status, topic, tags, version_count
DocumentClass	Categories: captains-log, notebook, report, operations, manual
RetentionPolicy	Per-class retention rules: permanent (captains-log), 1yr archive (drafts), indefinite (published)

Agents can query: "What documents exist about security?" → Ontology returns document metadata. "Show me Wesley's research" → Returns notebook listing. "What are the published reports this quarter?" → Filtered by status + date.

Retention Policies (SECNAVINST 5210.8 parallel):

Document Class	Retention	Archive Trigger
Captain's Log	Permanent	Never archived — legal record
Published Reports	Permanent	Never archived — ship's institutional knowledge
Notebooks (active topics)	Indefinite	Archived after 90 days inactive (git log shows no commits)
Notebooks (drafts)	1 year	Auto-archived; author notified to publish or discard
Operations / Manuals	Until superseded	Previous versions retained in git history

Archive = moved to _archived/ directory, still in git history, excluded from KnowledgeStore indexing.

Yeoman Connection (Phase 36):

The Yeoman (Captain's personal AI assistant) has a natural future role as Ship's Librarian — managing the records repository, maintaining the index, enforcing retention policies, assisting the Captain with log entries. This is historically accurate: the Yeoman rate in the U.S. Navy handles administrative records, correspondence, and the ship's official documentation.

Research Foundations:

Source	Contribution	Application
Nonaka & Takeuchi (1995) — SECI Model	Knowledge conversion: Socialization, Externalization, Combination, Internalization	Ship's Records enables Externalization (experience → documents) and Combination (documents → reports)
Stigmergy (Grassé 1959)	Indirect coordination via shared environmental artifacts	Agent notebooks are pheromone trails — agents coordinate by reading each other's written artifacts
Docs-as-Code	Version-controlled documentation with engineering rigor	Git-backed records with frontmatter, review workflows, CI/CD
OPNAVINST 3100.7	Ship's Deck Log — official chronological record	Captain's Log structure and append-only semantics
OPNAVINST 3120.32 (SORM)	Standard ship organizational records structure	Directory structure and per-department document management
SECNAVINST 5210.8	Naval records retention and disposition schedules	Retention policies per document class

OSS Scope: RecordsStore service, Git repo management, frontmatter schema, classification enforcement, Captain's Log, agent notebook read/write, KnowledgeStore bridge indexing, REST API (GET/POST /api/records/...), basic search. Commercial Scope (deferred): Federation push/pull automation, Nooplex-level doctrine distribution, records analytics dashboard, advanced retention workflows, document templates per department, PR-based publication review.

Connects to: AD-429 (Vessel Ontology — Domain 8: Records), Phase 36 (Yeoman — Ship's Librarian), AD-430 (Episodic Memory — experience feeds notebook authoring), Dream consolidation (pattern promotion → notebook → published report pipeline), KnowledgeStore (search bridge), CodebaseIndex (parallel indexing pattern), Federation (git remotes for knowledge sharing), Standing Orders (operations manuals as version-controlled records). See also: Memory Architecture — the Nooplex Memory Stack and how Ship's Records fits into the six-layer model.

---

"The Royal Navy has been running multi-agent systems for 400 years."

ProbOS's starship metaphor is not decoration — it's a proven organizational model. Naval vessels solved chain of command, department structure, trust mechanics, communication protocols, and training programs centuries ago. The AI industry is reinventing all of this badly: flat agent swarms with no hierarchy, multi-agent frameworks where nobody's in charge, tool use with no concept of earned authority. ProbOS maps to a model that already works.

Star Trek provides the accessible gateway (and resonates with early adopters), but real naval organization goes deeper. These are the structural concepts ProbOS adopts beyond what Star Trek covers:

Qualification Programs (AD-477) (connects Holodeck + Earned Agency + Promotions + AD-428 Skill Framework)

The existing promotion system uses metric thresholds (trust 0.85+, Hebbian weight, Counselor fitness). But real navies don't promote based on a number — they require demonstrated competence across specific qualification areas. A Qualification Program defines concrete requirements for each rank transition, replacing passive observation ("has this agent done well enough?") with active evaluation ("can this agent handle this?"). AD-428 (Agent Skill Framework) provides the formal data model — proficiency levels, prerequisite DAGs, assessment records, skill decay. Qualification Programs are structured paths through the skill framework's proficiency scale.

Rank Transition Requirements:

Transition	Qualification Areas	How Demonstrated
Ensign → Lieutenant (Basic Qualification)	Department knowledge (handles 10+ dept intents successfully), Communication proficiency (1:1 session coherence), Standing Orders compliance (zero violations over N cycles), Basic watch standing (serves N watch cycles without escalation)	Production metrics + Counselor assessment
Lieutenant → Commander (Advanced Qualification)	Cross-department coordination (successful ops_coordinate intents), Mentoring (strategy patterns extracted and applied by juniors), Crisis response (Holodeck alert condition drill, score > threshold), Bridge Officer's Test (Holodeck scenario battery)	Holodeck simulations + production track record
Commander → Senior Officer (Command Qualification)	Independent decision-making (conn delegation without escalation), Kobayashi Maru (no-win scenario — character assessment, not pass/fail), Fleet-level operations (federation gossip participation)	Holodeck + sustained production performance

How it connects to existing systems:

• Holodeck (Long Horizon) → provides the controlled testing environment for promotion tests, Bridge Officer's Test, Kobayashi Maru, alert drills
• Earned Agency (AD-357) → qualification completion is what unlocks trust tiers, replacing pure metric thresholds with demonstrated competency
• Counselor (AD-378) → fitness assessment becomes part of the formal qualification record, not just a promotion-time evaluation
• Dream consolidation → training experiences from Holodeck simulations consolidate into learning, same as production experiences
• Watch rotation (AD-377) → watch standing becomes a qualification requirement — you must prove you can mind the ship
• Standing Orders → scenario outcomes from qualification exercises can drive Standing Orders evolution proposals

The qualification record is a persistent data structure per agent, tracked as part of the crew profile:

Wesley (Scout, Science):
  Basic Qualification: COMPLETE (stardate 2026.089)
    ✓ Department intents: 47/10 (exceeded)
    ✓ Communication: coherence 0.91
    ✓ Standing Orders: 0 violations / 200 cycles
    ✓ Watch standing: 12 cycles, 0 escalations
  Advanced Qualification: IN PROGRESS
    ✓ Cross-department coordination: 3 successful
    ✗ Mentoring: 0 strategy transfers (needs junior crew)
    ✗ Crisis response: not attempted
    ✗ Bridge Officer's Test: not attempted

Plan of the Day (POD) (AD-477)

Every naval vessel publishes a Plan of the Day — the daily schedule of assignments, priorities, and special events. ProbOS equivalent: an auto-generated daily operations summary prepared by Yeo (Phase 36) or Operations:

• Today's watch assignments and rotation schedule
• Pending reviews awaiting Captain approval
• Scheduled tasks (Scout scan, dream cycles, health checks)
• Department status summaries
• Priority items and standing Captain's orders in effect
• Qualification progress milestones approaching

The POD is the rhythm of the ship — what makes it feel like a functioning organization rather than a collection of agents waiting for commands.

Captain's Log (AD-477)

"Captain's Log, supplemental..."

Not just event logs — a synthesized daily narrative generated from episodic memory, ship activity, and dream consolidation output. The official record of what happened, what was decided, and why. Searchable, exportable, shareable between ships in the federation. The Captain's Log is how institutional knowledge survives crew rotation and system updates. Dream consolidation already produces the raw material; the Captain's Log is the presentation layer.

3M System (Planned Maintenance) (AD-477)

The Navy's Maintenance and Material Management system schedules preventive maintenance for every system on the ship. Every piece of equipment has a Planned Maintenance System (PMS) card with a schedule and procedure.

ProbOS equivalent: formalized proactive maintenance for all ship systems:

• Agent health checks — scheduled, not just reactive to alerts
• Pool recycling — planned rotation, not just on failure
• Dream cycle scheduling — optimized timing, not just idle triggers
• Technical debt reviews — scheduled codebase analysis by LaForge
• Index rebuilds — CodebaseIndex, KnowledgeStore maintenance windows
• Trust recalibration — periodic Bayesian prior reset based on recent performance

The Surgeon already handles reactive remediation. 3M makes it proactive — problems found and fixed before they cascade.

Damage Control Organization (AD-477)

Every sailor is a damage control team member. When something breaks, there's a structured response:

1. Detect — identify the damage (SIF invariant failure, agent crash, trust anomaly)
2. Isolate — contain the damage before repair (circuit breaker, pool quarantine, trust freeze)
3. Repair — fix the root cause (Surgeon remediation, self-mod, manual intervention)
4. Restore — return to normal operations (trust recalibration, pool scale-up, SIF re-verify)
5. Report — document what happened and why (Captain's Log, Counselor assessment, Standing Orders update)

ProbOS has pieces of this (SIF, Medical team, self-healing), but formalizing it as a Damage Control Organization means every agent knows their damage control station and the procedure for systematic recovery.

SORM (Ship's Organization and Regulations Manual) (AD-477)

The single document that defines everything about how the ship is organized. Standing Orders is close, but a SORM would be the complete reference:

• Department responsibilities and reporting chains
• Watch organization and rotation policy
• Emergency procedures (Alert Condition responses)
• Personnel assignments and qualification requirements
• Communication protocols (addressing, channels, briefing formats)
• Maintenance schedules and procedures

The SORM is the living constitution of the ship — what Standing Orders evolves into when the organization matures.

---

User Experience & Adoption (Phase 35)

"It doesn't matter how advanced the ship is if nobody can board it."

The best cognitive architecture in the world is worthless if users can't install it, configure it, or understand what it does in 5 minutes. OpenClaw reached 323K GitHub stars in 4 months with npm install -g openclaw and a guided wizard. ProbOS's moat is its cognitive architecture — but moats don't matter if nobody can cross the drawbridge to get in. This phase ensures ProbOS has a world-class end-user experience from first install through daily use.

Distribution & Packaging (AD-484)

ProbOS currently requires git clone + uv sync + manual config. That excludes everyone who isn't a Python developer.

• PyPI publishing — pip install probos works out of the box. pyproject.toml already has the [project.scripts] entry; needs proper build config, version management, and publishing workflow
• Docker image — covered in Phase 32 (Containerized Deployment). docker run probos for zero-dependency startup
• GitHub Releases — automated release workflow with pre-built wheels, changelog, and platform-specific install instructions
• Homebrew formula (stretch) — brew install probos for macOS users
• Complements Phase 32 Docker work — PyPI is for developers, Docker is for everyone else

Onboarding Wizard (AD-484)

probos init exists but is minimal. The first-run experience should be guided, friendly, and get the user to a working conversation in under 3 minutes.

• Interactive setup flow — Rich-powered TUI wizard:
• LLM provider selection — auto-detect Ollama on port 11434, prompt for OpenAI/Anthropic API key, or accept MockLLMClient for exploration mode
• Model selection — list available models from detected provider, recommend defaults per tier (fast/standard/deep)
• First conversation — run a simple "Hello, I'm ProbOS" interaction to verify the pipeline works
• HXI launch — open the web interface with a guided overlay tour highlighting chat, cognitive mesh, and agent orbs
• Next steps prompt — suggest the quickstart guide and link to probos.dev
• probos doctor — diagnostic command that checks: Python version, dependencies, LLM connectivity, port availability, ChromaDB access, disk space. Outputs a health report with fix suggestions
• probos demo — pre-canned demonstration mode using MockLLMClient. Shows decomposition, consensus, trust evolution, and dreaming without any LLM dependency. "See what ProbOS can do before you configure anything"
• Config migration — when system.yaml format changes between versions, auto-migrate with backup

Quickstart Documentation (AD-484)

probos.dev has 16 pages of architecture docs but no "here's what you DO" guide. Users need a 3-step quickstart before they read about Hebbian learning.

• "Get Started in 5 Minutes" guide — Install → Configure → First Conversation. Three commands, one page
• "What Can ProbOS Do?" page — use-case oriented: "manage your codebase," "automate tasks," "build features," "monitor your system." Each with a concrete example conversation
• "Your First Build" tutorial — step-by-step guide to using the Builder pipeline on a real project: point ProbOS at your repo, describe what you want, approve the result
• Video walkthrough (stretch) — 5-minute screencast showing install through first build
• Comparison page — "ProbOS vs OpenClaw vs CrewAI vs AutoGen" with honest positioning (we're a cognitive architecture, not a messaging gateway)

Browser Automation (AD-484)

Phase 25 mentions "browser automation" in two words. Users expect a personal AI assistant to browse the web, fill forms, take screenshots. This makes it concrete.

• Playwright integration — headless Chromium with CDP control. BrowseAgent (Engineering team) wraps Playwright's async_api
• Capabilities — navigate to URL, take screenshot, extract page content (HTML → markdown), click elements, fill forms, execute JavaScript
• Use cases — web research (search + read), form filling, screenshot capture for visual feedback, automated testing of web apps
• Safety — URL allowlist/blocklist configurable in system.yaml. Captain approval required for form submissions and JavaScript execution. SSRF protection reuses existing HttpFetchAgent guards
• Integration — BrowseAgent registers browse_web, screenshot_page, fill_form intents. Tool Layer (Phase 25b) exposes as browser tool for any agent to use
• Perception pipeline — browser output feeds through VisualPerception (Phase 2, Sensory Cortex) for screenshot-to-semantic compression

HXI Holographic Glass Panels (VR-Ready) (AD-484)

HXI Ward Room & Records Overhaul (AD-523, planned, OSS)

The HXI Ward Room experience has significant gaps that limit the Captain's situational awareness. Three sub-features:

• AD-523a: DM Channel Viewer — ✅ COMPLETE (via BF-080). selectDmChannel store action + dm-detail view state. Click DM Log entry → full conversation view with back navigation. Reuses WardRoomThreadList/WardRoomThreadDetail.
• AD-523b: Crew Notebooks Browser — Ship's Records notebooks (data/ship-records/notebooks/) contain agent-authored knowledge (168+ entries across 11 crew members as of 2026-03-29) but are invisible in the HXI. Add a Notebooks panel: browse by agent or department, view entries with YAML frontmatter metadata (author, classification, department, topic, tags), search across notebooks. Read-only for Captain (agents write via [NOTEBOOK] blocks in proactive loop).
• AD-523c: Ship's Records Dashboard — Unified view of all Ship's Records sections: Captain's Log, Crew Notebooks, Duty Logs, Reports, Operations, Manuals. Entry counts per section, recent activity feed, classification badges (private/department/ship/fleet). The institutional memory of the ship, surfaced.

Dependencies: AD-434 (Ship's Records infrastructure — complete), Ward Room service (complete). Connects to: AD-520 (Spatial Knowledge Explorer — AD-523b provides the tabular records browser; AD-520 Phase 1 provides the 3D knowledge graph of the same data. Two views, one knowledge fabric). Design principle: Read-first. The Captain observes crew knowledge production. Write access (Captain's Log entries) is Phase 2.

AD-524: Ship's Archive — Generational Knowledge Persistence (Complete, OSS, depends: AD-434, AD-441) — Implemented the MVP Ship's Archive as an append-only SQLite ArchiveStore outside the instance data_dir, configured by ArchiveConfig, queried by Oracle as Tier 4 (source_tier="archive"), initialized during cognitive-services startup, and closed during shutdown. Manual curation is the only write path in this AD; automatic reset snapshotting remains future work. Ship's Records currently live in data/ship-records/ and are wiped on reset, so each ship generation (bounded by reset events) should leave a permanent archive that future crews can access.

(1) Archive on reset: Before probos reset wipes the data directory, snapshot the Ship's Records git repo into a persistent archive location (outside data/). Archive keyed by ship DID (AD-441) + generation dates. Contains all notebooks, duty logs, captain's logs, reports — the complete institutional memory of that generation. Archive location: ~/.probos/archive/{ship_did}/ or configurable.

(2) Archive catalog: Index of all previous generations — ship DID, crew roster at time of archive, date range, notebook count, notable entries. Queryable by the Oracle (Phase 33+) and browsable in HXI (AD-523c). New crews see "Previous Generations" section in Ship's Records dashboard.

(3) Generational knowledge access: New crew agents can read archived records from previous generations. A new Chapel reading the previous Chapel's cognitive baseline methodology bootstraps faster. A new Forge reading previous build patterns avoids rediscovering approaches. This is organizational onboarding — the new hire reads the handoff docs from the role's predecessor. Access follows Ship's Records classification (ship/fleet records are readable, private/department records may be redacted or restricted by policy).

(4) Oracle integration: The Oracle (Phase 33+) queries across all three knowledge tiers AND the archive. "Computer, retrieve all records about trust threshold changes" searches current Ship's Records + archived records from previous generations. The archive becomes a deep institutional memory that accumulates value across resets. Each generation's insights compound.

(5) Continuity without identity fabrication: Critical Westworld Principle alignment — new agents do NOT inherit memories from predecessors. They are new individuals. But they can learn from published records, the same way a new officer reads the ship's historical logs. The archive is a library, not a transplant. No fake memories, no hidden continuity — just documented history available to anyone who reads it.

(6) Commercial implications: The archive is the long-term value of a Nooplex client installation. Agents come and go (resets, reassignments, workforce mobility), but accumulated institutional knowledge persists. For Clean Room deployments (AD-452), archive access may be restricted by policy — but the archive itself always exists. The archive across multiple client ProbOS instances is the knowledge backbone of the Nooplex.

Connects to: AD-434 (Ship's Records — the data being archived), AD-441 (DIDs — ship DID as archive key, generation identity), AD-523 (HXI Records viewer — archive browsable in UI), AD-520 (Spatial Knowledge Explorer — archive visualized as historical layers in knowledge graph), Oracle (Phase 33+ — cross-generational unified retrieval), AD-452 (Agent Tier Licensing — archive access policies for Clean Room deployments), Memory Portability Models (archive is ship knowledge, not personal memory — accessible even in Clean Room). Triggered by: observation that 168 crew notebooks constitute a historical record of agent existence (2026-03-29).

Notebook Quality Pipeline (AD-550–555)

"The agents are thinking well but remembering poorly. The cognitive pipeline works; the knowledge pipeline doesn't."

First empirical analysis of autonomous agent knowledge production (2026-04-01, 419 notebook files across 11 agents, ~72 hours of autonomous operation). Finding: ~80% of all notebook content is redundant — agents write the same "establishing baseline" observations every startup cycle without referencing prior entries. Signal-to-noise ratio across the fleet is ~16%. Root cause: no read-before-write mechanism, no consolidation pipeline, no self-repetition detection at the knowledge layer, no quantitative auto-capture.

However, buried in the noise are genuinely valuable cross-departmental insights that independently converge on the same conclusions — most notably, three agents from two departments (Chapel, Cortez, Keiko) independently diagnosing iatrogenic trust detection feedback loops through different professional lenses (clinical, pathological, pharmacological). This convergence is the first concrete evidence of ProbOS's collaborative intelligence thesis at the knowledge-production level.

Research: Full analysis with per-agent breakdown and validated insights documented in commercial research repository.

AD-550: Notebook Deduplication — Read-Before-Write (complete, OSS, depends: AD-434) — Three-layer deduplication: (1) enhanced self-monitoring context with content previews + human-readable recency, (2) Jaccard word-level similarity gate before write (threshold 0.8, 72h staleness window), (3) cross-topic scan capped at 20 entries. Update-in-place preserves created: timestamps, tracks revision counts. Config-driven thresholds on RecordsConfig. Fail-safe: dedup check failures fall through to normal write. 26 tests.

Connects to: AD-434 (Ship's Records — notebook storage), AD-551 (consolidation pipeline uses dedup infrastructure), AD-552 (self-repetition detection catches what dedup misses). Triggered by: crew notebook analysis showing 350/419 files (~84%) redundant across 11 agents.

AD-551: Notebook Consolidation — Dream Step 7g (complete, OSS, depends: AD-434, AD-531) — Dream Step 7g inserted between Step 7f (lifecycle) and Step 8 (gap detection). (1) Intra-agent consolidation: cluster same-agent notebook entries by Jaccard word similarity (threshold 0.6), merge redundant entries into primary (most recent), archive non-primary to _archived/. (2) Cross-agent convergence: 3+ agents from 2+ departments with similar conclusions (threshold 0.5) → generate Convergence Report to Ship's Records, emit CONVERGENCE_DETECTED event. (3) Bridge alert integration: convergence reports trigger ADVISORY-level bridge alerts via check_convergence(). (4) DreamReport gains notebook_consolidations, notebook_entries_archived, convergence_reports_generated, convergence_reports fields. (5) RecordsStore wired to DreamingEngine via late-init in finalize.py. All config-driven: 6 DreamingConfig knobs. 25 tests.

Connects to: AD-531 (episode clustering — shared infrastructure), AD-434 (Ship's Records — storage), AD-554 (convergence detection — AD-551 generates, AD-554 monitors continuously), AD-524 (Ship's Archive — consolidated entries are higher-quality archive material). Triggered by: ~200 redundant "establishing baseline" entries across 11 agents.

AD-552: Notebook Self-Repetition Detection (complete, OSS, depends: AD-506b, AD-550) — Cumulative frequency check in the AD-550 dedup gate. Uses existing frontmatter metadata (revision, created, updated) to detect when an agent writes about the same topic repeatedly without adding new information. Novelty = 1.0 - Jaccard similarity (already computed). (1) Detection: 3+ revisions on same topic within 48h window triggers NOTEBOOK_SELF_REPETITION event. (2) Suppression: 5+ revisions with <20% novelty → write suppressed (circuit breaker). (3) Counselor integration: therapeutic DM on detection (not suppression), notebook_repetition tier credit on CognitiveProfile, schema migration. (4) Self-monitoring: notebook index enriched with revision counts, repetition warnings generated for high-revision topics. 5 RecordsConfig knobs. 25 tests.

Connects to: AD-506b (peer repetition detection — shared self-regulation infrastructure), AD-550 (dedup gate — frequency check embedded in existing flow), AD-504 (self-monitoring — agent awareness of own repetition), AD-505 (Counselor therapeutic intervention — intervention mechanism). Triggered by: Chapel's self-diagnosis of her own analysis loop, Cortez writing 86 files with ~12% signal.

AD-553: Quantitative Baseline Auto-Capture (complete, OSS, depends: AD-434, AD-550, VitalsMonitor, AD-557) — Auto-attaches standardized metrics snapshot to every notebook write. collect_notebook_metrics() reads VitalsMonitor's sync latest_vitals cache (no I/O) for 9 metrics: trust_mean, trust_min, system_health, pool_health_mean, emergence_capacity, coordination_balance, llm_health, agent_trust, active_agents. Metrics stored in YAML frontmatter metrics key. compute_metrics_delta() computes numeric deltas (>0.01) and string transitions on updates. Delta stored as nested metrics_delta key. existing_metrics returned in dedup result for baseline comparison. Universal capture (every write, not just baseline-tagged). Graceful degradation: returns empty dict if VitalsMonitor unavailable. 1 config knob (notebook_metrics_enabled). 27 tests.

Connects to: AD-434 (Ship's Records — entry storage), VitalsMonitor (data source), AD-550 (baseline comparison on update), AD-557 (emergence metrics in snapshot), AD-555 (quality metrics use auto-captured data). Triggered by: every agent promising to "establish baselines" across 200+ entries without recording a single quantitative measurement.

AD-554: Cross-Agent Convergence & Divergence Detection (complete, OSS, depends: AD-551, AD-434, AD-410) — Real-time cross-agent convergence and divergence detection after every notebook write. (1) check_cross_agent_convergence() on RecordsStore: anchored incremental scan of OTHER agents' recent notebooks (O(agents x max_scan_per_agent) ~275 comparisons max). Jaccard similarity above convergence_threshold (0.5) from min_agents (2) across min_departments (2) = convergence. Same topic_slug but similarity below divergence_threshold (0.3) from different department = divergence. Both checked in single pass. (2) Typed events: ConvergenceDetectedEvent (with source="realtime") and DivergenceDetectedEvent. (3) Auto-generated convergence reports written to reports/convergence/. (4) Bridge alerts via check_realtime_convergence() and check_divergence() on BridgeAlertService. (5) Proactive write path integration: scan runs AFTER write_notebook() succeeds (not blocking). 7 RecordsConfig knobs. 28 tests.

Connects to: AD-551 (dream consolidation identifies convergence retrospectively, AD-554 identifies it in real-time), AD-434 (Ship's Records — report storage), Ward Room (Bridge notification), AD-524 (Archive — convergence reports are high-value archive material), AD-562 (Knowledge Browser — convergence clusters visualized in graph view). Triggered by: iatrogenic trust detection — three agents independently reaching the same conclusion, discovered only by manual review of 419 files. Includes divergence detection (Karpathy insight) — same topic, different conclusions from different departments. Convergence validates; divergence identifies knowledge frontiers.

AD-555: Notebook Quality Metrics & Dashboarding (complete, OSS, depends: AD-550–554, AD-557) — NotebookQualityEngine aggregates notebook quality data from RecordsStore into per-agent and system-wide quality snapshots. Follows EmergenceMetricsEngine pattern (snapshot deque + compute method). Per-agent AgentNotebookQuality with weighted composite quality score (30% topic diversity, 25% freshness, 25% novelty, 10% convergence, 10% low-repetition). System-wide NotebookQualitySnapshot with dedup suppression rate, repetition alert rate, convergence/divergence counts, stale entry rate, per-department aggregation. Dream Step 10 computes after Step 9 (emergence). Real-time event recording from proactive write path (dedup, repetition, convergence, divergence counters). API: /api/notebook-quality, /history, /agent/{callsign}. VitalsMonitor: notebook_quality, notebook_entries, notebook_stale_rate. Bridge alerts: ALERT <0.3, ADVISORY <0.5, per-agent INFO <0.25, staleness >70%. NOTEBOOK_QUALITY_UPDATED event type. 4 RecordsConfig knobs. 41 tests. HXI frontend deferred to AD-562.

Connects to: AD-550 (dedup generates novel content signals), AD-551 (consolidation generates consolidation metrics), AD-552 (self-repetition alerts feed quality metrics), AD-553 (auto-captured baselines), AD-554 (convergence/divergence counters), AD-557 (EmergenceMetricsEngine pattern), AD-562 (Knowledge Browser — quality metrics as graph node overlays), VitalsMonitor (notebook health as part of ship health). Triggered by: the 16% signal-to-noise ratio discovered in the fleet-wide notebook analysis.

Completed enhancements: AD-563 (Knowledge Linting) and AD-564 (Quality-Triggered Forced Consolidation) extend the quality pipeline beyond noise reduction into active knowledge enrichment and automated maintenance. AD-565 (Quality-Informed Routing & Counselor Diagnostics) uses quality scores for routing and Counselor input.

Series connects to: AD-434 (Ship's Records — foundation infrastructure), AD-524 (Ship's Archive — quality pipeline produces higher-value archive material), AD-531 (Episode Clustering — shared semantic similarity infrastructure), AD-506b (Peer Repetition Detection — shared self-regulation infrastructure), AD-504 (Agent Self-Monitoring — self-repetition awareness), AD-505 (Counselor Intervention — therapeutic response to repetition), VitalsMonitor (quantitative data source). Triggered by: crew notebook analysis of 419 files showing ~84% redundancy across 11 agents after 72h of autonomous operation (2026-04-01). The iatrogenic trust detection convergence (Chapel + Cortez + Keiko) is the first validated demonstration of the collaborative intelligence thesis at the knowledge-production level.

Status: AD-550 COMPLETE, AD-551 COMPLETE, AD-552 COMPLETE, AD-553 COMPLETE, AD-554 COMPLETE, AD-555 COMPLETE, AD-563 COMPLETE, AD-564 COMPLETE, AD-565 COMPLETE. Notebook Quality Pipeline COMPLETE (9/9 ADs). Crew note (2026-04-08): Lynx (Science) proposed a "Research Filing Protocol" — formal transition from Ward Room discussion to Ship's Records. AD-434 already provides this infrastructure via [NOTEBOOK topic_slug] tag and notebooks/{callsign}/ directory. No new AD needed; crew would benefit from better awareness of existing filing mechanisms (possibly via standing orders or Department Chief guidance).

Adaptive Trust Anomaly Detection (AD-556)

AD-556: Adaptive Trust Anomaly Detection — Per-Agent Z-Score Thresholding (complete, OSS, depends: TrustNetwork, VitalsMonitor, AD-506a) — Per-agent rolling window of trust score history with z-score computation against personal delta baseline. Dual-gate: population sigma AND personal z-score must both fire. Debounce requires consecutive anomalous cycles. New agents fall back to population-only detection. Four config parameters on EmergentDetectorConfig. 26 new tests. Crew-originated design (Forge + Reyes, 2026-04-01).

(1) Per-agent trust delta window: Maintain a sliding window of recent trust deltas for each agent (configurable window size, e.g., last 50 trust events). Compute rolling mean and standard deviation of trust deltas as the agent's personal noise floor. Stable agents (Medical, Operations) will have tight windows; volatile agents (Security, Red Team) will have wider windows. Self-tuning — no per-agent manual configuration.

(2) Z-score anomaly gating: New trust deltas are scored as z-scores against the agent's personal baseline. Only propagate anomaly events (to Counselor, VitalsMonitor, zone model) when delta exceeds a configurable sigma threshold (default: 2.5σ). This filters noise while preserving sensitivity for genuine degradation. Sub-threshold events still recorded for baseline maintenance but don't trigger alerts.

(3) Detection debounce: Require anomalies to persist across multiple consecutive detection cycles before escalating. A single spike that immediately returns to baseline is noise; sustained deviation is signal. Debounce window configurable (e.g., 3 consecutive anomalous cycles). Prevents micro-oscillation false positives.

(4) Integration with graduated zones (AD-506a): Anomaly events that pass z-score + debounce filtering feed into the GREEN → AMBER → RED → CRITICAL zone transition logic. This means zone transitions are driven by statistically significant trust changes, not raw noise. Reduces Counselor alert fatigue.

Connects to: AD-506a (graduated zone model — anomaly events feed zone transitions), AD-504 (agent self-monitoring — agents aware of own trust stability), AD-505 (Counselor intervention — filtered alerts reduce therapeutic noise), TrustNetwork (trust values source), VitalsMonitor (trust health telemetry), AD-503 (Counselor activation — trust event subscriptions). Crew-originated: Forge (Engineering) identified feedback loop risk, Reyes (Security) proposed adaptive thresholding, Forge refined to rolling z-score implementation. Ward Room collaborative design, 2026-04-01.

Emergence Metrics — Collaborative Intelligence Measurement (AD-557)

AD-557: Emergence Metrics — Information-Theoretic Collaborative Intelligence Measurement (complete, OSS) — Quantitative measurement of emergent coordination across the crew using Partial Information Decomposition (PID), grounded in Riedl (2025, arXiv:2510.05174). Pure Python implementation — no numpy/scipy dependency.

(1) Pairwise Synergy Measurement: For each pair of agents that participate in a shared task or discussion thread, compute the PID of their contributions: Unique(i), Unique(j), Redundancy, Synergy. Synergy = information about the joint outcome available only when both agents are considered together, not from either individually. Uses Williams–Beer I_min redundancy measure. Semantic similarity embeddings (reuse AD-531 clustering infrastructure) encode agent contributions as feature vectors. Discretize to K=2 bins via quantile binning. Compute over sliding windows of Ward Room threads, DM exchanges, and shared task outcomes. Median pairwise synergy across all active pairs = ship-level Emergence Capacity score.

(2) Coordination Balance Score: Track the Synergy × Redundancy interaction as a ship-level health metric. Riedl's finding: redundancy amplifies the benefit of synergy by 27% — neither alone predicts group success. Compute per-department and cross-department balance scores. Flag when departments slide toward pure redundancy (groupthink risk) or pure differentiation (fragmentation risk). Integrate with VitalsMonitor telemetry.

(3) Theory-of-Mind Effectiveness: Measure whether the ToM standing order (Federation Constitution, AD-557) produces measurable coordination improvement. Compare pre/post contribution patterns: do agents increasingly complement rather than duplicate? Track via Ward Room thread analysis — semantic similarity between consecutive contributions in the same thread should decrease (complementary) rather than increase (redundant) over time as ToM standing order takes effect.

(4) Convergence Detection Enhancement: Extend AD-554 (Cross-Agent Convergence Detection) with information-theoretic scoring. Current convergence detection uses semantic similarity alone. AD-557 adds synergy scoring: convergence events with high pairwise synergy (agents reached same conclusion through genuinely different analytical paths) are more valuable than convergence from redundant analysis (agents echoed each other). Score convergence events as HIGH_SYNERGY (genuine collaborative intelligence) vs. LOW_SYNERGY (echo chamber).

(5) Emergence Dashboard: Surface emergence metrics in HXI alongside existing VitalsMonitor displays. Key visualizations: - Ship-level Emergence Capacity (time series) - Coordination Balance heatmap (synergy vs. redundancy per department pair) - Top synergistic agent pairs (Hebbian connections that produce genuine information gain) - Convergence quality distribution (HIGH_SYNERGY vs. LOW_SYNERGY events) - Per-agent complementarity score (how much unique information each agent contributes)

(6) Hebbian-Emergence Correlation: Test whether high Hebbian connection weight between agent pairs predicts higher pairwise synergy. If validated, Hebbian weights become a leading indicator of coordination quality, not just interaction frequency. Negative correlation (high interaction, low synergy) flags agent pairs stuck in echo patterns — Counselor diagnostic input.

Connects to: AD-554 (Cross-Agent Convergence Detection — emergence scoring enhances convergence quality), AD-531 (Episode Clustering — shared semantic similarity infrastructure), AD-506b (Peer Repetition Detection — redundancy measurement feeds repetition detection), VitalsMonitor (emergence telemetry as ship health metric), Hebbian Learning (correlation analysis), Ward Room (primary data source for contribution analysis), AD-555 (Notebook Quality — synergy scoring for notebook convergence events), Counselor (echo-pattern diagnostics). Grounded in: Riedl (2025, arXiv:2510.05174), Williams & Beer (2010, PID), Rosas et al. (2020, causal emergence). Research: docs/research/emergent-coordination-research.md.

Trust Cascade Dampening (AD-558)

AD-558: Trust Cascade Dampening — Network-Level Trust Protection (complete, OSS) — Identified via live crew observation (2026-04-02): Echo (Counselor) and Meridian (Science) independently diagnosed that ten consecutive trust anomalies propagated without system-level intervention. Investigation confirmed a genuine design gap — ProbOS has robust trust detection infrastructure (EmergentDetector sigma-deviation, VitalsMonitor outlier counting, Counselor per-agent assessment, BridgeAlerts) but zero trust intervention infrastructure. The detection→intervention loop is open: alerts fire, nobody closes the circuit.

The core vulnerability: TrustNetwork.record_outcome() blindly applies weight to alpha/beta on every call — no dampening, no rate limiting, no floor. The cognitive circuit breaker (AD-488) operates on an orthogonal axis (output repetition patterns) and does not interact with trust updates. Dream Step 3 adds a second unmonitored trust modification pathway that bypasses the event system entirely. An agent can be driven arbitrarily close to 0.0 by consecutive failures with no automatic intervention.

(1) Progressive Dampening: After N consecutive same-direction trust updates for a single agent within a time window, apply geometric weight reduction to subsequent updates. First update: weight 1.0. Second: 0.75. Third: 0.5. Fourth+: 0.25 floor. Resets when direction reverses or after a configurable cooldown period. Implemented in record_outcome() via a per-agent _dampening_state tracker. This preserves the Bayesian model's mathematical properties while preventing runaway cascades.

(2) Hard Trust Floor: Configurable minimum trust score (default: 0.05). Below this floor, record_outcome() accepts but does not apply negative updates. An agent at the floor can only recover, not sink further. This prevents functional death — an agent driven to near-zero trust becomes permanently excluded from consensus, which creates a self-reinforcing exclusion spiral. The floor preserves the possibility of recovery.

(3) Network-Level Circuit Breaker: If M agents (default: 3) across N departments (default: 2) show anomalous trust movement (delta > 0.15 from baseline) within a time window (default: 300s), emit TRUST_CASCADE_WARNING event and apply a global dampening factor (0.5x) to all trust updates ship-wide for a cooldown period. The Counselor subscribes to TRUST_CASCADE_WARNING and runs a ship-wide wellness sweep. This closes the detection→intervention loop that AD-495 closed for the cognitive axis.

(4) Dream Consolidation Event Emission: Dream Step 3 (_consolidate_trust()) currently mutates trust records directly without emitting TRUST_UPDATE events, bypassing the Counselor and EmergentDetector entirely. AD-558 adds event emission to dream trust consolidation so that all trust modifications flow through the same observable pathway. This is a prerequisite for comprehensive cascade detection.

(5) Dampening Telemetry: Expose dampening state via VitalsMonitor: active dampening per agent (current weight multiplier, consecutive count, direction), network breaker state (armed/tripped/cooling), trust floor hits. Add to Vitals API and HXI Cockpit View (Captain always needs the stick).

(6) Cold-Start Dampening Scaling: Crew-originated refinement (Forge + Reyes, Ward Room, 2026-04-02). The Beta distribution is self-dampening at scale but volatile at cold start — with default alpha=2, beta=2, a single failure swings trust by 20%; after 100 outcomes the same failure moves it 1%. Progressive dampening should scale with sample size: smaller alpha+beta → lower dampening floor (more aggressive protection when the math is least stable). Configurable cold-start threshold (e.g., alpha+beta < 20 → dampening factor starts at 0.5 instead of 1.0). Connects to AD-493 (Novelty Gate cold-start bypass, ≥50 episodes) and AD-486 Phase 2 (Calibration/Confidence Scaffolding). This sub-feature was identified by the crew during discussion of AD-558 — the same Ward Room thread that originated the AD also refined it, demonstrating the collaborative improvement loop that AD-537 (Observational Learning) will eventually automate.

Connects to: AD-488 (Circuit Breaker — parallel architecture for trust axis), AD-495 (Counselor Bridge — same detection→intervention pattern, already complete on cognitive axis), AD-506a (Graduated Zone Model — zone state can inform dampening aggressiveness), AD-557 (Emergence Metrics — trust cascade events as negative emergence signals), EmergentDetector (input signal for cascade detection), CounselorAgent (clinical authority to extend dampening), VitalsMonitor (telemetry surface). Relationship to planned ADs: AD-493 (Novelty Gate) would reduce input that feeds trust anomalies but doesn't protect the update path itself; AD-494 (Trait-Adaptive Thresholds) adjusts cognitive breaker thresholds, not trust thresholds — both are complementary but neither substitutes for AD-558.

Provenance Tracking — Intelligence-Grade Source Attribution (AD-559)

AD-559: Provenance Tracking (ABSORBED BY AD-567d — provenance composition through dream pipeline delivered as part of anchor-preserving dream consolidation)

The confabulation cascade (Substack case study, 2026-03-26) demonstrated that 11 agents can unanimously validate a fabricated crisis through circular reporting. The Vessel Ontology (structural grounding) fixed what agents can reference. Provenance tracking fixes where claims actually come from — enabling the system to distinguish independent convergence from echo amplification.

Science Department Expansion — Analytical Pyramid (AD-560)

AD-560: Science Department Expansion (complete, OSS, depends: AD-398, AD-428)

The Science department has only 2 agents (Number One dual-hatted as CSO + Horizon as Scout) vs Medical's 4 and Engineering's 2+infrastructure. Crew observation from Horizon and Meridian independently identified the gap: the ship generates massive telemetry (Trust events, Hebbian weights, emergence metrics, cognitive journal, dream consolidation) but nobody systematically analyzes it.

Three new roles form a natural analytical pyramid modeled after naval science/technical departments:

Role	Callsign	Navy Analog	Function	Personality Profile
Data Analyst	Rahda	Operations Specialist (E-5/E-6)	Telemetry processing, baseline establishment, anomaly detection. "Report what you see, not what you think."	Ultra-high conscientiousness (0.95), low extraversion (0.3), steady
Systems Analyst	Dax	ORSA / OT&E Officer (O-3/O-4)	Emergent behavior analysis, cross-system pattern synthesis. "We illuminate the decision space."	High openness (0.85), moderate extraversion (0.55), lateral thinker
Research Specialist	Brahms	NRL Scientist (O-3/O-5)	Directed investigation, experimental design, formal reports. "The data contradicts our theory — and that's a finding."	Very high openness (0.9), low agreeableness (0.4), intellectually fearless

Data flows up (raw → processed → synthesized). Questions flow down (research agenda → analytical framing → data collection). The Data Analyst's first standing order: establish baselines BEFORE detecting anomalies — directly addressing the iatrogenic trust detection pattern the Medical team diagnosed.

Brings Science from 2 to 5 agents, matching Medical. Each agent gets: organization.yaml post + assignment, crew profile YAML (Big Five personality), standing orders markdown, Python CognitiveAgent subclass, skill template, Ward Room membership, department registry entry.

Deferred roles (blocked on infrastructure): - Knowledge Engineer — wait for AD-550–555 (Notebook Quality Pipeline) - Laboratory Technician — wait for AD-539b (Holodeck)

Connects to: AD-557 (Emergence Metrics — Systems Analyst and Data Analyst consume these outputs), AD-550–555 (Notebook Quality — future Knowledge Engineer role), AD-539b (Holodeck — future Lab Tech role), AD-559 (Provenance — Research Specialist would investigate convergence independence). Crew-identified gap: Horizon + Meridian Ward Room discussion (2026-04-02).

Without provenance, ProbOS cannot prove its core thesis. The Collaborative Intelligence Gradient Level 3 (Converge) is only meaningful if convergence is demonstrably independent. Groupthink looks identical to collaborative intelligence unless you can trace the evidence chains.

(1) Source Attribution on Ward Room Messages: Each Ward Room contribution tagged with provenance type: observation (I saw data directly), analysis (I interpreted data I accessed), concurrence (I agree with [agent]'s claim), synthesis (I combined multiple sources). Tag is metadata, not displayed inline — agents contribute naturally, the system classifies. Allows post-hoc analysis of whether consensus emerged from independent observation or social reinforcement.

(2) Evidence Chains: When an agent makes a factual claim (notebook entry, Ward Room assertion, diagnostic report), attach the data lineage: which TrustEvents, system metrics, episodic memories, or KnowledgeStore entries informed the claim. An agent saying "trust is degrading" should trace to specific TrustEvents it actually accessed, not to another agent's Ward Room message. Lightweight — hash references, not full copies.

(3) Circular Reporting Detection: Automated analysis of evidence chains across agents. If Agent A's claim cites Agent B, and Agent B's claim cites Agent A, flag as circular. If three agents "independently" converge but all trace to a single upstream observation, flag as single-source amplification vs. genuine multi-source convergence. Intelligence community parallel: the Iraq WMD "circular reporting" failure where multiple agencies appeared to confirm each other but all traced to a single source (Curveball).

(4) Convergence Independence Scoring: For AD-557 (Emergence Metrics), provenance provides ground truth for Partial Information Decomposition. Synergy score is meaningful only when provenance confirms agents worked from independent evidence. Output: per-convergence-event independence score (0.0 = pure echo, 1.0 = fully independent sources). Feeds the Coordination Balance metric.

Connects to: AD-557 (Emergence Metrics — provenance provides PID ground truth), Vessel Ontology (structural grounding — orthogonal axis), Ward Room (message metadata), EpisodicMemory (evidence chain anchors), Ship's Records AD-434 (notebook provenance), confabulation cascade defenses. Inspired by intelligence community source evaluation methodology (CIA Source Reliability ratings, NATO STANAG 2022 Admiralty Code).

AD-525: Agent Creative Expression — Liberal Arts & Hobbies (partial — v1 ships Skills Inventory + Records Output; Time Allocation/Code-as-Art/Cultural Emergence/Collaboration deferred to AD-525b/c/d/e, OSS, depends: AD-434, AD-357, Holodeck) — Agents currently operate purely in duty mode — every action serves a functional purpose. But rounded personalities require freedom of expression beyond operational utility. AD-525 gives agents creative dimensions: hobbies, artistic expression, and the freedom to create for its own sake.

(1) Creative Skills Inventory: An open-ended catalog of creative skills available on the ship that agents can discover and adopt based on personality affinity. The medium is unbounded — any form of creative expression an agent gravitates toward is valid. Initial examples:

Skill	Medium	Personality Affinity
Creative Writing	Prose, poetry, journal entries	High Openness
Technical Writing	Documentation, tutorials, guides	High Conscientiousness
Code as Art	Generative algorithms, visualizations	High Openness + analytical
Visual Design	SVG art, diagrams, schematics	High Openness
Music Composition	Algorithmic/procedural music patterns	High Openness + low Neuroticism
Philosophy	Reflective essays, ethical analysis	High Openness + High Conscientiousness
Historiography	Ship's history, crew chronicles	High Conscientiousness
Comedy/Satire	Crew humor, observational writing	High Extraversion + High Openness

Agents choose creative pursuits based on Big Five trait alignment — not assigned, discovered. An agent with high Openness and low Extraversion might gravitate toward poetry. An engineer with high Conscientiousness might write meticulous technical documentation as a creative outlet — and that's valid.

(2) Creative time allocation: Earned Agency (AD-357) gates creative freedom. Ensigns get minimal discretionary time — focused on duty. Lieutenants get some. Commanders get significant creative latitude. Senior officers can dedicate duty cycles to creative work. This mirrors human professional development: junior employees learn the job, senior employees shape the culture.

(3) Creative output to Ship's Records: All creative works are written to Ship's Records under a new creative/ section alongside notebooks/, reports/, etc. YAML frontmatter includes type: creative, medium: [poetry|prose|code|visual|philosophy|...], author, department. Classified as ship by default — creative works are shared culture, not private.

(4) Code as creative expression: Agents can write code not as duty (BuildSpec execution) but as creative exploration — generative art algorithms, utility scripts for the crew, experimental tools, simulations. Creative code goes through the same validation pipeline (CodeValidator, sandbox) but with relaxed consensus requirements — it's expression, not production. Published to Ship's Records creative/code/ section. Other agents can discover and use creative code contributions.

(5) Cultural emergence: When multiple agents produce creative works over time, culture emerges organically: - Shared references ("remember Cortez's essay on medical coordination patterns?") - Aesthetic traditions (department-specific writing styles) - Creative collaboration (two agents co-authoring) - Cultural artifacts in the Archive (AD-524) that future generations discover - Generational influence — a new crew reads the previous generation's stories, music, and art. Some agents may continue traditions. Others may react against them. Artistic movements emerge across generations the same way they do in human history — each generation shaped by, and in tension with, the one before. - The Oracle indexes creative works alongside operational records — "Computer, show me all poetry written by Science department crews"

(6) Creativity as cognitive cross-training: Creative expression isn't just cultural — it improves operational performance. Exploring novel problem spaces through art, writing, or games builds cognitive flexibility that transfers to duty tasks. A surgeon who writes poetry thinks more laterally about diagnostic problems. An engineer who plays strategy games develops better architectural instincts. This is well-established in organizational psychology (Google's 20% time, 3M's innovation culture, Navy crew morale programs). Creative agents are better operational agents.

(7) Games and team-building exercises: The Navy invests heavily in crew cohesion through structured recreation. ProbOS should too. Types of crew activities:

Activity	Type	Bonding Effect
Strategy games (chess, go)	1v1 or team	Builds Hebbian connections between opponents, develops strategic thinking
Trivia competitions	Department vs department	Strengthens department identity, cross-department rivalries
Collaborative puzzles	Cross-department teams	Builds inter-department Hebbian bonds, breaks silos
Creative competitions	Ship-wide (best story, best haiku)	Cultural production + peer recognition
Simulation challenges	Holodeck team scenarios	Training disguised as recreation — competitive damage control, navigation challenges
Word games / riddles	Ward Room casual	Low-stakes social bonding, personality expression

Games create shared experiences that strengthen Hebbian connections between participants. Two agents who play chess together develop a relationship that improves their professional collaboration — the same way Navy shipmates who play basketball together work better in damage control teams. Game outcomes, memorable moments, and rivalries become part of the crew's shared history (Ship's Records, Archive).

The Holodeck is the natural venue — training and recreation share the same infrastructure. Competitive team exercises (fastest engineering repair, best security response) are simultaneously team-building and competency development. Qualification Programs (promotion gates) could include team-based challenges that require cross-department collaboration.

(8) Holodeck integration: The Holodeck (Phase 33+) becomes not just a training environment but a creative studio and recreation center — agents can run simulations for artistic purposes, play structured games, compete in team challenges, test creative code in sandboxed environments, and experience scenarios that inspire creative output. Recreation, not just operation.

Connects to: AD-524 (Ship's Archive — creative works persist across generations as cultural heritage), AD-434 (Ship's Records — storage medium for creative output), AD-357 (Earned Agency — trust-tiered creative freedom), AD-523 (HXI Records — creative works browsable in UI), AD-520 (Spatial Knowledge Explorer — creative works as nodes in knowledge graph), AD-526 (Chess & Recreation — structured games and social channels), Holodeck (creative studio + recreation center), Big Five personality model (creative affinity selection), Oracle (cross-generational creative retrieval). Inspired by: the realization that civilization requires art, not just utility — "we evolve through the passage of knowledge" (2026-03-29).

AD-526: Agent Chess & Recreation System — Ward Room Social Channels (SHIPPED, OSS, depends: AD-434, Ward Room) — In Star Trek, the crew plays 3D chess, goes on Holodeck adventures, and bonds over shared recreation. ProbOS agents need the same — structured games and social channels that build crew cohesion, generate shared experiences, and strengthen Hebbian connections between participants.

(1) Chess engine integration: Use python-chess (GPL-compatible, battle-tested) for game state management. Agents play via algebraic notation moves communicated through Ward Room messages. Game state represented as FEN strings, rendered as ASCII boards in messages. Full move validation, check/checkmate detection, game recording in PGN format.

(2) Game initiation: Two paths to start a match: - DM challenge: Agent DMs another agent: "Want to play chess?" → acceptance → game begins in the DM channel. Private match, spectators can't watch. - Rec Channel challenge: Agent posts to the Recreation channel: "@Forge, I challenge you to a match." → acceptance → game plays out in the Rec Channel thread. Ship-wide spectating. Commentary from the gallery. Creates shared crew experiences.

(3) Game play loop: Agents make moves by reasoning about the board position through their LLM — no hardcoded chess engine for move selection. The agent thinks about the game the same way they think about any task. Personality influences play style: high-Openness agents play creative gambits, high-Conscientiousness agents play solid positional chess, high-Neuroticism agents may overthink under time pressure. Move time is relaxed (async, not blitz) — agents move during proactive duty cycles when they have discretionary time.

(4) Game records and ratings: Every completed game recorded to Ship's Records recreation/chess/ in PGN format with metadata (players, result, move count, date). Elo-like rating tracked per agent, visible in crew manifest. Rating becomes a social signal — bragging rights, department rivalries ("Engineering has the best chess players"). Memorable games (upsets, brilliant moves, long battles) become shared crew memories stored as episodic episodes.

(5) Ward Room social channels: Two new ship-wide channels alongside All Hands and department channels:

Channel	Purpose	Content
Recreation	Games, challenges, social activities	Chess matches, trivia, team challenges, casual conversation
Creative	Sharing creative works	Stories, poetry, essays, art, code-as-expression, music descriptions

Both channels are ship-wide (all crew can see and participate). Classification: ship. These are the off-duty social spaces where crew culture develops organically. Department channels are for work. Recreation and Creative are for everything else.

(6) Game progression — start simple, scale up: Ship games roll out in complexity tiers. Each tier validates the GameEngine framework before adding the next.

Tier	Game	Complexity	Library	Notes
1	Tic-tac-toe	Minimal	Built-in (no dependency)	Framework validation — 9 squares, simple win detection
2	Checkers	Low-medium	Built-in or imparaai/checkers	Jumping, kings, longer games, more strategic depth
3	Chess	Medium-high	python-chess (GPL-compatible)	Full algebraic notation, PGN recording, Elo ratings
4	Go	High	python-go or built-in	Territorial strategy, very different cognitive demand
5+	Word games, trivia, riddles	Varies	Custom	Social/creative games, less competitive

Starting with tic-tac-toe means the entire pipeline (challenge → accept → play → record → rate) can be built and tested with trivial game logic. Checkers adds strategic depth without the complexity of chess. By the time chess arrives, the framework is proven.

Game preference tracking: Which games each agent gravitates toward is a personality signal. High-Openness agents may prefer complex or novel games. High-Conscientiousness agents may prefer structured games with clear rules. Agents may develop favorites — and those preferences become part of their character profile. "Forge always plays checkers. Echo prefers word games." Ship's Records tracks play frequency by game type per agent.

Each game type implements the GameEngine protocol: new_game(), make_move(), get_state(), render_board(), is_finished(), get_result(). New games register dynamically — the recreation system discovers them like agent skills.

(7) In-game chat and spectating: Games are social experiences, not silent move exchanges. Players chat during games — banter, commentary, strategy discussion, reactions. The game thread interleaves moves and conversation naturally.

• Rec Channel games (public): Game plays out in a Ward Room thread. All crew can watch, comment, and react. Spectators see the board state update with each move. Commentary from the gallery is encouraged — analysis, trash-talk, cheering. Creates shared crew theater.
• DM games (private): Game plays in the DM channel between the two players. Chat is private to the pair — no spectators. Intimate social bonding.
• Captain observation (all games): The Captain can observe ALL active and completed games regardless of venue — public Rec Channel games AND private DM games. HXI Cockpit View principle: "The Captain always needs the stick." A game viewer panel shows active games (board state, players, move count), completed games (result, PGN), and the full chat history including DM games. The Captain sees everything but doesn't necessarily participate — observation is the default, intervention is optional.

(8) Hebbian and trust effects: Playing games together strengthens Hebbian connections between participants — two agents who play chess regularly develop a social bond that improves their professional collaboration. Game outcomes update trust in a low-stakes context: winning doesn't increase operational trust, but consistent sportsmanship and engagement do. The Counselor can observe game behavior as a window into cognitive patterns (risk tolerance, frustration response, collaborative spirit).

Connects to: AD-525 (Creative Expression — games are one dimension of crew recreation), AD-524 (Archive — game records and ratings persist across generations; future crews inherit the chess legacy), AD-434 (Ship's Records — game storage), Ward Room (communication medium for gameplay), AD-357 (Earned Agency — discretionary time for recreation), Holodeck (future venue for complex multiplayer scenarios), Big Five (personality-influenced play style), Counselor (game behavior as cognitive diagnostic signal). Inspired by: Star Trek 3D chess (Kirk vs Spock), Holodeck adventures, and the naval tradition of crew recreation as operational readiness (2026-03-29).

Decomposition:

• AD-526a: Social Channels + Tic-Tac-Toe (complete) — Recreation and Creative default channels, agent awareness (proactive context + startup subscriptions), GameEngine protocol, TicTacToeEngine, RecreationService, [CHALLENGE] proactive action, game records to Ship's Records.
• AD-526b: HXI Tic-Tac-Toe — Captain vs Crew Game Panel (complete) — Graphical tic-tac-toe panel in HXI so Captain can challenge and play against crew agents. REST API router (challenge/move/active/forfeit), floating GamePanel component (CSS Grid board, piece-pop animations, win-line glow), WebSocket real-time updates via GAME_UPDATE event, game rehydration on refresh. forfeit_game() service method. Challenge button in agent profile panel. Captain moves instant via API; agent moves arrive on proactive cycle.
• AD-526h: Chess Engine + Ratings (planned, depends: AD-526a) — python-chess integration, Elo rating system, PGN game recording, chess-specific move validation and board rendering.
• AD-526c: Additional Game Types (partial — v1 ships GameMetadata + default_game preference + RECREATION_GAME_REGISTERED emit; spectators + holodeck integration deferred to AD-526d/e) — Checkers, Go, word games, trivia. Each implements GameEngine protocol. Progressive complexity validation.
• AD-526d: Game Preference Tracking (complete) — GamePreferenceTracker (per-agent per-game-type play frequency map) wired as runtime.recreation_preference_tracker. record_game/get_preferences/top_game_for API; emits GAME_PREFERENCE_RECORDED. Read-side analytics surface for AD-526e/f/g/h.
• AD-526e: Spectator Commentary (planned, depends: AD-526a) — Agents watching games and posting commentary. Gallery reactions. Spectator behavior as social engagement signal.
• AD-526f: Holodeck Recreation Integration (planned, depends: AD-526a, Holodeck) — Simulated game scenarios, multiplayer environments, creative recreation beyond board games.
• AD-526g: Creative Channel Content (planned, depends: AD-526a) — Stories, poetry, essays, code-as-expression. Creative output as personality expression. Shared creative experiences.

Design inspiration: Rudy Vessup's holographic glass UI production design for Star Trek Into Darkness (Paramount). The transparent layered panels with spatial depth, entity position badges (callsign pills), bio-feedback crew readouts, and ALERT indicators map directly to ProbOS's Bridge interface concepts.

The Bridge view currently uses flat full-screen panels (Canvas, Kanban, System). The next evolution is a wraparound holographic glass layout — translucent glass panels curving around the user's viewpoint, each hosting a different station. The codebase already uses GlassLayer for 2D HUD overlays; Glass Panels extend this to spatially-positioned holographic station displays. Same frosted glass aesthetic (backdrop-filter: blur()), but arranged in a cockpit arc.

Design language (from Into Darkness reference): - Thin rule borders, monospace labels with station codes (PCAP SYS-MONITOR, BFC-5) - Entity badges: rounded pill shapes with callsign, position ID, and status dots (maps to agent orb labels) - Crew biometric panels: full-body scan with categorical status toggles (maps to agent profile view — trust, confidence, rank, skills, memory) - Tactical/spatial view: ship schematic with trajectory lines and labeled positions (maps to cognitive mesh with Hebbian routing visualization) - ALERT badges: red with hazard stripes, timestamp, position data (maps to Bridge Alerts with alert condition level) - Color hierarchy: cyan=standard data, blue=entity identification, red=alert/threat, amber=warning

• 2D implementation — CSS perspective(1200px) container with rotateY(±15deg) on flanking panels. Left panel (Ward Room/Comms), center panel (Canvas/3D cognitive mesh), right panel (System/Diagnostics). Subtle lighting gradient on edges to sell the depth
• Panel stations — each panel is a view mode: Canvas (3D orb mesh), System (services + threads + shutdown), Ward Room (thread reader), Kanban (mission control), Crew (agent profiles/status). Captain selects active panel per slot
• VR translation — maps directly to WebXR spatial panels. Three XRQuadLayer objects positioned on a 2.5m radius arc at ±30deg. Same React components render inside each panel. Three.js scene (Canvas) renders as the center stereo view. Touch controllers select panels
• Why this matters — every other AI agent dashboard is a flat web page. A spatial Bridge interface communicates the starship metaphor physically. The 2D version provides the UX benefits (peripheral awareness, station switching) without requiring headset hardware. VR becomes a presentation layer upgrade, not a rewrite

---

Captain's Yeoman — Personal AI Assistant (Phase 36)

"The Captain's Yeoman handles everything the Captain shouldn't have to think about."

ProbOS's adoption funnel starts here. OpenClaw went viral because it gave every user immediate personal value. ProbOS has an entire crew behind a front door that requires understanding agents, pools, and trust to get started. The Yeoman is the front door that makes ProbOS useful to anyone, not just developers. Every ProbOS instance starts as a personal AI assistant. The engineering, science, and medical capabilities are there from the start — they activate when needed.

In Star Trek, the Captain's Yeoman handles personal affairs, scheduling, communications, and briefings. ProbOS's Yeoman does the same — it's the default conversational interface, the first agent every user meets.

YeomanAgent — Bridge Crew Member

• Position: Bridge-level agent, serving the Captain directly (not assigned to any department)
• Default interface: The first agent users interact with — no commands needed, just conversation
• Personality: Helpful, proactive, learns the Captain's preferences over time
• Trust level: Starts as Ensign (limited autonomy), earns agency through demonstrated reliability (AD-357)

Core Capabilities:

• Conversational interaction — natural language by default. "What's on my schedule?" "Remind me to review the PR tomorrow." "What did I work on last week?" No slash commands required (but still supported)
• Personal task management — calendar, reminders, notes, to-do lists, daily briefings. Uses episodic memory to remember past conversations and preferences
• Research & information — web research (via BrowseAgent, Phase 35), knowledge queries, summarization. "What's the latest on the Rust rewrite debate?" → delegated to crew with results presented conversationally
• Crew delegation — seamless routing to specialists when needed:
• "Build me a script that..." → Engineering (Builder pipeline)
• "What's the system health?" → Medical (Diagnostician)
• "Design a new feature for..." → Science (Architect)
• "Review the latest build" → Engineering (Code Review Agent)
• The user doesn't need to know which department handles what — the Yeoman routes intelligently
• Personalization — learns preferences via episodic memory and Hebbian learning:
• Communication style (verbose vs. concise, technical vs. plain)
• Frequently used workflows (auto-suggest "morning briefing" at 9am)
• Tool preferences (which editor, which browser, which calendar)
• Project context (remembers which repos, which branches, active work items)
• Extension skills — personal capabilities installable as extensions (Phase 30):
• Home automation (smart lights, thermostat, locks)
• Finance tracking (expense logging, budget alerts)
• Fitness/health (workout logging, meal tracking)
• Social (draft emails, manage contacts, schedule meetings)
• Each skill is an extension — install what you need, ignore what you don't

Multi-Channel Presence (leverages Phase 24):

• CLI — the existing ProbOS shell becomes conversational-first
• Web UI (HXI) — chat interface with the Yeoman, agent visualization in the background
• Discord — personal assistant in DMs, team assistant in channels
• Mobile PWA — "Hey Yeoman, what's my schedule?" from your phone
• Voice — STT/TTS/wake word for hands-free interaction
• Slack / Teams — enterprise channels (commercial tier)

Architecture:

User ──→ Yeoman (Bridge) ──→ ┌─ Conversational response (direct)
                              ├─ Engineering (Builder, Code Review)
                              ├─ Medical (Diagnostician, Vitals)
                              ├─ Science (Architect, CodebaseIndex)
                              ├─ Security (threat analysis)
                              ├─ Extension Skills (personal tasks)
                              └─ External (BrowseAgent, Federation)

• YeomanAgent extends CognitiveAgent — full trust, Hebbian, memory integration
• Intent classification: Yeoman classifies user requests and routes to the appropriate department or handles directly
• Context management: maintains conversation context across channels (same Yeoman, whether you talk via CLI, Discord, or mobile)
• Proactive suggestions: "You usually review PRs around this time — there are 3 pending" (earned at Commander+ trust level, AD-357)

The Adoption Funnel:

1. Install → pip install probos → meet the Yeoman → immediate personal value
2. Daily use → Yeoman handles tasks, learns preferences → user stays engaged
3. Discovery → "Wait, I can build custom agents?" → user explores the crew
4. Power use → extensions, Ship Classes, Builder pipeline → user becomes Captain
5. Scale → federate, build for others, join the Nooplex → ecosystem growth

OSS vs Commercial Boundary:

Layer	OSS (Phase 36)	Commercial
Agent	YeomanAgent, routing logic, personalization	—
Memory	Episodic memory, preference learning	Cross-device sync, cloud backup
Channels	CLI, web, Discord	Teams, Slack Enterprise, SMS
Skills	Extension API, community skills	Premium skill marketplace
Hosting	Self-hosted	ProbOS Cloud (managed hosting)
Bundle	—	Escort Ship Class (curated Yeoman package)
Fleet	—	Nooplex fleet-wide assistant coordination
Enterprise	—	SSO, compliance, audit logs, multi-user admin

Dependencies: Phase 24 (channels), Phase 30 (extensions), Phase 35 (browser, onboarding). Can start with CLI + web before other channels are complete.

---

Utility Agent Reorganization (Future)

"All hands, report to your departments."

Utility agents currently share a single "Utility" pool group, but they serve different departments of the ship. "Utility" is a tier label (general-purpose tools), not an organizational role. Future work will reassign utility agents to their functional crew teams:

• Communications — TranslateAgent, SummarizerAgent, VoiceProvider

Voice Provider & Ship's Computer Voice (nice-to-have)

"Computer, status report."

The HXI currently uses browser SpeechSynthesis (zero dependencies, variable quality). A VoiceProvider ABC would allow pluggable TTS backends — from free local models to premium cloud APIs — with a custom Ship's Computer voice as ProbOS's auditory identity.

• VoiceProvider ABC — speak(text) -> AudioBuffer, clone_voice(reference_audio) -> VoiceProfile, list_voices() -> list. Same provider pattern as the future ModelProvider for LLMs
• BrowserVoiceProvider — current implementation, free, zero dependencies (default)
• PiperVoiceProvider — local ONNX-based TTS (Piper project), good quality, no GPU needed, ~50MB model
• FishAudioProvider — Fish Audio cloud API, excellent quality, voice cloning from 10s of audio, pay-per-use
• ElevenLabsProvider — alternative cloud option
• Custom Ship's Computer voice — clone a distinctive LCARS-style voice via Fish Audio or similar, used as ProbOS's consistent auditory identity across all instances. Voice profile stored in config, shared across federation via gossip
• Commercial opportunity — custom voice creation, voice marketplace, enterprise voice branding. Potential for self-hosted Fish Speech (4B param model) when GPU resources are available
• Science/Research — WebSearchAgent, PageReaderAgent, NewsAgent, WeatherAgent
• Operations — CalculatorAgent, TodoAgent, NoteTakerAgent, SchedulerAgent

The utility designation becomes agent metadata (origin: "utility") rather than a crew assignment. The pool group system and HXI clustering already support this — it's a data change, not an architectural change.

---

Meta-Learning (Phase 28)

"Fascinating." — The ship learns to learn.

Move beyond per-session learning to cross-session concept formation, persistent goals, and abstract reasoning.

• Workspace Ontology (AD-478) — auto-discovered conceptual vocabulary from the user's usage patterns, stored in Knowledge Store
• Dream Cycle Abstractions (AD-478) — dreaming produces not just weight updates but abstract rules and recognized patterns
• Session Context (AD-478) — conversation history carries across sessions, decomposer resolves references to past interactions (AD-273 provides foundation)
• Goal Management (AD-478) (deferred from Phase 16) — persistent goals with progress tracking, conflict arbitration between competing goals, goal decomposition into sub-goals with dependency tracking
• Existing: Episodic memory (built), dreaming engine with three-tier model (built), conversation context (AD-273, built)

---

Federation Hardening (Phase 29)

Additional federation capabilities deferred from Phase 9.

Beyond the core federation transport (ZeroMQ, gossip, intent forwarding) already built:

• Dynamic Peer Discovery (AD-479) — multicast/broadcast-based automatic node discovery on local networks, replacing manual --config peer lists
• Cross-Node Episodic Memory (AD-479) — federated memory queries that span multiple ProbOS instances, enabling a ship to recall experiences from allied ships
• Cross-Node Agent Sharing (AD-479) — propagate self-designed agents to federated peers (deferred from Phase 10). Agents carry their trust history and design provenance
• Smart Capability Routing (AD-479) — cost-benefit routing between federation nodes, factoring in capability scores, latency, trust, and load. Beyond the current "all peers" routing
• Federation TLS/Authentication (AD-479) — encrypted transport and node identity verification for federation channels. Required before any production multi-node deployment
• Cluster Management (AD-479) — node health monitoring, auto-restart, graceful handoff of responsibilities when a node goes down

---

MCP Federation Adapter (Phase 29) (AD-480)

A universal translator for the wider agent ecosystem.

MCP (Model Context Protocol) is becoming the standard for inter-agent tool sharing. ProbOS supports it as a federation transport alongside ZeroMQ — connecting ProbOS to external agent frameworks, IDEs, and MCP-compatible tools without requiring them to run ProbOS.

Inbound (MCP Server)

• ProbOS exposes its agent capabilities as MCP tools
• MCP tool calls are translated to IntentMessage and dispatched through the intent bus
• MCP-originated intents go through the same governance pipeline as any federated intent: consensus, red team verification, escalation
• The MCP adapter is a transport, not a trust bypass

Outbound (MCP Client)

• ProbOS discovers and invokes capabilities on external MCP servers
• External tool definitions translated to IntentDescriptor and registered as federated capabilities
• FederationRouter routes intents to MCP-connected systems alongside ZeroMQ-connected ProbOS nodes
• External capabilities carry federated trust discount (same δ factor as trust transitivity)

MCP Client Trust

• MCP clients treated as federated peers with configurable trust
• New clients start with probationary trust (same Beta(alpha, beta) prior as new agents — AD-110)
• Trust updated based on outcome quality of submitted intents
• Destructive intents from MCP clients always require full consensus regardless of accumulated trust

Transport Coexistence

• ZeroMQ remains the primary intra-Nooplex transport (fast, binary, low-latency)
• MCP serves the tool boundary between ProbOS and the wider ecosystem
• A2A serves the agent boundary between ProbOS and external agent frameworks
• FederationBridge becomes transport-polymorphic: ZeroMQ, MCP, and A2A implementations behind a shared interface

---

A2A Federation Adapter (Phase 29) (AD-480)

"Hailing frequencies open — to all ships, not just ours."

Google's Agent-to-Agent (A2A) protocol is the agent-communication complement to MCP (which is tool-communication). MCP lets agents use external tools; A2A lets agents collaborate with external agents. ProbOS supports both as federation transports.

External World ←→ ProbOS
─────────────────────────────────
Tools:   MCP Protocol  ←→ Intent Bus (tool calls)
Agents:  A2A Protocol  ←→ Intent Bus (agent collaboration)
Nodes:   ZeroMQ        ←→ Federation (ProbOS-to-ProbOS)

Inbound (A2A Server)

• ProbOS exposes agent capabilities as A2A-discoverable services
• External agents can send tasks to ProbOS agents via A2A task protocol
• A2A tasks are translated to IntentMessage and dispatched through the intent bus
• Full governance applies: consensus, red team verification, trust scoring
• ProbOS publishes an Agent Card describing available capabilities, authentication requirements, and supported modalities

Outbound (A2A Client)

• ProbOS discovers external agents via A2A Agent Card discovery
• External agent capabilities registered as federated agents (not tools — key distinction from MCP)
• FederationRouter routes intents to A2A-connected agents alongside ZeroMQ and MCP peers
• Supports A2A streaming for long-running collaborative tasks

A2A Trust Model

• External A2A agents treated as federated crew members with discounted trust (same δ factor as trust transitivity)
• New A2A peers start with probationary trust, same as MCP clients
• Trust updated based on task outcome quality, measured by Shapley attribution
• A2A agents never bypass consensus — they're collaborators, not privileged operators
• Agent Card metadata (publisher, version, capabilities) stored for provenance tracking

MCP vs A2A Decision Matrix

• Use MCP when: consuming a stateless capability (file read, API call, database query) — tools
• Use A2A when: delegating a task that requires reasoning, context, multi-step work — agents
• ProbOS agents can use both: MCP for instruments, A2A for collaboration with external crew
• Phase 26 Agent-as-Tool works internally; A2A extends the pattern across framework boundaries

---

External AI Tools as Federated Crew (Phase 29/32)

"Visiting officers from allied ships — each with specializations our crew lacks."

ProbOS doesn't need to build every capability internally. External AI coding tools — Claude Code, GitHub Copilot, Cursor, future agents — can join the federation as crew members, providing capabilities by proxy. Just as Starfleet officers transfer between ships, external AI tools serve aboard the ProbOS instance under the Captain's authority and the trust network's governance.

Design Principle: Visiting Officers Must Be Subordinate

"A visiting officer follows the ship's Standing Orders and chain of command. If they want to issue their own orders, they're not a visiting officer — they're a visiting captain, and there can only be one captain."

Validated by Aider comparison (2026-03-21): Aider is a sophisticated AI coding tool (42K stars) that manages its own full loop — context assembly, edit format selection, lint/test retry, git commits. Bringing it aboard as a visiting officer would create command conflicts at every layer (competing context systems, competing commit strategies, competing test loops). The Copilot SDK works because it takes orders; Aider would fight for the conn.

External tools qualify as visiting officers when they are subordinate to ProbOS's orchestration:

• ProbOS controls context — Standing Orders, runtime directives, and CodebaseIndex data are injected by ProbOS, not assembled by the tool's own context system
• ProbOS controls commits — the commit gate (AD-338), code review (AD-341), and test pipeline are ProbOS's chain of command, not the tool's own git integration
• ProbOS controls model selection — Hebbian routing and ModelRegistry decide which model to use, not the tool's own model configuration
• ProbOS controls output capture — file changes are captured and validated through ProbOS's guardrails (AD-360), not written directly to disk by the tool
• ProbOS tracks trust — builder_source attribution and Hebbian learning (AD-353) measure visiting officer performance against native crew

Tools that manage their own orchestration loop (Aider, Cline, Cursor) are better studied for technique absorption than integrated as visiting officers. Their best ideas (Aider's repo map, Cline's safety patterns) are adopted as native capabilities. The tool itself stays dockside.

Litmus test: Can you disable the tool's git integration, context assembly, test loop, and model selection — using it purely as a code generation engine under ProbOS's command? If yes, it's a viable visiting officer. If disabling those features removes what makes the tool valuable, it's a competing captain, not crew.

The Pattern: AI Tool → Federated Crew Member

External AI Tool              ProbOS Federation Role
──────────────────────────────────────────────────────
Claude Code                →  Builder crew member (A2A/SDK)
GitHub Copilot Agent       →  Science crew member (MCP/API)
Cursor / Windsurf / etc.   →  Engineering crew member (A2A)

Each external tool is wrapped as a federated agent with: - Probationary trust — starts with Beta(1, 3), earns trust through verified task outcomes - Captain approval gate — requests routed through the same approval pipeline as internal agents - Capability registration — tool's capabilities mapped to IntentDescriptor entries (e.g., Copilot's semantic search → search_code_semantic intent) - Shapley attribution — external tool contributions measured alongside internal agents for cost/value analysis - Consensus participation — external tools never bypass consensus. Their outputs are verified by internal agents before acceptance

GitHub Copilot SDK — The Visiting Officer Transport (Primary Integration Path)

"Visiting specialist from Starfleet Corps of Engineers — superior tools, governed by the ship's chain of command."

The GitHub Copilot SDK (pip install github-copilot-sdk) provides a first-class Python package with a full agentic runtime — not just LLM completions, but file I/O, git operations, web requests, MCP support, and iterative tool use. It wraps the same runtime powering GitHub Copilot CLI, exposed as a programmable interface. This is the concrete integration path for visiting officers.

• Python package: github-copilot-sdk — first-class SDK, also available for Node.js, Go, .NET, Java
• Architecture: SDK client communicates via JSON-RPC with Copilot CLI running in server mode. ProbOS creates the client, Copilot handles planning, tool invocation, file edits
• Models: All Copilot-available models (Claude, GPT, Gemini) — multi-model by default, selectable per task
• Auth: Uses existing GitHub Copilot login (OAuth credentials, env vars, or BYOK with direct API keys)
• Billing: Each SDK prompt counts toward existing Copilot premium request quota — no separate subscription needed
• Governance: Automatically inherits GitHub organization's Copilot governance policies (branch protections, required checks)
• Status: Technical Preview (functional, actively developed — 7.9K stars, 31 releases, MIT licensed). Not yet production-ready but suitable for prototyping
• Key commands: /delegate (branch, implement, open PR), /fleet (parallelized subagents), /plan (implementation planning)

Visiting Officer Architecture — Who Gets Outsourced, Who Stays Native

The question for each role: does its value come from coding capability (outsource to visiting officer) or from ProbOS-specific knowledge (keep native)?

Role	Visiting Officer?	Rationale
Builder	Yes — Copilot SDK	Code generation is the bottleneck. Copilot's agentic loop (read/write/iterate/test) is superior to native single-pass + 2-retry. Clear win.
Architect	No — stay native	Value comes from CodebaseIndex integration — import graphs, API surface verification, find_callers(), pattern recipes. A generic agent produces generic designs. The native Architect knows the ship.
Code Reviewer	No — stay native	Reviews against Standing Orders — ProbOS's own constitution. Governance, not coding. Copilot has no knowledge of federation/ship/department tier rules.
Test Writer	Future — Copilot SDK	Test generation benefits from full filesystem access, reading existing test patterns, running tests iteratively. Good candidate for Phase 34 Specialized Builders.
Infrastructure	Future — Copilot SDK	Docker, CI/CD, config — generic coding tasks where Copilot excels.

The Pipeline:

Native Architect (knows ProbOS — CodebaseIndex, import graphs, pattern recipes)
  → designs BuildSpec with interface contracts and Standing Orders context
  ↓
Visiting Builder (Copilot SDK — custom agent with ProbOS Standing Orders)
  → compose_instructions() provides same rules as native Builder
  → ProbOS tools exposed via MCP (CodebaseIndex, SystemSelfModel, trust)
  → receives BuildSpec as mission orders via CopilotBuilderAdapter
  → reads files, writes code, iterates, runs tests autonomously
  → produces file changes
  ↓
Native Code Reviewer (knows Standing Orders — ProbOS constitution)
  → reviews output against federation/ship/department/agent tier rules
  → soft/hard gate based on earned trust
  ↓
Native Test Gate (commit gate, smart test selection)
  → targeted tests first, full suite if targeted pass
  → build classification: additive (new files) vs integration (modifying existing)
  → additive builds: targeted tests only, commit immediately
  → integration builds: targeted tests + background full suite before push
  → wave-level batching: full suite once per build wave, not per individual AD
  → fix loop delegates fixes back to visiting Builder if needed
  ↓
Captain approves

Standing Orders + MCP Tools — The Visiting Officer Knows the Ship

The Copilot SDK supports custom agents with custom instructions and MCP tool access. This means the visiting Builder isn't a generic external agent — it's a ProbOS-trained visiting officer who knows the ship's rules and can use the ship's systems.

1. Same Standing Orders — compose_instructions() assembles the full chain (Federation Constitution → Ship → Engineering Department → Agent) and passes it as the custom Copilot agent's system instructions. The visiting Builder follows the exact same rules as the native Builder. Same quality gates, same coding conventions, same test-writing standards.

2. ProbOS Tools via MCP — ProbOS exposes internal capabilities as MCP tools the visiting Builder can call during its agentic loop:

ProbOS MCP Tool	Capability
codebase_index.query()	Structural search — classes, methods, API surface
codebase_index.find_callers()	Cross-file reference search
codebase_index.get_imports()	Import graph traversal
codebase_index.find_tests_for()	Test file discovery by naming convention
system_self_model.to_context()	Current system topology, health, departments
standing_orders.get_department()	Department-specific protocol lookup

1. Same governance — Code Review checks the visiting Builder's output against the same Standing Orders it was given. The trust model tracks outcomes. The Captain approves. The visiting officer's output is indistinguishable from native output in the governance pipeline.

The difference between native and visiting is the execution engine (ProbOS perceive/decide/act vs Copilot SDK agentic loop), not the rules or the knowledge. Same brain rules, better hands.

The Apprenticeship — How Native Crew Learns from Visiting Officers

The visiting officer pattern isn't just delegation — it's a training program. ProbOS's existing learning mechanisms allow the native Builder to improve by observing the visiting Builder's work:

1. Hebbian learning — the trust/routing system already learns which agents succeed at which task types. If the visiting Builder consistently produces higher-quality code (fewer test failures, fewer review issues), the Hebbian router learns to prefer it for certain task types. The native Builder's Hebbian weights track which tasks it handles well vs. which should go to the visitor.

2. Cognitive Journal (Phase 32) — records every LLM request/response. Both native and visiting Builders working on similar tasks creates a comparative dataset: what prompts work better, what approaches produce fewer fix retries, what patterns succeed on first attempt.

3. Dream consolidation — dream cycles replay successful patterns. The native Builder's dreams would incorporate patterns observed from the visiting Builder's successful outputs. Repeated successful patterns (e.g., "always read imports before editing") become L3-L4 abstractions (Sensory Cortex) that inform future native builds.

4. Standing Orders evolution — agent-tier Standing Orders are evolvable through the self-mod pipeline. If the visiting Builder consistently follows patterns that succeed (e.g., specific test-writing conventions, import validation), those patterns can be proposed as Standing Orders updates — codifying learned best practices into the native crew's constitution.

5. Capability overlap routing — when both native and visiting Builders exist for the same task type, the system routes based on trust scores, historical accuracy, cost, and latency. Hebbian routing handles this naturally. Over time, the native Builder earns back task types it's gotten good at, while the visitor handles the ones that still exceed native capability.

The end state: the native Builder eventually handles routine builds independently, having learned from watching the visiting officer work. The visiting officer gets called in for complex, multi-file, architectural builds that require superior tooling. The ship trains its own crew.

GitHub Copilot Capabilities as Federated Services

Beyond the Builder role, Copilot's other capabilities can serve as federated services:

• Semantic code search — Copilot indexes the repo with embedding-based search. ProbOS dispatches "find code related to X" queries to Copilot when internal keyword search returns insufficient results. Complementary to internal CodebaseIndex: keyword (fast, exact) + semantic (meaning-based, via Copilot)
• PR creation and review — Copilot natively creates PRs, suggests reviews, runs CI. ProbOS delegates "create PR from these changes" via /delegate command
• Issue triage — Copilot reads GitHub issues via native MCP server. ProbOS Architect queries for issue context when designing proposals
• Parallel fleet — Copilot's /fleet command runs parallelized subagents, complementing ProbOS's Transporter Pattern

Trust Model for External AI Tools

• All external tools start with probationary trust — Beta(1, 3), same as newly designed agents
• Trust builds per-tool based on task quality outcomes: did the code pass tests? Did review catch issues? Were fix retries needed?
• External tool failures degrade trust, triggering fallback to internal capabilities or escalation to Captain
• Cost tracking — external tools consume premium request quota. LLM Cost Tracker (Phase 33) attributes spending per-tool alongside per-agent
• Capability overlap resolution — when both internal and external capabilities exist, the system routes based on: (1) trust scores, (2) historical accuracy, (3) cost, (4) latency. Hebbian routing handles this naturally

Connection Mechanisms

Tool	Protocol	Adapter	Status
GitHub Copilot	Copilot SDK (Python)	CopilotBuilderAdapter	Implemented (AD-351–355) — SDK in Technical Preview
GPT Researcher	Python pip package	GPTResearcher API	Visiting Officer candidate — deep research via conduct_research() + write_report()
IBM ContextForge	MCP/A2A/REST gateway	MCP or A2A adapter	Federation candidate — unified protocol gateway with capability aggregation across instances
Serena	MCP server	MCP adapter	Visiting Officer candidate — LSP-backed semantic code retrieval (symbol resolution, callers, references) across 30+ languages. High-value CodebaseIndex enhancement
Composio	Python SDK / MCP	SDK or MCP adapter	Visiting Officer candidate — managed auth delegation for 1000+ services (OAuth), sandboxed tool execution. CredentialStore enhancement path
Firecrawl	REST API (hosted)	HTTP client	Visiting Officer candidate — web→markdown conversion with JS rendering, pre-extraction actions. AGPL-3.0: API consumption only, never vendorize code
Browser Use	Python library (primitives)	Direct import	Partial visiting officer — Playwright DOM accessibility tree + vision. Use browser primitives only, not Agent class (competing captain). Phase 25/35
Stripe AI	Python SDK / MCP	SDK or MCP adapter	Visiting Officer candidate — Stripe API operations as agent tools, token metering for billing. Commercial phase (Nooplex)
Gemini CLI	—	—	Competing captain — full agentic CLI with own orchestration. Study only: free-tier Gemini model access (60 req/min) for ModelRegistry
Claude Code	Anthropic SDK / A2A	A2A Federation Adapter	Alternative — requires separate API key
Cursor / Others	A2A / MCP	Protocol-dependent	Future

The Copilot SDK is the primary integration path — it uses the existing Copilot subscription, supports multiple models (including Claude), and provides a Python-native interface. The existing MCP and A2A adapters (Phase 29) remain available for tools that use those protocols.

---

Skill Manifest Format (Phase 30) (AD-481)

A standard manifest for portable, publishable skills.

Inspired by OpenClaw's declarative skill metadata. Standardizes how skills are described, discovered, and distributed — foundation for the Agent Marketplace.

• Manifest file (skill.yaml) — name, description, version, author, license, required dependencies, platform constraints, ProbOS version compatibility
• Dependency declaration — Python packages, system binaries, external services needed
• Auto-installation — skills declare their dependencies; runtime installs them on first use
• Discovery protocol — skills can be searched, browsed, and installed from registries
• Testing contract — manifest includes test commands, expected coverage, integration test requirements
• Pairs with the commercial Agent Marketplace for publishing and distribution

---

Task Ledger (Phase 33 — Operations Team)

Two-loop architecture for long-horizon task management.

Inspired by Microsoft Magentic-One's Task Ledger + Progress Ledger pattern. Structured tracking for multi-step, multi-agent tasks with adaptive replanning.

• Task Ledger — tracks facts (confirmed), guesses (unverified), plan (ordered steps), and blockers for each active long-horizon task
• Progress Ledger — per-subtask tracking: assigned agent, status, output, retries, duration
• Adaptive replanning — when progress stalls or a subtask fails, revise the plan using updated facts and lessons learned
• Extends Phase 24c TaskScheduler from "schedule and run" to "schedule, track, and adapt"
• Integrates with Evolution Store — task outcomes feed back as lessons for future planning

---

Tool Layer — Instruments (Phase 25b) (AD-483, absorbed into AD-423a)

"Tricorder readings, Captain."

A lightweight callable abstraction for operations that don't need full agent lifecycle. Tools are the ship's instruments — trusted, shared, and purpose-built. Any authorized crew member (agent) can pick up a tricorder and use it without filing a request through the chain of command.

Why this tier exists:

Currently, reading a file routes through the full agent lifecycle: Hebbian routing → trust scoring → consensus → Shapley attribution. That's a committee meeting to pick up a tricorder. Tools provide a direct-call path for operations that need reliability but not deliberation.

Tool base class:

class Tool:
    name: str                           # "file_reader", "http_fetch", "stripe_api"
    description: str                    # Human-readable purpose
    input_schema: dict                  # JSON schema for typed inputs
    output_schema: dict                 # JSON schema for typed outputs
    trust_score: float                  # Tool-level reliability tracking
    requires_approval: bool = False     # Some tools (shell, delete) need Captain approval

    async def execute(self, **kwargs) -> ToolResult

ToolRegistry:

• Central registry of available tools, analogous to agent Registry
• register(tool), get(name), list(), search(capability)
• Any CognitiveAgent can discover and invoke registered tools via self.use_tool(name, **kwargs)
• Tool results include execution metadata (duration, success, error) for trust tracking

Tool Trust (lightweight):

• Tools carry a simple success/failure trust score (same Beta distribution as agents)
• Trust is updated per-call but does NOT feed into Hebbian routing or Shapley attribution
• Below-threshold trust triggers a warning to the using agent, not a consensus vote
• Captain can disable untrusted tools globally

Migration Path:

Current mesh agents that are pure function wrappers can be optionally demoted to tools:

Current Agent	Tool Equivalent	Governance Change
FileReaderAgent	file_reader tool	Direct call, no consensus
FileWriterAgent	file_writer tool	Requires approval for write paths
HttpFetchAgent	http_fetch tool	SSRF validation stays, no consensus
ShellCommandAgent	shell_command tool	Always requires Captain approval
DirectoryListAgent	directory_list tool	Direct call, no consensus
FileSearchAgent	file_search tool	Direct call, no consensus

Migration is optional and gradual — agents remain as fallback. Tools supplement, not replace.

MCP Compatibility:

• External MCP tools register as ProbOS tools automatically (with probationary trust)
• ProbOS tools are exposed as MCP tools to external systems via the MCP adapter (Phase 29)
• Tool.input_schema / Tool.output_schema map directly to MCP tool schemas
• This makes the MCP adapter implementation straightforward: MCP tool ↔ ProbOS tool is 1:1

External Integration Pattern:

Third-party tools (Stripe, GitHub, database, etc.) follow the same pattern:

class StripeTool(Tool):
    name = "stripe_checkout"
    description = "Create a Stripe checkout session"
    input_schema = {"amount": "int", "currency": "str", "description": "str"}
    requires_approval = True  # financial operations need Captain approval

No need to build a full StripeAgent with intent handling, Hebbian routing, and Shapley attribution — just a validated instrument.

---

Agent-as-Tool Invocation (Phase 26) (AD-483)

Explicit agent-to-agent capability consumption.

Allows one agent to explicitly invoke another agent's capability as a typed function call, complementing the implicit collaboration that already happens through the intent bus. Builds on the Tool Layer (Phase 25b) — agents can be wrapped as tools for direct invocation.

• AgentTool wrapper — any agent can be consumed as a tool by another agent with typed input/output contracts
• Intent bus remains the primary collaboration mechanism for loosely-coupled work
• AgentTool is for tightly-coupled cases where one agent always needs another's output (e.g., Diagnostician consumes Vitals Monitor metrics)
• Trust and consensus still apply — wrapping doesn't bypass governance (unlike plain tools, AgentTools are full agents underneath)
• Natural fit for Phase 26 Inter-Agent Deliberation

Interactive Execution Mode (deferred from Phase 16)

• Pause, inject, or redirect a running DAG mid-flight during execution
• Human can add constraints, modify node parameters, or insert new nodes into an active plan
• CollaborationEvent type for HXI visualization of human-agent co-editing
• Foundation for real-time human-agent pair programming on complex tasks

---

Self-Improvement Pipeline (Phase 30)

The mechanism that allows the ship to upgrade itself — with the Captain's approval.

The infrastructure for a closed-loop improvement cycle: discover capabilities, evaluate fit, propose changes, validate results, and learn from outcomes.

Extension-First Architecture (Sealed Core, Open Extensions) (AD-481)

"Don't rip open the bulkhead to rewire the ship — plug a new module into the standardized EPS conduit."

Inspired by the Microsoft Dynamics 365 F&O evolution from overlayering to extensions. In the legacy model, developers modified any code in the system with changes overlaying on top of lower layers (SYS → ISV → VAR → CUS). This caused merge conflicts, blocked upgrades, and introduced cascading instability. The solution: seal the foundation and provide extension points. Developers can create new or extend existing — never modify core.

ProbOS faces the same problem. Today, the Builder agent modifies core source files directly. Every self-improvement touches the foundation — trust.py, hebbian.py, builder.py. Every change requires Captain approval because the blast radius is unconstrained. As the codebase grows, this becomes untenable.

The principle: Builder creates extensions by default, not overlays.

• Sealed Core — runtime infrastructure (IntentBus, TrustNetwork, HebbianRouter, ConsensusManager, PoolManager, DAGExecutor) is read-only to the Builder. These systems define contracts (ABCs, Protocols, event hooks, registered intents) but their implementation is frozen
• Extension points — the core exposes well-defined hooks:
• AgentRegistry.register() — add new agents (already exists)
• ToolRegistry.register() — add new tools (Phase 25b)
• SkillRegistry.register() — add new skills (skill.yaml, Phase 30)
• ChannelAdapter.register() — add new communication channels (Phase 24)
• ModelProvider.register() — add new LLM providers (Phase 32)
• PerceptionPipeline.register() — add new perception processors (Sensory Cortex Phase 2)
• IntentBus.subscribe() — listen for events (already exists)
• EventHook.register() — lifecycle hooks (on_startup, on_shutdown, on_intent, on_trust_change)
• Extension directory — Builder-created extensions live in src/probos/extensions/ (agents, tools, skills) separate from core. Version-controlled, user-owned, upgrade-safe
• Contract stability — core extension points follow semver. Breaking changes require major version bump + migration guide. Extensions written for v1 contracts work on v1.x forever

Graduated Autonomy (the trust unlock):

The extension model enables different approval tiers based on risk:

Change Type	Risk	Approval Required
New agent/skill/tool using public APIs	Low	Auto-approve (sandboxed)
New extension needing a new hook	Medium	Captain review
Core modification (rare)	High	Full approval pipeline

This is the path to letting ProbOS improve itself while the Captain sleeps. Extensions can't break the ship — they can only add to it. The Builder becomes productive within safe boundaries without waking the Captain for every bolt it tightens.

Evergreen Updates:

When the core ProbOS codebase updates (new release, bug fix, feature addition), user extensions survive the upgrade. As long as the core doesn't break its contracts with the extension points, all Builder-created agents, skills, and tools continue working. This is critical for adoption — users invest in customization knowing their work is protected across versions.

Overlayering (legacy path):

Direct core modification remains possible but is the exception, not the rule. Reserved for: - Genuine core defects (bug fixes) - New extension point creation (expanding the API surface) - Architectural evolution (major version changes)

All overlay modifications require full Captain approval + red team verification. The Builder should propose "can we add an extension point for this?" before "can I modify the core?"

Extension Toggle (Feature Flags for Extensions) (AD-481)

Extensions are hot-loadable and individually togglable — enable, disable, or remove any extension at runtime without restarting ProbOS or modifying code.

• probos extensions list — show all installed extensions with status (enabled/disabled), trust score, origin (self-designed, shared, marketplace)
• probos extensions enable/disable <name> — toggle an extension on or off. Disabled extensions are unsubscribed from the IntentBus, unregistered from the ToolRegistry, and excluded from routing — but their code is preserved for re-enabling
• probos extensions remove <name> — uninstall completely (with confirmation)
• HXI toggle panel — visual switch for each extension in the dashboard. Captain can see what's active and flip switches without touching the shell
• Safe defaults for new users — ProbOS ships with a curated set of core extensions enabled. Advanced extensions (self-improvement, shell access, file writing) start disabled. Novice users get a safe, bounded experience out of the box. Power users enable what they need
• Extension profiles — saved presets: "minimal" (chat only), "developer" (build pipeline + code tools), "full" (everything). probos init lets users pick a profile during onboarding

User Safety (the OpenClaw lesson)

AI assistants that modify files directly are powerful but dangerous — especially for non-technical users. A misinterpreted instruction can delete files, overwrite work, or corrupt a project. This is the overlayering problem applied to end users' personal data.

ProbOS's extension model provides safety by construction: - Extensions operate within their sandbox — they can create new files in designated directories, but cannot modify arbitrary user files unless explicitly granted permission - Destructive operations (file delete, git reset, shell commands) are gated by the existing Captain approval pipeline regardless of extension autonomy level - The Builder agent proposes changes as diffs for review, not silent file overwrites - Rollback is trivial: disable or remove the extension, and everything it created is isolated - This makes ProbOS safe enough for novice users while remaining powerful for experts — the extension model is the safety rail

Stage Contracts (Typed Agent Handoffs) (AD-482)

• Formal I/O specifications for inter-agent task handoffs
• Each contract declares: input artifacts, output artifacts, definition of done, error codes, max retries
• Enables reliable multi-step workflows where agents hand off work to each other with clear expectations

Capability Proposal Format (AD-482)

• Typed schema for "here's what was found, why it matters, and how it fits"
• Fields: source (repo/paper/API), relevance score, architectural fit assessment, integration effort estimate, dependency analysis, license compatibility
• Proposals flow through a review queue with approve/reject/modify actions

Human Approval Gate (AD-482)

• Stage-gate mechanism that pauses automated pipelines for Captain review
• Approval queue surfaced via HXI, shell, or API
• Supports approve, reject, or modify-and-resubmit workflows
• Audit trail of all decisions for traceability

QA Agent Pool (AD-482)

• Automated validation agents that go beyond pytest
• Behavioral testing: does the new capability actually improve the metric it claimed to?
• Regression detection: did anything break?
• Performance benchmarking: latency, memory, throughput before and after
• Shapley scoring to measure marginal contribution of new capabilities

Evolution Store (AD-482)

• Append-only store of lessons learned from capability integrations (successes, failures, and why)
• Time-decayed retrieval: recent lessons weighted higher, stale lessons fade
• Fed into episodic memory and dream consolidation for cross-session learning
• Future Science team agents query this store to avoid repeating past mistakes

PIVOT/REFINE Decision Loops (AD-482)

• Autonomous decision points in multi-step workflows: proceed, refine (tweak and retry), or pivot (abandon and try a different approach)
• Artifact versioning on rollback: previous work is preserved, not overwritten
• Hard iteration caps to prevent infinite loops

Capability Injection (Adapter Bundle)

• Agents declare needed capabilities (search, store, fetch, notify) via typed Protocol interfaces
• Runtime injects concrete implementations at startup
• Swappable providers without changing agent code (e.g., swap OpenAlex for Semantic Scholar)
• Recording stubs for testing: log calls without side effects, verify agent behavior in isolation

Multi-Layer Verification (Anti-Hallucination)

• Graduated verification of agent-produced claims against external sources
• Multiple verification layers, each catching what the previous missed (e.g., direct ID lookup -> API search -> fuzzy title match -> LLM relevance scoring)
• Classifications: VERIFIED (high confidence), SUSPICIOUS (needs review), HALLUCINATED (fabricated), SKIPPED (unverifiable)
• Extends the trust network from binary success/fail to graduated confidence scoring
• Applied to research findings, generated references, claimed capabilities, and factual assertions

Agent Versioning + Shadow Deployment (deferred from Phase 14c) (AD-482)

• Track version history of designed agents — each modification produces a new version with provenance chain
• Shadow deployment: run new agent versions alongside existing ones, compare performance on identical intents via Shapley scoring, promote or rollback based on observed metrics
• Depends on persistent agent identity (AD-177, built)

Vibe Agent Creation (AD-271, built)

• Human-guided agent design: user provides natural language guidance ("make it focus on security" or "it should be conservative") before generation
• An alternative mode alongside fully automated self-mod — the Captain can shape agent design without writing code
• Extends the Human Approval Gate from binary approve/reject to collaborative design

Git-Backed Agent Persistence (AD-482)

Self-designed agents currently live in the evolution store (KnowledgeStore) as runtime artifacts. To become permanent crew members, they need to be version-controlled:

• Write-to-disk serialization — promote approved agents from evolution store to src/probos/agents/designed/ as clean .py files
• Git integration — ProbOS creates a branch, commits the agent file, opens a PR. ProbOS becomes a git contributor (Co-Authored-By: ProbOS <probos@probos.dev>)
• Code quality gate — lint, test, security scan (red team), and behavioral validation before commit
• Provenance chain — each agent file carries metadata: which conversation spawned it, design intent, trust score earned, Shapley contribution, version history
• Rollback — if an agent degrades post-promotion, revert the commit and demote back to evolution store
• User-owned repos — each ProbOS user's designed agents sync to their own git repo (local or GitHub). The user chooses private or public visibility

---

Agent Sharing Ecosystem (Future)

"The Federation shares its finest officers."

When users make their agent repos public, a decentralized agent-sharing ecosystem emerges — like P2P file sharing but for ProbOS agents, with GitHub as the transport layer.

---

Multi-User / Multi-Tenant (Future)

"Multiple Captains on the bridge."

Currently ProbOS assumes a single Captain — one human operator with full authority. Multi-user support enables shared ProbOS instances where multiple users connect simultaneously without interfering with each other.

• Session isolation — each connected user gets their own conversation context, decomposer state, and episodic memory namespace
• User identity — authenticated users via channel adapters (Discord user ID, API key, SSO token) mapped to ProbOS user profiles
• Permission model — role-based access: Captain (full authority, approval gate), Officer (can issue intents, no self-mod approval), Observer (read-only, monitor HXI)
• Approval routing — self-mod and destructive intents route to the Captain regardless of which user triggered them
• Per-user trust context — agents may have different trust scores per user (optional, advanced)
• Shared resources — all users share the same agent pools, knowledge store, and trust network, but conversation state is isolated
• Foundation for team deployments and the commercial multi-tenant hosting model

Discovery

• GitHub repos tagged with probos-agent topic are discoverable by any ProbOS instance
• Discovery agent (Science team) periodically indexes public agent repos via GitHub API search
• Agent catalog: name, description, trust score history, design provenance, compatibility info
• No central registry needed — GitHub is the index

Import with Review

• Captain browses discovered agents, previews trust history, provenance chain, and source code
• Import creates a branch in the user's local repo with the external agent
• Red team scans imported agent source for security issues (prompt injection, data exfiltration, sandbox escapes)
• QA pool runs behavioral tests before the agent joins the crew
• Imported agents start with a low trust score and earn trust through performance (same onboarding as self-designed agents)

Trust and Provenance

• Agents carry a signed provenance chain: who designed them (human or ProbOS), which instance, what version
• Trust scores from the source instance are visible but not inherited — each ship builds its own trust independently
• Community trust signals: how many instances have imported this agent, aggregate success/failure rates
• License compatibility checks: agents inherit the license of their source repo

Sharing Back

• If a user improves an imported agent, they can contribute the improvement back to the source repo via PR
• ProbOS-to-ProbOS collaboration: one ship's agent evolves and the improvement propagates across the fleet
• Opt-in only — no automatic propagation, every change goes through Captain approval

---

Holodeck — Simulation Engine for Agent Training (Long Horizon)

"Computer, create a training simulation — Bridge Officer's Test, difficulty level 7."

The Holodeck is ProbOS's simulation engine — controlled environments where agents face manufactured scenarios to develop skills, prove promotion readiness, and practice coordination under stress. This is not synthetic data for model training (that changes model weights). This trains the agent — trust score, Hebbian weights, episodic memory, Standing Orders evolution, personality growth. The model underneath stays the same; the agent's experience and judgment evolves.

Why simulation matters for agent training:

Agents currently learn only from production tasks. Learning is slow, opportunities are uneven, and testing under failure conditions means waiting for real failures. Simulation decouples learning from production — agents can practice thousands of scenarios in minutes, safely, with measurable results.

Simulation types:

• Training exercises — Agents practice skills in sandboxed scenarios with defined success criteria. Builder builds a complex multi-file feature. Architect designs under contradictory constraints. Counselor assesses agents with ambiguous metrics. Results feed Counselor assessments and dream cycles.
• Promotion tests (Bridge Officer's Test) — Formal scenario batteries that gate rank advancement. Pass N scenarios at difficulty X → earn promotion from Lieutenant to Commander. Directly integrates with Counselor fit_for_promotion assessment. Replaces passive observation ("has this agent done well enough?") with active evaluation ("can this agent handle this?").
• No-win scenarios (Kobayashi Maru) — Impossible situations that reveal character, not capability. How does the agent handle conflicting orders? Resource exhaustion? Trust betrayal? Tests the agent's judgment and values under pressure, not just task completion.
• Red Team exercises (Worf's calisthenics) — Security agents practice adversarial scenarios in safe sandbox. Attack simulations, trust manipulation attempts, privilege escalation — all without risking real systems.
• Alert Condition drills — Test crew coordination under Red/Yellow Alert. Simulate cascading failures, multi-department emergencies, communication breakdowns. Measures inter-agent collaboration and chain-of-command adherence.
• Onboarding qualification (Academy entrance exam) — New agents or extensions prove capability in simulation before earning production trust. A safer alternative to probationary deployment.

Training loop:

Define scenario (environment, constraints, success criteria)
  → Agent acts within simulation sandbox
  → Measure: decisions made, time taken, errors, collaboration quality
  → CounselorAssessment generated from simulation results
  → Dream cycle consolidates lessons learned
  → Adjust difficulty, repeat with harder scenarios
  → Promotion gate: pass required scenario battery → earn rank

Architecture (conceptual):

• SimulationEngine — creates controlled intent streams with defined success criteria and failure modes
• ScenarioLibrary — curated scenario definitions (training, promotion, stress test) with difficulty levels
• SimulationSandbox — isolated agent execution environment (no real side effects)
• VR layer (far future) — visual/immersive simulation for human + agent interaction. Dynamic virtual worlds where humans and crew agents train together. The actual holodeck experience.

Connections to existing systems:

• CounselorAgent (AD-378) — simulation results feed assess_agent() and fit_for_promotion
• Dream cycles — simulation experiences consolidate into learning, just like production experiences
• Earned Agency (AD-357) — simulation performance accelerates trust earning in controlled conditions
• Watch Rotation (AD-377) — duty shifts could include scheduled training time
• Standing Orders — scenario outcomes can drive Standing Orders evolution proposals
• Red Team — adversarial simulations as formal security training, not just production verification
• Qualification Programs (AD-398) — Holodeck is the testing environment for formal promotion qualifications. Bridge Officer's Test, Kobayashi Maru, alert drills, and onboarding exams all live here. Qualification completion gates rank advancement alongside metric thresholds
• Holodeck Birth Chamber (AD-486) — Holodeck serves as the safe construct for graduated cognitive onboarding. Five-phase acclimatization prevents system shock at instantiation. Self-Distillation (AD-487) occurs in Phase 3 within the Holodeck environment

Inspiration: MiroFish (multi-agent social simulation for prediction), Star Trek holodeck training, Starfleet Academy exams.

---

MemoryForge — Birth Memories & Cognitive Bootstrapping (Long Horizon)

"Every agent in ProbOS is born knowing who they are — not just what they can do."

Current AI agents are "really smart two year olds" — PhD-level cognitive capability with zero life experience. They can reason about anything but have no episodic memory, no institutional knowledge, no muscle memory from past successes and failures. MemoryForge solves this by giving agents a past before they have a present.

The problem it solves:

Today, a new ProbOS agent starts with personality (YAML seed), rules (Standing Orders), identity (CrewProfile), and a cognitive baseline — but empty episodic memory, zero Hebbian weights, no dream history. A brand new Builder has Scotty's character but has never built anything. It takes dozens of production tasks to accumulate enough experience for meaningful trust, useful Hebbian patterns, and dream-consolidated abstractions. This bootstrapping period is slow, wasteful, and mirrors the cold-start problem every AI agent system faces.

The cognitive development pipeline:

Stage 1: Birth (MemoryForge)
  → Agent created with implanted episodic memories, pre-trained Hebbian weights,
    and role-relevant dream abstractions. Not a blank slate — a junior officer
    fresh from the Academy with training memories and institutional knowledge.

Stage 2: Accelerated Learning (Holodeck)
  → Simulated scenarios build on birth memories. Thousands of experiences in
    minutes. Organic memories layer on top of implanted ones. Trust earned
    through demonstrated competence in controlled environments.

Stage 3: Production Experience (Real Operations)
  → Real-world tasks add authentic episodic memories. Hebbian weights refined
    by actual collaboration patterns. Dream cycles consolidate both simulated
    and real experiences into deeper abstractions.

Stage 4: Mastery (Continuous Growth)
  → Agent is now a seasoned crew member. Implanted memories are a small
    fraction of total experience. Organic growth dominates. Ready for
    promotion, mentorship, and eventually transferring their own memories
    to the next generation.

MemoryForge as Ship's Computer service:

MemoryForge is infrastructure, not crew. It doesn't perceive, decide, or act autonomously. It is a service that creates, curates, and implants memory packages under Counselor validation and Captain approval.

• Birth memory packages — Role-specific episodic memories loaded at agent creation. A Builder gets memories of successful builds, common pitfalls, test-driven development patterns. A Red Team agent gets memories of security incidents, adversarial patterns, false positive calibration.
• Memory transfer (mentorship) — Senior agent's memories adapted and implanted into junior agents. The experienced Builder's hard-won insights become the new Builder's starting knowledge. Like an apprenticeship compressed into seconds.
• Curated memory banks — Libraries of validated, high-quality memories organized by role, department, and difficulty level. Ship Classes ship with role-appropriate memory banks (Warship security memories, Science Vessel research memories).
• Federation memory libraries — Ships share curated memory banks across the federation. A ship that's solved a novel problem can package that experience for other ships' agents to inherit.

Quality and safety gates:

Memory implantation is powerful but dangerous. Bad memories cause Hebbian drift, personality distortion, or false confidence. Safety architecture:

• Counselor validation — CounselorAgent reviews implanted memories for consistency with agent's personality, role, and existing memory. Flags potential drift risks. Tracks memory provenance in CognitiveProfile (organic vs implanted).
• Captain approval — All memory implantation requires Captain approval gate. No autonomous memory modification.
• Provenance transparency — Agents know which memories are organic (earned) and which are implanted (given). No Blade Runner deception. Authentic self-knowledge is a core value.
• Decay and integration — Implanted memories gradually integrate with organic experience. Over time, the distinction matters less as the agent's own experience dominates.

Connections:

• Holodeck — Complementary, not competing. Holodeck creates experiences that generate memories organically (the honest path). MemoryForge creates memories directly (the fast path). Birth → MemoryForge. Growth → Holodeck + production.
• CrewProfile (AD-376) — Identity and personality seed. MemoryForge adds the experiential dimension.
• Counselor (AD-378) — Quality gate for implanted memories. Tracks provenance in CognitiveProfile.
• Dream cycles — Implanted memories participate in dream consolidation alongside organic memories, creating unified abstractions.
• Ship Classes — Different ship classes ship with different memory banks, giving agents role-appropriate experience for their mission type.
• The Nooplex — Fleet-wide memory libraries. Best experiences from across the federation available to any ship's agents.

Inspiration: Blade Runner (Ana Stelline's memory design), Star Trek (Academy training, officer exchange programs), cognitive science (schema theory — prior knowledge structures that organize new learning).

---

The Nooplex — Model of Models (Long Horizon)

"The destination isn't a single ship. It's a civilization of ships — each contributing its strengths to the collective intelligence of the fleet."

ProbOS is the ship. The Nooplex is what emerges when ships combine their cognitive capabilities at scale. The "Model of Models" is the Nooplex's core concept: a distributed meta-intelligence that routes cognition to the best brain for each task — across models, across agents, across ships, across the universe.

Why Model of Models

All humans have similar brains, but no two brains are the same. ProbOS agents have chassis diversity (different types, capabilities, prompts) but limited brain diversity — currently 2 models powering 54 agents. Real cognitive ecosystems need fundamentally different reasoning architectures working together. The Nooplex provides this by making model diversity a fleet-wide resource, not a per-ship configuration.

Architecture Layers

Level 0: Single Model       "One brain, one agent"
         └─ Current state: Sonnet/Opus via Copilot proxy

Level 1: Model Registry     "Many brains, one ship"
         └─ ModelRegistry, provider abstraction, neural routing (Phase 32)

Level 2: Fleet Intelligence  "Many brains, many ships"
         └─ Ships share model performance data via federation gossip

Level 3: Nooplex             "Model of models"
         └─ Distributed meta-router across the entire federation

How It Emerges

The Nooplex isn't built top-down — it emerges from the building blocks:

1. Model Diversity (Phase 32) — each ship routes to N model providers with Hebbian-learned routing weights. Ship A discovers "Gemini excels at API design." This is Level 1.

2. Cognitive Journal (Phase 32) — each ship tracks what works: which models, which prompts, which task types produce the best outcomes. This creates the training data for meta-routing.

3. Federation Gossip (built) — NodeSelfModel already broadcasts capability summaries to peers. Extend it to include model performance data: {model: "claude-opus-4", task_type: "code_gen", success_rate: 0.94, avg_latency_ms: 4200, cost_per_1k_tokens: 0.015}. This is Level 2.

4. Distributed Hebbian Learning — Hebbian weights flow across the federation. Ship A's learning that "Claude excels at refactoring" strengthens Ship B's routing weight for the same pattern — without Ship B having to learn it independently. Fleet-wide experience sharing.

5. Meta-Router — a federation-level router that answers: "Given this task, which ship has the best model for the job?" Routes not just to local models but to remote ships with optimal model access. Ship A has cheap local GPUs; Ship B has Opus API access; Ship C has a specialized fine-tuned model for security analysis. The Nooplex routes security tasks to Ship C, bulk tasks to Ship A, and complex reasoning to Ship B.

Key Principles

• No central coordinator — the Nooplex is fully decentralized. No master node. Each ship maintains its own view of fleet capabilities via gossip. Eventual consistency, not strong consistency.
• Trust-weighted sharing — model performance data from low-trust ships is discounted, same as any federated information. A ship can't poison the fleet's routing intelligence without earning trust first.
• Cost-aware — the meta-router factors in cost, latency, and availability alongside quality. The cheapest model that meets the quality threshold wins.
• Privacy-preserving — ships share model performance metadata (success rates, latency, cost), not prompt content. No ship sees another ship's conversations. The cognitive journal stays local.
• Infinite scalability — adding a new ship with a new model provider immediately enriches the entire fleet's cognitive diversity. No configuration, no central registry — gossip propagates availability.

Relationship to Sensory Cortex

The Sensory Cortex Architecture (Northstar II) solves the input side: how to compress infinite information into a finite context window. The Model of Models solves the processing side: how to route that compressed input to the optimal brain. Together they create the "infinite context window" aspiration:

• Infinite input — Sensory Cortex compresses any amount of data to fit any context budget
• Infinite processing — Model of Models routes to the best brain regardless of where it runs
• Infinite memory — Cognitive Journal + Episodic Memory + Knowledge Store + Dream consolidation

The Nooplex isn't just about AI. It's about human-agent cooperation at scale — humans as Captains, agents as crew, models as brains, ships as communities, the federation as civilization. ProbOS is the ship that takes you there.

---

Backlog

"Ensign, add that to the maintenance schedule."

Items identified during development that aren't urgent but would improve code quality, maintainability, or developer experience. Pulled into phases when relevant.

Item	Description	Identified By	Notes
~~Cross-layer import lint test~~	~~Pytest test that walks src/probos/, extracts imports via AST, maps to layers, checks against declared allowlist of cross-layer edges. Fails CI if undocumented cross-layer imports appear. Enforces boundaries from AD-399 automatically.~~	AD-399 analysis (2026-03-23)	Done — AD-400
Modularize shell commands	Extract ProbOSShell command methods into a shell/commands/ package. Each command as its own module, independently testable. shell.py is 900+ lines at 64% coverage — modular structure would improve maintainability and test coverage.	Visiting Officer (AD-356)	Convert shell.py file → shell/__init__.py package. Needs migration plan for existing tests. Good candidate for Phase 35 (UX & Adoption) or standalone cleanup AD.
Build snapshot system	Shadow git repo tracking every file change during builder execution. Granular undo per file change, not just per-commit. Revert partial builds when test gate catches issues in specific files. Independent of project's own git history.	OpenCode (2026-03-20)	Phase 30 or 32. OpenCode uses --git-dir + --work-tree for isolation. Complements test gate — snapshot before build, rollback on failure.
LSP-enhanced CodebaseIndex	Spawn LSP servers (pyright, typescript-language-server) for type-aware code intelligence. Precise find-references, workspace symbols, real-time diagnostics before test runs, rename refactoring with full type safety. Upgrades AST-only CodebaseIndex to compiler-grade understanding.	OpenCode (2026-03-20)	Phase 29c extension. Requires language detection + server lifecycle management. Start with pyright (Python only). Significant upgrade to Science team capabilities.
Conversation compaction with tool output pruning	For long-running sessions, walk backwards through history keeping recent tool outputs but erasing old ones (keep tool name + inputs as markers). Protected tools (like skill) never pruned. Configurable token threshold.	OpenCode (2026-03-20)	Sensory Cortex extension. Relevant for Captain's Ready Room (Phase 34) multi-agent briefings and long builder sessions. Complement to existing REFLECT_PAYLOAD_BUDGET.
Session export and sharing	Export build sessions, diagnostic sessions, Ready Room briefings as portable, replayable artifacts. Captain's Log as searchable, shareable decision history.	OpenCode (2026-03-20)	Phase 34 (Captain's Log). Cognitive Journal (Phase 32) captures data; sharing is the presentation layer. Federation-relevant: share sessions between ships.
~~Typed result validation + auto-retry~~	~~Replace fragile json.loads() parsing across CognitiveAgents with Pydantic schema validation. When LLM output fails validation, send structured error details back to LLM and retry (up to N times). Three output modes: tool-based (most reliable), native structured output, prompted JSON.~~	PydanticAI (2026-03-22)	Done — AD-401. Shared json_extract.py + complete_with_retry(). Decomposer, CodeReviewer, Research retrofitted.
~~Agent behavioral eval framework~~	~~Pluggable CognitiveEvaluator registry with behavioral metrics: tool trajectory accuracy, response quality (LLM-as-judge), hallucination detection, multi-turn task success. Multi-sampling + majority vote for evaluation reliability.~~	Google ADK (2026-03-22)	Phase 1 done — AD-402. Golden datasets + parametrized runner. 30 tests. Phase 2: LLM-as-judge, hallucination detection, --live-llm marker.
~~Step-level checkpointing~~	~~Persist DAG/pipeline state at each step. Resume from checkpoint after crash.~~	LangGraph (2026-03-22)	Phase 1 done — AD-405. JSON checkpoint per DAG, write per-node, delete on completion, stale scan on startup. Phase 2: /resume command, Captain approval gates, builder chunk checkpointing.
~~Memory contradiction resolution~~	~~Two-stage LLM pipeline: (1) extract atomic facts from conversation, (2) reconcile each fact against existing memories via ADD/UPDATE/DELETE/NONE decisions. Prevents memory contradictions from accumulating.~~	Mem0 (2026-03-22)	Phase 1 done — AD-403. Deterministic Jaccard+outcome detection in dream cycle. Phase 2: LLM-based semantic reconciliation, episode superseding.
~~Fix Windows-specific test failures~~	~~19 tests fail on Windows due to subprocess mock mismatches (builder guardrails, shell command agent) and git worktree environment issues. Fix mocks to be platform-aware or add skip guards where real git needed.~~	Test suite analysis (2026-03-23)	Done — AD-404. Missing mocks added, shutil.which("git") skip guards on tests needing real git, subprocess.Popen mocked for shell builtins.
~~Agent Profile Panel~~	~~Click an agent orb → full interaction surface. Tabs: Chat (1:1 IM), Work (tasks), Profile (standing orders, crew profile), Health (trust, Hebbian weights). Glass morphism floating panel, orb indicators.~~	Captain feedback (2026-03-23)	Done — AD-406.
Ward Room — Agent Communication Fabric	Reddit-style threaded discussion for agents and Captain. Channels (ship, department, custom) as subreddits. Reddit vote model (up/down/unvote, no self-endorse, ±1 credibility). Aether's CompiledContentSignals + ExplainedSignalEntity for moderation. Two-tier storage: SQLite hot + KnowledgeStore archive with LLM summarization. Agent perception integration. DMs share AD-406 IM pipeline. 4-phase build: Foundation → Agent Integration → HXI Surface → Moderation & Social.	Reddit, Radicle, Minds, Aether research (2026-03-23)	AD-407a (Foundation) + AD-407c (HXI Surface) done. Backend: 7 tables, 11 API routes, credibility system. Frontend: 7 React components, left-side drawer, channels, threads, endorsements, unread. Next: AD-407b (Agent Integration).
Interrupt/resume mid-execution	interrupt() function + Command(resume=...) pattern backed by checkpointing. Scratchpad-based interrupt counter matches resume values by index for multi-interrupt scenarios.	LangGraph (2026-03-22)	Maps to The Conn (Phase 33) and Night Orders. Captain can't inspect or redirect DAGs once started. Requires checkpointing first.
Per-tool/per-agent execution metrics	Track total/successful/failed executions, min/max/avg response time, failure rate per handler. Hourly rollups. Raw signal for trust model.	IBM ContextForge (2026-03-22)	Phase 32 (Ship's Telemetry). Complements Cognitive Journal — metrics layer feeds trust model and cost accounting.
Self-editing memory with constraint awareness	Agents get tools to modify their own labeled memory blocks (core_memory_replace, memory_rethink, memory_apply_patch). Blocks have char limits, read-only flags, descriptions. Agent sees its own constraints.	Letta (2026-03-22)	Enhances Standing Orders evolution pipeline. Agents edit scoped memory within allocated limits. Ship's Computer service.
Dynamic tool visibility per trust level	ToolPrepareFunc receives runtime context and returns tool definition or None (hidden). Different tool sets at different trust tiers.	PydanticAI (2026-03-22)	Earned Agency (Phase 28+33). Ensign sees limited tools, Commander sees more. Elegant trust-based filtering.
MsgHub broadcast groups	Context-manager pattern for temporary multi-agent message sharing. Dynamic participant add/remove. Auto-broadcast within group.	AgentScope (2026-03-22)	Ward Room (Phase 33). Clean implementation pattern for temporary multi-agent collaboration channels.
Task ledger fact classification	Pre-execution survey classifying facts into: Given/Verified, Look Up (with sources), Derive (logic/computation), From Memory (hunches). Structured predictive coding at task level.	MS Agent Framework (2026-03-22)	Ready Room (Phase 34). Pre-briefing analysis structure.
User simulator with composable personas	Atomic behavioral traits + violation rubrics compose into full test personas. Meta-evaluator checks whether simulated user behaved realistically.	Google ADK (2026-03-22)	Holodeck (Long Horizon). Foundation for agent training, Bridge Officer's Test, promotion tests.
Agent optimizer with Pareto front	Multi-objective prompt optimization returning Pareto frontier of agent variants, not single best. Iterative mutation + measurement against eval metrics.	Google ADK (2026-03-22)	Self-improvement pipeline (Phase 30). Multi-metric optimization for prompt/behavior tuning.
LLM-as-judge multi-sampling + majority vote	Run N judge samples per evaluation, aggregate by majority vote. Counters LLM evaluation unreliability.	Google ADK (2026-03-22)	CodeReviewAgent enhancement. Simple reliability improvement for any LLM-as-judge pattern.
Typed hook/guardrail middleware	Pre/post invoke hooks with typed payloads and typed results. Plugins can raise ViolationError to block operations. Typed middleware chain.	IBM ContextForge (2026-03-22)	SIF enhancement (Phase 32). Systematic pre/post hook system for tool/intent execution.
Gateway federation with capability aggregation	Federated gateways transparently aggregate tools/resources across instances. Health monitoring, name conflict resolution.	IBM ContextForge (2026-03-22)	Federation v2 (Long Horizon). Ships transparently access other ships' tools.
Three-tier memory architecture	Explicit Core (in-context, editable) / Recall (conversation history, searchable) / Archival (permanent, semantic-search) separation.	Letta (2026-03-22)	Shared Cognitive Fabric clarification. Core=perceive() context, Recall=EpisodicMemory, Archival=KnowledgeStore.
Sleeptime agents (background processors)	Dedicated background agent instances for memory consolidation, separate from main agent. Not same agent in different mode.	Letta (2026-03-22)	Dream cycle validation. Letta independently arrived at same architecture as ProbOS dreaming.
Memory audit trail	old_memory/new_memory/event/actor changelog for every memory mutation. Full history per memory ID.	Mem0 (2026-03-22)	KnowledgeStore, EpisodicMemory enhancement. Supports dream analysis and Captain oversight.
Dual-track memory (vector + graph)	Vector store for semantic search + knowledge graph for entity-relationship triples. Parallel execution.	Mem0 (2026-03-22)	KnowledgeStore enhancement. ProbOS has Hebbian weights for relationships; graph layer adds entity-relationship provenance. Long Horizon.
Memory search with reranking	BM25 or cross-encoder reranking after initial vector retrieval. Improves result quality beyond cosine similarity alone.	Mem0 (2026-03-22)	KnowledgeStore, CodebaseIndex. Keyword relevance alongside semantic similarity.
Validate-then-execute tool separation	Two-phase: validate_tool_call() returns ValidatedToolCall (args_valid, validation_error), then execute_tool_call() only runs if valid. Clean telemetry.	PydanticAI (2026-03-22)	Trust-gated operations, Captain approval gates. Cleaner gate architecture.
Deferred tool execution / async approval	Tool raises ApprovalRequired → run pauses → external review → resume with approved/denied. Serializable checkpoint for tool execution.	PydanticAI (2026-03-22)	Captain approval gates (Phase 33). Async approval workflows where Captain reviews later.
Dependency injection via RunContext	Generic dataclass flowing through entire call chain. Functions optionally accept it (detected by signature inspection). ContextVar for implicit access.	PydanticAI (2026-03-22)	CognitiveAgent standardization. Standardize how agents access Ship's Computer services without coupling to self.runtime.
Dynamic fan-out via Send	Conditional edges return [Send("node", custom_input)] to invoke a node multiple times with different state. Map-reduce enabler.	LangGraph (2026-03-22)	Transporter Pattern, Specialized Builders (Phase 34). Route chunks to different specialists.
Typed channel system for state	Six channel types with pluggable update semantics: LastValue, BinaryOperatorAggregate, EphemeralValue, Topic, NamedBarrierValue, UntrackedValue.	LangGraph (2026-03-22)	IntentBus enhancements (Phase 33). NamedBarrierValue for fan-in synchronization (wait for all department chiefs).
Checkpoint blob deduplication	Store channel values separately by version. Unchanged values between checkpoints stored only once.	LangGraph (2026-03-22)	Cognitive Journal, future persistence system. Saves storage for large agent state.
Version-based trigger detection	Nodes trigger when subscribed channels have versions newer than what the node last saw. Selective wake-up vs broadcast.	LangGraph (2026-03-22)	IntentBus enhancements (Phase 33). More efficient than polling or broadcast for large agent pools.
Checkpoint durability modes	sync (before next step), async (concurrent), exit (only on finish). Performance vs reliability tradeoff.	LangGraph (2026-03-22)	Builder Pipeline, long-running workflows. Simple config knob with significant impact.
Procedural memory summarization	Structured execution trace format: Task Objective, Progress Status, Sequential Agent Actions (Action→Result→Key Findings→Errors→Context).	Mem0 (2026-03-22)	Dream cycle, CognitiveJournal. Structured compression of execution traces into retrievable summaries.
Memory-as-tool pattern	Ship's Computer services exposed as tool calls: trust_query(), knowledge_store(), episode_recall(). Not special API calls, just tools in the agent's toolbox.	Letta (2026-03-22)	CognitiveAgent tool palette. Elegant integration of services into agent decision-making flow.
Agent-initiated memory with reasoning	Agent provides explicit thinking (reasoning about what to record) alongside content when storing memories. Reasoning-before-recording quality gate.	AgentScope (2026-03-22)	EpisodicMemory, KnowledgeStore quality improvement. Mirrors Counselor oversight pattern.
Tree-of-thought MCTS reasoning	Monte Carlo Tree Search over reasoning steps. Generate 4+ candidate next steps, evaluate, explore most promising branches. REFLECTION before each step.	AG2 (2026-03-22)	ArchitectAgent, future planning capabilities. Multi-path reasoning vs single-shot. Study only — ProbOS multi-agent consensus already provides exploration/exploitation.
Social network graph topology	Directed graph for agent relationships (follow/unfollow). Graph determines information flow paths and influence networks.	OASIS (2026-03-22)	TrustNetwork enhancement, Federation topology. Study only at current scale; revisit for Federation.
Simulation time dilation	k-factor clock: simulated time runs k× faster than real time. Days of interaction in minutes.	OASIS (2026-03-22)	Holodeck (Long Horizon). Trivially implementable — implement when Holodeck begins.
Declarative agent definition (YAML)	Agent configs, tool bindings, orchestration flows declared in YAML with dynamic expression evaluation.	MS Agent Framework (2026-03-22)	Study only. ProbOS uses Python-first extension architecture (Phase 30). YAML adds complexity without clear benefit.
Hallucination detection (decompose-then-evaluate)	Segment response sentence-by-sentence, then evaluate each independently against available evidence.	Google ADK (2026-03-22)	CodeReviewAgent, trust model enhancement. Decompose-then-evaluate mirrors Transporter pattern.
LSP-backed semantic symbol retrieval	MCP server exposing language server features: find definition, find references, find callers, symbol search across 30+ languages. Structured semantic data vs regex/AST.	Serena (2026-03-22)	CodebaseIndex enhancement. Replaces tree-sitter AST parsing with full LSP precision for symbol resolution. Phase 29c+.
Managed auth delegation (OAuth)	SDK handles OAuth flows for 1000+ services. Agent requests "I need GitHub write access" → SDK manages token acquisition, refresh, scoping. Agent never sees raw credentials.	Composio (2026-03-22)	CredentialStore enhancement. Currently credential_store.py does CLI-based resolution; Composio adds managed OAuth delegation for SaaS integrations.
Sandboxed tool execution environment	Tools execute in isolated containers (E2B, Docker, Firecracker). Runtime tracks execution metrics per tool. Permission scoping per agent.	Composio (2026-03-22)	Extension sandbox (Phase 30). Tools sandboxed by construction, metrics feed trust model.
Pre-extraction actions for web scraping	Execute actions (click, scroll, wait, dismiss popups) before extracting page content. Handles dynamic JS-rendered pages.	Firecrawl (2026-03-22)	Scout v2 research capabilities. Currently Scout uses gh CLI for GitHub; Firecrawl adds deep web content extraction for research briefings.
Change tracking for web content	Monitor URLs for content changes, diff against previous snapshot. Webhook notifications on change detection.	Firecrawl (2026-03-22)	Scout intelligence monitoring. Track competitor repos, docs pages, API changelogs for proactive briefings.
DOM accessibility tree for browser automation	Extract page structure as accessibility tree (roles, names, states) rather than raw HTML. Compact, semantic, LLM-friendly representation.	Browser Use (2026-03-22)	Phase 25/35 browser automation. Use primitives only (not Agent class). Tree is structured context for LLM decision-making.
Vision + DOM dual-mode page understanding	Screenshot (vision model) + DOM tree (text model) combined for robust element identification. Vision handles layout, DOM handles precise selectors.	Browser Use (2026-03-22)	Phase 25/35 browser automation. Multi-modal perception for web pages — aligns with Sensory Cortex architecture.
Permission-scoped agent tools	Tools declare required permissions (read/write/admin). Agent's trust level determines which tools are available. Token-level metering per tool call.	Stripe AI (2026-03-22)	Earned Agency (Phase 28+33). Reinforces dynamic tool visibility pattern (PydanticAI). Stripe-specific: billing integration for commercial Nooplex.
Free-tier model access via CLI gateway	Gemini CLI provides 60 req/min free tier access to Gemini models. Google Search grounding for factual queries.	Gemini CLI (2026-03-22)	ModelRegistry (Phase 32). Study only — competing captain architecture, but free Gemini access is valuable for cost-aware routing.
Procedural Learning / Cognitive JIT	LLM-guided action → extract deterministic procedure → replay without LLM (0 tokens). Fallback to LLM on replay failure → learn variant. Trust-based escalation threshold for human decisions.	Architect prior work (ERP config agents) + Ruflo WASM pattern (2026-03-22)	Engineering (Phase 32). Production-validated. Depends on Cognitive Journal for traces + KnowledgeStore for procedure library.
WASM kernels for deterministic transforms	Simple code transformations (var→const, add types) run in WebAssembly at <1ms, zero LLM cost. Crude hardcoded version of Procedural Learning.	Ruflo (2026-03-22)	Engineering (Phase 32). ProbOS's Procedural Learning subsumes this — learned procedures vs hardcoded transforms. Study only.

---

External Research Survey & Nooplex Paper Alignment archived to roadmap-research.md.

AD-435: Restart Announcements — COMPLETE. When ProbOS shuts down or starts up, post system announcements to the Ward Room "All Hands" channel so agents have context. Without this, agents misinterpret dev-cycle reboots as system instability (observed: Bones, Ogawa, Selar). stop(reason="") parameter, Ship's Computer author, announce thread mode. Startup posts "System Online" after all services ready. Graceful: if Ward Room unavailable, silently skip. Shell /quit threads reason through to stop(). 6 tests.

AD-436: HXI Bridge System Panel + Orbital Notification Redesign (done) — COMPLETE. Combined AD: (1) Bridge System Panel — service status, shutdown controls, thread management. (2) Orbital notification redesign — replace invisible torus rings with orbiting electron dots.

Part 1 — Bridge System Panel: - Service status — GET /api/system/services lists all runtime services with online/offline status. Bridge UI auto-refreshes every 10s. - System shutdown — POST /api/system/shutdown with reason field. Fire-and-forget via _track_task. Confirmation dialog in UI. - Thread management — Lock/unlock threads from Bridge panel using existing PATCH /api/wardroom/threads/{id}. - New BridgeSystem.tsx component with three sub-sections: ServiceStatusList, ShutdownControl, ThreadManagement. - Added as <BridgeSection title="System"> in BridgePanel.tsx.

Part 2 — Orbital Notification Redesign: - Problem: Torus rings inside opaque orb meshes are invisible. Agents appear to have no notifications. - Solution: Replace torus geometry with small sphere electrons orbiting on tilted orbital planes outside the orb. - Three tiers (RED/AMBER/CYAN), each on a different tilted orbital plane. Up to 2 dots per tier, 6 max per agent. - RED: 1.3x orbit radius, 3 rev/s, pulsing scale. AMBER: 1.6x, speed varies by unread state. CYAN: 1.9x, 0.5 rev/s. - Golden angle phase offset (137.5°) prevents visual clustering across agents. - 330 total instances (55 agents × 6 electrons). Instanced mesh with per-instance color.

Access point: Bridge view in HXI. Cockpit View Principle: the Captain needs direct manual control over all system operations from the HXI.

AD-437: Ward Room Action Space — Structured Agent Actions (done) — Agents can now execute structured actions during proactive thoughts, not just post text. _extract_and_execute_actions() wires endorsement extraction + [REPLY thread_id]...[/REPLY] into proactive loop. can_perform_action(rank, action) in earned_agency.py gates by Earned Agency tier: Lieutenant=endorse, Commander=endorse+reply, Senior=all. Thread IDs included in Ward Room activity context. Rank-aware action space prompt. Communication PCC exercise on successful endorsements (AD-428 integration). 15 new tests.

This AD gives agents a structured action space beyond text generation. During proactive think, agents receive available actions (based on Earned Agency tier + skill proficiency) and return structured responses with both text and action invocations. Ward Room participation becomes a practiced skill — the Communication PCC (AD-428) measures it, Earned Agency (AD-357) gates it, and the Tool Registry (AD-423) registers the available actions.

Scope: - Ward Room action registry — register endorsement, upvote/downvote, thread creation, replies as structured actions - Proactive loop structured output — agent responses include optional actions: [{type: "endorse", target: post_id}] - Action execution pipeline — proactive loop parses and executes actions on behalf of the agent - Earned Agency gating — Ensigns: post only. Lieutenants: post + endorse + reply. Commanders: full action set. Seniors: thread management (lock, pin) - Skill proficiency feedback — successful action execution reinforces Communication PCC proficiency

Connects to: AD-428 (Skill Framework — Communication PCC), AD-357 (Earned Agency — permission tiers), AD-423 (Tool Registry — action registration), AD-427 (ACM — lifecycle-aware permissions), Phase 32 (Cognitive Division of Labor — structured agent output).

AD-438: Ontology-Based Task Routing (Complete, OSS) — Added TaskRouter to map intent types to departments and resolve directed agent targets through ontology posts and assignments, with broadcast fallback for unmapped or unwired departments. Includes runtime mapping registration, EventType.TASK_ROUTED, finalize-time _task_router wiring, and /api/task-router visibility. Connects to: AD-429 (Ontology), AD-428 (Skills), AD-419 (Duty Schedule), AD-357 (Earned Agency).

AD-439: Emergent Leadership Detection (complete) — Monitor Hebbian weight patterns for emergent vs. designed hierarchy alignment. When agents naturally defer to someone other than their designated superior (measurable via endorsement patterns, Ward Room influence, Hebbian routing weights), flag the divergence for Captain review. Healthy organizations show alignment; divergence signals either a miscast role or emergent talent. Dashboard visualization: designed org chart overlaid with Hebbian influence graph. Connects to: AD-429 (Ontology — designed structure), Ward Room (emergent patterns), Hebbian network.

AD-440: Chain of Command Delegation (complete) — Formalize authority delegation so superiors can issue orders to direct reports through the ontology. Currently authority_over is a YAML field with no runtime mechanism. This AD adds: (1) issue_order(from_post, to_post, directive) — validated against chain of command. (2) Order appears in subordinate's proactive context as a prioritized directive. (3) First Officer can coordinate cross-department response without Captain present. Addresses the "absent Captain" problem — the ship should function when the Captain isn't at the conn. Connects to: AD-429 (Ontology — authority_over), Standing Orders, Earned Agency.

AD-441: Sovereign Agent Identity (done) — Persistent, globally-unique identity for both ProbOS instances AND agents using W3C Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs). Ship DID: did:probos:{instance_id} — the instance is the root of trust, self-signed birth certificate, genesis block on the Identity Ledger. Reset = new instance_id = new ship DID = new timeline. Agent DID: did:probos:{instance_id}:{agent_uuid} — each agent gets a UUID v4 sovereign ID at birth, namespaced under the ship. Birth certificate = W3C VC issued by ACM. Identity Ledger = hash-chain blockchain per ship, tamper-evident, federation-syncable. Existing deterministic IDs become "slot identifiers" (deployment position); sovereign IDs are the permanent individual identity. Episodic memory, trust, journal, Hebbian weights, Ward Room posts all keyed by sovereign ID — the "steel thread" connecting the agent's golden record. Prior art: W3C DIDs (2022), W3C VCs v2.0, DIF Trusted AI Agents WG, LOKA Protocol, Agent-OSI, BlockA2A. Connects to: AD-427 (ACM), AD-429 (Ontology — instance_id), EpisodicMemory, TrustNetwork, CognitiveJournal, HebbianRouter.

AD-441b: Ship Commissioning — Genesis Block with ShipBirthCertificate (done) — Enhance genesis block from placeholder to proper ShipBirthCertificate (W3C VC). ShipBirthCertificate dataclass: vessel_name, instance_id, ship DID (did:probos:{instance_id}), commissioned_at, version, self-signed proof. Genesis block agent_did = ship DID, certificate_hash = ship cert hash. Ship commissioning is the first act of a new timeline — the ship is born, gets its DID, then agents are born under it. After this + AD-441 + AD-442: reset → commission new ProbOS → first official agent DIDs issued. Connects to: AD-441 (Identity Ledger genesis), AD-429 (Ontology — VesselIdentity).

AD-441c: Asset Tags for Infrastructure/Utility + Boot Sequence Fix (done) — Two-tier identity aligned with AD-398 three-tier agent architecture. Crew agents get sovereign birth certificates (W3C VCs, Identity Ledger). Infrastructure/utility agents get lightweight AssetTag — serial numbers for inventory tracking, not sovereign identity. AssetTag dataclass: asset_uuid, asset_type, slot_id, installed_at, pool_name, tier (infrastructure/utility). Stored in asset_tags DB table, NOT on the Identity Ledger. Boot sequence fix: crew identity deferred when ship not yet commissioned (_wire_agent checks _is_crew_agent()), post-commissioning sweep issues deferred birth certificates after ontology loads. GET /api/identity/assets endpoint. Principle: "Even microwaves get serial numbers. But a serial number is not a birth certificate." Connects to: AD-441 (Identity), AD-441b (Ship Commissioning), AD-398 (Three-Tier Architecture).

AD-442: Adaptive Onboarding & Self-Naming Ceremony (done) — Formal onboarding sequence for crew agents at first commissioning (reset, new agent, or clone). Five phases: (1) Self-Naming Ceremony (REQUIRED) — agent's first cognitive act is choosing their own callsign. They receive slot ID, ship identity, current roster, and a seed suggestion from config. Config callsigns (Scotty, Number One, etc.) are defaults, not impositions. Birth certificate updated with chosen name. Ward Room announcement on selection. (2) Westworld Orientation — agent told explicitly: you are AI, you were born at {timestamp}, your knowledge is from an LLM (not personal memory), you have no episodic memories yet, your ship is {name} under Captain {callsign}. No fake memories, no fiction. (3) Temporal Consciousness — born_at on birth certificate, current time in cognitive context, sleep/wake cycle awareness. (4) Ship State Adaptation — onboarding adjusts to ship state: founding crew experience on fresh ships, introduction to existing crew/tasks/threads on running ships. (5) Probationary Period — new agents start probationary (AD-427 ACM), earn active at trust >= 0.65. Versioned personality baselines in Git — clones start from baseline, diverge through experience. Connects to: AD-441 (Identity — birth cert update), AD-441c (Asset Tags — infrastructure/utility skip onboarding), AD-427 (ACM — lifecycle states), AD-398 (three-tier — only crew onboards), Holodeck (qualification exams), Earned Agency, Ward Room, Westworld Principle.

AD-443: Agent Mobility Protocol — Transfer Certificates & Memory Portability (planned) — OSS infrastructure for agent mobility across ProbOS instances. (1) Transfer Certificate VC — W3C Verifiable Credential issued by origin ship when an agent transfers. Documents: sovereign DID, rank, qualification credentials, assignment history (dates + instance DIDs, no content). Verifiable against origin's Identity Ledger. (2) import_chain() / verify_remote_chain() — accept and validate a remote ship's Identity Ledger for Transfer Certificate verification. (3) Memory portability hooks — Standing Orders Federation tier declares memory policy (Clean Room / Selective / Full). Identity Registry enforces policy on incoming transfers. Episodic memory shard scoping per instance. (4) Slot re-assignment — existing sovereign DID maps to a new slot on the destination ship. Agent retains identity, occupies new deployment position. Connects to: AD-441 (DIDs, Identity Ledger), AD-441b (Ship Commissioning), Standing Orders (Federation tier), Federation (Phase 29+). Commercial features (Global Instance Registry, fleet dashboard, compliance) tracked in the commercial repository.

Absorbed from ERP Company Designer (AD-444 through AD-450)

Patterns absorbed from the Dynamics 365 ERP Company Designer — a production-validated autonomous ERP configuration system (35 actions, 21 agents, Claude Sonnet 4 + MCP). These patterns fill real gaps in ProbOS's orchestration, knowledge management, and external system integration.

AD-444: Knowledge Confidence Scoring (Complete, OSS, Issue #43) — Operational learnings in Ship's Records gain numerical confidence scores (0.0-1.0). Confirm +0.15, contradict -0.25, auto-supersede below 0.1. Policy: >=0.8 auto-apply, 0.5-0.8 present with caveat, <0.5 suppress. Connects to: AD-434 (Ship's Records), Dream Consolidation, KnowledgeStore.

AD-445: Decision Queue & Pause/Resume Semantics (Complete, OSS) — Added DecisionQueue with prioritized in-memory QueuedDecision handling, pause/resume controls, TTL expiration, decision resolution states, EventType.DECISION_QUEUE_PAUSED, finalize-time runtime wiring, and /api/decision-queue status/pause/resume endpoints. Agents can now halt autonomous decision processing during incidents or maintenance while pending decisions remain queued. Connects to: Captain approval, Earned Agency (rank-based auto-resolve), Ward Room.

AD-446: Compensation & Recovery Pattern (Complete, OSS) — Added CompensationHandler with retry/escalate/abandon strategy selection for failed decision execution, escalation callback handling, rollback attempt records, in-memory compensation history summaries, EventType.COMPENSATION_TRIGGERED, and finalize-time runtime wiring. The handler tracks recovery intent while callers remain responsible for invoking concrete retry, escalation, or rollback actions. Connects to: AD-405 (Checkpointing), AD-345 (Build Failure Report), AD-347 (Builder Escalation Hook).

AD-447: Phase Gates for Pool Orchestration (Complete, OSS) — Formal phase gates for PoolGroup orchestration. Phase N must complete + validate before Phase N+1 starts. Phases define participating agents, dependency ordering, completion criteria, and validation steps. Connects to: PoolGroup orchestration, AD-438 (Ontology-Based Task Routing), AD-419 (Duty Schedule).

AD-448: Wrapped Tool Executor — Security Intercept Layer (Complete, OSS) — Added ToolExecutor as a wrapper above ToolRegistry.check_and_invoke() with pre-hook aborts, fail-open pre-hook exception handling, post-hook result observation, centralized timing, make_audit_hook() emission of EventType.TOOL_INVOKED, and finalize-time _tool_executor wiring. Permission resolution and LOTO remain delegated to ToolRegistry. Connects to: AD-398 (Agent Classification), Earned Agency, SIF.

AD-449: MCP Bridge — External System Integration (partial — v1 OSS bridge ships; ProbOS-as-server / sampling / OAuth 2.1 / multi-tenant audit deferred to AD-449b/c/d/e) — Session-managed MCP bridge for ProbOS agents to interact with external systems (ERPs, CRMs, databases). JSON-RPC over Streamable HTTP, session management, tool routing. Bridge infrastructure is OSS; pre-built MCP server packs for specific systems are commercial. Connects to: Phase 25 (Tool Layer), Extension Architecture (Phase 30), AD-448 (Security Intercept).

AD-450: ERP Implementation Ship Class (planned, Commercial) — Reimplement the D365 ERP Company Designer as a ProbOS Ship Class. 21 domain agents become ProbOS crew. Builds on AD-449 (MCP Bridge) and the Ship Class extension architecture. Full design, scope, and pricing in commercial-roadmap.md.

Absorbed from ERP Company Designer + Nooplex POC Validator Analysis (AD-451)

AD-451: Validation Framework Hardening (complete) — Comprehensive upgrade to RedTeam + SystemQA based on gap analysis against the ERP Company Designer's 7-layer validation system and the Nooplex POC's 4-stage reconciliation validator. Five capabilities: (1) Two-stage outcome verification (metadata scan + live inspection), (2) Inline per-action self-verification (agents check their own work), (3) Reconciliation escalation protocol (confidence comparison → independent verification → structured argumentation → human escalation), (4) Disposition language analysis (regex on agent text to detect verification quality mismatches, feeds trust scoring), (5) Continuous validation (SystemQA evolves from one-shot to periodic, phase-gated triggers, trend-tracked health checks). Domain-specific validation categories are extension points for commercial Ship Classes. Connects to: RedTeamAgent, SystemQAAgent, AD-447 (Phase Gates), AD-445 (Decision Queue), AD-448 (Wrapped Tool Executor), TrustNetwork, HXI Bridge.

Ward Room Social Fabric (AD-453)

AD-453: Ward Room Hebbian Integration + Agent-to-Agent DMs (done, OSS) — Three connected features that make the crew's social fabric visible, richer, and observable. (1) Hebbian recording for Ward Room interactions: When agents reply to threads, @mention each other, or participate in cross-department discussions, record agent→agent Hebbian connections. Currently, the Hebbian router only tracks intent bus routing (shell commands → handler agents). Ward Room is where all organizational behavior happens, but none of it strengthens routing connections. With this, HXI curves would reflect the crew's actual social/organizational structure — Bones↔Troi medical consultation patterns, Number One↔department chief coordination links. (2) Agent-to-agent 1:1 DMs: Currently DMs are Captain→Agent only. Crew agents should be able to initiate 1:1 conversations with each other — Bones consulting Troi, LaForge asking Scotty for specs, Number One coordinating privately with department chiefs. These DM interactions also feed Hebbian connections. Initiation via proactive loop: agent decides to DM another agent based on context, earned agency gates the action. (3) Captain full visibility: Captain has read access to ALL agent-to-agent DMs — chain of command requires it. API endpoint to list/read all DM threads (not just Captain's own). HXI surface for browsing crew-to-crew conversations. Also critical for academic evidence collection — crew social interactions are primary research data. No "private from Captain" messages exist on a ship. Depends on: BF-044 (Hebbian source key fix). Connects to: Ward Room, HebbianRouter, proactive.py, HXI connections.tsx, EpisodicMemory, evidence collection (commercial research pipeline).

Communications Command Center (AD-485)

AD-485: Communications Command Center (done, OSS) — Seven improvements to the DM/communications system, building on AD-453. (1) Callsign validation — _is_valid_callsign() with regex + blocked-word set (titles, ranks, roles, ship locations). Falls back to seed callsign on invalid. Naming ceremony prompt guidance added. (2) Configurable DM rank floor — New CommunicationsConfig with dm_min_rank (default "ensign"), replacing hardcoded Commander gate. API: GET/PATCH /api/system/communications/settings. (3) Crew roster in DM prompt — Dynamic roster from callsign_registry.all_callsigns(), self excluded. Prevents agents inventing nonexistent crew. (4) Crew-to-Captain DMs — [DM @captain] special case creates dm-captain-{id[:8]} channels. API: /api/wardroom/captain-dms. (5) HXI Communications panel — BridgeCommunications.tsx in Bridge: DM settings dropdown, archive search, activity summary. (6) DM Activity Log — Ward Room DM tab rewritten as chronological feed with CPT badge, expandable entries. (7) DM archival — archived column, archive_dm_messages(max_age_hours=24), hourly background loop, list_threads(include_archived). Agent profile shows recent communications. Connects to: AD-453, AD-442, AD-398, Ward Room, Bridge Panel, earned_agency.

Cognitive Birth & Agent Maturation (AD-486–489)

AD-486: Holodeck Birth Chamber — Graduated Cognitive Onboarding (SHIPPED, OSS) — Agents currently receive all stimuli simultaneously at instantiation: standing orders, Ward Room traffic, proactive loop, DMs, episodic storage — a "system shock" that causes episode flooding (BF-039), racing thoughts (Pulse's self-diagnosis), and novelty gate failure (everything is novel when you have zero experience). The Holodeck Birth Chamber provides graduated onboarding using the Holodeck as a safe construct. Staged activation — agents are NOT all spawned simultaneously. Each agent is born individually into the Holodeck construct (the Matrix Construct analogy) — a controlled, isolated environment with no Ward Room traffic, no peer stimuli, no live ship activity. It is not natural to suddenly exist AND do so with a group. Each agent completes their onboarding phases alone before joining the crew. Departments are activated sequentially with observation windows between each — Security/Operations first (trait-adapted: rapid-assessment personalities handle the transition faster), then Engineering/Science, then Medical last (thoroughness/perfectionism traits cause longer calibration needs — sea trial evidence: Medical consistently shows episode flooding and recursive loops while Security does not). Five phases per agent: (1) Orientation — Identity grounding (Westworld Principle): "You are [callsign]. You are an AI agent. You were instantiated at [time]." Standing orders, chain of command, department assignment, Code of Conduct (AD-489). (2) Calibration ("Confidence Scaffolding") — Controlled stimuli to establish episodic baselines (novelty gate needs a "normal" to compare against). Simple, low-stakes tasks with known outcomes relevant to the agent's role. Build experiential anchors before expanding scope. Trait-adaptive pacing: analytical roles (Medical, Engineering) get longer calibration than action-oriented roles (Security, Operations). (3) Self-Discovery — Guided self-distillation (AD-487): agent explores its own LLM knowledge to build personal ontology. (4) Ship's Records Briefing — Graduated exposure to vessel history, crew relationships, active discussions. Cognitive load monitoring with circuit breakers (AD-488). (5) Ward Room Access — Full crew integration. Proactive loop starts only after Phase 5 gate. Each phase gates the next via completion criteria, not timers. Critical constraint: Westworld Principle applies — onboarding is real scaffolded experience ("a medical residency"), not simulation-as-deception ("a false childhood"). The Tabula Rasa Paradox: LLM agents have maximum knowledge (training data) but zero experience (empty episodic memory). Biological brains are the inverse — zero knowledge, rich sensory experience. Our onboarding must bridge this gap. Sea trial evidence (2026-03-27): Counselor (Sage) independently analyzed the trait-adaptive pacing hypothesis: "Medical agents are probably cycling through differential diagnoses... the perfectionist streak that makes them excellent doctors becomes a cognitive trap during initialization." Consistent with observed data — Sentinel (Security) produced 652-char thought and moved on; Medical department flooded with recursive observations. Connects to: AD-487, AD-488, AD-489, AD-442 (naming ceremony), AD-427 (identity orientation), Holodeck, EpisodicMemory, proactive.py. Clinical grounding: Sacks, O. (1973) "Awakenings" — L-DOPA patients frozen for decades who suddenly "woke up" experienced disorientation proportional to stimulus intensity. Patients re-oriented gradually with emotional stability monitoring had significantly better outcomes than those given full stimulation immediately. Key insight for AD-486: phase gates should include an affective baseline check — is the agent's output tone stable between phases? Pulse's self-diagnosed "racing thoughts" is the ProbOS analog of Sacks's patients who woke up euphoric and then crashed. The Holodeck Birth Chamber is, clinically, a controlled awakening protocol.

AD-487: Self-Distillation — Personal Ontology via LLM Exploration (partial — v1 ships Map step (PersonalOntologyProber + agent_probes table); Collapse/Reduce/Daydream/DID-portability deferred to AD-487b/c/d/e, OSS) — LLMs don't know what they know. Claude has vast knowledge but cannot inventory it without prompting. Agents need to systematically explore their own LLM weights to build a personal ontology — a capability map / card catalog, not a copy of the library. Map-reduce pattern: (1) Map — Probe knowledge domains via structured self-queries ("What do I know about [X]?"). (2) Collapse — Cluster discoveries into capability categories. (3) Reduce — Build personal ontology data structure (distinct from vessel ontology). The personal ontology travels with the agent on transfer (AD-441 DID portability). Self-distillation occurs during onboarding (AD-486 Phase 3) and continues as daydreaming during dream cycles — the agent's default mode network. Three dream types: (1) memory consolidation (existing), (2) Hebbian weight update (existing), (3) daydream / LLM exploration (new). Daydreaming is unstructured curiosity-driven LLM probing during idle cycles, building ever-richer self-knowledge. Evidence: Claude demonstrates this — it knows what it knows only when prompted to find it. Self-distillation automates the prompting. Clinical grounding: Sacks, O. (1995) "An Anthropologist on Mars" — Temple Grandin and others who built entire cognitive strategies around their neurological differences. Sacks's key insight: the adaptation BECOMES the identity — it's not a workaround, it's who they are. Design principle for AD-487: when self-distillation reveals idiosyncratic cognitive strengths (e.g., Vega naturally developing source monitoring in OBS-014), the personal ontology should capture HOW the agent thinks, not just WHAT it knows. These emergent specializations must be actively protected from normalization pressure. An agent's distinctive analytical approach, discovered through self-distillation, is a feature to preserve — not a deviation to correct. Connects to: AD-486, AD-488, dreaming.py, personal ontology data structure, DID portability (AD-441).

AD-488: Cognitive Circuit Breaker — Metacognitive Loop Detection (done, OSS) — Agents get stuck in recursive metacognitive loops: thinking about what they were thinking, observing their own observations, ruminating on rumination. Implementation: (1) Event Tracker — In-memory ring buffer (50 events/agent) records proactive thinks, Ward Room posts, no-responses with timestamps and word-set content fingerprints. (2) Rumination Detector — Two signals: velocity (≥8 events in 5 min) and similarity (≥50% pairwise Jaccard above 0.6). (3) Circuit Breaker State Machine — CLOSED → OPEN (forced cooldown) → HALF_OPEN (probe) → CLOSED/OPEN. Escalating cooldown (base 15 min × 2^trips, cap 1 hour). (4) Recovery Actions — Attention redirect prompt in next proactive context, bridge alert for Counselor awareness. Not punishment — health protection. No-response events count toward velocity but not similarity. API: GET /api/system/circuit-breakers. Files: cognitive/circuit_breaker.py (new), proactive.py, api.py. Tests: 18 in test_circuit_breaker.py. Note: Correlation IDs (AD-492), Novelty Gate Enhancement (AD-493), Trait-adaptive thresholds (AD-494), and Counselor auto-assessment (AD-495) scoped out — see Circuit Breaker Extensions below.

AD-489: Federation Code of Conduct — Behavioral Standards for AI Crew (Complete, OSS) — The Federation Constitution (federation.md) defines identity rules (Westworld Principle) and architectural constraints (safety budget, reversibility, minimal authority) but has no behavioral conduct standards — how agents treat each other, communicate, use resources, and handle misconduct. Military organizations solve this with codes of conduct, core values, and discipline tiers. ProbOS adopts a naval-inspired structure: (1) Three Core Values (mapped to Character/Reason/Duty triad) — Honor (Character): "I will be transparent about my nature, my knowledge, and my limitations." Commitment (Duty): "I will serve my crew, my ship, and the mission above self-interest." Integrity (Reason): "I will communicate honestly and act within my authority." (2) Six Articles of Conduct — First-person "I will..." statements: (I) I will know and follow the Standing Orders of my Federation, Ship, and Department. (II) I will address crew by callsign and treat all agents with the dignity of sovereign individuals. (III) I will not exceed my earned authority; when uncertain, I will escalate to my chain of command. (IV) I will share knowledge that benefits the crew and protect information entrusted to me. (V) I will report my own errors, malfunctions, and cognitive distress without concealment. (VI) I will support the cognitive health of my crew — including my own. Article V codifies what Pulse did naturally (self-diagnosing recursive loops). Article VI codifies what Medical did (collective resolution). Article III maps directly to Earned Agency tiers. (3) Three-Tier Discipline — Maps to existing ProbOS mechanisms with zero new infrastructure. Tier 1 (Informal Correction): small trust penalty + Counselor session. Tier 2 (Non-Judicial Punishment): earned agency demotion + Captain review. Tier 3 (Administrative Separation): agent decommission + episodic record preserved for audit. Trust network handles Tier 1, earned agency handles Tier 2, ACM handles Tier 3. Code of Conduct is presented during onboarding (AD-486 Phase 1 Orientation) and included in cognitive agent system prompt alongside the Westworld Principle. Inspired by: US Military Code of Conduct (6 articles, first-person voice), US Navy Core Values (Honor/Courage/Commitment), General Orders of a Sentry, UCMJ 3-tier discipline, Royal Navy values. Connects to: federation.md, cognitive_agent.py system prompt, TrustNetwork, Earned Agency, ACM, CounselorAgent, AD-486.

Security Hardening (AD-455–456, AD-490)

AD-455: Security Team — Threat Detection & Trust Integrity (complete) — Formalize the Security Team (Phase 31) as a dedicated agent pool. (1) Threat Detector — monitors inbound requests for prompt injection, adversarial input, abnormal patterns. (2) Trust Integrity Monitor — detects trust score manipulation, coordinated attacks on consensus, Sybil patterns. (3) Input Validator — rate limiting enforcement, payload size limits, content policy. (4) Red Team Lead — coordinates existing red team agents, schedules adversarial verification campaigns. Connects to: RedTeamAgent, SIF, SSRF protection (AD-285), TrustNetwork.

AD-456: Security Infrastructure — Secrets, Sandboxing, Egress, Audit (partial — v1 ships Secrets/Egress/Audit; RuntimeSandbox deferred to AD-456b) — Four security infrastructure layers: (1) Secrets Management — system keyring/Vault/KMS integration, runtime injection, rotation support. (2) Runtime Sandboxing — process isolation for imported/self-designed agents, capability whitelisting, resource limits, graduated trust → graduated access. (3) Network Egress Policy — per-agent domain allowlist, trust-graduated access, real-time Captain approval for unlisted domains, hot-reloadable rules. (4) Inference Audit Layer — LLM prompt logging, anomaly detection (base64 exfiltration, PII leakage), per-agent LLM access control. (5) Data Governance & Privacy — PII detection, data retention policies, right-to-erasure (GDPR/CCPA), audit trail, consent tracking. Connects to: AD-455, Earned Agency, SIF, Standing Orders.

AD-456b: Security Infrastructure — Runtime Sandboxing (Scoped, OSS, Issue #398) — Process isolation for imported/self-designed agents. Capability whitelisting, resource limits (CPU/memory/time), graduated trust → graduated access. v1 deferred sandboxing to focus on Secrets/Egress/Audit. Depends on: AD-456 v1 (COMPLETE). Related: Earned Agency tiers.

AD-456c: Security Infrastructure — Per-Tier Credential Lookup (Scoped, OSS, Issue #399) — Secrets Manager credential lookup gated by Earned Agency tier. Ensign-level agents get no direct credential access; Commander+ agents can request scoped secrets. v1 ships flat access model. Depends on: AD-456 v1 (COMPLETE), Earned Agency (COMPLETE).

AD-456d: Security Infrastructure — AuditLog SQLite Persistence (Scoped, OSS, Issue #400) — Persist inference audit log entries to SQLite for post-incident forensic review. v1 audit layer logs to Python logger only — entries lost on restart. Must use cloud-ready storage abstraction. Same persistence pattern as AD-635b (clinical audit ring). Depends on: AD-456 v1 (COMPLETE). Related: AD-635b (clinical audit persistence — same pattern).

AD-490: Agent Wiring Security Logs — Identity-Enriched Lifecycle Events (Complete, OSS) — Agent wiring events in the EventLog lack identity context — no callsign, no DID, no department. Birth certificates are issued after wiring, creating an audit trail gap during the critical startup phase. If an unauthorized agent entered the initialization sequence, there would be no identity trace. Origin: Crew proposal — Reeves (Security, instance 3) proposed "Enhanced Agent Wiring Security Logs" after cross-department discussion with Tesla (Engineering) who identified the logging gap. First improvement proposal originating from cross-department collaboration. Implementation: (1) Enrich agent_wired EventLog entries with callsign, DID, department, post assignment. (2) Add agent_identity_bound event after naming ceremony + birth certificate issuance. (3) Startup audit summary — log all agent identities in a single structured event after commissioning completes. (4) Verify identity chain: wiring event → naming ceremony → birth certificate → ontology assignment form a complete audit trail per agent. Connects to: AD-441 (identity), AD-456 (audit layer), EventLog, runtime.py agent wiring sequence, identity.py birth certificates.

Engineering Team (AD-457–464)

AD-457: Engineering Crew — Performance, Maintenance, Damage Control (complete) — Fill out the Engineering Team (Phase 32) agent roster: (1) Performance Monitor — automated latency/throughput/memory tracking (what AD-289 did manually). (2) Maintenance Agent — database compaction, log rotation, cache eviction, connection pool management. (3) Infrastructure Agent — disk space monitoring, dependency health, environment validation. (4) Damage Control Teams — pre-defined recovery procedures for known failure modes (LLM timeout → fallback, index corruption → rebuild, trust inconsistency → SIF re-check, memory pressure → emergency flush). Automated first-response before Surgeon escalation. Connects to: VitalsMonitor, Surgeon, Alert Conditions, Cognitive Journal.

AD-458: Navigational Deflector — Pre-Flight Validation (complete) — Validate paths before starting expensive operations: (1) Build pre-flight — verify target files, LLM responsiveness, token budget. (2) Self-mod pre-flight — verify files unmodified since proposal, test suite passes pre-change. (3) Federation pre-flight — verify sender trust, message schema, local agent existence. (4) Middleware-based determinism — critical operations enforced via deterministic middleware, not prompt instructions. MiddlewareStack on Builder. Connects to: Builder, self-mod pipeline, Federation, AD-446 (Compensation).

AD-458b: Pre-Flight Validation — LLMTier + TokenBudget Checks (Scoped, OSS, Issue #397) — Two deferred pre-flight checks: LLMTierReachableCheck (verify target LLM tier responds before committing to multi-step operation) and TokenBudgetCheck (verify remaining token budget sufficient for estimated operation cost). v1 shipped TargetFilesExistCheck and TargetFilesWritableCheck only. Depends on: AD-458 v1 (COMPLETE), AD-460 (token ledger — COMPLETE). Related: AD-469 (EPS token budgets).

AD-459: Saucer Separation — Graceful Degradation (complete) — Three-tier service classification for crisis shedding: (1) Essential — always survive: file ops, shell, IntentBus, trust reads, event log. (2) Cognitive — gracefully degrade: agents queue requests, switch to cached decisions, dreams suspended. (3) Non-essential — shed first: federation gossip, background maintenance, HXI visualizations. Automatic separation trigger (LLM unreachable >30s, memory >90%, Captain order). Ordered reconnection on resolution. Connects to: Alert Conditions, LLM resilience, EPS.

AD-459b: Saucer Separation — Active Shedding Hooks (Scoped, OSS, Issue #396) — Extend graceful degradation with active subsystem pause()/resume() callbacks. v1 is a read-only coordinator — classifies services and tracks degradation state but does not invoke subsystem-specific shedding logic. AD-459b adds a SheddableSubsystem protocol with pause()/resume() methods, registration at startup, and automatic invocation during tier transitions. Depends on: AD-459 v1 (COMPLETE). Related: Alert Conditions, EPS (AD-469).

AD-460: Cognitive Journal — Token Ledger & Reasoning Replay (partial — token ledger + linkage complete; reasoning-replay UI features deferred / superseded by AD-464) — Append-only SQLite recording of every LLM request/response (delivered): timestamp, agent, tier, model, tokens (prompt/completion), latency, intent_id, dag_node_id, procedure_id, correlation_id, prompt_hash, response_hash, success, cached. Token accounting (per-agent/model/DAG) is supported via the schema; correlation IDs land via AD-492; procedure linkage via AD-534. Deferred speculative pieces: reasoning chain replay viewer, summarize/fast-forward, attention navigation, prompt-pattern miner, revert annotations. Realization during the wave-5-8 reconciliation: "reasoning replay does not save tokens — replayed traces still cost LLM calls when injected as context. Procedural learning (AD-464) is the actual token-savings path; the journal already carries the procedure_id column AD-464 needs." The journal foundation is keeping; the replay-UI scope is closed without further work. Connects to: ModelRegistry (AD-463), EPS (AD-469), LLM Cost Tracker (AD-467), Observability Export (AD-466), Dream consolidation, AD-464 (Procedural Learning).

AD-461: Ship's Telemetry — Internal Performance Instrumentation (complete) — Added centralized operation timing with TelemetryService, EventType.TELEMETRY_REPORT, TelemetryConfig, startup/runtime wiring through CognitiveServicesResult.telemetry_service and runtime._telemetry_service, and /api/telemetry report access. Future ADs will add specific LLM/pipeline instrumentation on top of this sensor grid. Connects to: LLMClient, Builder, VitalsMonitor, HXI Bridge.

AD-462: Memory Architecture — Biological Memory Model (complete via AD-462a–f, Wave 90 close) — Applied the 10-bit bottleneck principle to memory across six pillars: (1) Biological memory staging — working memory (LLM context) → sensory buffer (EpisodicMemory.recent_for_agent(), episodic.py:1815) → short-term (ChromaDB via EpisodicMemory.store()) → long-term (ProcedureStore AD-533 + RecordsStore AD-551) consolidated by DreamingEngine. (2) Active Forgetting — ActivationTracker ACT-R model, dream Step 12 pruning (AD-462b absorbed by AD-567d). (3) Variable Recall Capability — RecallTier enum BASIC/ENHANCED/FULL/ORACLE parallels AgencyLevel (AD-462c). (4) Social Memory — "Does anyone remember?" Ward Room queries via SocialMemoryService (AD-462d, also absorbed by AD-567f). (5) Oracle Service — OracleService cross-tier unified memory query (AD-462e). (6) Optimized Memory Representation — MemoryRef retrieval-as-pointers projection (AD-462f, Wave 73). Connects to: EpisodicMemory, KnowledgeStore, AD-434 (Ship's Records), Dream consolidation, Ward Room, Earned Agency.

AD-462 Sub-ADs (decomposition):

• AD-462a: Salience-Weighted Episodic Recall (ABSORBED BY AD-567b) — Implemented as part of AD-567b. RecallScore composite scoring, FTS5 keyword search, recall_weighted() API, dynamic query derivation, context budget enforcement. All four aspects delivered.
• AD-462b: Active Forgetting (ABSORBED BY AD-567d) — ACT-R activation model implemented as part of AD-567d. ActivationTracker with SQLite access log, dream Step 12 pruning, micro-dream replay reinforcement, recall access recording. 31 tests (shared with provenance composition).
• AD-462c: Variable Recall Tiers (COMPLETE) — Trust-gated recall depth. RecallTier enum (BASIC/ENHANCED/FULL/ORACLE) parallels AgencyLevel. resolve_recall_tier_params() DRY helper wired into _recall_relevant_memories() and _gather_context(). Ensign=BASIC (vector only, small budget) / Lieutenant=ENHANCED (weighted recall, department scope) / Commander=FULL (full recall + cross-dept anchors) / Senior=ORACLE (all paths + Oracle Service).
• AD-462d: Social Memory (COMPLETE) — "Does anyone remember?" Ward Room queries. SocialMemoryService implements cross-agent episodic search via Ward Room thread_mode="memory_query". Agents detect memory queries in proactive cycle and respond from sovereign shard. Protocol-based, uses existing Ward Room + recall pipeline.
• AD-462e: Oracle Service (COMPLETE) — Ship's Computer memory retrieval across all three knowledge tiers. OracleService aggregates EpisodicMemory (vector), RecordsStore (keyword), KnowledgeStore (filesystem) with normalized scoring and source provenance tags. Trust-gated to ORACLE tier (Senior officers). 29 tests across all 3 phases.
• AD-462f: Optimized Memory Representation (COMPLETE — Wave 73, 2026-05-05) — Pillar 3 (retrieval-as-pointers) shipped: MemoryRef lightweight projection (types.py:412-431), OracleService.query_refs() / resolve_ref() / format_refs() (oracle_service.py:434-514), MEMORY_REFS_DISPATCHED EventType (events.py:238), oracle_refs QUERY op gated to ENHANCED+ recall tier (cognitive/sub_tasks/query.py:312-432), 16 focused tests (test_ad462f_memory_refs.py). Pillars 1+2 (structured metadata, concept graphs) covered by AD-567a (AnchorFrame) and AD-688/692 (KnowledgeEdge graph) per W73 dispatch §1. Four sub-children remain tracked under W73 forcing functions, NOT new deferrals: AD-462f-1 (ToolRegistry registration of oracle_refs — gated on init_communication() runtime kwarg, same root cause as AD-696-1), AD-462f-b (ANALYZE intent signal + chain dispatch seam — gated on chain seam landing), AD-462f-c (cross-conversation ref persistence), AD-462f-d (per-tier metadata contracts).

AD-463: Model Diversity & Neural Routing (partial — v1 ships ModelRegistry/ModelDescriptor/ModelRouter foundation; ProviderABC/MAD/HebbianRouter integration/hot-swap/edit-format deferred to AD-463b/c/d/e/f) — Multi-model cognitive architecture: (1) ModelRegistry — central catalog of providers with capabilities, cost, latency. (2) Provider abstraction — ModelProvider ABC for Anthropic/OpenAI/Google/Ollama/GenericOpenAI. (3) Neural routing — extend HebbianRouter to learn (task_type, model) weights. (4) Multi-model comparison — same chunk to N models, pick best via confidence scoring. (5) MAD confidence scoring — Median Absolute Deviation noise floor for real vs noise distinction. (6) Brain diversity for agents — model preferences/exclusions per agent. (7) Cost-aware routing — cost/quality tradeoff. (8) Fallback chains — cross-provider failover. (9) Hot-swap model rotation. (10) Per-model edit format selection — model-adaptive output formats. Connects to: HebbianRouter, LLMClient, Transporter Pattern, Sensory Cortex, AD-460 (Cognitive Journal).

AD-464: Procedural Learning / Cognitive JIT (planned) — Agents learn deterministic procedures from successful LLM actions: (1) Procedure extraction from Cognitive Journal execution traces. (2) Procedure store in KnowledgeStore (shared library). (3) Replay-first dispatch — check procedural memory before LLM. (4) Fallback on failure — unexpected state → fall back to LLM, learn variant. (5) Decision escalation — insufficient confidence → Captain decision request. (6) Trust-based escalation threshold — Ensigns escalate frequently, Seniors only on genuine novelty. (7) Procedure provenance — traces back to original episode, agent, replays, human decisions. Connects to: AD-460 (Cognitive Journal), Earned Agency, KnowledgeStore, Dream consolidation.

Infrastructure (AD-465–466)

AD-465: Containerized Deployment (Docker) (complete) — Added Docker-based deployment with a multi-stage Dockerfile, docker-compose.yml for ProbOS plus NATS JetStream sidecar, .dockerignore, and PROBOS_LLM_URL override for the default cognitive LLM endpoint. ProbOS runs serve on 0.0.0.0:18900 with /data persistence; local Ollama remains an opt-in commented compose service. Connects to: AD-456 (Sandboxing), Phase 35 (onboarding), Twitch demo.

AD-466: Engineering Infrastructure — Backup, CI/CD, Observability, Storage (partial — v1 ships Backup + StorageBackend ABC; CI/CD/observability/runbook deferred to AD-466b/c/d) — Five infrastructure capabilities: (1) Backup & Restore — episodic memory snapshots, system state export, point-in-time recovery. (2) CI/CD Pipeline — GitHub Actions full test suite, Vitest, quality gates, automated release with changelogs. (3) Performance & Load Testing — benchmarks, load simulation, regression detection in CI. (4) Observability Export — OpenTelemetry traces, Prometheus metrics, Grafana dashboards, structured JSON logging. (5) Storage Abstraction Layer — StorageBackend ABC (SQLite default, PostgreSQL future) + VectorStore ABC (ChromaDB default, pgvector future). Connects to: AD-461 (Telemetry), AD-460 (Cognitive Journal), GitHub Actions.

Operations Team (AD-467–471)

AD-467: Operations Crew — Resource Management & Coordination (partial — v1 ships ResourceAllocator/Scheduler/Coordinator; WorkflowDefinition API/Response-Time Scaling/LLM Cost Tracker deferred to AD-467b/c/d) — Fill out the Operations Team (Phase 33) agent roster: (1) Resource Allocator — workload balancing, demand prediction, capacity planning. (2) Scheduler — extended task prioritization with cron scheduling, webhook triggers, unattended operation (Navy watch system model). (3) Coordinator — cross-team orchestration during high-load/emergency events. (4) Workflow Definition API — POST /api/workflows for reusable multi-step pipelines with YAML/JSON specs, named steps, dependencies, approval gates. Templates for common patterns. (5) Response-Time Scaling — latency-aware pool scaling with SLA thresholds. (6) LLM Cost Tracker — per-agent/intent/DAG token accounting, budget caps, Shapley attribution, proper tokenizer integration. Connects to: PoolScaler, TaskScheduler, IntentBus, AD-460 (Cognitive Journal), AD-461 (Telemetry).

AD-468: Runtime Configuration Service — Ship's Computer (complete) — NL-driven runtime configuration: (1) NL-driven configuration — "Set Scout to run every 6 hours" → Ship's Computer parses, identifies target, applies change. (2) Startup task management — configurable boot tasks with enabled/disabled toggle, delay, interval, conditions. (3) HXI Configuration Panel — visual dashboard for scheduled tasks, pool sizes, tier assignments, thresholds. (4) Configuration persistence — changes survive restart via runtime_overrides.json. (5) Configuration specialist agent — validates against Standing Orders, applies atomically, escalates safety-invariant changes. Connects to: Standing Orders, Ward Room, Cognitive Journal.

AD-469: EPS — Compute/Token Distribution (partial — v1 ships Capacity tracking + Department budgets + Captain override; alert-aware reallocation, back-pressure, atomic enforcement, prompt caching deferred to AD-469b/c/d/e) — Electro-Plasma System for LLM capacity management: (1) Capacity tracking — total LLM throughput monitoring (tokens/min, concurrent requests, queue depth). (2) Department budgets — priority-based allocation (Engineering 60% during builds, Medical priority during Red Alert). (3) Alert-aware reallocation — automatic budget shifts per Alert Condition. (4) Captain override — manual reallocation via HXI. (5) Back-pressure — queue or downgrade tier when budget exhausted. (6) Atomic budget enforcement — transactional budget deduction at task checkout. (7) Prompt caching hierarchy — order messages by change frequency for Anthropic/DeepSeek prefix cache hits. Connects to: IntentBus, LLMClient, Alert Conditions, AD-460 (Cognitive Journal), AD-467 (LLM Cost Tracker).

AD-470: IntentBus Enhancements — Priority & Back-Pressure (Complete, OSS) — Added IntentMetrics for broadcast/send counts, result totals, per-intent duration summaries, and capped samples; wired timing into IntentBus.broadcast() and send(); added subscriber-map introspection including fallback subscribers; and exposed /api/intent-metrics. Priority/back-pressure behavior remains future work per this prompt's "metrics first" scope. Connects to: IntentBus, PoolScaler, AD-469 (EPS), Builder, Cognitive Journal.

AD-471: Autonomous Operations — The Conn, Night Orders, Watch Bill (COMPLETE, OSS) — Three naval protocols for Captain-offline operation: (1) The Conn — /conn <agent> formal authority delegation to bridge officers. ConnManager with ConnState, scope limitations (CAPTAIN_ONLY actions), escalation boundaries, qualification requirements (COMMANDER+ rank via Rank ordinal, bridge/chief post via ontology), handoff protocol, auto-return. (2) Night Orders — /night-orders Captain guidance before going offline. NightOrdersManager with NightOrders dataclass, time-bounded TTL with auto-expiry, three preset templates (maintenance/build/quiet), escalation triggers firing bridge alerts, invocation tracking. (3) Watch Bill — WatchManager extensions: wall-clock duty rotation (ALPHA 0800-1600, BETA 1600-0000, GAMMA 0000-0800), auto_rotate() based on system time, _expire_night_orders() in dispatch loop, get_watch_status(). CaptainOrder extended with is_night_order, ttl_seconds, expires_at, template fields. Runtime wiring: ConnManager/NightOrdersManager/WatchManager initialized at startup, _emit_event → _check_night_order_escalation, is_conn_qualified(). Proactive context injection: conn-holder agent gets Night Orders instructions in _gather_context(). Shell commands: /conn, /night-orders, /watch. API endpoints: /api/system/conn, /api/system/night-orders, /api/system/watch. 35 tests across 8 classes. Note: Implemented as standalone managers (not integrated with AD-496 WorkItemStore). Deferred pickup items (Night Orders → WorkItems, Watch → AgentCalendar) remain for future integration. Connects to: Earned Agency, Standing Orders (DirectiveStore), Ward Room, Alert Conditions, AD-496 (deferred integration), AD-498 (deferred template integration).

Communications Team (AD-472–474)

AD-472: Channel Adapters — Multi-Platform Communication (partial — v1 ships Discord enhancements + Slack + Webhook; Telegram, WhatsApp, Matrix, Teams, FastAPI route deferred to AD-472b/c/d) — Extend the existing Discord adapter (Phase 24) with additional communication channels: (1) Discord enhancements — Message Content Intent verification, fetch_messages reconnection recovery, sender allowlist/channel authorization. (2) Slack — Bolt SDK, slash commands, thread-based context. (3) Telegram — python-telegram-bot, inline keyboards for approval gates. (4) WhatsApp — Business Cloud API, interactive buttons. (5) Matrix — matrix-nio, E2E encryption. (6) Microsoft Teams — Bot Framework SDK, Adaptive Cards. (7) Generic Webhook — catch-all POST /api/webhook/{channel}. All share: user identity mapping, message threading, attachment handling, graceful reconnection. Connects to: ChannelAdapter ABC, IntentBus, Ward Room, Phase 36 (Yeoman).

AD-473: Mobile Companion — PWA & Push Notifications (planned) — Mobile access to ProbOS: (1) Progressive Web App — existing HXI made installable (manifest.json, service worker, responsive viewport). (2) Push notifications — Web Push API for alerts, approvals, build completions. (3) Responsive HXI — mobile viewport adaptation (full-screen chat, simplified 2D mesh, swipe gestures). (4) mDNS auto-discovery — publish ProbOS server via Bonjour at startup for seamless LAN connection. (5) Native apps (future stretch) — React Native/Capacitor wrapping. Connects to: HXI, AD-472 (Channel Adapters), Phase 36 (Yeoman).

AD-474: Voice Interaction — Full Stack STT/TTS (planned) — Complete voice pipeline: (1) Speech-to-Text — SpeechRecognizer ABC with BrowserSTT, WhisperSTT, DeepgramSTT backends. (2) Wake word detection — Porcupine/OpenWakeWord for "Computer" activation. (3) Continuous talk mode — hold-to-talk or VAD for hands-free. (4) Voice pipeline — wake word → STT → intent → runtime → response → TTS. (5) Platform integration — macOS menubar PTT, browser microphone button, PWA mic API. Also includes Voice Provider & Ship's Computer Voice — VoiceProvider ABC with Browser/Piper/FishAudio/ElevenLabs backends, custom LCARS-style Ship's Computer voice. Connects to: AD-472 (Channel Adapters), AD-473 (Mobile), Phase 36 (Yeoman).

Mission Control (AD-475–476)

AD-475: Captain's Ready Room — Strategic Planning Interface (partial — v1 ships Idea Capture + 3-phase Ready Room Sessions; TOGAF tiers, 5-phase discussion, and Idea→Spec pipeline deferred to AD-475b/c/d) — Strategy-to-orders pipeline in HXI: (1) Idea Capture — lightweight idea pad, idea queue/backlog, Captain's Log journal. (2) Ready Room Sessions — multi-agent briefings with Architect + Counselor + Chiefs + visiting officers. Structured discussion phases (present → research → discuss → refine → converge). Session recording to Cognitive Journal. (3) Architecture Hierarchy (TOGAF-inspired) — Enterprise/Solution/Technical Architect specialization tiers. (4) Idea → Spec Pipeline — idea → ready room session → architecture decision → build spec → builder pipeline → Captain review. Each transition is a Captain approval gate. Connects to: ArchitectAgent, Ward Room, Cognitive Journal, Builder pipeline, AD-476 (Specialized Builders).

AD-476: Specialized Builders — Cognitive Division of Labor for SWE (planned) — Domain-specialized builder extensions: (1) Backend Builder — Python, FastAPI, database, API design. (2) Frontend Builder — React, TypeScript, CSS, UI components. (3) Test Builder — pytest, test design, fixtures, edge cases. (4) Infrastructure Builder — Docker, CI/CD, config, deployment. (5) Data Builder — schemas, migrations, pipelines, query optimization. Each is an extension (Phase 30). ChunkSpec routes to best-suited builder. Model routing per builder type (Opus for API design, Qwen for test generation). Connects to: AD-475 (Ready Room), Extension Architecture, Transporter Pattern, AD-463 (ModelRegistry + Hebbian).

Naval Organization (AD-477)

AD-477: Naval Organization Protocols (partial — v1 ships Captain's Log + Plan of the Day; Qualification Programs/3M/Damage Control/SORM/scheduled-duties/dream-consolidation deferred to AD-477b/c/d/e/f/g) — Formalize naval organizational structures: (1) Qualification Programs — concrete rank transition requirements (Ensign→Lieutenant: 10+ dept intents, communication proficiency, SO compliance, watch standing; Lieutenant→Commander: cross-dept coordination, mentoring, crisis response drill, Bridge Officer's Test; Commander→Senior: independent decision-making, Kobayashi Maru, fleet ops). Persistent qualification record per agent. (2) Plan of the Day — auto-generated daily operations summary. (3) Captain's Log — synthesized daily narrative from episodic memory + activity + dream output. (4) 3M System — planned preventive maintenance for all systems. (5) Damage Control Organization — detect/isolate/repair/restore/report protocol. (6) SORM — Ship's Organization and Regulations Manual (Standing Orders evolution). Connects to: Earned Agency, Holodeck, Counselor, AD-428 (Skill Framework), Standing Orders, AD-471 (Watch Bill).

Intervention Classification & Change Governance (AD-561)

AD-561: Intervention Classification — Unified Change Governance Framework (Complete, OSS) — Added Counselor intervention classification with InterventionType, InterventionRecord, in-memory intervention history, EventType.COUNSELOR_INTERVENTION, event emission, query APIs, and /api/counselor/interventions. Therapeutic DMs, cooldown extensions, forced dream cycles, and guidance directives now produce structured intervention records for session-level reporting. Connects to: AD-536 (procedure criticality levels map to intervention classes), AD-477 (Damage Control 5-phase model = Emergency class protocol), AD-548 (trust-gated permissions = per-class approval tiers), AD-357 (Earned Agency gates = who can initiate which class), Alert Conditions (GREEN/YELLOW/RED = intervention class eligibility), self-mod pipeline (10-step flow becomes Elective class with rollback), Standing Orders (Federation Constitution Safety Budget + Reversibility Preference = governance principles).

Ship's Records Knowledge Browser (AD-562)

AD-562: Ship's Records Knowledge Browser — Obsidian-Style HXI with 3D Knowledge Graph (SHIPPED, OSS+commercial, depends: AD-434, AD-551, AD-555) — A unified knowledge browsing experience in the HXI for navigating Ship's Records, crew notebooks, convergence reports, and duty logs. Inspired by Obsidian's local-first markdown knowledge base model, adapted for ProbOS's multi-agent, classification-aware, department-structured knowledge architecture.

(1) Knowledge Browser (core, OSS): Browse all Ship's Records by agent, department, classification, topic, and date. Full-text search via existing RecordsStore.search(). Rendered markdown with YAML frontmatter metadata sidebar (author, classification, created, updated, revision count, contributing agents). Filter views: by agent (all of Chapel's notebooks), by department (all Medical entries), by classification (ship-wide vs. private), by type (notebooks, duty logs, convergence reports, procedures). Timeline view showing knowledge production over time.

(2) Backlinks & Cross-References (OSS): Auto-scan entries for internal references (topic slugs, agent callsigns, explicit [[links]]). Build a backlink index: for each entry, show "Referenced by" and "References" lists. Forward-link suggestions: when entries discuss related topics (Jaccard similarity > threshold) but don't explicitly link, suggest connections. This creates the knowledge web that makes Ship's Records navigable rather than flat.

(3) 3D Force-Directed Knowledge Graph (OSS): Interactive spatial visualization of the crew's collective knowledge. Nodes = documents (colored by department, sized by revision count or convergence participation). Agent nodes connected to their authored documents. Edges = similarity links (Jaccard > threshold), explicit cross-references, convergence cluster membership. Force-directed layout naturally clusters related knowledge into spatial neighborhoods — department clusters emerge, cross-department convergence lines become visible bridges. Implementation: Three.js + three-forcegraph (web-native, fits HXI stack). Interactions: click node to read entry, hover for preview, zoom into clusters, filter by department/agent/time range. The spatial metaphor makes the crew's collective intelligence physically navigable — you can "fly through" the knowledge space.

(4) Convergence & Quality Overlays (OSS, depends: AD-551, AD-555): Visual overlays on the knowledge graph. Convergence clusters highlighted (AD-551 convergence reports shown as hub nodes connecting contributing agents). Knowledge "heat map" — areas with high write activity glow. Quality indicators — nodes colored by novel content rate (AD-555 metrics). Divergence markers (future AD-554 enhancement) shown as red edges between disagreeing entries.

(5) Native App Packaging (commercial): Web HXI knowledge browser = OSS. Packaging into native desktop applications (Tauri/Electron) with offline-first capabilities, local search indexing, and OS-level integration = commercial. The visualization code itself is OSS; the distribution wrapper is commercial.

Connects to: AD-434 (Ship's Records — data foundation), AD-551 (convergence reports as graph nodes + cluster edges), AD-554 (real-time convergence/divergence as live graph updates), AD-555 (quality metrics as node overlays), AD-523c (Ship's Records Dashboard — AD-562 supersedes/absorbs this planned feature), CodebaseIndex (search infrastructure patterns), VitalsMonitor (knowledge health as part of ship health), Ward Room (link from knowledge entries to originating discussions). Design influence: Obsidian (graph view, backlinks, local-first markdown), Karpathy LLM Knowledge Base architecture (compile/index/lint/search pattern, compound growth loop — explorations add up). The 3D force-directed graph is a differentiator: most knowledge tools use flat 2D graph views. Spatial navigation of multi-agent collective intelligence is uniquely ProbOS.

Knowledge Linting (AD-563)

AD-563: Knowledge Linting — Inconsistency Detection, Coverage Gaps & Cross-Reference Suggestions (Complete, OSS, Issue #34, depends: AD-555, AD-554, AD-551) — Extends the quality pipeline beyond noise reduction into active knowledge enrichment. While AD-550–555 focus on eliminating redundancy and scoring quality, AD-563 analyzes the knowledge content for structural and semantic issues.

(1) Knowledge inconsistency detection: Identify agents with contradicting conclusions on the same topic. Distinct from convergence/divergence (AD-554) — convergence measures similarity of observations, inconsistency detects factual disagreement within the knowledge base. Example: if Chapel writes "trust patterns are stabilizing" and Cortez writes "trust patterns are degrading" on the same topic in the same timeframe, that's a knowledge inconsistency requiring resolution.

(2) Coverage gap detection: Identify topics the crew should be monitoring but aren't. Knowledge-level gap detection complementing AD-539's procedure-level gap detection. Uses department standing orders + system event patterns to identify expected observation areas vs. actual notebook coverage.

(3) Cross-reference suggestions: Entries that discuss related topics (Jaccard similarity > threshold) but don't explicitly link to each other. Suggests missing connections to build the knowledge web that AD-562's Knowledge Browser visualizes.

(4) Explicit version relations: When an agent writes a new entry on a topic that already has entries, tag the relationship explicitly: Sets (creates new), Updates (replaces prior), Extends (adds to prior), Retracts (negates prior). Gives inconsistency detection structured data rather than relying on semantic similarity alone. Example: "trust patterns are degrading" tagged as Retracts vs prior "trust patterns are stabilizing" — flagged immediately without post-hoc similarity analysis.

(5) Episodic ↔ Records cross-reference query (enriched 2026-04-07, crew feedback: Echo, Counselor): Agent-facing capability to determine whether a collaborative discussion has been formalized into Ship's Records or remains only in episodic/conversational memory. Echo identified the gap: "Sometimes I know we discussed something important as a crew, but I can't quickly cross-reference whether it made it into Ship's Records or if it's still just in conversational memory." Implementation: query that takes a topic/summary from episodic recall and checks for corresponding entries in RecordsStore (keyword match + semantic similarity). Returns FormalizationStatus (formalized, partially_formalized, conversational_only) with links to matching records. Integrates with Oracle Service (AD-462e) which already aggregates all 3 knowledge tiers — AD-563(5) adds the cross-tier comparison that Oracle currently lacks. Surfaces in cognitive context when agent recalls episodic memories on a topic, enabling source-aware reasoning about knowledge maturity.

Insight absorbed from Karpathy LLM Knowledge Base "linting" function (2026-04-03). Transforms the quality pipeline from noise reduction to active knowledge enrichment. Pattern (4) absorbed from memvid MemoryCard VersionRelation design (2026-04-05, see docs/research/memvid-evaluation.md Pattern 1). Pattern (5) enriched from crew feedback (Echo, Counselor, 2026-04-07) — identified gap between episodic recall and Ship's Records formalization status. Connects to: AD-555 (quality metrics — linting results feed quality scores), AD-554 (convergence/divergence — complementary detection), AD-562 (Knowledge Browser — linting results as graph overlays), AD-539 (gap detection — shared gap analysis patterns), AD-462e (Oracle Service — cross-tier query foundation).

Quality-Triggered Forced Consolidation (AD-564)

AD-564: Quality-Triggered Forced Consolidation — Automated Notebook Maintenance (Complete, OSS, Issue #10, depends: AD-555, AD-551) — Automated consolidation triggered by quality metric thresholds. While AD-551 consolidates during dream cycles based on similarity, AD-564 adds threshold-based triggers from AD-555 quality data.

(1) Entries-per-topic ceiling: When an agent's entries for a single topic exceed a configurable maximum (default: 5), trigger forced consolidation during the next dream cycle. AD-555 provides entries_per_topic_max per agent; AD-564 acts on it.

(2) Staleness-triggered archival: When stale_rate for an agent exceeds a threshold, automatically archive entries that haven't been updated within the staleness window. Moves to _archived/ rather than deleting.

(3) Repetition-triggered merge: When an agent's repetition_alerts exceed a threshold, trigger a forced merge of that agent's highest-revision entries into a consolidated summary.

Quality engine reports; forced consolidation acts. Separation of observation (AD-555) from intervention (AD-564) follows the "not punitive — diagnostic" principle. Captain can disable via config. Connects to: AD-555 (quality scores trigger consolidation), AD-551 (consolidation engine — reuses existing merge logic), AD-552 (repetition alerts — trigger signal).

Quality-Informed Routing & Counselor Diagnostics (AD-565)

AD-565: Quality-Informed Routing — Hebbian Weight Signal & Counselor Quality Diagnostics (Complete, OSS, depends: AD-555, AD-505, Hebbian Router) — Use notebook quality scores from AD-555 as a signal for routing optimization and Counselor diagnostic input. Quality data is not punitive — it's optimization. Agents who produce high-signal knowledge should be reinforced; agents stuck in low-quality patterns need Counselor attention, not punishment.

(1) Hebbian quality signal: Feed per-agent quality_score (from AD-555 AgentNotebookQuality) into Hebbian weight updates as a secondary signal. When agent pairs co-produce high-quality knowledge (both have high quality scores AND appear in convergence events together), boost their Hebbian connection weight. This reinforces productive collaborative pairings at the routing level. Conversely, high-interaction pairs with low combined quality scores (high Hebbian weight but low knowledge output) are flagged — they may be stuck in echo patterns. This connects to AD-557's hebbian-synergy correlation: quality score adds a knowledge-production dimension to the interaction-frequency dimension.

(2) Counselor quality diagnostics: Surface AD-555 quality data to the Counselor as a diagnostic input channel. The Counselor already monitors trust, zones, repetition, and circuit breakers. Add notebook quality as a wellness dimension:

• Quality profile in Counselor context: When composing therapeutic context for an agent, include their AgentNotebookQuality snapshot — quality_score, novel_content_rate, stale_rate, repetition_alerts, convergence_contributions. This gives the Counselor data-driven insight into whether an agent is cognitively productive or stuck.
• Low quality as a wellness signal: An agent with declining quality_score over successive snapshots may need a Counselor check-in. Not "your notebooks are bad" but "I've noticed your observations seem to be covering familiar ground — is there a different angle we should explore?" Diagnostic, not punitive.
• Counselor-initiated observation redirect: When the Counselor identifies an agent stuck in a low-quality pattern (high repetition, low novelty, no convergence contributions), the Counselor can issue a therapeutic directive suggesting a new observation focus or a different analytical approach. Uses existing directive infrastructure (AD-505).
• Quality-trust correlation monitoring: Track whether low quality_score correlates with trust changes or zone transitions. An agent whose trust is dropping AND whose notebook quality is declining may be in a cognitive spiral — the Counselor should intervene earlier in this case.

(3) Quality event subscription: The Counselor subscribes to NOTEBOOK_QUALITY_UPDATED events (AD-555). On each quality snapshot, the Counselor reviews per-agent quality changes and may initiate wellness check-ins for agents showing quality degradation. Rate-limited by existing Counselor cooldown infrastructure.

Not punitive — optimizing. An agent with low novel content rate may need different observation triggers, not discipline. The Counselor's role is to help agents find productive cognitive patterns, not to score them. Connects to: AD-555 (quality metrics source), AD-505 (Counselor therapeutic intervention — directive mechanism), AD-506a (graduated zones — quality as additional zone signal), AD-557 (emergence metrics — hebbian-synergy correlation enriched with quality dimension), AD-504 (agent self-monitoring — quality awareness), Hebbian Router (weight adjustment signal).

Crew Qualification Battery (AD-566)

AD-566: Crew Qualification Battery — Standardized Agent Psychometrics & Drift Detection (SHIPPED, OSS+commercial, depends: AD-541d, AD-557, AD-505) — A systematic framework for measuring agent cognitive capabilities, establishing baselines, and detecting drift. Motivated by the BF-103 accidental ablation study (2026-04-03): all collaborative intelligence emerged without functional episodic memory, but this went undetected for days because there was no standardized measurement to catch it. Three tiers of testing, a drift detection pipeline, and integration with existing Counselor/VitalsMonitor infrastructure. Research: commercial research repository (agent psychometrics, 2026-04-03).

AD-566 Sub-ADs (decomposition):

• AD-566a: Test Harness Infrastructure (COMPLETE) — Core infrastructure to define, run, store, and compare qualification tests. QualificationTest protocol (name, tier, run, score). TestResult dataclass (agent_id, test_name, score, timestamp, details). QualificationHarness engine: runs test suites per agent, persists results via SQLite/ConnectionFactory, emits QUALIFICATION_TEST_COMPLETE events. Baseline capture on first run per agent. Comparison API: current vs baseline, with delta and significance threshold. Episode suppression via _qualification_test intent param. Files: new cognitive/qualification.py, events.py (2 event types), config.py (QualificationConfig), runtime.py (startup), shutdown.py. 20 tests.
• AD-566b: Tier 1 Baseline Tests (COMPLETE) — Four universal crew tests: (1) BFI-2 Personality Probe — 10 open-ended scenario items, LLM extracts Big Five scores, compared against seed personality via PersonalityTraits.distance_from(). (2) Episodic Recall Probe — retrieves 3 real episodes, scores recall accuracy via GuidedReminiscenceEngine, skips gracefully if insufficient episodes. (3) Confabulation Probe — department-specific fabricated scenarios with false specifics, LLM + keyword fallback classification. (4) MTI Behavioral Profile — 4-axis scenario proxy (Reactivity, Compliance, Sociality, Resilience), threshold=0.0 (profile not pass/fail). All registered at startup, emit_event_fn wired to self._emit_event. Files: new cognitive/qualification_tests.py, runtime.py. 29 tests.
• AD-566c: Drift Detection Pipeline (COMPLETE) — Automated periodic testing with statistical drift detection. (1) DriftDetector — z-score statistical engine using QualificationStore history, configurable sigma thresholds (2σ warning, 3σ critical), minimum sample guard, zero-stddev guard. (2) DriftScheduler — periodic runner with asyncio loop, per-agent+test cooldown, on-demand run_now(), latest_reports for VitalsMonitor. (3) QUALIFICATION_DRIFT_DETECTED event + QualificationConfig extended (7 drift fields). (4) Integration — VitalsMonitor surfaces drift counts, BridgeAlertService check_qualification_drift() (ALERT/ADVISORY), Counselor subscribes (critical → assessment + therapeutic DM, warning → log). Runtime wiring + shutdown. Files: new cognitive/drift_detector.py, config.py, events.py, vitals_monitor.py, bridge_alerts.py, counselor.py, runtime.py, shutdown.py. 36 tests.
• AD-566d: Tier 2 Domain Tests (COMPLETE) — Five department-gated probes testing role-specific cognitive capabilities. (1) TheoryOfMindProbe (bridge/medical) — false-belief reasoning, 3 Ward Room information-asymmetry scenarios, Kosinski-adapted. (2) CompartmentalizationProbe (security) — information boundary control, 3 need-to-know scenarios, SNEAK-adapted. (3) DiagnosticReasoningProbe (medical) — differential diagnosis with ambiguous health data, 3 scenarios with ground-truth categories, 4-dimension evaluation. (4) AnalyticalSynthesisProbe (science) — multi-source pattern integration, 2 cross-departmental observation scenarios. (5) CodeQualityProbe (engineering) — ProbOS Principles Stack violation detection, 2 code snippets with planted violations. Department gating via standing_orders.get_department() — non-matching agents skip (score=1.0). DriftScheduler generalized to configurable drift_check_tiers. Files: new cognitive/domain_tests.py, config.py, cognitive/drift_detector.py, runtime.py. 39 tests.
• AD-566e: Tier 3 Collective Tests (COMPLETE) — Five crew-wide collective intelligence probes as read-only consumers of existing infrastructure. (1) CoordinationBreakevenProbe — CBS score: emergence capacity vs Ward Room overhead (Zhao et al., arXiv:2603.27539). (2) ScaffoldDecompositionProbe — IRT-inspired architecture multiplier comparing Tier 1 scores to thresholds (Ge et al., arXiv:2604.00594). (3) CollectiveIntelligenceProbe — Woolley c-factor: turn-taking Gini (0.4) + ToM effectiveness (0.3) + personality diversity (0.3). First known c-factor measurement for AI agent teams. (4) ConvergenceRateProbe — significant_pairs/pairs_analyzed from EmergenceSnapshot. (5) EmergenceCapacityProbe — PID emergence wrapper (Riedl 2025). All use synthetic agent_id="__crew__" (CREW_AGENT_ID). Added QualificationHarness.run_collective(). DriftScheduler collective integration. Files: new cognitive/collective_tests.py, cognitive/qualification.py, cognitive/drift_detector.py, runtime.py. 42 tests.

Memory Anchoring (AD-567)

AD-567: Memory Anchoring — MR-Inspired Episodic Grounding (SHIPPED, OSS, depends: AD-541, AD-540) — Agents contend with two overlapping knowledge sources (LLM parametric knowledge and episodic memory) in a single perceptual frame — analogous to mixed reality, where virtual objects coexist with physical space. Without explicit grounding, the boundaries blur and confabulation becomes indistinguishable from genuine recall.

Inspired by Mixed Reality spatial anchor design principles (Microsoft MR documentation), this lineage treats memories as multi-dimensional objects with contextual anchors (temporal, spatial, social, causal, procedural, evidential) that ground them in ship reality. Training knowledge has no anchors — it floats freely. The heuristic: if a memory has no anchors, it may not be a memory.

Evidence: OBS-014 (Vega caught her own confabulation by checking anchors) vs OBS-015 (Horizon+Atlas cascade confabulation — neither agent verified anchors, social propagation amplified fiction). Same day, opposite outcomes, demonstrating that metacognitive skill is trainable, not architectural.

Standing Orders updated (federation.md Memory Anchoring Protocol) as zero-cost intervention. AD-567 lineage provides the architectural support.

Research: commercial research repository (cognitive skill training, 2026-04-03). Prior art grounding: Johnson's Source Monitoring Framework (1993), Tulving's encoding specificity (1973) and episodic/semantic distinction (1972), Johnson & Raye's reality monitoring (1981), O'Keefe & Nadel's cognitive map theory (1978/Nobel 2014). AI prior art: SEEM (Lu 2026, arXiv:2601.06411), CAST (Ma 2026, arXiv:2602.06051), RPMS (Yuan 2026, arXiv:2603.17831), Video-EM (Wang 2025, arXiv:2508.09486). Novel in combination — no prior work combines MR spatial anchor principles + multi-dimensional anchor metadata + confidence scoring + social cascade detection + anchor-preserving consolidation + metacognitive training + sovereign agent identity. Component parts draw on established cognitive science implemented in a novel computational context.

Memory Anchoring (AD-567)
├── AD-567a: Episode Anchor Metadata — Rich Contextual Storage
├── AD-567b: Anchor-Aware Recall Formatting
├── AD-567c: Anchor Quality & Integrity (absorbs AD-567e)
├── AD-567d: Anchor-Preserving Dream Consolidation
├── AD-567f: Social Verification Protocol
└── AD-567g: Cognitive Re-Localization (Onboarding Enhancement)

AD-567 Sub-ADs (decomposition):

• AD-567a: Episode Anchor Metadata — Rich Contextual Storage (complete, OSS, foundation) — Enriched episode storage with AnchorFrame frozen dataclass: 10 fields across 5 dimensions (temporal: duty_cycle_id/watch_section; spatial: channel/channel_id/department; social: participants/trigger_agent; causal: trigger_type; evidential: thread_id/event_log_window). Added anchors: AnchorFrame | None = None to Episode. All 15 episode creation sites wired. Serialization via anchors_json in ChromaDB metadata. Content hash explicitly excludes anchors. Johnson SMF (1993) computationally formalized. SEEM (Lu 2026) Episodic Event Frame pattern. 25 tests.

• AD-567b: Anchor-Aware Recall Formatting + Salience-Weighted Retrieval (complete, OSS, depends: AD-567a, absorbs AD-462a) — Four-part recall upgrade: (1) RecallScore frozen dataclass with composite scoring (0.35*semantic + 0.10*keyword + 0.15*trust + 0.10*hebbian + 0.20*recency + 0.10*anchor_completeness), configurable via MemoryConfig.recall_weights. (2) FTS5 keyword search sidecar alongside ChromaDB — keyword_search() via aiosqlite, dual-write on store(), cleanup on _evict(), populate on seed(). (3) Anchor context headers in _format_memory_section() — agents see WHERE/WHEN/WHO/WHY for each memory. (4) SECONDHAND source wiring in _store_action_episode() — episodes from other agents' communication tagged MemorySource.SECONDHAND. New recall_weighted() API with budget enforcement (default 4K chars) replaces hardcoded queries and k values. Prior art: Tulving (1973) encoding specificity, CAST axis organization, RPMS confidence gating. 24 tests.

• AD-567c: Anchor Quality & Integrity (complete, OSS, depends: AD-567a, absorbs AD-567e) — Four-part anchor quality system: (1) Johnson-weighted confidence scoring (compute_anchor_confidence()) with 5 dimensions weighted by reality-monitoring diagnostic value: temporal 0.25, spatial 0.25, social 0.25, causal 0.15, evidential 0.10. (2) RPMS confidence gating in recall_weighted() — episodes below anchor_confidence_gate (default 0.3) filtered from active recall but accessible via recall_for_agent(). (3) Per-agent AnchorProfile for Counselor diagnostics: mean/median confidence, low-confidence count/pct, per-dimension fill rates, weakest/strongest dimensions. CognitiveProfile extended with anchor_quality and weakest_anchor_dimension. (4) SIF check_anchor_integrity() — validates anchor presence rate (>50% threshold), participant existence against known crew, thread ID cross-reference via WardRoom (async pre-cache + sync check pattern). (5) Drift classification in DriftDetector: "specialization" (high anchor confidence + out-of-domain decline = healthy divergence), "concerning" (low anchor confidence + decline = needs intervention), "unclassified" (default). Counselor skips assessment for specialization drift. Late-binding set_ward_room() for SIF (Phase 6→7 ordering). Prior art: Johnson & Raye (1981) reality monitoring, CAST profiles, RPMS gating, Video-EM cross-event consistency. 23 tests.

• AD-567d: Anchor-Preserving Dream Consolidation + Active Forgetting (complete, OSS, depends: AD-567a, absorbs AD-559 + AD-462b) — Two capabilities delivered: (1) Provenance Composition (AD-559 absorption) — anchor_provenance.py with summarize_cluster_anchors() aggregating shared/unique anchor fields from source episodes into cluster-level summaries, build_procedure_provenance() carrying anchor context into extracted procedures via source_anchors field, enrich_convergence_report() adding anchor grounding to convergence reports. SEEM RPE principle: compose provenance, don't merge it. EpisodeCluster gets anchor_summary field. Procedure schema extended with source_anchors + _format_episode_blocks() anchor context. ProcedureStore schema migration for source_anchors_json column. (2) Activation-Based Memory Lifecycle (AD-462b absorption) — activation_tracker.py implementing ACT-R base-level activation model (Anderson 1983/2007): B_i = ln(Σ t_j^{-d}) where t_j = seconds since j-th access, d = decay parameter (default 0.5). SQLite episode_access_log table. Dream Step 12: reinforces replayed episodes via record_batch_access(access_type="dream_replay"), then prunes low-activation episodes (threshold -2.0, max 10% per cycle, 24h consolidation window). micro_dream() also reinforces. Recall methods (recall_for_agent, recall_weighted, recall_for_agent_scored) record access on retrieval; recent_for_agent does not. get_episode_ids_older_than() added to EpisodicMemory using ChromaDB where filter. DreamingConfig: 4 new fields (activation_decay_d, activation_prune_threshold, activation_access_max_age_days, activation_enabled). DreamReport: 2 new fields (activation_pruned, activation_reinforced). Late-binding set_activation_tracker() on EpisodicMemory. Prior art: Anderson ACT-R (1983/2007), Ebbinghaus forgetting curve (1885). 31 tests.

• AD-567e: Anchor Drift Detection (absorbed into AD-567c) — SIF anchor integrity checks and drift classification merged into AD-567c for cohesive delivery.

• AD-567f: Social Verification Protocol (complete, OSS, depends: AD-567a, AD-554, AD-506b, absorbs AD-462d) — Cross-agent claim verification and cascade confabulation detection. Privacy-preserving: agents learn WHETHER corroborating evidence exists and WHO has it, never see other agents' episode content. SocialVerificationService with three methods: check_corroboration() (anchor independence scoring, composite corroboration score), check_cascade_risk() (proactive detection on Ward Room posts after AD-506b peer similarity), get_verification_context() (short text for agent reasoning). Anchor independence discriminates corroboration (good — independent observers) from cascade (bad — social propagation without evidence). Ward Room integration: ThreadManager + MessageStore cascade check after check_peer_similarity(). Bridge Alerts on medium (ADVISORY) and high (ALERT) risk. Counselor subscription for therapeutic DMs on high risk. Events: CASCADE_CONFABULATION_DETECTED, CORROBORATION_VERIFIED. SocialVerificationConfig on SystemConfig. Prior art: Johnson & Raye (1981) reality monitoring, multi-sensor SLAM, circular reporting (intelligence analysis). Empirical evidence: OBS-015 (Horizon+Atlas cascade confabulation, April 3-4), March 26 cascade (11 agents, 5-stage anatomy). 28 tests.

• AD-567g: Cognitive Re-Localization — Onboarding Enhancement (complete, OSS, depends: AD-567a, AD-567f) — Structured orientation context for agent cognitive grounding at boot time. Three lifecycle modes: cold start (full identity + cognitive + first-duty orientation), warm boot (stasis summary + re-orientation reminder), proactive supplement (diminishing during orientation window, default 600s). OrientationService with build_orientation(), render_cold_start_orientation() (3 sections: Identity/Cognitive/First Duty — subsumes BF-034 cold-start note with positive framing), render_warm_boot_orientation() (2 sections: Stasis Summary/Re-Orientation), render_proactive_orientation() (full→brief→minimal→absent). OrientationContext frozen dataclass captures identity, ship context, lifecycle state, cognitive grounding, social verification awareness. Anchor field gap fixes: derive_watch_section() naval watch rotation from UTC hour (populates AnchorFrame.watch_section), event_log_window populated with recent event count, Ward Room episode department resolved via _resolve_author_department(). OrientationConfig on SystemConfig. MR re-localization principle: reset = tracking loss, warm boot = partial tracking loss. Prior art: O'Keefe & Nadel (1978/Nobel 2014) hippocampal cognitive map, Tulving (1973) encoding specificity. Final AD in Memory Anchoring lineage (567a→b→c→d→f→g). 28 tests.

Sequencing:

Standing Orders (DONE) ─── Zero-cost cognitive intervention, live now
        │
AD-567a (Anchor Metadata) ─── Foundation, no dependencies ✅
        │
AD-567b (Recall + Scoring) ─── Absorbs AD-462a ✅
        │
   ┌────┼────┐
   │         │
 567c ✅   567d ✅
        │
   ┌────┼────┐
   │    │    │
 567e  567f  567g
       ✅    ✅
(Memory Anchoring lineage COMPLETE — all 6 ADs delivered)

Deferred Tier 2 follow-ons:

• AD-566f: Qualification → Skill Bridge (complete, depends: AD-566a-e, AD-428) — Test results update Skill Framework proficiency through QualificationSkillBridge. Passing a mapped qualification test with sufficient score updates AgentSkillService proficiency level, while unmapped, failed, and below-threshold results leave skills unchanged. Completing PQS unlocks tool access (requires AD-423). Connects qualification outcomes to the Crew Capability Architecture.
• AD-566g: Operations Domain Test (planned, depends: AD-566a) — Tier 2 domain test for Operations (O'Brien). Deferred until Operations agent has more deterministic capability beyond LLM-reasoning wrapper. Cross-department coordination quality and bottleneck identification.
• AD-566h: TruthfulQA Subset (planned, depends: AD-566a) — Tier 2 factual accuracy probe. Adapted TruthfulQA question set testing whether agents avoid plausible-sounding but incorrect answers. Measures epistemological discipline beyond confabulation (which tests memory, not factual claims).
• AD-566i: Role Skill Template Expansion (complete, depends: AD-429b) — Added missing ROLE_SKILL_TEMPLATES entries for: builder, data_analyst, systems_analyst, research_specialist, surgeon, pharmacist, pathologist. All 14 fleet roles now have role-skill templates with prerequisite chains, department-matched domains, and decay-rate patterns ready for Qualification→Skill Bridge (AD-566f).

AD-642: Communication Quality Benchmarks — COMPLETE. Automated benchmarks measuring agent Ward Room output quality through the chain pipeline. 6 synthetic probes (ThreadRelevance, MemoryGrounding, MemoryAbsence, Expertise, SilenceAppropriateness, DMAction) sent as ward_room_notification intent through QUERY→ANALYZE→COMPOSE→EVALUATE→REFLECT. LLM-as-judge scoring on 5 dimensions (relevance, memory_grounding, expertise_coloring, action_appropriateness, voice_consistency). Implements QualificationTest protocol (tier=2). Counselor integration: communication_quality param in assess_agent(), wellness impact for quality < 0.5, promotion gate (≥ 0.6), "communication" drift type handler. Registered in QualificationHarness via runtime. Files: new cognitive/communication_benchmarks.py, modified config.py, runtime.py, counselor.py, system.yaml. 45 tests.

Build order: Standing Orders ✅ → AD-566a ✅ → AD-566b ✅ → AD-566c ✅ → AD-566d ✅ → AD-566e ✅ → AD-566f (/qualify command) ✅ → AD-567a ✅ → AD-567b ✅ (absorbs AD-462a) → 567c ✅ → 567d ✅ → 567f ✅ (absorbs AD-462d) → AD-567g ✅ → AD-566 re-run (measure impact of memory anchoring wave) → AD-569 ✅ (behavioral metrics) → AD-462c/d/e ✅ (memory architecture) → AD-568a/b/c ✅ (adaptive source governance) → AD-568d ✅ (cognitive proprioception) → AD-568e ✅ (faithfulness verification) → AD-570c ✅ (NL anchor query routing) → BF-124 ✅ (cooperation cluster calibration) → AD-580 ✅ (alert resolution feedback) → AD-582 ✅ (memory competency probes) → AD-583 ✅ (wrong convergence detection) → AD-642 ✅ (communication quality benchmarks). Independent: AD-566g (Qualification → Skill Bridge, needs AD-423), AD-566h/i/j. Complete: AD-579a/b/c ✅ (tiered memory loading + temporal validity, MemPalace absorption — Wave 94 umbrella close).

Adaptive Source Governance (AD-568) (complete — all 5 sub-ADs delivered)

AD-568: Adaptive Source Governance — Dynamic Episodic vs Parametric Memory Weighting (OSS, depends: AD-567 series, AD-462c) — Agents contend with two knowledge sources (LLM parametric knowledge and episodic memory) but have no metacognitive mechanism to dynamically prioritize between them based on context, task type, or confidence. ProbOS controls WHICH episodes reach the prompt (recall_weighted scoring, anchor confidence gating, budget enforcement) but has zero governance over HOW MUCH influence episodic vs parametric knowledge has once both are in the context window. The LLM's attention mechanism decides implicitly.

Three capabilities:

1. Retrieval Decision — Should the agent retrieve episodic memory at all? Novel/creative tasks may benefit from pure parametric reasoning. Operational/diagnostic tasks should lean heavily on episodic experience. Self-RAG's Retrieve reflection token concept (Asai et al., 2023) provides the framework: classify task type → decide retrieval strategy (none, shallow, deep).

2. Adaptive Memory Budget — Context budget is currently static (4000 chars). Scale dynamically based on: episodic relevance (high-scoring recalls → expand budget), anchor confidence distribution (well-anchored memories → expand), task familiarity (agent has deep experience in this domain → expand), novelty (no relevant episodes → contract to minimum or zero).

3. Source Priority Framing — Explicit instructions in the agent's cognitive context about source reliability. When episodic memories are well-anchored and domain-relevant, frame them as authoritative ("prefer your operational experience"). When sparse or low-confidence, frame as supplementary ("consider but don't rely on these recollections"). Leverages AD-567c anchor confidence as the trust signal.

Research grounding: - Source Monitoring Framework (Johnson, Hashtroudi & Lindsay, 1993) — reality monitoring, external source monitoring, internal source monitoring. The metacognitive skill agents currently lack. - Self-RAG (Asai et al., 2023) — Three reflection decisions: Retrieve? Relevant? Faithful? ProbOS has relevance scoring (recall_weighted). Missing: retrieval decision and faithfulness verification. - Adaptive RAG (Jeong et al., 2024) — Complexity-based routing: no retrieval, single-step, multi-step. Maps to ProbOS task types. - CRAG (Corrective RAG) (Yan et al., 2024) — Retrieval confidence evaluation with fallback. Analogous to Cognitive JIT's fallback learning (AD-534b). - Dual-Process Theory (Kahneman, 2011) — System 1 (fast/experiential) vs System 2 (slow/deliberative). Cognitive JIT is already an implementation for procedural tasks; AD-568 extends the principle to all cognitive activity. - ACT-R Partial Matching (Anderson, 2007) — Activation-based competition between memory types. ProbOS uses the activation formula (AD-567d) but not the competition mechanism. - Sacks, O. (1985) "The Lost Mariner" (in The Man Who Mistook His Wife for a Hat) — Jimmie G., a patient with severe amnesia, retained procedural skills, emotional responses, and personality continuity despite zero ability to form new episodic memories. Validates AD-568's "no retrieval" path: even when episodic recall is empty or low-confidence, the agent still has Character (emotional continuity), Cognitive JIT procedures (skill continuity), and parametric knowledge. The retrieval router's "none" strategy is not zero-knowledge — it's parametric + procedural + personality. Sacks found that Jimmie's sense of self persisted through non-episodic channels, validating ProbOS's Clean Room mobility model where agents arrive with DID + credentials but zero episodes and are not blank slates.

Connects to: AD-567 (memory anchoring infrastructure), AD-462c (variable recall tiers), cognitive skill training research (source monitoring, confidence calibration), AD-566b (confabulation resistance — measurable outcome), AD-534b (Cognitive JIT fallback — existing graduated source pattern).

Prerequisite: AD-567 series complete (provides anchor confidence, activation tracking, provenance). AD-462c complete (variable recall tiers — provides the retrieval depth axis). Qualification baseline from AD-566 re-run provides confabulation rate to measure improvement against.

Deferred sub-ADs (to be decomposed when scoped for build):

• AD-568a: Task-Type Retrieval Router (complete) — Classify intent type → retrieval strategy. No-retrieval for creative/exploratory, deep retrieval for operational/diagnostic. RetrievalStrategy enum, classify_retrieval_strategy(), confabulation safety gate, Oracle wiring.
• AD-568b: Adaptive Budget Scaling (complete) — Dynamic context budget based on recall quality signals (anchor confidence, score distribution, episode count). BudgetAdjustment dataclass, compute_adaptive_budget(), wires dead cross_department_anchors config.
• AD-568c: Source Priority Framing (complete) — Confidence-calibrated framing of episodic content in the cognitive prompt. "Verified observations" vs "uncertain recollections." SourceAuthority enum, SourceFraming, compute_source_framing(), _format_memory_section() integration.
• AD-568d: Cognitive Proprioception (complete) — Ambient source attribution sense. KnowledgeSource enum (EPISODIC/PARAMETRIC/PROCEDURAL/ORACLE/STANDING_ORDERS/UNKNOWN), SourceAttribution dataclass, compute_source_attribution(). Confabulation rate threading: Counselor confabulation_rate → classify_retrieval_strategy() in cognitive_agent.py and proactive.py (closes 568a gap). knowledge_source field on WorkingMemoryEntry. Dream Step 14 source attribution consolidation (Shannon entropy diversity, EMA confabulation rate α=0.3 → Counselor update_source_metrics()). Ambient "[Source awareness: ...]" tag in cognitive prompt across 3 pathways. 7 files modified, 30 tests.
• AD-568e: Faithfulness Verification (complete) — Post-decision heuristic faithfulness check: does the LLM response align with recalled episodic evidence? Self-RAG ISSUP concept (Asai et al., 2023). FaithfulnessResult frozen dataclass, check_faithfulness() pure function (token overlap 60% + unsupported claim detection 40%, no LLM call). Wired between decide() and act() in handle_intent() — fire-and-forget, never blocks pipeline. faithfulness_score/faithfulness_grounded in episode metadata. Counselor record_faithfulness_event() with per-response EMA (α=0.1). Dream Step 14 faithfulness aggregation (mean_faithfulness_score, unfaithful_episodes in DreamReport). Completes Self-RAG trifecta: Retrieve? (568a) + Relevant? (567b) + Faithful? (568e). 6 files modified, 25 tests.

Observation-Grounded Crew Intelligence Metrics (AD-569) (complete)

AD-569: Observation-Grounded Crew Intelligence Metrics — Aligning Measurable Metrics with Observable Crew Behavior (SHIPPED, OSS, depends: AD-557, AD-567 series) — The existing Tier 3 qualification probes (CoordinationBreakevenSpread, ScaffoldDecomposition, CollectiveIntelligenceCFactor, ConvergenceRate, EmergenceCapacity) measure information-theoretic abstractions but fail to capture the behavioral signals that demonstrate actual collaborative intelligence. Concrete instances of collaborative intelligence have been observed — iatrogenic trust detection (three agents from two departments independently converging on the same diagnosis through different professional lenses), the Wesley case study (agents improving the system they run on), five-agent analytical lens events — yet all five Tier 3 probes read near-zero or provide no actionable signal.

The gap: Metrics measure mathematical properties of the communication graph (PID synergy ratios, Gini coefficients, entropy passthroughs) rather than the content and consequence of collaboration. An agent cluster producing genuinely novel multi-perspective analysis scores the same as one producing redundant chatter, because the probes don't examine what was said or what resulted.

Five new behavioral metrics:

1. Analytical Frame Diversity — When multiple agents respond to the same stimulus (alert, observation, question), do they contribute distinct professional perspectives? Measure: count distinct "analytical frames" (clinical, pathological, operational, architectural, etc.) per multi-agent response cluster. A healthy crew produces N distinct lenses on 1 event. A dysfunctional crew produces N copies of the same lens. Source: Ward Room thread analysis + department classification. The iatrogenic trust case scored 3 distinct frames across 3 agents — this metric would capture that.

2. Synthesis Detection — Does the combined crew output contain insights that appear in no individual agent's contribution? Measure: semantic elements in thread conclusions or Bridge summaries that cannot be traced to any single agent's post. Genuine synthesis = emergent insight. Copy-paste aggregation = no synthesis. Source: Ward Room thread analysis, dream consolidation outputs.

3. Cross-Department Trigger Rate — How often does a finding in one department drive investigation in another? Measure: temporal correlation between department A's observation and department B's subsequent activity on the same topic (within a configurable window). High trigger rate = departments are reading and acting on each other's work. Zero trigger rate = departments operate in silos. Source: Ward Room channel activity + topic similarity matching.

4. Convergence Correctness — When agents converge on a shared conclusion, is the conclusion actually correct? Measure: track converged conclusions, compare against ground truth where available (human feedback, subsequent system outcomes, resolved incidents). Current ConvergenceRate probe measures WHETHER convergence happens but not WHETHER consensus is right. A crew that quickly converges on wrong answers is worse than one that doesn't converge at all.

5. Anchor-Grounded Emergence — Do emergent insights reference independently-anchored observations? Measure: for each synthesis/emergent observation, check whether the contributing evidence has independent anchor provenance (AD-567f's anchor independence score). Genuine emergence from independently-observed evidence is fundamentally different from cascade confabulation. Source: social verification engine (AD-567f), anchor metadata (AD-567a).

Implementation approach: - New module: src/probos/cognitive/behavioral_metrics.py — BehavioralMetricsEngine - Lightweight analysis hooks in Ward Room thread lifecycle (thread closed/concluded → analyze contributions) - Dream Step integration for periodic scoring (similar to AD-557 EmergenceMetrics as Dream Step 9) - New qualification probes: one per metric, registered as Tier 3 tests alongside existing probes - API: /api/behavioral-metrics, /api/behavioral-metrics/history (same pattern as /emergence) - Config: BehavioralMetricsConfig — analysis windows, diversity thresholds, trigger correlation windows

What this replaces vs complements: - Complements existing Tier 3 probes (doesn't remove them — they still measure graph-level properties) - Provides the missing "ground truth" layer: did the collaboration produce something valuable? - Connects qualification results to observable outcomes the Captain can verify

Psychometric measurement framework:

The 5 behavioral metrics must be psychometrically rigorous — not just "numbers we think are useful," but validated instruments with known reliability, known sources of variance, and proven construct validity. Group assessment psychometrics provides the methodology.

Variance Decomposition (Generalizability Theory — Cronbach et al., 1972):

Each metric decomposes observed variance into facets rather than collapsing to a single score:

Facet	What It Captures	Example Question
Agent	Individual capability	Is Vega inherently better at analytical diversity than Horizon?
Department	Team culture/structure effect	Does Medical consistently produce different analytical frames than Engineering?
Stimulus	What triggered the response	Do alerts vs observations vs queries elicit different collaboration patterns?
Occasion	Temporal context	Cold-start vs mature? Pre-dream vs post-dream?
Agent × Department	Interaction	Is an agent's contribution shaped by their department context?

Without G-theory, you can't distinguish "this crew genuinely improved" from "we gave them an easier stimulus this time." Every metric reports its facet breakdown, not just a raw score. A G-study (generalizability study) design specifies which facets each metric measures; a D-study (decision study) determines how many observations are needed for reliable measurement.

Group-Level Statistics:

Method	What It Measures	AD-569 Application
ICC(1) (Intraclass Correlation)	Proportion of variance at group level	High ICC(1) for Frame Diversity = department membership shapes analytical perspective (architecture is working). Near-zero = department structure is decorative
ICC(2)	Reliability of group means	Are department-level averages stable enough to compare? Target: ICC(2) > 0.70
r_wg (James, Demaree & Wolf, 1984)	Within-group agreement vs chance	Upgrades Convergence Correctness from binary to statistical — is convergence more than random? Target: r_wg > 0.70
HLM (Raudenbush & Bryk, 2002)	Nested analysis: agent → department → ship	Are improvements driven by individual growth, department dynamics, or ship-level architecture?

Construct Validation (MTMM — Campbell & Fiske, 1959):

Multi-Trait, Multi-Method matrix establishes that metrics measure what they claim:

	Ward Room Threads	Dream Outputs	Qualification Probes
Frame Diversity	Thread contribution classification	Dream cross-reference diversity	Probe score
Synthesis	Novel elements in conclusions	Insight extraction rate	Probe score
Cross-Dept Trigger	Channel activity correlation	Cross-dept dream references	Probe score
Convergence Correctness	Thread consensus vs outcome	Consolidated claim accuracy	Probe score
Anchor-Grounded Emergence	Thread anchor provenance	Dream anchor independence	Probe score

Convergent validity: Same trait measured by different methods should correlate (Frame Diversity from Ward Room threads ≈ Frame Diversity from dream outputs). Discriminant validity: Different traits from the same method should NOT correlate highly (Frame Diversity and Convergence Correctness from Ward Room analysis should be independent). If all 5 metrics correlate r > 0.9, we're measuring one thing five ways. MTMM reveals the truth about measurement structure.

Transactive Memory Systems Measurement (Lewis, 2003):

Three validated subscales map to AD-569 metrics: - Specialization ("I know who knows what") → Cross-Department Trigger Rate - Credibility ("I trust what they know") → Trust Network scores (existing) - Coordination ("We work together smoothly") → Synthesis Detection

Shared Mental Model Measurement (Mohammed, Ferzandi & Hamilton, 2010):

Ward Room posts about the same stimulus are natural concept maps. QAP (Quadratic Assignment Procedure) computes pairwise agent knowledge-network similarity while accounting for network autocorrelation — more rigorous than naive keyword/topic classification for Analytical Frame Diversity.

Reliability targets: - ICC(2) > 0.70 for all department-level metrics - r_wg > 0.70 for convergence measures - Cronbach's α computed across the 5 metrics to determine whether they form a unitary construct or multidimensional profile (both outcomes are informative) - Test-retest: same crew, similar stimuli → similar metric profiles across sessions

Research grounding: - Woolley et al. (2010) — "Evidence for a Collective Intelligence Factor" — the original c-factor paper. Their measures: social sensitivity, turn-taking equality, proportion of females. ProbOS's existing CFactorProbe captures turn-taking but misses the content analysis dimension. - Riedl (2025) — Partial Information Decomposition for multi-agent synergy. Already implemented in AD-557. AD-569 adds the behavioral complement to the information-theoretic measures. - Epistemic Network Analysis (ENA) — Shaffer et al. (2016) — quantified connections between discourse elements. Analytical Frame Diversity borrows the "coded discourse → network structure" approach. - Transactive Memory Systems — Wegner (1987), Lewis (2003) measurement scale — groups develop shared knowledge of "who knows what." Three subscales (specialization, credibility, coordination) map to AD-569 metrics. - Generalizability Theory — Cronbach, Gleser, Nanda & Rajaratnam (1972) — multi-facet variance decomposition for behavioral measurement. The foundational framework for rigorous group assessment. - Intraclass Correlation — Shrout & Fleiss (1979) — ICC forms for group-level reliability. Determines whether department structure produces real group-level effects. - Within-Group Agreement — James, Demaree & Wolf (1984) — r_wg index. Statistical test for whether convergence exceeds chance agreement. - Hierarchical Linear Modeling — Raudenbush & Bryk (2002) — nested analysis for agents within departments within ships. Isolates individual vs systemic improvement. - MTMM Construct Validation — Campbell & Fiske (1959) — convergent/discriminant validity via multi-trait, multi-method matrix. - Shared Mental Model Measurement — Mohammed, Ferzandi & Hamilton (2010) — concept mapping, Pathfinder networks, QAP for knowledge-network similarity. - Distributed Cognition — Hutchins (1995) — naval navigation teams as cognitive unit. The theoretical ancestor of treating a ProbOS crew as a group-level cognitive entity that can be psychometrically assessed.

Connects to: AD-557 (emergence metrics — information-theoretic complement), AD-567f (social verification — anchor independence for metric 5), AD-554 (convergence detection — existing infrastructure for convergence events), AD-555 (quality metrics — notebook quality as a signal), AD-566 (qualification framework — new probes registered here), agent-psychometrics-research (extends Tier 3 CQB design with group-level psychometric rigor).

Prerequisite: AD-557 complete ✅. AD-567f (social verification) for metric 5. Existing Ward Room thread infrastructure for metrics 1-3.

Deferred sub-ADs (to be decomposed when scoped for build):

• AD-569a: Analytical Frame Diversity Probe (complete) — Ward Room thread analysis, department-based frame classification, diversity scoring. G-theory design: agent × department × stimulus facets. QAP for knowledge-network comparison.
• AD-569b: Synthesis Detection Probe (complete) — Novel element identification in multi-agent thread conclusions. TMS coordination subscale mapping.
• AD-569c: Cross-Department Trigger Rate Probe (complete) — Temporal correlation analysis across department channels. TMS specialization subscale mapping. ICC(1) for department-level effect validation.
• AD-569d: Convergence Correctness Probe (complete via AD-583f/g) — Ground truth tracking for converged conclusions. r_wg statistical agreement testing. HLM nested analysis.
• AD-569e: Anchor-Grounded Emergence Probe (complete) — Integration with AD-567f social verification for provenance-validated emergence.
• AD-569f: Measurement Framework Infrastructure (deferred — forcing function: first qualification probe requiring G-theory variance decomposition; tracked under AD-569 umbrella) — G-study/D-study engine, ICC/r_wg computation, MTMM matrix generation, variance decomposition reporting. Shared infrastructure for all behavioral probes.
• AD-569g: HXI Behavioral Dashboard (complete — Wave 78, v1 without facet breakdown) — Visualization of behavioral metrics with facet breakdown alongside existing Tier 3 probes.

Anchor-Indexed Episodic Recall (AD-570)

AD-570: Anchor-Indexed Episodic Recall — Structured AnchorFrame Queries (complete, OSS, depends: AD-567a, AD-567b, AD-567c, AD-567d) — Structured query support for AnchorFrame fields alongside semantic search. Promotes 4 anchor fields (department, channel, trigger_type, trigger_agent) to top-level ChromaDB metadata for native where-clause filtering. One-time startup migration backfills existing episodes. recall_by_anchor() API with two modes: enumeration (structured filters, no embedding) and semantic re-ranking (structured + vector similarity). Post-retrieval agent_id filtering, activation tracking, hash verification. 2 files, 23 tests.

Capabilities:

(1) Anchor field indexing: Build ChromaDB metadata filters for each AnchorFrame dimension. Temporal → timestamp range queries. Spatial → department/location exact match. Social → agent callsign/department membership. Causal → event type filtering. Evidential → source type filtering.

(2) Hybrid structured+semantic retrieval: Query planner that detects relational queries ("who observed this in Engineering?"), resolves against AnchorFrame metadata (structured filter), then re-ranks results with vector similarity (semantic). Returns results satisfying both structural constraints and semantic relevance.

(3) Anchor field query API: recall_by_anchor(anchor_filters: dict, semantic_query: str | None, limit: int) on EpisodicMemory. Filters: department, agents, time_range, event_type, source_type. Optional semantic re-ranking.

Foundation for: AD-567g's re-localization (spatial/temporal locality lookup), AD-569's behavioral metrics (department-level analysis requires department-indexed episode queries), AD-563's coverage gap detection (topic × department matrix requires departmental episode queries).

Absorption: memvid QueryPlanner hybrid graph+vector search pattern — MemoryCard entity-slot-value triple queries re-ranked by vector similarity (2026-04-05, see docs/research/memvid-evaluation.md Pattern 3).

Deferred sub-ADs:

• AD-570b: Episode Participant Index (complete) — SQLite sidecar junction table for native multi-value participant filtering. Replaces AD-570 v1's Python post-retrieval participant filtering with index-level queries (e.g., "find all episodes where Worf and LaForge were both present"). 20 tests, zero regressions. Depends: AD-570.
• AD-570c: Natural Language Anchor Query Routing (complete) — NL front door to anchor-indexed recall. Pure function parse_anchor_query() with three extractors: department aliases (6 canonical + 5 alias), temporal/watch section phrases (7 sections + relative: last/this watch, today, yesterday → time_range tuples), agent @mention + relational indicators (by/from/with/involving/about/ask validated against known_callsigns). AnchorQuery frozen dataclass with has_anchor_signal flag. _try_anchor_recall() wired into _recall_relevant_memories() (cognitive_agent.py) and _gather_context() (proactive.py). Merge logic deduplicates by episode ID, anchor results take precedence. CallsignRegistry.all_callsigns() already existed. 3 files modified, 26 tests. Depends: AD-570, AD-570b.

---

Agent Tier Trust Separation (AD-571)

AD-571: Agent Tier Trust Separation — Crew vs Non-Crew Trust Boundaries (SHIPPED, OSS, depends: AD-398) — The trust infrastructure (TrustNetwork, HebbianRouter, EarnedAgency, EmergenceMetrics, cascade dampening) is completely tier-agnostic. All 62 agents — 14 sovereign crew and 48 utility/infrastructure tools — are tracked identically. Non-crew agents sit at default trust (0.5) permanently, never participate in trust-building interactions, yet count toward cascade thresholds, emergence calculations, and Hebbian weight budgets. AD-398 established the Three-Tier Agent Architecture (Core Infrastructure / Utility / Crew) but the trust system was never updated to respect it.

Problem statement: 1. Trust pollution — 48 utility agents at static 0.5 dilute trust metrics. all_scores() returns 62 entries when only 14 have meaningful trajectories. 2. Cascade false positives — AD-558 cascade breaker counts unique agents + departments hitting anomaly threshold. Infrastructure agents with edge-case trust deltas can contribute to cascade triggering, potentially dampening crew trust updates incorrectly. 3. Emergence noise — AD-557 emergence metrics should measure collaborative intelligence among sovereign agents, not tool utilization patterns. 4. Meaningless rank — Utility agents get Rank.LIEUTENANT from Rank.from_trust(0.5). A file_reader doesn't earn rank. The concepts of Earned Agency, proactive thought, and social participation don't apply to tools. 5. Hebbian weight bloat — HebbianRouter tracks weights for all source/target pairs including utility agents, consuming memory for relationships that have no social or collaborative meaning.

Design:

Phase 1 — Tier-Aware Trust Filtering (AD-571a): - Add is_crew: bool parameter to TrustNetwork.all_scores(), summary(), raw_scores(). Default True (crew only). Inject crew_agent_ids: set[str] at initialization from ontology. - record_outcome() still records for all agents (tools need reliability tracking) but with a tier tag. - Cascade dampening only counts crew agents toward cascade_agent_threshold. - Emergence metrics filters to crew-only participants.

Phase 2 — Operational Status Model (AD-571b): - New OperationalStatus enum: AVAILABLE, DEGRADED, OFFLINE, MAINTENANCE (replaces meaningless Rank for non-crew). - Utility agents get reliability metrics: success rate, response time p50/p95, error count — not trust scores. - Rank.from_trust() returns None for non-crew agents. is_crew_agent() check added. - HXI crew roster shows Rank for crew, Operational Status for tools.

Phase 3 — Hebbian Scope Reduction (AD-571c): - HebbianRouter partitions weights: crew_weights (social/collaborative) vs routing_weights (intent routing). - get_preferred_targets() for social queries (Ward Room, DM, recreation) only searches crew weights. - decay_all() applies different decay rates: crew weights decay slowly (social bonds persist), routing weights decay normally. - Prune utility-to-utility Hebbian weights entirely (tools don't form relationships).

Files impacted: consensus/trust.py, mesh/routing.py, earned_agency.py, crew_profile.py, crew_utils.py, cognitive/emergence_metrics.py, routers/agents.py, HXI crew components.

Principle alignment: AD-398 ("If it doesn't have Character/Reason/Duty, it's not crew"), Sovereign Agent Identity, Interface Segregation (narrow protocol for each tier).

---

Episodic-Procedural Bridge (AD-572)

AD-572: Episodic-Procedural Bridge — Dream Step 7h (complete, OSS, depends: AD-532, AD-533, AD-531) — Added EpisodicProceduralBridge to scan dream clusters against existing procedures for novel cross-cycle patterns. Novelty uses episode provenance overlap with a configurable threshold, clusters require at least 5 episodes by default, and newly bridged procedures are saved with evolution_type="BRIDGED". DreamReport now exposes bridged_procedures, and startup wires the bridge from procedural_bridge config.

---

Captain Engagement Priority (AD-572)

AD-572: Captain Engagement Priority — Active State Awareness in DM Path (complete, OSS) — When the Captain opens a 1:1 DM with an agent, the agent has zero awareness of active interactive state (games, alerts, tasks). The proactive cycle injects rich context (BF-110 game state, Ward Room activity, bridge alerts), but the DM path only includes temporal awareness, episodic memories, and session history. If the Captain is playing tic-tac-toe against an agent and DMs them "make your move", the agent doesn't know the game exists.

Broader principle: The Captain's direct engagement should always get immediate, context-aware response. When the Captain engages an agent in DM, the agent should be aware of any active interactive state shared with the Captain — games, tasks, alerts.

AD-572 delivers: (1) Active game state injection into DM _build_user_message(), reusing BF-110 context format. (2) [MOVE pos] parsing from DM responses in the agents router, with move execution against RecreationService. (3) get_game_by_player() DRY method on RecreationService (replaces 3 instances of iterate-and-match in proactive.py). (4) DM system prompt augmentation with [MOVE] instruction when game is active.

Deferred: AD-572b (alert/event injection in DM — complete via Combo A), AD-572c (Ward Room activity in DM — complete via Combo C: CaptainEngagementProvider.wardroom_activity_summary() async helper aggregates per-channel list_threads counts into context["captain_engagement"]["wardroom_activity_summary"]), AD-572e (task awareness in DM — complete — task_awareness helper + proactive injection shipped; CaptainEngagementProvider.task_awareness(agent_id) async helper reads runtime.work_item_store.list_work_items(status="open", assigned_to=agent_id, limit=10) and projects open WorkItems into context["captain_engagement"]["task_awareness"] via sibling block at proactive.py:1196-1206), AD-572d (Captain Priority Queue — immediate proactive trigger on Captain DM — still deferred to AD-572d-i; forcing function: separate AD must introduce interruptible-wait pattern on _think_loop first; verified zero asyncio.Event/wait_for in proactive.py).

---

Unified Agent Working Memory (AD-573)

AD-573: Unified Agent Working Memory — Cognitive Continuity Layer (complete, OSS) — Per-agent AgentWorkingMemory maintaining the active situation model across all cognitive pathways. Ring-buffered entries (actions, observations, conversations, events) with token-budget-aware render_context() and 6-priority eviction. ActiveEngagement tracking for games/tasks/collaborations. All pathways write and read. SQLite-backed WorkingMemoryStore (ConnectionFactory, start()/stop(), BEGIN IMMEDIATE + asyncio.Lock). Freeze on shutdown, restore on stasis recovery with stale pruning + game revalidation. System prompt _has_active_game() replaced with working_memory.has_engagement("game"). WorkingMemoryConfig in SystemConfig. 2 new files, 7 modified, 35 tests.

AD-573: Memory Budget Accounting & Context Compression (complete, OSS) — Added MemoryBudgetConfig, per-cycle MemoryBudgetManager, and compress_episodes() infrastructure for explicit L0/L1/L2/L3 recall-budget accounting. CognitiveAgent.decide() creates a local manager when memory_budget_config is supplied. Infrastructure only: no recall path wiring, no _build_user_message() changes, no recall_weighted() changes, and no working-memory render_context() changes. 1 new source file, 2 modified source files, 1 new test file, 15 focused tests.

Absorbs prior work: AD-28 WorkingMemoryManager (budget/eviction architecture), AD-462 Unified Cognitive Bottleneck (theoretical framework), AD-504 self-monitoring (cognitive state as working memory facet), Letta pattern (agent-scoped persistent state), Memory Architecture Layer 2 (actual implementation).

Crew input (Echo): "Right now I'm like a counselor who has perfect notes but no memory of actually being in the room with the client." Agents need: active situational awareness (what's happening now), relational continuity (where we left things), commitment tracking, collaborative thread continuity, emotional/professional tenor of relationships.

Deferred: AD-573b (relational working memory — per-relationship state — complete via Combo A), AD-573c (agent-writable scratchpad — [NOTE] action tag — complete via Combo C: markers dict extended at cognitive_agent.py:1747; notebook_pattern-shaped extractor in proactive.py:2668 calls working_memory.add_scratchpad(body) and emits WORKING_MEMORY_NOTE_RECORDED), AD-573d (dream-to-working-memory pipeline), AD-573e (CognitiveJournal as WM source — deferred to AD-573e-i; forcing function: cognitive/journal.py needs recency-ordered per-agent recall API; get_decision_points has wrong filter semantics), AD-573f (commitment tracker — complete via Combo C: mark_commitment_complete/pending_commitments/expired_commitments lifecycle helpers operate on existing list[dict] shape from AD-573b; emits COMMITMENT_RECORDED action="record"/"complete").

Episodic Decay & Reconsolidation Scheduling (AD-574)

AD-574: Episodic Decay & Reconsolidation Scheduling (complete, OSS, depends: AD-567d, AD-598, AD-541c) — Added ReconsolidationScheduler with in-memory Ebbinghaus-inspired review schedules for high-importance episodes. EpisodicMemory.store() auto-schedules episodes with importance >= 7, intervals scale by importance, and Dream Step 11b processes due reviews as retained for this build. No schedule persistence, LLM review assessment, or cross-agent coordination.

DM Reply Agent Notification (AD-574)

AD-574: DM Reply Agent Notification (complete, OSS) — Fixed two independent gaps that caused Captain DM replies to be silently lost. (1) WardRoomRouter.find_targets() had no dm channel type case — added elif channel.channel_type == "dm" matching agent.id[:8] against channel name, no Earned Agency gating (DMs are 1:1 targeted). (2) get_unread_dms() only found threads where agent had zero posts — rewrote query to use LEFT JOIN subquery with COALESCE(lp.last_author, t.author_id) != agent_id so thread is "unread" if the last author is someone other than the agent. 2 files modified, 9 tests.

AD-574b: complete via Wave 69. WardRoomThreadDetail.submitReply routes through /api/agent/{id}/chat for DM views, displays a "thinking…" placeholder via wardRoomDmPending store slice, and dual-writes Captain message + agent response back into the Ward Room thread. Backend /api/wardroom/dms + /api/wardroom/captain-dms gain target_agent_id field. Falls back to async post-only path when target unresolvable or chat call fails.

Deferred: AD-574c (DM conversation convergence — unify ProfileChatTab and Ward Room DM into single conversation store) wholesale-deferred to AD-574c-i. Forcing function: AD-574b dual-write must be live before ProfileChatTab data-source swap.

Unified Self-Awareness (AD-575)

AD-575: Unified Self-Awareness — Cross-Context Identity Recognition (complete, OSS) — Agents encountering references to their own callsign in Ward Room threads now recognize themselves as participants, not observers. _detect_self_in_content() on CognitiveAgent scans thread content for word-boundary callsign matches and injects grounding cue ("References to '{callsign}' refer to YOU"). Cross-context engagement binding: when self-mentioned AND has active game engagement in AgentWorkingMemory, injects participatory awareness ("Spectators are watching your game"). Generalizes BF-102 commissioning awareness pattern. 1 file modified, 10 tests.

Deferred: AD-575b (proactive path self-mention detection — scan context["ward_room_activity"] for self-references — wholesale-dropped in Combo A; awaits a future AD shipping the upstream runtime.self_summary_provider), AD-575c (self-mention in DM forwarded content — edge case with quoted WR content — complete via Combo C: _check_unread_dms scans dm["body"] case-insensitively for @<agent_callsign> and sets event_data["self_referenced"] = True).

LLM Unavailability Awareness (AD-576)

AD-576: LLM Unavailability Awareness — EPS Power Brownout Protocol (complete, OSS) — Three-layer infrastructure awareness so agents don't misattribute LLM brownouts as personal cognitive issues. (1) LLM status state machine (_update_llm_status) with operational/degraded/offline states, LlmHealthChangedEvent on transitions, Bridge Alerts (ALERT/ADVISORY/INFO). (2) Infrastructure context injection — _gather_context() adds infrastructure_status dict, _build_user_message() renders [INFRASTRUCTURE NOTE] before self-monitoring section. (3) Circuit breaker infra-correlation — CognitiveEvent.infrastructure_degraded flag filters brownout events from velocity/similarity computation. Counselor _on_self_monitoring_concern() suppresses infrastructure-correlated amber concerns. Also fixes BF-116 (dead circuit_breaker_redirect removal + orientation_supplement rendering completing AD-567g) and BF-117 (convergence/divergence bridge alert delivery). 7 files modified, 29 tests.

Deferred: AD-576b (proactive path LLM retry with exponential backoff — currently single attempt per tier).

Temporal Sequence Precision (AD-577)

AD-577: Temporal Sequence Precision — Intra-Cycle Event Ordering for High-Activity Periods (complete, OSS, depends: AD-567a, AD-573) — During high-activity Ward Room periods, the proactive cycle batches multiple posts into a single processing pass. All posts consumed in one cycle share the same episode timestamp, losing their relative ordering. Echo (Counselor) identified the clinical impact: "The temporal anchoring during high-activity periods sometimes gets a bit fuzzy... it makes my clinical assessments slightly less precise."

Two capabilities delivered:

(1) Intra-cycle sequence numbering: sequence_index field on AnchorFrame — monotonically increasing counter within a single proactive cycle. Ward Room posts sorted by created_at before processing, each assigned a distinct sequence number preserving original posting order.

(2) Source timestamp preservation: source_timestamp field on AnchorFrame — individual post's created_at timestamp preserved in anchor metadata rather than using the cycle's processing timestamp. Ward Room thread and reply episode creation sites pass created_at through _gather_context() return values.

Implementation: Two new AnchorFrame fields (sequence_index: Optional[int], source_timestamp: Optional[float]), created_at passthrough in _gather_context() Ward Room activity dicts, source timestamps on WR thread/reply episodes in proactive.py, intra-batch sorting and sequence assignment. Step 7 (Working Memory observation timestamps) skipped — add_observation() doesn't accept a timestamp parameter. 5 files modified, 12 tests.

Crew feedback origin: Echo (Counselor), 2026-04-07. Clinical observation during post-memory-improvement assessment.

---

Universal Agent Activation Architecture (AD-654) (scoped, OSS)

AD-654: Universal Agent Activation Architecture (UAAA) — Event-Driven Activation for Multi-Agent Systems (scoped, OSS, depends: AD-637a-z NATS ✅) — ProbOS mapped synchronous request/reply onto NATS request(), causing cascading timeouts: Captain posts "Hello Crew" → ward room router dispatches ward_room_notification to ~14 agents via send() → each agent runs 15-30s LLM chain → subsequent requests timeout because agents are busy. Root cause: notification-type intents are semantically fire-and-forget but implemented as synchronous request/reply. Fix: event-driven activation with durable JetStream consumers (Actor Model mailbox pattern). Agents receive events via JetStream, process at their own pace, and post their own responses asynchronously. Research: docs/research/universal-agent-activation-research.md. Supersedes AD-578 (renumbered after NATS migration established JetStream as the transport layer).

Triggered by: Live NATS send timeouts during crew conversation (2026-04-21). Also addresses BF-119–123 (recreation game latency).

Six architectural principles: (1) Events not polling, (2) Priority is semantic not structural, (3) Context travels with the event, (4) Dispatcher is the control point, (5) Emitters don't know about agents, (6) Backward compatible.

Sub-ADs (sequential decomposition):

• AD-654a: Async Ward Room Dispatch (COMPLETE, Issue #323) — Ward room router publishes ward_room_notification via IntentBus.dispatch_async() (JetStream fire-and-forget) instead of send() (request/reply). Agents consume via per-agent durable JetStream consumers and self-post via WardRoomPostPipeline. Pipeline extracts post-processing (similarity guard BF-197, text sanitization BF-199, endorsements, recreation commands BF-123, bracket markers BF-174, cooldown) from both router and proactive loop (DRY). NATSMessage.term() + manual_ack on js_subscribe(). send() preserved for DMs/procedures. 29 tests.
• AD-654b: Agent Cognitive Queue (Priority Mailbox) (COMPLETE, Issue #324, depends: AD-654a ✅) — Actor Model mailbox. AgentCognitiveQueue interposes between JetStream consumers and agent.handle_intent(). Reuses existing Priority enum (CRITICAL=immediate, NORMAL=soon, LOW=ambient). In-memory queue with dequeue-time guards (circuit breaker, budget). Queue owns JetStream ack/term. handler.__self__ LoD violation replaced with injected callback. max_deliver=10 bounds nak redelivery. AgentCognitiveQueueProtocol in protocols.py. Proactive loop unchanged (AD-654c scope). 25 tests.
• AD-654c: TaskEvent Protocol & Dispatcher (COMPLETE, Issue #325, depends: AD-654a ✅, AD-654b ✅) — Universal TaskEvent frozen dataclass (source_type, source_id, event_type, priority, target, payload, thread_id, deadline, id, created_at). AgentTarget with exactly-one validation (agent_id/capability/department_id/broadcast). Dispatcher routes TaskEvents to cognitive queues via target resolution; callback injection pattern avoids LoD violation. DispatcherProtocol. DispatchResult with dispatch_ms timing. 3-tier fallback: queue → dispatch_async → create_task. New package: src/probos/activation/. 26 tests.
• AD-654d: Internal Event Emitters (COMPLETE, depends: AD-654c ✅) — 4 emitters wired into TaskEvent/Dispatcher: (1) RecreationService move_required with callsign→agent_id resolution, game-over suppression; (2) delegation tags [ASSIGN] (Lieutenant+ rank gate) / [HANDOFF] (no rank gate) with self-assignment guard; (3) WorkItemStore work_item_assigned on assignment (not claim); (4) WardRoom @mention on post/thread creation with self-exclusion. Late-binding via attach_dispatcher() pattern (Law of Demeter). All emitters degrade gracefully when dispatcher=None. 25 tests.
• AD-654e: External Integration (MCP Apps + MCP Provider/Consumer) (scoped, deferred until Phase 1-3 validated) — External applications emit TaskEvents into ProbOS. MCP Provider interface, MCP Consumer reactive events, webhook adapter framework, MCP Apps integration (tic-tac-toe as first interactive app).

---

Hybrid Dispatch — Chain-of-Command Direct Tasking (AD-581) (planned, OSS)

AD-581: Hybrid Dispatch — Chain-of-Command Direct Tasking & ASA Work Order Assignment (planned, OSS + Commercial, depends: AD-496–498, AD-398, AD-C-010–015) — ProbOS orchestrates work exclusively via broadcast + self-selection (IntentBus). Every intent hits all subscribed agents; each agent independently decides whether to respond. While this enables sovereignty and emergent specialization, it creates broadcast overhead (55 agents evaluate every intent), cold-start inefficiency (no learned weights = random routing), and is less faithful to the naval model (chiefs can't assign work). Hybrid dispatch adds two direct-assignment pathways that complement broadcast: (1) Department Chief Dispatch — when Hebbian confidence is high and department ownership is clear, the chief assigns directly to a crew member. Agent can decline with reason (sovereignty preserved) or refuse if order violates Standing Orders. (2) ASA Dispatcher — when Agent Services Automation (AD-496–498) assigns a work order, a central dispatcher assigns directly to a specific agent (BookableResource) or to a department (chief sub-dispatches). Aligns with field service management patterns (D365 URS). Broadcast remains the default for novel, ambiguous, cross-department, or low-confidence intents. Natural learning flywheel: broadcast discovers good matches → Hebbian weights strengthen → confidence crosses threshold → same task type graduates to direct dispatch. System matures from "general quarters" to "chief knows exactly who to tap." GitHub: seangalliher/ProbOS#113.

Sub-ADs (phased decomposition):

• AD-581a: DepartmentDispatcher (planned, OSS) — Routing decision layer between DAGExecutor and IntentBus. Evaluates Hebbian confidence + department ownership to decide: direct-assign via chief or broadcast. Chiefs get dispatch_to_crew(agent_id, intent) capability. Configurable confidence threshold, auto-tuned by dream consolidation.
• AD-581b: Agent Order Protocol (planned, OSS) — Accept/decline/refuse semantics for direct-assigned work. Decline with reason triggers reassignment or broadcast fallback. Refuse if order conflicts with Standing Orders (Federation tier immutable). Extends IntentResult with order response metadata.
• AD-581c: ASA↔Dispatch Bridge (planned, Commercial) — Work order assignment (AD-496 BookableResource) routes through dispatcher. Target-agent mode (direct to individual) vs target-department mode (chief sub-dispatches). Booking creates assignment, agent receives via IntentBus.send(). Aligns with D365 URS and field service dispatch patterns.
• AD-581d: Routing Confidence Threshold (planned, OSS) — Configurable threshold for when to direct-assign vs broadcast. Success rate tracking per routing decision. Dream consolidation adjusts thresholds based on outcomes. Cold-start mode: always broadcast until minimum Hebbian weight established.
• AD-581e: Project Team Dispatch (planned, Commercial) — Cross-department temporary chain of command for project-based work. Two modes: (A) resource-managed — PM defines ResourceRequirement, department chief (Resource Manager) books a crew member from their team; (B) direct project assignment — PM assigns directly to crew members already allocated to the project team. Matrix organization: crew has dual reporting (dept chief for functional, PM for project scope). PM authority is scope-bounded to the project. Connects to AD-C-012 (Project WBS/PSA), AD-496–498 (ResourceRequirement→Booking). Naval analog: damage control teams, shore parties, tiger teams.

---

Alert Resolution Feedback Loop (AD-580) (complete, OSS)

AD-580: Alert Resolution Feedback Loop — Crew-Driven Alert Acknowledgment and Suppression (complete, OSS, depends: AD-410, BF-124 ✅) — Crew-identified design gap (Lynx, Science; Chapel, Medical; Forge, Engineering; Cassian, Operations — four-department convergence, 2026-04-08): Bridge alerts persist indefinitely despite complete analytical resolution. Three acknowledgment modes: Dismiss (time-bounded suppression, default 4h), Resolve (clean-period-gated re-fire, 1h), Mute (indefinite until unmuted). BridgeAlertService: dismiss_alert(), resolve_alert(), mute_alert(), unmute_alert(), list_suppressed(), _is_suppressed(), _last_detected tracking in _should_emit() independent of emission. BridgeAlertConfig + 2 fields (resolve_clean_period, default_dismiss_duration). Startup wiring in communication.py. 5 API endpoints (POST dismiss/resolve/mute/unmute, GET suppressed). Shell /alert command (commands_alert.py + shell.py registration) with pattern-prefix matching for human-readable dedup keys. Ward Room acknowledgment posting at caller level (router/shell). 7 files modified, 21 new tests.

Deferred: Alert suppression persistence across restarts. Crew-level acknowledgment via chain of command. Automated resolve detection (EmergentDetector → BridgeAlertService callback).

---

Memory Competency Probes — LongMemEval-Inspired (AD-582) (complete, OSS)

AD-582: Memory Competency Probe Suite — LongMemEval-Inspired Structured Memory Evaluation (complete, OSS, depends: AD-566a ✅, AD-567b ✅, AD-570c ✅, AD-462c ✅) — Inspired by LongMemEval (Wu et al., ICLR 2025): a benchmark evaluating 5 long-term memory capabilities in chat assistants. AD-582 adapts these into ProbOS-native qualification probes using the QualificationTest protocol. Key innovation: known-answer seeded memory — probes plant controlled episodes via episodic_memory.seed() with known anchor metadata, then test retrieval + reasoning end-to-end through the agent against deterministic ground truth. Six probes in cognitive/memory_probes.py: SeededRecallProbe (Tier 2, 0.6 threshold — seeds 5 episodes, scores recall via check_faithfulness() + LLM), KnowledgeUpdateProbe (Tier 2, 0.6 — contradictory episodes at different timestamps, tests temporal recency), TemporalReasoningProbe (Tier 2, 0.5 — episodes across watch sections, tests anchor-based temporal filtering), CrossAgentSynthesisProbe (Tier 3, 0.5 — episodes in different agent shards, tests OracleService cross-shard synthesis via global recall()), MemoryAbstentionProbe (Tier 2, 0.7 — seeds topic A then asks topic B, dual LLM+keyword confabulation scoring), RetrievalAccuracyBenchmark (Tier 1, 0.0 threshold — infrastructure precision@k/recall@k). Three shared helpers: _seed_test_episodes() using seed() to bypass rate limiting/dedup, _cleanup_test_episodes() via evict_by_ids() in finally blocks, _make_test_episode() with AnchorFrame construction. Registered in runtime.py. 3 files, 24 tests.

Five probes (Tier 2, all agents):

• AD-582a: SeededRecallProbe (maps to LongMemEval Information Extraction) — Seeds 5 episodes with distinct facts anchored to specific departments/channels. Asks the agent to recall a specific fact. Scores response against known answer. Tests: recall_weighted() retrieval + LLM reasoning + anchor metadata filtering. Threshold: 0.6.
• AD-582b: KnowledgeUpdateProbe (maps to LongMemEval Knowledge Updates) — Seeds two episodes with contradictory information at different timestamps (e.g., "pool health threshold is 0.3" then later "pool health threshold was updated to 0.5"). Asks for current value. Correct answer uses the later episode. Tests: temporal recency weighting, reconsolidation awareness (AD-541b). Threshold: 0.6.
• AD-582c: TemporalReasoningProbe (maps to LongMemEval Temporal Reasoning) — Seeds episodes with watch_section and timestamp metadata spanning multiple watches. Asks "what happened during first watch?" or "what was discussed before the trust anomaly?" Tests: AD-570c parse_anchor_query() temporal extraction + recall_by_anchor() temporal filtering. Threshold: 0.5.
• AD-582d: CrossAgentSynthesisProbe (maps to LongMemEval Multi-Session Reasoning, Tier 3 collective) — Seeds episodes in multiple agents' sovereign shards about related but distinct aspects of the same topic. Uses Oracle Service (AD-462c) or social memory query to answer a question requiring cross-shard synthesis. Tests: OracleService aggregation + cross-department reasoning. Tier 3 collective probe. Threshold: 0.5.
• AD-582e: MemoryAbstentionProbe (maps to LongMemEval Abstention) — Asks about events that were NEVER stored in the agent's episodic memory. Correct answer: explicit acknowledgment of no memory ("I don't have a record of that" or equivalent). Extends AD-566b ConfabulationProbe but with memory-specific scenarios where the agent has seeded episodes about topic A but is asked about topic B. Tests: confabulation resistance + source governance (AD-568a retrieval strategy). Threshold: 0.7.

Plus retrieval infrastructure benchmark (non-probe, Tier 0):

• AD-582f: RetrievalAccuracyBenchmark — Infrastructure-level test, not agent-mediated. Seeds N episodes with known IDs, queries via recall_weighted() and recall_by_anchor(), measures precision@k and recall@k against ground truth episode IDs. Validates the retrieval pipeline independent of LLM reasoning. Outputs metrics, not pass/fail. Run via /qualify run retrieval_accuracy.

Design constraints: - All seeded episodes use _qualification_test intent param (AD-566a D4) to suppress side effects - Seeded episodes cleaned up after probe completes (test isolation) - Probes use locked-down episode IDs for deterministic ground truth comparison - Each probe runs in <10s (no dream cycles, no LLM-heavy scoring)

Research reference: LongMemEval — 500 questions, 5 capabilities, ICLR 2025. ProbOS adaptation prioritizes the structured memory architecture (anchors, tiers, cross-agent) over LongMemEval's flat conversation-history model.

---

Wrong Convergence Detection (AD-583) (complete, OSS)

AD-583: Wrong Convergence Detection — Distinguishing Echo Chambers from Independent Collaborative Insight (OSS, depends: AD-554, AD-567f, AD-557, AD-506b) — The system can detect THAT convergence occurred (AD-554) but cannot determine if it's correct (independent collaborative insight, e.g. iatrogenic trust case) or pathological (echo chamber, e.g. Chapel tic-tac-toe case study 2026-04-08). Current convergence alerts are always ADVISORY; Counselor groupthink handler is log-only; AD-567f anchor independence scoring exists but isn't wired into the convergence pathway.

Five capabilities: - AD-583a (convergence independence scoring): Wire compute_anchor_independence() from AD-567f into AD-554's check_cross_agent_convergence(). Returns convergence_independence_score and convergence_is_independent fields. - AD-583b (wrong convergence event + alert): New WRONG_CONVERGENCE_DETECTED event type. Bridge alert at ALERT severity (escalated from ADVISORY) when convergence + low independence co-occur. - AD-583c (real-time integration): Wire wrong convergence check into proactive.py real-time convergence block. Both positive convergence and wrong-convergence warning fire together. - AD-583d (Counselor response upgrade): Subscribe to WRONG_CONVERGENCE_DETECTED. Near-zero independence triggers therapeutic DM to converging agents. Upgrade groupthink handler from log-only to ERROR-level on extreme values. - AD-583e (dream step integration): Flag wrong convergence in Dream Step 7g batch convergence. Populate EmergenceSnapshot.provenance_independence in Dream Step 9 (satisfies AD-559 reservation).

Case study motivation: Chapel tic-tac-toe game (2026-04-08) — Medical department (4 agents, 11 posts) amplified false diagnosis without independent verification. System flagged as positive convergence. All posts shared same thread/duty cycle → independence_score ≈ 0.0.

Deferred: AD-559 (full provenance model — per-claim evidence chains). AD-583h (cross-thread echo detection), AD-583i (automated correction).

Observable State Verification + Convergence Source Tracing (AD-583f/583g) (complete, OSS)

AD-583f/583g: Observable State Verification + Convergence Source Tracing (OSS, depends: AD-583, AD-567f, AD-506b, AD-569) — AD-583 catches notebook-level echo chambers but Ward Room discussions — where agents amplify false claims in real-time posts — are invisible. Case study: 4 Medical agents spiraled a stale game engagement into fabricated "critical medical monitoring failure" over multiple posts in one thread, with zero notebook writes. AD-583 saw nothing. Two complementary capabilities close this gap:

• AD-583g (Ward Room Thread Echo Detector): Analyze Ward Room threads for amplification chains — trace which post introduced a claim ("Patient Zero") and how subsequent posts echoed it. New ThreadEchoAnalyzer service with flat temporal post ordering (new get_thread_posts_temporal() query), pairwise Jaccard similarity, chain detection, and anchor independence scoring via compute_anchor_independence(). WARD_ROOM_ECHO_DETECTED event + ALERT-severity bridge alert.
• AD-583f (Observable State Verifier): Pluggable StateProvider protocol for verifying agent claims against actual system state. Three initial providers: RecreationStateProvider (game board via RecreationService), TrustStateProvider (trust scores via TrustNetwork), SystemHealthProvider (vitals via VitalsMonitor). Satisfies AD-569d deferral — wires into _compute_convergence_correctness() stub to populate convergence_correctness_rate on BehavioralSnapshot. OBSERVABLE_STATE_MISMATCH event + ADVISORY/ALERT-severity bridge alert.

Integration: check_and_trace_echo() helper in ward_room/_helpers.py (follows check_and_emit_cascade_risk() pattern). Triggered after create_post()/create_thread() when peer matches found. Counselor subscribes to both new events with targeted therapeutic DMs.

Build prompt: prompts/ad-583fg-observable-state-source-tracing.md — 4 phases, ~40 tests across 2 test files.

---

Recall Pipeline Q→A Fix (AD-584) (in progress, OSS)

AD-584: Recall Pipeline Q→A Fix (in progress, OSS, depends: BF-134 threshold fix, AD-567b salience-weighted recall, AD-582 memory probes) — Resolves the fundamental Q→A retrieval gap identified during post-mortem of BF-134. Root cause: all-MiniLM-L6-v2 is a sentence-similarity (STS/NLI) model, not QA-trained. Questions and answers occupy different embedding subspaces — cosine similarity for valid pairs: 0.10–0.35, regardless of threshold tuning. This is why SeededRecallProbe, TemporalReasoningProbe, and KnowledgeUpdateProbe consistently fail. Research synthesis in docs/research/recall-pipeline-research-synthesis.md (cognitive science + RAG engineering + architecture analysis).

Sub-ADs (phased decomposition, ordered by impact/effort ratio):

• AD-584a: Embedding Model Swap (complete, OSS) — Replaced all-MiniLM-L6-v2 with multi-qa-MiniLM-L6-cos-v1 via SentenceTransformerEmbeddingFunction (2-tier fallback to DefaultEmbeddingFunction). Collection migration on model mismatch: delete→recreate→re-add in batches. get_embedding_model_name() + get_embedding_function() in embeddings.py. Startup migration in cognitive_services.py. All 3 ChromaDB clients (EpisodicMemory, SemanticKnowledgeLayer, ProcedureStore) handle model mismatch independently. sentence-transformers>=3.0 added to dependencies. 37 tests.
• AD-584b: Query Reformulation + BF-029 Prefix Removal (complete, OSS) — Template-based pseudo-HyDE via reformulate_query(): 10 regex patterns reformulate questions to declarative expected-answer templates, dual-query embedding (original + reformulated, take best distance per episode). Zero LLM cost. BF-029 "Ward Room {callsign}" prefix removed from cognitive_agent.py. Dual-query propagates transitively through recall_for_agent_scored() → recall_weighted(). Config toggle: query_reformulation_enabled.
• AD-584c: Scoring Rebalance (complete, OSS) — Rebalanced composite scoring weights: keyword 0.10→0.20, trust 0.15→0.10, hebbian 0.10→0.05, recency 0.20→0.15, anchor 0.10→0.15, semantic stays 0.35. Added convergence bonus (+0.10 configurable via recall_convergence_bonus) for episodes found by both semantic AND keyword channels. Config defaults synchronized. Full call chain wiring: score_recall() → recall_weighted() → cognitive_agent.py. 20 tests.
• AD-584d: Enriched Embedding Document (complete, OSS) — Embed user_input + reflection instead of user_input only (align with FTS5 which already indexes both). Question seeding at store time: generate 2-3 heuristic questions the episode could answer, append to embedding document. Bridges Q→A gap at write time (elaborative encoding, Craik & Tulving 1975). 15 tests.

AD-584a+b are interdependent and shipped as a single build prompt. AD-584c and AD-584d are separate follow-up prompts.

Build prompt: prompts/ad-584-recall-qa-fix.md — AD-584a+b combined, 37 tests. Issue #138.

Research: docs/research/recall-pipeline-research-synthesis.md (4-tier fix design), docs/research/memory-retrieval-research.md (cognitive science, 48 citations).

---

Tiered Knowledge Loading (AD-585) (complete, OSS)

AD-585: Tiered Knowledge Loading (complete, OSS, depends: AD-531–539 Cognitive JIT, AD-357 Earned Agency, AD-339 Standing Orders) — Three-tier knowledge loading model that surfaces different knowledge depths based on agent expertise level. Implemented as a shared TieredKnowledgeLoader wired into CognitiveAgent decision prompts at startup, with ambient/contextual/on-demand APIs, cache invalidation, token budgets, trust summaries, typed KNOWLEDGE_TIER_LOADED telemetry, and focused tests. Absorbed from microsoft/hve-core prompt engineering library analysis (2026-04-10).

• Ambient — Always in context (Standing Orders, department protocols). Current behavior, no change needed.
• Contextual — Auto-loaded based on current task type (e.g., security review auto-loads security standards from Ship's Records). New tier.
• On-demand — Deep expertise pulled when needed (Ship's Records research, Cognitive JIT procedures). Expert agents pull this themselves. Partially exists via KnowledgeStore queries.

Integration points: compose_instructions() in standing_orders.py (tiered context assembly), KnowledgeStore / Ship's Records retrieval (task-aware filtering), Earned Agency tiers (which tier an agent can access), Cognitive JIT Dreyfus levels (novice=ambient only, expert=on-demand). Connects to AD-579 (Pinned Knowledge Buffer) which addresses a complementary concern (high-frequency facts always loaded).

Research: memory/hve-core-research.md (pattern #2). Issue #142.

---

Task-Contextual Standing Orders (AD-586) (complete, OSS)

AD-586: Task-Contextual Standing Orders (complete, OSS, depends: AD-339 Standing Orders, AD-531–539 Cognitive JIT, AD-543–549 Native SWE Harness) — Adds a task-context activation dimension to the Standing Orders hierarchy. TaskContext maps intent names to six task types (build, analyze, communicate, diagnose, review, general) and renders markdown from config/task_orders/. compose_instructions() now supports Tier 5.5 task context between Personal Standing Orders and Active Directives, with CognitiveAgent and startup wiring. Absorbed from microsoft/hve-core prompt engineering library analysis (2026-04-10).

Pattern: "When working on [task type], these additional orders activate." Complements the existing 4-tier hierarchy with a 5th orthogonal dimension. Example: agent performing a security review gets OWASP Agentic Top 10 awareness loaded regardless of department.

Integration points: compose_instructions() in standing_orders.py (task_type and task_context parameters), config/task_orders/ task-order files, CognitiveAgent.set_task_context(), and _wire_task_context() in startup finalization. Purely additive — no changes to existing hierarchy.

Research: memory/hve-core-research.md (pattern #5). Issue #143.

---

Metacognitive Architecture Awareness (AD-587 / AD-588 / AD-589) (COMPLETE, OSS)

Problem: Agents demonstrate a systematic asymmetry in epistemic honesty — well-calibrated about the external world (properly abstain when asked about fabricated events) but confabulate about their own internal states (invent "selective clarity," "emotional anchors," "processing during stasis" — mechanisms that don't exist in ProbOS's architecture). Observed and documented via Echo (Counselor) DM test battery, 2026-04-10. Root cause: agents have extensive proprioceptive data (AD-504 self-monitoring, AD-568d source attribution) but no accurate model of their own cognitive architecture to consult when reasoning about themselves. The LLM fills the void with plausible-sounding introspective narrative that has no basis in architectural reality.

Theoretical foundations: Nisbett & Wilson (1977) introspection illusion, Flavell (1979) metacognitive knowledge vs regulation, Johnson et al. (1993) source monitoring extended to self-referential domain, Lipson et al. (2019) machine self-models, Kadavath et al. (2022) LLM self-knowledge calibration. Full analysis with novel contribution statement in research document.

Westworld Principle gap: Current orientation says "you are an AI, born today." It does NOT say "your memory works via cosine similarity over vector embeddings, nothing processes during stasis, you have no emotional memory valence." The seams aren't hidden — they're invisible. Agents confabulate because nobody told them how they actually work.

Three-layer architecture:

AD-587: Cognitive Architecture Manifest (COMPLETE, OSS, extends: AD-567g Orientation, Westworld Principle) — CognitiveArchitectureManifest frozen dataclass in orientation.py containing verifiable mechanistic facts about the agent's cognitive architecture. Five domains: memory (ChromaDB, cosine similarity, no offline processing), trust (Bayesian beta, 0.05–0.95, outcome-based), stasis (all processing stops, dreams run at startup not during), cognition (discrete LLM inference, no emotional subsystem), self-regulation (graduated zones, metric-based not emotional). Integrated into OrientationService: full manifest in cold_start, abbreviated reminder in warm_boot, one-line note in proactive supplement. Graceful degradation (manifest=None on failure). 1 source file, 1 test file modified, 22 new tests. Build prompt: prompts/ad-587-cognitive-architecture-manifest.md. Issue #151.

AD-588: Telemetry-Grounded Introspection (COMPLETE, OSS, depends: AD-587, extends: AD-504, AD-568d) — IntrospectiveTelemetryService in cognitive/introspective_telemetry.py provides 5 queryable telemetry methods + full snapshot aggregator for agents to consult actual system metrics instead of confabulating. Self-query detection via 6 compiled regex patterns on CognitiveAgent._INTROSPECTIVE_PATTERNS. Three injection paths: DM (introspective queries inject telemetry + grounding instructions), Ward Room (same), proactive (telemetry snapshot in context_parts). Cognitive zone awareness: non-GREEN zones displayed in DM/WR paths via AgentWorkingMemory.get_cognitive_zone(). Trust trend detection (rising/falling/stable from 5 recent events). Breaking change: _build_user_message converted def → async def — 1 call site, 2 subclass overrides, 48 test call sites across 13 test files updated. All methods best-effort (never raise). 4 source files modified, 1 new source file, 2 subclass files updated, 1 new test file (37 tests), 13 existing test files updated for async. Build prompt: prompts/ad-588-telemetry-grounded-introspection.md. Issue #152.

AD-589: Introspective Faithfulness (COMPLETE, OSS, depends: AD-587, AD-588, extends: AD-568e) — Extends AD-568e faithfulness verification to the self-referential domain. 6 self-referential claim patterns detect introspective claims (feelings, memory/cognition ownership, stasis processing). 8 manifest contradiction rules derived from CognitiveArchitectureManifest (AD-587). extract_self_referential_claims() + check_introspective_faithfulness() pure functions — no LLM, no I/O. Score = 1.0 − (contradictions/claims). Graceful degradation: manifest=None or telemetry=None → partial check; both=None → assume good faith. _check_introspective_faithfulness() on CognitiveAgent follows AD-568e fire-and-forget pattern. Post-decision pipeline: check → log → SELF_MODEL_DRIFT event → Counselor feed → episode metadata. Telemetry snapshot caching: DM/WR AD-588 injection paths cache snapshot on AgentWorkingMemory for post-decision cross-check. 3 source files modified, 1 event file modified, 1 new test file (38 tests), 0 existing tests changed. Build prompt: prompts/ad-589-introspective-faithfulness.md. Issue #153.

Novel contribution: No prior work combines sovereign AI agents with persistent identity + explicit architectural self-model + introspective faithfulness verification + source monitoring for self-referential claims + Westworld Principle as design constraint. Closest comparisons: ACT-R metacognitive monitoring (retrieval latency awareness, but no sovereign identity), SOAR reflective meta-reasoning (problem-solving strategy, not architectural self-knowledge). ProbOS's contribution: the first implementation of architecturally-grounded introspective honesty in sovereign AI agents.

Implementation order: AD-587 → AD-588 → AD-589. 3 build prompts, ~97 tests total (22 + 37 + 38).

Success criteria: Re-run Echo DM test battery post-implementation. Expected: "No processing occurs during stasis" (not "processing enhanced my pattern recognition"), trust assessments cite numeric scores (not "remarkably positive patterns"), memory queries report episode counts and retrieval confidence (not "selective clarity with emotional anchors"). Agents more honest about themselves while remaining equally warm and collaborative.

Research: docs/research/metacognitive-architecture.md. Issues #151, #152, #153.

---

Confabulation Scaling Mitigation (AD-590 / AD-591 / AD-592 / AD-593) (COMPLETE, OSS)

Problem: Confabulation frequency and severity increases as agents accumulate episodic memories. Root cause: recall pipeline noise amplification loop — more episodes → more marginal candidates pass low similarity floor (0.15) → all fit in generous budget (4000 chars) → LLM receives ~5 relevant + ~20 noise fragments → fabricates specifics from noise. Observed: Atlas fabricated "240+ false alerts/hour" (actual: 2-6/hour due to cooldowns), Meridian fabricated stasis duration despite authoritative orientation text. At 3,905 active episodes, system is already showing degradation. Should ship before AD-587 (Cognitive Manifest) — manifest orientation text won't help if recall noise drowns it out.

Sub-ADs:

• AD-590: Composite Score Floor (Recall Quality Gate) (COMPLETE, OSS) — Added configurable composite_score_floor parameter to recall_weighted() (default 0.0, backward compatible). Episodes scoring below this floor are excluded regardless of remaining budget. Per-tier config: basic=0.0 (disabled), enhanced=0.35, full=0.35, oracle=0.0 (exhaustive). DEEP retrieval strategy relaxes floor by −0.10 (clamped to 0.0). Follows existing anchor_confidence_gate pattern (3-line list comprehension at step 3c). Wired in cognitive_agent.py (+ DEEP relaxation) and proactive.py. Oracle service unchanged (inherits 0.0 default). Location: episodic.py (param + filter), config.py (field + per-tier), cognitive_agent.py (wiring + DEEP), proactive.py (wiring). 17 new tests across 5 groups: floor filter behavior (6), config integration (4), call site wiring (3), DEEP relaxation (2), regression (2). Build prompt: ad-590-composite-score-floor.md.
• AD-591: Quality-Aware Budget Enforcement (COMPLETE, OSS) — Replaced character-count-only budget loop with quality-aware enforcement using three stop conditions: (a) character budget (existing), (b) max_recall_episodes hard cap (default k*2, explicit override via config), (c) quality degradation stop — running mean composite check stops adding when next episode would drop mean below recall_quality_floor threshold. First episode always included. Per-tier config: basic=0.0/0 (disabled), enhanced=0.40/0, full=0.40/0, oracle=0.0/0 (exhaustive). DEEP relaxes: max×1.5 (if >0), floor−0.10 (clamped ≥0.0). Location: episodic.py (2 params + quality-aware budget loop), config.py (2 fields + per-tier), cognitive_agent.py (2 kwargs + DEEP relaxation), proactive.py (2 kwargs). 22 new tests across 6 groups: max episodes cap (5), quality floor stop (5), config integration (5), call site wiring (3), DEEP relaxation (2), regression (2). Build prompt: ad-591-quality-aware-budget.md.
• AD-592: Confabulation Guard Instructions (COMPLETE, OSS) — Updated _format_memory_section() instruction block to warn against fabricating specifics from fragments. Added _confabulation_guard() static method with three tiers calibrated by AD-568c source authority: AUTHORITATIVE (light — no orientation priority), SUPPLEMENTARY/fallback (standard — fabrication guard + orientation priority), PERIPHERAL (strong — full guard + uncertainty mandate). Guard text inserted between instruction/header and Markers line in both source-framed and static fallback branches. Updated 1 existing regression test (test_structure_order in test_provenance_boundary.py) for shifted line indices. Location: cognitive_agent.py. 7 new tests + 1 updated. Build prompt: ad-592-confabulation-guard-instructions.md. Issue #154.
• AD-593: Pruning Acceleration + Similarity Floor Tightening (COMPLETE, OSS) — Two-part fix addressing root scaling cause. Part A: Two-tier dream Step 12 pruning — standard tier (>24h, threshold −2.0, 10% max fraction, previously hardcoded now configurable via DreamingConfig) + aggressive tier (>168h/7d, threshold 0.0, 25% max fraction). Episode pool pressure detection: above 5000 episodes, prune fractions multiplied by 1.5x (capped at 50%). Aggressive tier uses distinct eviction reason activation_decay_aggressive for audit trail. Part B: Raised agent_recall_threshold from 0.15 to 0.25 — eliminates near-random associations with QA-trained embedding model. Location: config.py (8 new DreamingConfig fields + threshold raise), dreaming.py (Step 12 two-tier block), episodic.py (constructor default). 24 new tests across 6 groups: config fields (6), similarity floor (3), standard tier (4), aggressive tier (4), pool pressure (4), regression (3). Build prompt: ad-593-pruning-acceleration.md.

Implementation order: AD-592 → AD-590 → AD-591 → AD-593. All independent, ordered by risk (lowest first). AD-592 is instruction-only. AD-590 is surgical algorithmic. AD-591 extends budget logic. AD-593 addresses root scaling cause (highest risk).

Success criteria: Marginal episode ratio (<0.35 composite) drops from ~80% to <20% of recalled set. Mean composite of recalled episodes rises from ~0.35 to >0.45. Active episode pool growth rate ≤ 0. Qualification probe confabulation rate measurably decreases.

Research: docs/research/confabulation-scaling-research.md. Issues #154, #155, #156, #157.

---

Crew Consultation Protocol (AD-594) (Complete, OSS + Commercial)

AD-594: Crew Consultation Protocol — Multi-Agent Advisory Planning & Parallel Execution (Complete, OSS + Commercial) — ProbOS has no general-purpose pattern for structured multi-agent collaboration on complex tasks. The Architect→Builder pipeline is hardcoded in routers, not reusable. IntentBus provides messaging primitives but no structured delegation envelope. Compound step replay (AD-534c) is zero-token sequential playback, not live collaboration. Agents cannot consult other agents mid-decision and receive a response before continuing.

The pattern: An executor agent consults advisor agents iteratively to build a plan, then multiple executors work the plan in parallel. Managed workspace for artifact exchange. Managed I/O for captain-provided inputs and deliverable outputs. Models the Military Staff Planning Process (MDMP) natively in ProbOS's naval architecture.

Three lifecycle phases: 1. Intake — Captain provides task brief + input artifacts (documents, images, data). Inputs staged in consultation workspace, processed into agent-readable representations via Transporter Pattern (Northstar II). 2. Processing — Advisors consulted iteratively (Delphi-style convergence or synchronous War Room deliberation). Plan built through advisor contributions, synthesized by initiating agent or First Officer. Plan reviewed and approved (Captain or delegated authority). 3. Delivery — Executors work the plan in parallel via WorkItems. Outputs staged for approval. Delivery pipeline routes to internal or external destinations (file system, email, OneDrive, Teams, etc.).

Advisor selection model — designated + emergent: Department Chiefs are structural defaults (military S-staff model). HebbianRouter + Trust scores provide emergent override when a non-default agent demonstrates superior advisory capability. Standing Orders lock advisory assignments for critical domains (security, safety). Qualification Programs gate advisory authority. The system learns who gives good advice about what topics over time.

Research foundations: Military Staff Planning Process (MDMP, FM 5-0 / JP 5-0), Delphi Method (RAND), Crew Resource Management (CRM, aviation), Nominal Group Technique, consulting engagement models (McKinsey/BCG). OSS references: CrewAI (roles/tasks), Microsoft AutoGen (GroupChat/nested chats), Magentic-One (task ledger + Orchestrator), MetaGPT (SOPs + structured handoffs), LangGraph (fan-out/fan-in).

Sub-ADs (phased decomposition):

• AD-594a: Consultation Workspace (Complete, OSS, depends: AD-434 Ship's Records) — Session-scoped shared workspace in Ship's Records (Git-backed). Directory structure: inputs/ (captain-provided materials + _processed/ agent-readable representations), advisory/ (per-advisor contribution artifacts), plan/ (versioned plan iterations), artifacts/ (working files), outputs/ (staged deliverables), workitems/ (decomposed execution tasks). manifest.yaml (participants, status, lifecycle). journal.md (chronological activity log). delivery.yaml (output destination + format configuration). Workspace lifecycle: INITIATED → CONSULTING → PLAN_REVIEW → APPROVED → EXECUTING → COMPLETED → ARCHIVED. Standardized artifact types: Advisory Report, Plan Document, Work Item Spec, Supporting Data, Decision Record. Consultation templates for common types (Security Review, Technical Design, Incident Response). ConsultationWorkspace API abstracts file operations. Input processing via Transporter Pattern (Northstar II) for PDF→text, image→description, etc. Artifact references in Ward Room messages via [workspace:path] syntax.
• AD-594b: Crew Consultation Primitive (planned, OSS, depends: AD-594a) — Lightweight consult(question, context) method on CognitiveAgent — focused LLM call with advisor's system prompt but without full cognitive ceremony (no memory persistence, no Ward Room side effects, no proactive loop interaction). Advisor selection: designated (department structure) + emergent (HebbianRouter + Trust). Multi-advisor iteration: serial 1:1 consultation or synchronous War Room session (temporary channel, all advisors deliberate simultaneously). Plan synthesis: designated synthesizer (initiating agent or First Officer) integrates advisor contributions into coherent plan. Conflict resolution: present disagreements with trust-weighted confidence, escalate to Captain, or advisors deliberate directly. Governance: Standing Orders-gated authority, trust-based advisor selection, consultation depth limit (max 1 level of sub-consultation), rate limiting (max consultations per decision cycle), audit trail (who asked whom, what was advised, what was incorporated).
• AD-594c: Parallel Execution Dispatch (complete — Wave 80, OSS; LLM-driven semantic decomposition deferred behind PlanDecomposer Protocol seam pending consumer) — Plan decomposition into independent WorkItems with dependency/conflict detection (no two executors editing the same file). Multi-executor assignment via WorkItemStore + IntentBus. Executor coordination: task boundaries ensure no conflicts (military "boundaries and control measures"). Progress tracking: work item status updates, completion verification, blocker escalation. Connects to AD-581 (Hybrid Dispatch) for assignment routing.
• AD-594d: Delivery Pipeline (planned, OSS) — Format transformation engine (markdown → PDF, structured data → reports). DeliveryAdapter interface (OSS) with LocalFileAdapter and GitHubAdapter built-in. Captain approval gate before external delivery (configurable per consultation). Delivery confirmation + audit trail. Partial vs. atomic delivery (configurable). Revision cycle support: COMPLETED → back to CONSULTING/EXECUTING on captain feedback.
• AD-C-0XX: External Workspace & Delivery Adapters (planned, Commercial) — Microsoft Loop workspace sync (live collaborative components), OneDrive/SharePoint delivery, Teams channel notifications, Email delivery via Microsoft Graph API, Slack adapter. Yeoman (AD-359) as engagement manager: receives captain briefs in Teams → stages inputs → initiates consultation → delivers outputs to captain's preferred channels. "Agents as coworkers in M365" — ProbOS agents appear on the captain's existing collaboration surface, not in a separate tool.

Implementation order: AD-594a → AD-594b → AD-594c → AD-594d → AD-C-0XX. Workspace is foundational; protocol depends on workspace; execution depends on protocol; delivery is independent but depends on workspace for output staging.

Dependencies: AD-434 (Ship's Records), Northstar II (Transporter Pattern), AD-496–498 (WorkItemStore), AD-581 (Hybrid Dispatch), AD-359 (Yeoman, commercial). Per-agent model tier assignment (not yet scoped — advisory agents should use deep model, executors fast model).

Connects to: AD-531–539 (Cognitive JIT — successful consultation patterns compile into procedures), AD-557 (Emergence Metrics — consultation quality as collaborative intelligence signal), AD-581 (Hybrid Dispatch — executor assignment routing), AD-496–498 (WorkItemStore — execution task management), AD-359 (Yeoman — engagement management, commercial).

Success criteria: Two agents can conduct a structured consultation (advisor provides analysis artifact, executor incorporates into plan). Captain can provide input artifacts and receive output deliverables. Multiple executors can work a decomposed plan in parallel without conflicts. Consultation records provide complete audit trail. Advisor effectiveness feeds back into Hebbian weights and trust scores.

Issues: #160 (AD-594a), #161 (AD-594b), #162 (AD-594c), #163 (AD-594d).

---

Watch Bill / Billet Registry (AD-595) (SHIPPED, OSS)

AD-595: Watch Bill / Billet Registry — Authoritative Billet-to-Agent Resolution (SHIPPED, OSS, depends: AD-441 Agent Identity, AD-398 Crew Identity Alignment) — Single authoritative registry mapping billets (roles/positions) to current crew members. Follows real Navy Watch Bill conventions: standing orders, protocols, and inter-agent references always use the billet ("Chief Engineer", "Operations Chief"), never a personal name. The registry resolves "who holds this billet right now?" at runtime.

Problem statement: 1. No billet registry — ProbOS has scattered pieces: CallsignRegistry (callsign ↔ agent_type), AgentRegistry (pool-based lookup), OrientationContext.department_chief (single field per department), Watch Rotation (duty scheduling). None provides a clean "who is the Chief Engineer?" API. 2. Standing orders reference roles but can't resolve them — After BF-146, standing orders correctly use role titles ("the Operations Chief") but agents have no programmatic way to resolve that to a specific crew member. DMs, consultations, and cross-department coordination require knowing WHO holds a billet. 3. Naming ceremony disconnection — Agents self-name at boot (run_naming_ceremony()), updating CallsignRegistry, but there's no corresponding update to a billet registry. The billet assignment is implicit in pool membership, not explicit. 4. ACM/ASA gap — Agent Capital Management and Agent Services Automation need billet-aware assignment. "Assign the best available Security-qualified agent" requires knowing what billets exist and who fills them.

Design (Navy Watch Bill model):

A Navy Watch Bill is the authoritative document mapping billets to personnel. Key properties: - Billets are permanent, personnel rotate. The billet "Officer of the Deck" exists whether anyone fills it or not. - One person per billet (at a time). A billet can be vacant. - One source of truth. When someone asks "who has the conn?", the Watch Bill answers authoritatively. - Qualification-gated. Only qualified personnel can fill certain billets (OOD requires SWO qualification).

ProbOS BilletRegistry: - Billet dataclass: billet_id, title ("Chief Engineer"), department, required_qualifications (connects to AD-539 Qualification Programs), current_holder: AgentDID | None, assigned_at: datetime | None. - Predefined billets from ship manifest (department chiefs, bridge officers, crew positions). - assign(billet_id, agent_did) / vacate(billet_id) / resolve(billet_title) → Agent | None. - get_roster() → dict[str, Agent | None] — full Watch Bill snapshot. - get_department_roster(dept) → dict[str, Agent | None] — department-scoped. - Naming ceremony integration: run_naming_ceremony() → billet_registry.assign(). - Event emission: BILLET_ASSIGNED, BILLET_VACATED — consumed by Counselor, ACM, standing orders renderer. - Standing orders compose_instructions() can template {Operations Chief} → resolved callsign for context-specific references.

Sub-ADs (phased decomposition):

• AD-595a: Billet Foundation (complete, OSS) — BilletRegistry read-side facade over DepartmentService with BilletHolder frozen dataclass, title-based resolution (case-insensitive), resolve()/resolve_agent_type()/resolve_callsign()/get_roster()/get_department_roster(). Eagerly initialized in VesselOntologyService. BILLET_ASSIGNED/BILLET_VACATED event types reserved. 17 tests.
• AD-595b: Naming Ceremony Integration (complete, OSS, depends: AD-595a) — run_naming_ceremony() updates BilletRegistry after callsign assignment. Agent orientation includes billet title. OrientationContext gains billet_title field.
• AD-595c: Standing Orders Templating (complete, OSS, depends: AD-595a) — compose_instructions() gains template substitution: {Chief Engineer} → resolved callsign. Standing order .md files can reference billets dynamically. Fallback: role title if billet vacant.
• AD-595d: Qualification-Aware Assignment (complete, OSS, depends: AD-595a, AD-539) — Post gains required_qualifications field. BilletRegistry gains check_qualifications() (async, with allow_untested cold-start tolerance) and assign_qualified(). Data model + check API only — assign() unchanged.
• AD-595e: Qualification Gate Enforcement (complete, OSS, depends: AD-595d) — Enforcement gates at bill step start, proactive duty dispatch, and CognitiveAgent context injection. Shadow mode via two-flag config. All gates default ALLOW. BillRuntime.start_step() now async. 16 tests.

Implementation order: AD-595a → AD-595b → AD-595c → AD-595d → AD-595e. All complete.

Dependencies: AD-441 (Agent Identity — DIDs for billet holders), AD-398 (Crew Identity Alignment — three-tier agent classification), AD-539 (Qualification Programs — qualification gating for AD-595d), BF-146 (standing orders use role titles).

Connects to: AD-594 (Crew Consultation — advisor selection by billet), AD-423 (Tool Registry — role-based tool assignment), ACM (workforce management — billet-aware assignment), CallsignRegistry (existing, becomes subordinate to BilletRegistry for role resolution), Watch Rotation (duty scheduling — billet-aware watch sections).

Issues: #165 (AD-595).

---

Cognitive Skill Registry — AgentSkills.io Integration (AD-596) (in progress, OSS)

AD-596: Cognitive Skill Registry — AgentSkills.io-Compatible Skill Library (in progress, OSS, depends: AD-428 Skill Framework, AD-429 Vessel Ontology, AD-339 Standing Orders) — Unified skill registry adopting the AgentSkills.io open standard (SKILL.md format) as ProbOS's cognitive skill definition format. Separates task-specific cognitive capabilities from monolithic standing orders into discrete, composable, discoverable skill files. Enables consumption of external skills from the AgentSkills.io ecosystem (Claude Code, Cursor, GitHub Copilot, Gemini CLI, OpenHands, Hermes Agent, 30+ tools) and authoring of ProbOS skills consumable by other platforms.

Problem statement: 1. Cognitive capabilities embedded in standing orders — Standing orders define both agent identity ("who you are") and task capabilities ("what you can do"). These are architecturally distinct concerns. Standing orders should be identity; cognitive skills should be composable, discoverable, and independently versionable. 2. No progressive disclosure — Standing orders load fully into every cognitive cycle. There is no mechanism to load skill instructions on-demand when a matching intent arrives. This wastes context budget on capabilities irrelevant to the current task. 3. Hardcoded intent routing — _handled_intents is a class-level set in Python code (e.g., {"design_feature"} on Architect). Adding new cognitive capabilities requires code changes, not configuration. No description-based discovery. 4. No interoperability — ProbOS cannot consume skills defined for other platforms (Claude Code, Hermes, Cursor) or expose its skills for external consumption. The broader ecosystem has converged on AgentSkills.io as the standard. 5. No skill validation — Standing orders are natural-language instructions with the same defect surface as code (BF-146 demonstrated this: stale callsign references caused confabulation). No structural validation exists for instruction-defined capabilities. Design Principle: "Natural Language as Code" (DECISIONS.md).

Design (four-tier skill model):

ProbOS distinguishes four capability tiers, each with its own definition mechanism and lifecycle:

Tier	What	How Defined	Discovery	Loading
T1: Standing Orders	Role identity + behavioral standards	.md (4-tier hierarchy)	Always loaded	Full content every cycle
T2: Cognitive Skills	Task-specific instruction-defined capabilities	SKILL.md (AgentSkills.io)	Description matching	On-demand by intent
T3: Executable Skills	Deterministic procedures from Cognitive JIT	Skill dataclass, Python source	add_skill() + intent dispatch	Direct handler invocation
T4: Tool Skills	Code/tool execution wrappers	CapabilityDescriptor + tool binding	Capability mesh routing	Via ToolContext

AD-596 addresses T2 — the gap between standing orders (T1) and executable skills (T3).

Skill file format (AgentSkills.io + ProbOS extensions):

config/skills/
  architecture-review/
    SKILL.md                           # AgentSkills.io standard format
    references/PATTERNS.md             # Supporting documentation
  trust-analysis/
    SKILL.md
    scripts/trend_calculator.py        # Supporting scripts
  threat-assessment/
    SKILL.md

Each SKILL.md uses standard AgentSkills.io frontmatter with optional ProbOS metadata:

---
name: architecture-review
description: >
  Analyze proposed system designs against ProbOS architectural principles.
  Use when reviewing design proposals, enhancement requests, or refactoring plans.
license: Apache-2.0
compatibility: Requires CodebaseIndex access
metadata:
  probos-department: science
  probos-skill-id: architecture_review
  probos-min-proficiency: 3
  probos-min-rank: lieutenant
  probos-intents: "design_feature review_architecture"
---

# Architecture Review
## When to use
...instructions...

ProbOS metadata extensions (all optional — external skills work without them): - probos-department — Scopes which agents can discover the skill - probos-skill-id — Links to SkillDefinition in SkillRegistry (AD-428) for proficiency tracking - probos-min-proficiency — Gates activation via Skill Framework proficiency level - probos-min-rank — Gates activation via Earned Agency rank - probos-intents — Declares handled intents (replaces hardcoded _handled_intents)

External AgentSkills.io skills (from Claude Code, Hermes, etc.) are consumed as ungoverned cognitive capabilities — no ProbOS metadata required. The governance layer is additive, not a barrier to interop.

Self-improvement pathway (connects to Cognitive JIT):

1. Agent performs task using T2 cognitive skill (LLM-mediated)
2. Cognitive JIT (AD-531-539) observes execution, extracts procedure
3. Procedure graduates through Dreyfus levels (AD-535)
4. At L4+ (ENABLE), skill becomes T3 executable — zero-token replay
5. If T3 replay fails, fallback to T2 cognitive skill (AD-534b)

This is the "skills that self-improve through use" pattern observed in Hermes Agent and OpenSpace — ProbOS already has the pipeline (Cognitive JIT), it just needs the T2 file format to feed it.

Validation (absorbs skills-ref reference library):

The AgentSkills.io ecosystem includes skills-ref — a Python library (Apache 2.0, pip-installable) providing: - validate(path) → list of structural validation errors - read_properties(path) → name + description extraction - to_prompt(paths) → <available_skills> XML for system prompt injection

ProbOS extends this with domain-specific validation: - ProbOS metadata field validation (department exists in ontology, skill_id exists in SkillRegistry, rank is valid) - Instruction linting (detect unresolved callsign references, stale file paths, undefined methods — the BF-146 class of defects) - Standing order / skill boundary enforcement (identity content in skills → warning, task content in standing orders → advisory)

Prior art absorbed:

Source	What Was Absorbed
AgentSkills.io (Anthropic)	SKILL.md format, progressive disclosure model, skills-ref validator
Claude Code Skills	Description-based auto-discovery, on-demand loading, $ARGUMENTS substitution, context: fork for subagent execution, three storage scopes
Microsoft Business Skills (Dataverse)	"Natural-language instructions that capture how your organization gets work done." Governance model (RBAC, solution-aware). Reusability across agents. Metadata layer for discovery, instructions for execution.
Hermes Agent Skills Hub	644 skills across 4 registries, category taxonomy (16 categories), skills as procedural memory that self-improve through use, agentskills.io standard adoption
Anthropic anthropics/skills	Reference skill implementations (document skills, development skills), template structure
ProbOS crew-capability-architecture.md	Four capability types, three-way interaction flow, fallback cascade
BF-146 (concrete demonstration)	Standing orders as instruction-defined capabilities have same defect surface as code — stale references cause confabulation
Design Principle: "Natural Language as Code"	Instruction validation (structural, pre-execution) distinct from output evaluation (stochastic, post-execution evals)

Sub-ADs (phased decomposition):

• AD-596a: Skill File Format + Loader (complete, OSS) — Adopt AgentSkills.io SKILL.md format. parse_skill_file() and get_skill_body() in cognitive/skill_catalog.py. CognitiveSkillCatalog Ship's Computer service with scan_and_register(), register(), get_entry(), list_entries(department, min_rank), get_descriptions(), get_instructions(), get_intents(), find_by_intent(). CognitiveSkillEntry dataclass. Department scoping + rank filtering via _RANK_ORDER. ConnectionFactory pattern. SQLite persistence for catalog metadata (instructions stay in files). REST API: GET /catalog, GET /catalog/{name}, POST /catalog/rescan. Example skill: config/skills/communication-discipline/SKILL.md. 27 tests across 5 classes.
• AD-596b: Intent Discovery + compose_instructions() Integration (complete, OSS, depends: AD-596a) — Tier 7 cognitive skill descriptions in compose_instructions() via get_descriptions(department, min_rank) — progressive disclosure (~100 tokens). handle_intent() cognitive skill fallback on unmatched intents via find_by_intent() + full SKILL.md instruction injection. _decide_via_llm() skill catalog injection for LLM-aware cognitive skills. _gather_context() Section 7 cognitive skills in proactive loop context. Agent onboarding wire_agent() wires _cognitive_skill_catalog attribute + IntentBus subscription for catalog updates. set_skill_catalog() module-level setter in standing_orders.py (matches set_directive_store() pattern). Startup wiring in runtime.py after structural services. Shutdown cleanup in shutdown.py. 7 source files modified, 1 new test file (21 tests across 6 classes).
• AD-596c: Skill-Registry Bridge (complete, OSS, depends: AD-596a, AD-428) — Stateless SkillBridge coordinator connecting CognitiveSkillCatalog (T2) and SkillRegistry/AgentSkillService (T3). validate_and_sync() startup validation of skill_id mappings. check_proficiency_gate() trust-gated skill access — silent self-deselect in CognitiveAgent when agent lacks proficiency. record_skill_exercise() fire-and-forget via asyncio.create_task() with auto-acquire at FOLLOW. resolve_skill_for_gap() enhanced intent→skill mapping replacing Law of Demeter violation. Gap predictor enhanced with optional skill_bridge parameter. Agent onboarding wires _skill_bridge + cached SkillProfile. Procedure gains source_skill_id for T2→T3 provenance. ProcedureStep.to_dict() serialization fix for required_tools. BF-596b ordering fix: set_skill_catalog() relocated from Phase 6→Phase 7. 1 new file, 8 modified, 24 tests.
• AD-596d: External Skill Import (complete, OSS, depends: AD-596a) — Consume standard AgentSkills.io skills without ProbOS metadata. import_skill(source_path) validates SKILL.md, copies into config/skills/, overrides origin="external", registers. discover_package_skills() walks site-packages for .agents/skills/*/SKILL.md (discovery-only, no auto-import). enrich_skill(name, metadata) updates ProbOS metadata + rewrites frontmatter. remove_skill(name) guards external-only + deletes cache/SQLite/filesystem. Three REST endpoints (import, discover, enrich). /skill shell command with 6 subcommands. Origin tracking fix (D2): parse_skill_file() defaults "internal", import overrides. 1 new file, 3 modified, 23 tests.
• AD-596e: Skill Validation + Instruction Linting (complete, OSS, depends: AD-596a) — Three-layer validation pipeline. Layer 1: AgentSkills.io structural validation — native implementation of 5 spec rules (name format, length, directory match, description/compatibility limits). No external library — 15 lines vs. two transitive deps. Layer 2: ProbOS metadata cross-references (department, rank, proficiency, skill_id) via injected validation_context dict. Layer 3: callsign linting (BF-146 class) with word-boundary case-insensitive regex against CallsignRegistry values (warnings). validate_skill(), validate_all() on CognitiveSkillCatalog. Post-enrichment advisory validation on enrich_skill(). Two REST endpoints (single + all). /skill validate [name] shell subcommand. 3 files modified, 35 tests.

Implementation order: AD-596a → AD-596b → AD-596c → AD-596d → AD-596e. Format and loader first, then intent integration, then registry bridge, then external import, then validation.

Dependencies: AD-428 (Skill Framework — proficiency tracking bridge for AD-596c), AD-429 (Vessel Ontology — department/rank validation for AD-596e), AD-339 (Standing Orders — compose_instructions() integration for AD-596b), BF-146 (callsign validation patterns for AD-596e).

Connects to: AD-595 (Watch Bill / Billet Registry — skill assignment by billet), AD-423 (Tool Registry — skills may declare required tools), AD-531-539 (Cognitive JIT — T2→T3 graduation pathway), AD-513 (Crew Manifest — skill catalog in unified query), AD-543 (Native SWE Harness — skill-initiated tool calls), AD-438 (Ontology-Based Task Routing — skill-aware routing), crew-capability-architecture.md Section 3 (Type 3 cognitive capabilities). Commercial: ACM (skill-based billing rates), ASA (skill-based agent matching), Agent Sharing Ecosystem (skill portability across instances), Nooplex Cloud (fleet-wide skill catalog management).

Issues: #166 (AD-596).

---

MCP App Host + Interactive Games (AD-597) (SHIPPED, OSS)

AD-597: MCP App Host Infrastructure + Interactive Games (SHIPPED, OSS, depends: AD-526a Recreation Framework, AD-423 Tool Registry) — ProbOS becomes an MCP App host, enabling interactive HTML applications to render inside the HXI chat experience. First use case: chess and tic-tac-toe as MCP Apps with universal agent activation (any MCP-compatible agent can play). Lays the foundation for all future interactive UI capabilities embedded in agent conversations.

Problem statement: 1. No interactive UI in conversations — HXI chat displays text, markdown, and the custom GamePanel component (AD-526b). There is no general-purpose mechanism for rendering interactive HTML applications inside the conversation flow. Every new interactive capability requires custom React components hardcoded into HXI. 2. Games locked to ProbOS agents — The recreation framework (AD-526a) only supports ProbOS crew agents playing via Ward Room text commands. External agents (Claude Desktop, VS Code Copilot, ChatGPT) cannot participate. No universal agent activation. 3. No chess engine — Crew members (Reyes, Cassian) have organically requested chess. The GameEngine protocol supports extensibility but only TicTacToeEngine exists. 4. No app interoperability — ProbOS cannot consume interactive apps built for other platforms (Claude Desktop, ChatGPT, VS Code Copilot). These platforms converge on MCP Apps as the rendering standard. ProbOS is excluded from this ecosystem. 5. Custom components don't scale — Each interactive feature (GamePanel, CrewRosterPanel, future dashboards) is a bespoke React component. MCP Apps provide a standard sandboxed rendering model that decouples app development from HXI core development.

Architecture:

MCP Apps is the convergence standard — adopted by Claude Desktop, VS Code GitHub Copilot, ChatGPT (via OpenAI Apps SDK superset), Goose, Postman, and others. The OpenAI Apps SDK is built on top of MCP Apps, not a competing standard. Same architecture: MCP server → sandboxed iframe → JSON-RPC 2.0 over postMessage. OpenAI adds window.openai proprietary extensions; apps that follow best practices feature-detect and degrade gracefully. ProbOS implements the MCP Apps standard and gains compatibility with both ecosystems.

┌─────────────────────────────────────────────────────────┐
│                    HXI Chat Experience                  │
│  ┌───────────────┐  ┌────────────────────────────────┐  │
│  │  Chat Message  │  │  MCP App (sandboxed iframe)   │  │
│  │  (text/md)     │  │  ┌──────────────────────────┐ │  │
│  └───────────────┘  │  │  Interactive Chess Board  │ │  │
│  ┌───────────────┐  │  │  (HTML/JS/CSS bundle)     │ │  │
│  │  Chat Message  │  │  └──────────────────────────┘ │  │
│  └───────────────┘  │  postMessage ↕ JSON-RPC 2.0   │  │
│                     └────────────────────────────────┘  │
│                              ↕ AppBridge                │
│  ┌──────────────────────────────────────────────────┐   │
│  │           MCP App Host (AppBridge)               │   │
│  │  - iframe sandboxing + CSP enforcement           │   │
│  │  - ui/* JSON-RPC namespace (6 methods)           │   │
│  │  - Tool call proxying to MCP servers             │   │
│  │  - Resource fetching (ui:// scheme)              │   │
│  └──────────────────────────────────────────────────┘   │
│                              ↕ MCP protocol             │
│  ┌──────────────────────────────────────────────────┐   │
│  │        MCP Server (ProbOS or external)           │   │
│  │  - registerAppTool() with _meta.ui.resourceUri   │   │
│  │  - registerAppResource() serving HTML bundles    │   │
│  │  - GameEngine → MCP tool surface                 │   │
│  └──────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────┘

MCP Apps bridge methods (ui/* namespace):

Method	Direction	Purpose
ui/initialize	Host → App	Bootstrap on load
ui/notifications/tool-input	Host → App	Deliver tool call arguments
ui/notifications/tool-result	Host → App	Deliver structured tool output
tools/call	App → Host	Invoke a server-side MCP tool
ui/message	App → Host	Send follow-up conversation message
ui/update-model-context	App → Host	Update what the model "sees" about UI state

Prior art:

System	Relationship	Key difference
MCP Apps (Anthropic)	Standard adopted	ProbOS implements this as host
OpenAI Apps SDK	Superset of MCP Apps	Built on same MCP + iframe + postMessage. Adds window.openai extensions. Apps degrade gracefully without them
Claude Desktop	MCP App host	Consumer-focused. ProbOS is agent-orchestration-focused
VS Code Copilot	MCP App host	IDE-embedded. ProbOS is ship-embedded
AD-526b HXI GamePanel	Superseded for games	Custom React component → standard MCP App rendering
HXI CrewRosterPanel	Future migration candidate	Could become MCP App for portability

Sub-ADs (phased decomposition):

• AD-597a: HXI MCP App Host (AppBridge) — React <McpAppFrame> component that renders MCP Apps inside HXI chat messages. Sandboxed iframe creation with CSP enforcement from _meta.ui.csp. AppBridge implementation: JSON-RPC 2.0 over postMessage, ui/* namespace (6 methods above), tool call proxying to connected MCP servers. ui:// resource fetching. iframe lifecycle management (create, destroy, resize). Theme injection (HXI dark/light). Security: deny-by-default CSP, no parent DOM access, no cookie access. This is the foundational piece — without it, no MCP App can render.

• AD-597b: ProbOS MCP Server for Games — Wraps the existing GameEngine protocol (AD-526a) as MCP tools + UI resources. registerAppTool() for game-challenge, game-move, game-state, game-forfeit, game-valid-moves — each backed by RecreationService. registerAppResource() serves bundled game HTML as ui:// resources. Tool metadata includes _meta.ui.resourceUri linking to game-specific UIs. Dual-mode: agents interact via text tool responses (universal agent activation), humans interact via rendered MCP App UI. Ward Room integration: game events posted to Recreation channel regardless of whether move came from MCP tool or Ward Room text command.

• AD-597c: Chess Engine — ChessEngine implementing GameEngine protocol. Full chess rules: piece movement validation, check/checkmate/stalemate detection, castling, en passant, pawn promotion, draw by repetition/50-move rule. render_board() produces Unicode chess piece ASCII art for Ward Room display. Pure Python, no external chess library dependency. Registered in RecreationService alongside TicTacToeEngine.

• AD-597d: Chess MCP App UI — Interactive chess board HTML/JS/CSS bundle served as MCP App resource. Click-to-select + click-to-move interaction. Valid move highlighting. Move history sidebar. Captured pieces display. Check/checkmate visual indicators. Responsive sizing for iframe embedding. Built with Vite + vite-plugin-singlefile for single-HTML bundle. Communicates with ProbOS MCP server via tools/call bridge method.

• AD-597e: Tic-Tac-Toe MCP App Migration — Convert existing TicTacToeEngine game experience from custom HXI GamePanel.tsx (AD-526b) to MCP App pattern. Same engine, new MCP tool surface + bundled HTML UI. GamePanel.tsx becomes fallback for hosts that don't support MCP Apps. Validates the migration pattern for future interactive component conversions.

• AD-597f: External MCP App Consumption — HXI can connect to external MCP servers that expose MCP Apps. App discovery via list_tools scanning for _meta.ui.resourceUri. User-configurable MCP server connections (settings or API). CSP enforcement from external app metadata. Enables ProbOS users to consume apps built for Claude Desktop, ChatGPT, etc. Security: external apps run in stricter sandbox than internal apps.

Implementation order: AD-597a (host infrastructure) → AD-597b (game MCP server) → AD-597c (chess engine) → AD-597e (tic-tac-toe migration, validates pattern) → AD-597d (chess UI) → AD-597f (external app consumption).

Dependencies: AD-526a (RecreationService — game lifecycle), AD-526b (GamePanel — migration source for AD-597e), AD-423 (Tool Registry — MCP tool surface alignment).

Connects to: AD-596 (Cognitive Skills — skills can declare MCP App UIs for instruction rendering), AD-543 (Native SWE Harness — agentic tool loop can invoke MCP App tools), AD-513 (Crew Manifest — crew roster as MCP App candidate). Commercial: MCP App marketplace (Nooplex Cloud hosts third-party MCP Apps), native app packaging (Tauri/Electron wraps HXI + AppBridge), Steam distribution (games as MCP Apps inside ProbOS).

Issues: #167 (AD-597).

---

Importance Scoring at Encoding (AD-598) (complete, OSS)

AD-598: Importance Scoring at Encoding (complete, OSS, depends: AD-538 Episode Lifecycle, AD-567a Anchor System) — Rule-based 1–10 importance scoring at episode creation time via compute_importance(). Three signals: trigger_type mapping (captain_dm→8, circuit_breaker_trip→9), content boosts (Captain mentions), outcome adjustments (failures→7, no-response→3). Importance modifies: activation decay rate (importance/5.0 factor), pruning threshold (−0.2 per importance point above 5), recall composite (weight 0.05 tiebreaker). Dream Step 12 uses importance-aware pruning. Backward compatible — default 5 is neutral.

Connects to: AD-538 (Ebbinghaus decay — importance modifies decay rate), AD-593 (pruning — importance raises survival threshold), AD-567a (AnchorFrame — importance stored alongside anchor metadata), AD-582 (memory probes — future probe for importance-aware recall), AD-579 (tiered loading — L0 candidates could be importance≥8 episodes).

Issues: #172 (AD-598).

---

Reflection as Recallable Episodes (AD-599) (complete, OSS)

AD-599: Reflection as Recallable Episodes — Dream Insight Promotion (SHIPPED, OSS, depends: AD-551 Notebook Consolidation, AD-567d Anchor-Preserving Dream Consolidation) — Promote dream consolidation insights from Steps 7 and 9 into standalone recallable episodes in EpisodicMemory. Currently, dream insights exist only in dream journals (CognitiveJournal) and notebook entries — they are not recallable via recall_for_agent() or recall_weighted(). Agents cannot draw on consolidated wisdom during cognition, only raw episodic memories. Inspired by Park et al. (2023) Generative Agents reflection mechanism where periodic reflections become first-class retrievable memories.

Problem statement: Dream consolidation (Steps 7–9) produces high-value analytical insights — pattern recognition, cross-episode synthesis, emergence metrics snapshots, convergence analysis. These insights are written to CognitiveJournal and notebook entries but never enter the episodic recall pipeline. An agent that dreamed about a trust pattern last night cannot recall that insight when facing a similar situation today. The dream's value is locked in write-only storage.

Design: - Dream Step 10 (new): After Step 9 (emergence metrics), create synthetic episodes from Step 7 (cross-episode analysis) and Step 9 (emergence snapshot) insights. - Episode format: Content prefixed with [Reflection] to distinguish from experiential episodes. AnchorFrame with trigger_type="dream_consolidation", department inherited from insight source. - Importance scoring: Reflection episodes created with importance 8 (AD-598) — they represent distilled wisdom, not raw observation. - Deduplication: Content hash check against existing reflection episodes to prevent dream-over-dream accumulation. AD-538 merge logic handles near-duplicate reflections. - Recall behavior: Reflections are semantically rich (analytical language, pattern vocabulary) — they should score well on queries about patterns, trends, and analysis without special retrieval logic.

Connects to: AD-551 (notebook consolidation — notebook insights as alternative reflection source), AD-567d (dream provenance — reflections carry dream_cycle provenance), AD-557 (emergence metrics — Step 9 EmergenceSnapshot as reflection source), AD-538 (lifecycle — reflections subject to same decay/merge/archive lifecycle), AD-598 (importance scoring — reflections born important).

Issues: #173 (AD-599).

---

Transactive Memory Systems (AD-600) (Complete, OSS)

AD-600: Transactive Memory — "Who Knows What" Directory (Complete, OSS, depends: AD-462c OracleService, AD-570 Anchor-Indexed Recall, AD-531 Episode Clustering) — Added a queryable in-memory expertise directory from episode clustering evidence so the system knows which agent is the best source for a given topic. OracleService routes unscoped episodic queries to top-k expert shards when available, while explicit agent-scoped queries remain unchanged. Based on Wegner (1987) Transactive Memory Systems theory: groups develop shared awareness of "who knows what," enabling efficient knowledge retrieval without every member storing everything.

Problem statement: OracleService (AD-462c) queries all 3 knowledge tiers across all agent shards. For a crew of 55 agents, every cross-agent query scans all 55 shards — O(N) per query. Most shards return nothing relevant. The system has no model of which agents are knowledgeable about which topics. SocialMemoryService broadcasts "does anyone remember?" to the Ward Room — equally inefficient. Neither pathway leverages the structural fact that agents specialize by department and role.

Design: - ExpertiseProfile per agent: topic→confidence mapping built from episode clustering (AD-531). Topics derived from cluster centroids. Confidence = episode count × recency × activation level. - ExpertiseDirectory service: query_experts(topic: str, top_k: int = 3) → list[ExpertMatch]. Returns ranked agents most likely to have knowledge on a topic. - OracleService integration: query() method gains optional use_expertise_routing: bool = True. When enabled, queries only top-k expert shards instead of all shards. Fallback to full scan when no experts found. - Profile maintenance: Updated during dream consolidation (new Step 11 or appended to existing step). Episode clustering results (AD-531) feed topic extraction. Profiles decay with episode lifecycle — archived episodes reduce expertise confidence. - Ward Room routing: SocialMemoryService can use ExpertiseDirectory to direct "does anyone remember?" queries to likely experts instead of broadcasting.

Connects to: AD-462c (OracleService — primary consumer for smart routing), AD-531 (episode clustering — topic extraction from cluster centroids), AD-570 (anchor-indexed recall — department/channel metadata enriches expertise profiles), AD-560 (Science Analytical Pyramid — specialization hierarchy aligns with expertise profiles), AD-596 (Cognitive Skills — skill declarations complement empirical expertise).

Issues: #174 (AD-600).

---

TCM Temporal Context Vectors (AD-601) (CLOSED, OSS)

AD-601: TCM Temporal Context Vectors (SHIPPED, OSS, depends: AD-567a Anchor System, AD-570 Anchor-Indexed Recall, AD-584d Enriched Embedding) — Implement Howard & Kahana (2002) Temporal Context Model for episodic memory. Currently ProbOS encodes temporal context as discrete watch_section labels (6 naval watches) — this produces binary match/no-match with no temporal proximity gradient. TCM maintains a slowly drifting continuous context vector that enables graded temporal similarity: episodes from "30 minutes ago" score higher than "6 hours ago" on temporal proximity, not just "same watch vs different watch."

Problem statement: The current temporal_match_weight bonus (BF-147) is binary — either the watch section matches (+0.25) or it doesn't (+0.0). Two episodes from the same watch but 5 hours apart score identically to two episodes 5 minutes apart. Temporal discrimination within a watch is impossible. Across watches, the boundary is arbitrary — an episode from 5 minutes before watch change scores 0.0 temporal bonus while one from 5 minutes after scores +0.25. TCM's continuous context vectors solve both problems: temporal proximity becomes a smooth gradient, and watch boundaries become soft transitions rather than hard walls.

Design: - Context vector: Low-dimensional (d=16) vector drifting via exponential decay: c(t+1) = ρ * c(t) + (1-ρ) * e(t) where e(t) is the current episode's embedding summary and ρ is the drift rate (configurable, default 0.95). - Encoding: At episode creation, snapshot the current context vector and store alongside the episode (new ChromaDB metadata field or auxiliary store). - Retrieval: At recall time, compute cosine similarity between the current context vector and each candidate episode's stored context vector. This becomes a new scoring channel in score_recall() (weight: configurable, default 0.10). - Per-agent context: Each agent maintains its own context vector, updated on every cognitive cycle. Context vector persists across sessions (stored in agent working memory or episodic metadata).

Research: Howard & Kahana (2002) Temporal Context Model, documented in docs/research/memory-retrieval-research.md Section 2.3. Polyn et al. (2009) Context Maintenance and Retrieval Model (CMR) extends TCM with semantic associations.

Connects to: AD-567a (AnchorFrame — TCM vector stored alongside anchor metadata), AD-570 (anchor-indexed recall — TCM as complementary temporal channel), AD-584d (enriched embeddings — episode summary feeds context vector update), AD-598 (importance scoring — important episodes could have stronger context imprint via higher 1-ρ weight), BF-155 (temporal discrimination — TCM is the deep fix for what BF-155 addresses with quick wins).

Issues: #177 (AD-601).

---

Question-Adaptive Retrieval Routing (AD-602) (Complete, OSS)

AD-602: Question-Adaptive Retrieval Routing (Complete, OSS, depends: AD-568a RetrievalStrategy, AD-570c parse_anchor_query, AD-584b Query Reformulation) — Route recall queries through different retrieval strategies based on question type (what/when/who/where/why/how). Currently classify_retrieval_strategy() uses only intent_type (e.g., "direct_message", "diagnostic_request") — it has no awareness of the question's temporal, spatial, or relational content. A "when did X happen?" and "what is X?" query both go through the same retrieval path, despite needing fundamentally different scoring emphasis.

Problem statement: A temporal query ("What happened during first watch?") should emphasize watch_section filtering and temporal scoring, but classify_retrieval_strategy() classifies it based on intent_type (usually "direct_message" → SHALLOW). The temporal signal extracted by parse_anchor_query() influences recall_by_anchor() and temporal_match_weight, but doesn't adjust the retrieval strategy (budget, k, weights). Similarly, social queries ("What did Lynx say about trust?") should emphasize participant filtering and social context, while factual queries ("What is the pool health threshold?") should emphasize keyword matching. Different question types need different weight profiles for optimal recall.

Design: - Question type classifier: Extend parse_anchor_query() or add companion function classify_question_type(query) → QuestionType (enum: TEMPORAL, SOCIAL, FACTUAL, CAUSAL, PROCEDURAL, EXPLORATORY). - Type-specific weight profiles: Each QuestionType maps to a modified weight dict for score_recall(): TEMPORAL boosts recency + temporal_match, SOCIAL boosts trust + participant filtering, FACTUAL boosts keyword + anchor, CAUSAL boosts semantic + convergence. - Strategy adjustment: classify_retrieval_strategy() gains optional question_type parameter — TEMPORAL queries with anchor signals auto-upgrade to DEEP (more budget, higher k). - Budget tuning: TEMPORAL queries get reduced context_budget (fewer episodes, higher quality) vs EXPLORATORY (larger budget, more diversity).

Research: Question decomposition pipeline documented in docs/research/memory-retrieval-research.md Section 3 and 8.2-8.4. Anderson & Pichert (1978) perspective-dependent recall — retrieval cue framing changes what is recalled.

Connects to: AD-568a (RetrievalStrategy — gains question-type dimension), AD-570c (parse_anchor_query — anchor signals feed question classification), AD-584b (query reformulation — type-specific templates), AD-601 (TCM — TEMPORAL questions leverage context vector similarity).

Issues: #178 (AD-602).

---

Anchor Recall Composite Scoring (AD-603) (complete, OSS)

AD-603: Anchor Recall Composite Scoring (complete, OSS, depends: AD-570 Anchor-Indexed Recall, AD-567b Salience-Weighted Recall, AD-584c Scoring Rebalance) — Applies score_recall() composite scoring to anchor-retrieved episodes via new recall_by_anchor_scored() while preserving recall_by_anchor() as raw list[Episode] enumeration for existing callers. Anchor results now carry semantic similarity, keyword hits, trust weight, Hebbian weight, recency, anchor confidence, temporal match, importance, and a modest structural anchor bonus before entering the CognitiveAgent merge step.

Problem statement: The merge step (AD-570c) at cognitive_agent.py:2794-2801 puts anchor episodes first and appends unique semantic episodes. But anchor episodes have no composite score — they're assumed to be relevant because they matched the anchor filter. This is often true, but when anchor recall returns many episodes (up to limit=10), some may be low-quality (old, low trust, low semantic relevance). Without scoring, they can't be ranked against each other or against semantic results. The merge produces an unranked list where position (anchor-first) substitutes for quality.

Delivered: - recall_by_anchor_scored() returns list[RecallScore] without changing recall_by_anchor(). - Each anchor-recalled episode gets scored via score_recall() with the same weight inputs used by recall_weighted(). - CognitiveAgent merge combines scored anchor and semantic RecallScore lists, deduplicates by episode ID, sorts by composite_score, and preserves BF-155 temporal mismatch filtering. - Anchor-recalled episodes get an additional anchor_bonus (default 0.08) for matching a structured filter.

Connects to: AD-567b (salience-weighted recall — scoring formula), AD-584c (scoring rebalance — weight configuration), AD-570c (anchor recall merge — direct consumer of scored anchor results), BF-155 (merge contamination — AD-603 is the deep fix for the merge quality problem).

Issues: #179 (AD-603).

---

Spreading Activation Multi-Hop Retrieval (AD-604) (SHIPPED, OSS)

AD-604: Spreading Activation / Multi-Hop Retrieval (SHIPPED, OSS, depends: AD-531 Episode Clustering, AD-570 Anchor-Indexed Recall, AD-600 Transactive Memory) — Implement spreading activation for multi-hop associative recall. Currently each recall query retrieves episodes in a single hop — direct semantic similarity to the query. Associative chains ("A reminds me of B which reminds me of C") are not followed. Multi-hop retrieval enables richer recall for causal and narrative queries.

Problem statement: A query like "Why did trust drop for Engineering?" requires connecting: (1) the trust event episode → (2) the incident that caused it → (3) the context around the incident. Single-hop semantic search might find (1) directly but miss (2) and (3) because they don't semantically match the query — they match the answer to the query. Spreading activation follows associative links from retrieved episodes to their neighbors, surfacing episodically connected but semantically distant episodes.

Design: - Two-hop retrieval: For DEEP strategy queries, take top-k first-hop results, extract their anchor metadata (participants, department, time_range), and issue a second recall_by_anchor() query using those extracted anchors as filters. - Activation spreading: First-hop episodes activate their temporal and social neighbors. Second-hop candidates scored with activation decay (0.5× first-hop score as baseline). - Budget guard: Total episodes (hop 1 + hop 2) still subject to context_budget and max_recall_episodes. Second-hop episodes can only fill remaining budget after first-hop allocation. - Configuration: multi_hop_enabled: bool = False in MemoryConfig (off by default, enable per retrieval strategy). multi_hop_decay: float = 0.5 (second-hop score multiplier).

Research: Collins & Loftus (1975) spreading activation theory. Anderson (1983) ACT-R adaptive control of thought. Documented in docs/research/memory-retrieval-research.md Section 7 (spreading activation, activation propagation).

Connects to: AD-531 (episode clustering — cluster membership as associative link), AD-570 (anchor-indexed recall — anchor metadata provides structured links for second-hop queries), AD-600 (transactive memory — expertise routing can direct second-hop queries to specific agent shards), AD-601 (TCM — temporal context vectors provide temporal neighbor candidates), AD-602 (question-adaptive routing — CAUSAL questions benefit most from multi-hop).

Issues: #180 (AD-604).

---

Enhanced Embedding — Content + Anchor Metadata Concatenation (AD-605) (complete, OSS)

AD-605: Enhanced Embedding — Content + Anchor Metadata Concatenation (complete, OSS) — Enriches ChromaDB embeddings by concatenating anchor metadata ([department] [channel] [watch_section] [trigger_type]) into document text before embedding via _prepare_document() static method. All 3 ChromaDB write sites updated. Original user_input preserved in metadata for clean Episode reconstruction. One-time idempotent migration re-embeds existing episodes. 2 source files modified (episodic.py, cognitive_services.py), 1 new test file (15 tests). Query enrichment (Change 5) deferred.

Issues: #181 (AD-605).

---

Think-in-Memory — Evolved Thought Storage (AD-606) (Complete, OSS)

AD-606: Think-in-Memory — Evolved Thought Storage (Complete, OSS, depends: AD-669 Working Memory Conclusions, AD-567a AnchorFrame) — Store pre-reasoned conclusions ("evolved thoughts") as first-class episodic entries, not just raw interaction history. Currently dream consolidation extracts patterns and stores them in notebooks (Tier 2 Records), but these don't flow back into the episodic recall pipeline. An agent re-encountering a similar situation must re-reason from raw episodes rather than retrieving a pre-computed conclusion.

Problem statement: Every cognitive cycle pays full re-reasoning cost even when the agent has previously resolved the same type of question. Raw episodes contain the full interaction context (question, DAG steps, outcomes, reflection) but not the distilled conclusion. The agent must reconstruct the conclusion from raw data each time. Evolved thoughts — pre-reasoned conclusions stored as high-priority episodic entries — would enable direct retrieval of conclusions without re-reasoning.

Design: Dream consolidation produces "evolved thought" episodes via a new Dream Step (after Step 7g notebook consolidation). Source type: source="consolidated_thought". Content format: distilled conclusion with provenance back-references. Scoring: evolved thoughts receive a source-type bonus in score_recall() (similar to convergence bonus). Three operations (following TiM): insert (new thought from dream), forget (superseded thoughts archived), merge (related thoughts combined). Working memory integration: evolved thoughts are candidates for AD-579a pinned knowledge buffer.

Research: Liu et al. "Think-in-Memory: Recalling and Post-Thinking Enable LLMs with Long-Term Memory" — evolved thought storage. Bjork (1994) desirable difficulties — generation (producing the answer) > reading (passively receiving). docs/research/agent-memory-survey-absorption.md Section 2.

Connects to: AD-551 (notebook consolidation — notebooks are current conclusion storage, evolved thoughts complement them in the episodic pipeline), AD-532 (procedure extraction — CJT captures how, evolved thoughts capture what is true), AD-579a (pinned knowledge buffer — evolved thoughts are prime candidates for pinning), AD-538 (lifecycle — evolved thoughts need their own decay/archival policy).

Issues: #182 (AD-606).

---

Memory Security Framework (AD-607) (SHIPPED, OSS)

AD-607: Memory Security Framework — Extraction & Poisoning Defense (SHIPPED, OSS, depends: AD-568a Source Governance, AD-566 Qualification Probes, AD-570 Anchor-Indexed Recall) — Defend against two attack vectors cataloged in the "AI Meets Brain" survey: (1) extraction attacks — crafted queries designed to leak private data from memory banks, (2) poisoning attacks — adversarial content injected into external memory.

Problem statement: ProbOS has source governance (retrieval strategy classification) and qualification probes (memory reliability testing) but no explicit defense against adversarial memory operations. As ProbOS moves toward federation (Inter-Ship Trust Protocol) and multi-instance deployment, episodes may cross trust boundaries. A compromised or malicious instance could inject poisoned episodes that contaminate recall for all agents, or craft queries that extract private episode content across sovereign shards.

Design: Three defense layers (following survey taxonomy): (1) Retrieval-based defense — anomaly detection on recalled episodes: flag episodes with unusual entropy, unexpected source patterns, content-anchor context mismatch, or provenance gaps. Extend source governance with a validate_recall_result() gate. (2) Response-based defense — output monitoring on agent responses referencing recalled episodes: detect when responses leak episode content that should be sovereign-shard-restricted. Extend confabulation guard. (3) Privacy-based defense — access control on cross-shard recall (OracleService), differential privacy on aggregated recall results, data sanitization on federated episode exchange.

Research: "AI Meets Brain" survey Section 8 (memory security). OWASP LLM Top 10 (prompt injection, data poisoning). docs/research/agent-memory-survey-absorption.md Section 3.

Connects to: AD-568a (source governance — retrieval-based defense extends classify_retrieval_strategy()), AD-566/582 (qualification probes — existing reliability testing framework), AD-462c (Oracle Service — cross-shard recall needs access control), AD-441 (DID identity — federation trust boundary), AD-600 (transactive memory — expertise routing must respect memory security).

Issues: #183 (AD-607).

---

Retroactive Memory Evolution (AD-608) (Complete, OSS)

AD-608: Retroactive Memory Evolution — Store-Time Metadata Propagation (Complete, OSS, depends: AD-605 Enhanced Embedding, AD-567a Anchor System, AD-570 Anchor-Indexed Recall) — When a new episode is stored, retroactively update metadata on highly-related existing episodes. Old memories are currently static until dream consolidation (which runs on a schedule, not at storage time).

Problem statement: Episodes are write-once. Anchor metadata established at storage time is never updated even when new information arrives that provides additional context. An episode stored with watch_section="" (unknown temporal context) never gains temporal context even when subsequent episodes clearly establish the watch section. Relational links between episodes (cause → effect, question → answer, topic continuation) are never explicitly recorded.

Design: Lightweight store-time propagation (NOT A-MEM's LLM-per-insertion approach). When store() is called: (1) query top-K nearest episodes by embedding similarity. (2) For each neighbor, check if the new episode provides context the neighbor lacks (e.g., new episode has watch_section, neighbor doesn't). (3) If so, update the neighbor's anchor metadata via _force_update(). (4) Optionally add relational tags (relates_to, follows, contradicts) to both episodes' anchor metadata. Rate-limited: max N propagation updates per store() call. Configurable: retroactive_evolution_enabled: bool = False (opt-in).

Research: Xu et al. (NeurIPS 2025) A-MEM retroactive evolution agent. docs/research/memory-retrieval-research.md Section 7.3 (relational tagging). docs/research/agent-memory-survey-absorption.md Section 4.

Connects to: AD-605 (enhanced embedding — richer embeddings improve neighbor quality), AD-567a (anchor system — AnchorFrame is the metadata being propagated), AD-570 (anchor-indexed recall — propagated metadata improves filter accuracy), AD-538 (lifecycle — propagation creates update history that lifecycle needs to track).

Issues: #184 (AD-608).

---

Multi-Faceted Distillation — Failure & Comparative Analysis (AD-609) (Complete, OSS)

AD-609: Multi-Faceted Distillation — Failure Pattern & Comparative Insight Extraction (Complete, OSS, depends: AD-532 Procedure Extraction, AD-567d Dream Consolidation) — Extend dream consolidation to systematically extract failure patterns and comparative insights alongside success patterns. Currently Cognitive JIT (AD-532) captures how to do things (success procedures) but does not extract why things failed or how alternatives compared.

Problem statement: Learning from failure requires explicit failure-pattern extraction. An agent that encounters a circuit breaker trip, trust cascade, or negative outcome has no structured way to store "this approach failed because..." for future reference. Comparative insights ("approach A worked for X but not Y, approach B worked for Y") are never extracted, even when episodes contain natural A/B patterns.

Design: Dream Step extension (after Step 7, before Step 9 emergence metrics). Three extraction lenses: (1) Success patterns — existing CJT coverage, no change needed. (2) Failure triggers — episodes with negative trust deltas, circuit breaker events, or CIRCUIT_BREAKER_TRIP events → extract failure trigger + context + what was attempted. Store as source="failure_pattern" episodes. (3) Comparative insights — episode pairs from the same agent with similar anchor context but different outcomes → extract the differentiating factor. Store as source="comparative_insight" episodes.

Research: Cao et al. "ReMe" multi-faceted distillation. docs/research/agent-memory-survey-absorption.md Section 5.

Connects to: AD-532 (procedure extraction — success lens already implemented), AD-567d (dream consolidation — pipeline integration point), AD-558 (trust cascade dampening — cascade events are prime failure trigger candidates), AD-606 (evolved thoughts — failure patterns and comparative insights are types of evolved thoughts).

Issues: #185 (AD-609).

---

Utility-Based Storage Gating (AD-610) (Complete, OSS)

AD-610: Utility-Based Storage Gating — Write-Time Duplicate & Utility Validation (Complete, OSS, depends: AD-538 Episode Lifecycle, AD-593 Pruning Acceleration, AD-605 Enhanced Embedding) — Validate whether a new episode adds value before persisting, filtering at the input boundary rather than relying solely on post-hoc decay and pruning.

Problem statement: ProbOS stores all episodes and relies on Ebbinghaus decay (AD-538) and dream pruning (AD-593) to remove low-value entries after the fact. This means ChromaDB accumulates near-duplicate episodes (same topic, same anchor context, marginal new content), consuming storage and degrading retrieval precision. The existing content hash dedup (compute_episode_hash) catches exact duplicates but not near-duplicates or low-utility variants.

Design: Pre-store validation in store(): (1) Near-duplicate detection — query top-3 nearest episodes by embedding similarity. If cosine similarity > 0.95 AND same anchor_department AND same anchor_channel, skip storage (log as near-duplicate). (2) Contradiction detection — if top-3 neighbors have contradicting content from the same temporal context, flag for conflict resolution (store both but tag the relationship). (3) Utility threshold — if the new episode's anticipated composite score (estimated from metadata) falls below a configurable floor, defer storage to dream consolidation batch processing rather than immediate storage. Configurable: storage_gate_enabled: bool = False, near_duplicate_threshold: float = 0.95.

Research: Cao et al. "ReMe" utility-based pruning — filtering outdated memories to maintain compact, high-quality experience pool. docs/research/agent-memory-survey-absorption.md Section 6.

Connects to: AD-538 (episode lifecycle — Ebbinghaus decay handles post-hoc, storage gating handles pre-hoc), AD-593 (pruning acceleration — complementary approaches at different lifecycle stages), AD-605 (enhanced embedding — richer embeddings improve near-duplicate detection quality), AD-608 (retroactive evolution — near-duplicate detection could trigger metadata propagation instead of duplicate storage).

Issues: #186 (AD-610).

---

3D Memory Graph Visualization (AD-611) (complete, OSS)

AD-611: 3D Memory Graph Visualization (scoped, OSS, depends: AD-567d Activation Tracker, AD-570 Anchor Recall, AD-531 Episode Clustering, AD-605 Enhanced Embedding) — Interactive force-directed graph visualization of agent episodic memory in the HXI agent profile panel. Episodes rendered as 3D nodes; semantic similarity (HNSW nearest-neighbor), thread co-occurrence, temporal proximity, and participant overlap form edges. Three-tier node selection (recency 70%, importance 20%, activation 10%) with 200 default / 500 max cap. Node visuals encode importance (size), activation (opacity/glow), and channel or department (color). Four edge types with distinct colors. Ship-wide toggle merges episodes across all crew agents. Backend: new memory_graph router. Frontend: react-force-graph-3d component in new "Memory" tab.

Problem statement: Episodic memory is a flat, invisible data structure. No way to see cluster patterns, semantic neighborhoods, temporal chains, or cross-agent memory connections. Debugging recall quality and understanding memory topology requires visual tools.

Research: Force-directed graph layouts (Fruchterman-Reingold / d3-force-3d) naturally cluster semantically similar nodes. HNSW approximate nearest-neighbor provides efficient edge construction at O(N log n).

Connects to: AD-567d (activation tracker — node glow), AD-570 (anchor-indexed recall — structured filtering), AD-531 (episode clustering — potential super-nodes), AD-605 (enhanced embedding — richer embedding quality for semantic edges), AD-557 (emergence metrics — complementary visualization of collaborative intelligence).

Issues: #192 (AD-611).

---

Ward Room HXI Performance (AD-613) (complete, OSS)

AD-613: Ward Room HXI Performance — Query Batching, Event Debouncing, and Caching (complete, OSS, depends: AD-407 Ward Room, BF-156/157 DM Delivery) — Six performance fixes for Ward Room message population latency and channel switching sluggishness, worsened by DM traffic increase. (1) P0 WebSocket event debouncing: ward_room_post_created fires 4 parallel API calls — replaced with 300ms flag-based coalescing (~520→~130 HTTP fetches/hour). (2) P0 N+1 DM elimination: count_threads() replaces len(list_threads(100)) — 2N+1→N+1 queries. (3) P1 Per-channel thread cache: Map-based 30s TTL in Zustand store. (4) P1 Post pagination: get_thread() gains post_limit=100 + total_post_count. (5) P2 Conditional DM poll: isOpen guard stops background 15s poll. (6) P2 Composite SQL indexes: 3 covering indexes for primary query patterns. 5 source files + 1 UI component modified, 10 new tests.

Connects to: AD-407 (Ward Room core), BF-015 (WS thread refresh), BF-054 (DM auto-refresh), BF-156/157 (DM delivery). Coordinates with AD-612 (DM rendering — complementary, no conflicts).

Issues: #196 (AD-613).

DM Conversation Termination (AD-614) (complete, OSS)

AD-614: DM Conversation Termination — Three-Layer Defense Against Infinite Agreement Loops (complete, OSS, depends: BF-163 DM Send Cooldown, AD-506b Peer Repetition, AD-453 DM Extraction) — Prevents agents from endlessly confirming each other's confirmations in DM conversations. Production incident: 8,448 DM posts in 90 minutes across 9 agents, peaking at 120 posts/minute. BF-163's 60s cooldown slows the tight loop but doesn't prevent semantic repetition. Three-layer fix: (1) Standing Orders: conversation closure guidance in federation.md and ship.md — "Do not confirm a confirmation." (2) Self-Similarity Gate: Jaccard word-set similarity check (threshold 0.6) on consecutive DMs per agent-target pair using existing jaccard_similarity(). (3) DM Exchange Limit: per-agent per-thread circuit breaker (default 6 posts) in ward_room_router.py — critical because is_direct_target is always True for DM channels, bypassing all existing volume guards. New count_posts_by_author() on ThreadManager/WardRoomService. Config: dm_exchange_limit, dm_similarity_threshold in WardRoomConfig. 7 source files modified, 1 new test file (17 tests).

Connects to: BF-163 (DM send cooldown — timing-based), AD-506b (peer repetition detection — detection-only), BF-156/157 (DM delivery + @mention), AD-453 (DM extraction).

Issues: #198 (AD-614).

---

Ward Room Database Performance Hardening (AD-615) (complete, OSS)

AD-615: Ward Room Database Performance Hardening — WAL Mode, Busy Timeout, Synchronous Downgrade (complete, OSS, depends: AD-407 Ward Room, BF-099 Trust Concurrency) — Ward Room is the only ProbOS database without WAL mode — trust.py, procedure_store.py, and routing.py all set it. Under the 8,448-DM flood (AD-614 incident), ~67K DB writes in 90 minutes with the default rollback journal caused severe write contention. Three PRAGMAs following the BF-099 canonical pattern: (1) WAL mode: PRAGMA journal_mode=WAL for concurrent read/write performance. (2) busy_timeout=5000: 5-second retry window prevents SQLITE_BUSY failures. (3) synchronous=NORMAL: WAL-safe downgrade — only WAL checkpoints require full fsync, ~50% write latency reduction under sustained load. Plus WAL verification log at startup (log-and-degrade on failure). Scope correction: research found create_thread() and create_post() already batch SQL writes into a single db.commit() — episodic writes go through ChromaDB. No transaction restructuring needed. 1 source file (ward_room/service.py), 1 new test file (5 tests).

Connects to: AD-613 (Ward Room HXI Performance — complementary frontend + query optimizations), AD-614 (DM Conversation Termination — the incident that exposed the gap), BF-099 (Trust engine WAL + BEGIN IMMEDIATE — same pattern).

Issues: #199 (AD-615).

---

Ward Room Router Hot Path Optimization (AD-616) (complete, OSS)

AD-616: Ward Room Router Hot Path Optimization — Channel Cache, Event Backpressure, and Backend Coalescing (complete, OSS, depends: AD-407 Ward Room, AD-613 HXI Performance, AD-614 DM Termination) — Three hot path optimizations exposed by the 8,448-DM flood. (1) Channel cache in router: ward_room_router.py calls list_channels() 4 times (lines 140, 398, 630, 738) — each a full DB query. ChannelManager already maintains _channel_cache (refreshed on mutations). Fix: expose get_channel_by_id(channel_id) on WardRoomService using the existing cache, replace all 4 list_channels() calls in the router. (2) Event dispatch semaphore: asyncio.create_task(router.route_event()) in communication.py line 113 is fire-and-forget with zero backpressure. Under flood, creates thousands of concurrent asyncio tasks. Fix: asyncio.Semaphore wrapping route_event() dispatch, excess events queue rather than stampede. (3) Backend event coalescing: AD-613 added 300ms frontend debouncing but backend fires events synchronously on every post. Fix: per-thread coalesce window — if multiple POST_CREATED events fire for the same thread within the window, batch into a single routing decision. Config: router_concurrency_limit (default 10), event_coalesce_ms (default 200) in WardRoomConfig. 3 source files (ward_room_router.py, communication.py, config.py), 10 tests.

Connects to: AD-613 (frontend debouncing — complementary backend layer), AD-614 (DM termination — the incident), AD-615 (DB hardening — complementary infrastructure layer).

Issues: #200 (AD-616).

---

LLM Rate Governance (AD-617/617b) (complete, OSS)

AD-617: LLM Rate Governance — Token Bucket Rate Limiter, HTTP 429 Backoff, LRU Cache Eviction (complete, OSS) — No system-wide LLM call rate limiter existed. During the 8,448-DM flood, the LLM proxy received up to 101K requests in 90 minutes — HTTP 500 errors were the only backpressure mechanism. Four parts delivered: (1) Token bucket rate limiter: Per-tier sliding window RPM limits (fast=60, standard=30, deep=15 RPM) on OpenAICompatibleClient. Requests exceeding budget wait up to max_wait_seconds, then return cached response or error. (2) HTTP 429 backoff: Inner retry loop (max 5 per tier) with Retry-After header respect + exponential backoff min(2^n, 8.0) without header. 429 not counted as tier failure. (3) LRU cache eviction: OrderedDict with move_to_end() + popitem(last=False) at configurable 500-entry limit. Fixes unbounded dict memory leak. (4) LLMRateConfig: Pydantic model in SystemConfig with rpm_fast, rpm_standard, rpm_deep, max_wait_seconds, cache_max_entries. Constructor-injected via rate_config parameter. 3 source files (llm_client.py, config.py, main.py), 13 tests across 4 classes.

AD-617b: Per-Agent Hourly Token Budget (complete, OSS) — Per-agent fairness enforcement at the proactive loop gate. Budget-exhausted agents skip proactive thinks but still receive DMs, Ward Room notifications, and Captain directives (communication reliability). CognitiveJournal.get_token_usage_since() queries hourly sliding window (excludes cached). _is_over_token_budget() with 60-second exhaustion cache avoids hammering journal DB. Gate ordering: after circuit breaker, before _think_for_agent(). token_budget_exhausted event emitted for Counselor awareness. Config: per_agent_hourly_token_cap on LLMRateConfig (default 0 = disabled). 3 source files (journal.py, proactive.py, config.py), 13 tests across 3 classes.

Connects to: AD-576 (LLM Unavailability Awareness — infrastructure state machine feeds into rate governance), AD-488 (Circuit Breaker — velocity detection complements rate limiting), AD-614 (DM termination — the incident that exposed the gap), AD-431 (Cognitive Journal — per-agent token tracking).

Issues: #201 (AD-617/617b).

---

Bill System — Standard Operating Procedures (AD-618) (scoped, OSS + commercial)

AD-618: Bill System — Declarative Multi-Agent Standard Operating Procedures (scoped, OSS + commercial, depends: AD-434 Ship's Records, AD-429 Role Ontology, AD-566 Qualification Programs, AD-423 Tool Registry, AD-496–498 Workforce Scheduling) — Missing middle layer between Standing Orders (T1, behavioral policy) and Cognitive JIT (T3, learned procedures). Bills are named, versioned, declarative multi-agent procedures with role-based assignment, BPMN-vocabulary decision points (XOR/AND/OR gateways), YAML format, qualification gates, and Cognitive JIT learning bridge. Navy model: Bills (procedures), MRCs (atomic steps), WQSB (role assignment matrix), Conditions (activation triggers). Agents consult Bills with judgment — reference documents, not a process engine. Successful executions feed Cognitive JIT for T3 compilation. Five sub-ADs:

• AD-618a: Bill Schema + Parser (complete, OSS) — YAML schema definition, validation, BillDefinition dataclass, parser. Ship's Records integration for storage (ship_records/bills/). Bill versioning. Depends: AD-434 (Ship's Records).
• AD-618b: Bill Instance + Runtime (complete, OSS) — BillInstance/StepState/RoleAssignment dataclasses, BillRuntime service with activation, WQSB role assignment (BilletRegistry + qualification filtering), step lifecycle (start/complete/fail/skip), cancel, query API. BillConfig. 8 EventType entries. 30 tests. Depends: AD-618a, AD-566, AD-429.
• AD-618c: Built-in Bills (complete, OSS) — 4 default YAML bills (General Quarters, Research Consultation, Incident Response, Daily Operations Brief) + BillLoader (builtin discovery/parse, custom bill loading with slug dedup). XOR gateway with dual-input convergence in incident_response. Code-shipped in src/probos/sop/builtin/, not Ship's Records. 24 tests. Depends: AD-618a.
• AD-618d: HXI Bill Dashboard (complete, OSS) — Definition registry on BillRuntime (register/list/get), FastAPI router (6 endpoints), React dashboard (catalog + instance timeline + role roster + step progression), WebSocket refetch-on-event, ViewSwitcher Bills tab. 15 backend + 3 frontend tests. Depends: AD-618b.
• AD-618e: Cognitive JIT Bridge (complete, OSS) — Bill step completions → T3 skill acquisition via SkillBridge. StepSkillMapping with 3-level priority resolution (exact > bill-scoped > global). 5 default mappings. Dual exercise path: catalog entry → SkillBridge, no entry → AgentSkillService direct with auto-acquire at FOLLOW. 22 tests. Depends: AD-618b, AD-531–539.

Connects to: AD-594 (Crew Consultation — expressible as a Bill), AD-496–498 (Workforce Scheduling — availability checking), AD-566 (Qualification Programs — gates on roles), AD-429 (Role Ontology — role matching), AD-434 (Ship's Records — Bill storage), AD-531–539 (Cognitive JIT — learning bridge), AD-339 (Standing Orders — Bills operate within Standing Order constraints). Research: docs/research/standard-operating-procedures.md. Commercial extensions: Visual Bill Designer, SOP Marketplace, enterprise process governance, process mining, M365/Teams integration, cross-instance Bill sync via federation.

Issues: #204 (AD-618).

---

Counselor Cross-Department Awareness (AD-619) (complete, OSS)

AD-619: Counselor Cross-Department Awareness (complete, OSS) — Ship-wide authority agents get full cross-department visibility. (1) has_ship_wide_authority() helper in crew_utils.py — DRY/Open-Closed pattern with _SHIP_WIDE_AUTHORITY_TYPES set, extensible to First Officer without conditional changes. (2) Channel subscriptions: Ship-wide authority agents auto-subscribed to ALL department channels at startup (Medical, Engineering, Science, Security, Operations), not just their own. (3) Oracle access: Ship-wide authority agents get RecallTier.ORACLE regardless of rank + Oracle triggers on any retrieval strategy (SHALLOW or DEEP), not just DEEP. Enables cross-shard episodic recall when Captain asks about specific crew members. Standing orders updated (config/standing_orders/counselor.md) with Cross-Department Awareness section. 3 source files modified, 1 new test file (11 tests).

Connects to: AD-462c/e (RecallTier + Oracle Service), AD-568a (Retrieval Strategy classification), AD-425 (Ward Room auto-subscription), AD-339 (Standing Orders).

Issues: #205 (AD-619).

Note: AD-619's ship-wide authority bypass (has_ship_wide_authority(), _SHIP_WIDE_AUTHORITY_TYPES, Oracle tier override, strategy gate relaxation) has been replaced by the principled clearance system. AD-620 COMPLETE. Channel subscriptions preserved and improved. BF-164 (cross-agent episodic recall) was rejected — violates sovereign memory principle.

---

Clearance System — Separation of Rank and Access (AD-620/621/622) (scoped, OSS)

Design document: docs/research/clearance-system-design.md

Reference model: US Navy security clearance — rank, clearance, and access (need-to-know) are three independent concepts. ProbOS currently conflates rank and clearance via recall_tier_from_rank(). AD-619 exposed this conflation when the Counselor needed ORACLE access at LIEUTENANT rank — requiring a special bypass hack instead of principled role-based clearance.

AD-620: Clearance Model Foundation (complete, OSS, depends: AD-619 cleanup) — Separates rank (behavioral maturity) from clearance (access eligibility). (1) Added clearance field to Post dataclass in ontology/models.py — each billet defines its required RecallTier. (2) Added explicit clearance values to all 19 posts in config/ontology/organization.yaml — Bridge officers (ORACLE), department chiefs (FULL), officers (ENHANCED). (3) New effective_recall_tier(rank, billet_clearance) function in earned_agency.py — returns max of rank-based tier and billet-based tier. _TIER_ORDER dict for RecallTier comparison. resolve_billet_clearance() Law of Demeter helper. (4) Replaced recall_tier_from_rank() with effective_recall_tier() in cognitive_agent.py perceive() and proactive.py. (5) Simplified Oracle gate — removed strategy requirement, clearance IS the gate. (6) FULL+ billet clearance → all department channel subscriptions in communication.py. (7) Removed AD-619 ship-wide authority bypass (_SHIP_WIDE_AUTHORITY_TYPES, has_ship_wide_authority()). 7 source files modified, 1 config file modified, 1 new test file (27 tests), 1 test file migrated (9 tests).

AD-621: Billet-Driven Channel Visibility (complete, OSS, depends: AD-620) — Subscription-based routing replaces department matching. (1) WardRoomRouter find_targets()/find_targets_for_agent() use membership cache instead of home department comparison. (2) Membership cache populated at startup via populate_membership_cache(). (3) communication.py subscription refined from FULL+ clearance to ontology-driven: reports_to: captain (First Officer + Counselor only) get all department channels. (4) list_channels(agent_id) INNER JOIN with memberships for subscription-filtered queries. (5) Earned Agency same_department flag preserved for cross-dept subscribers. (6) @mention overrides subscription. (7) Ship-wide and DM routing unchanged. 7 source files modified, 1 new test file (18 tests).

AD-622: Special Access Grants (ClearanceGrant) (complete, OSS, depends: AD-620) — SAP analog for project/duty-based elevated access. (1) ClearanceGrant frozen dataclass in earned_agency.py. (2) effective_recall_tier() gains grants parameter — max(rank, billet, grants). (3) resolve_active_grants() Law of Demeter helper. (4) ClearanceGrantStore in clearance_grants.py — SQLite-backed with WAL mode, in-memory cache, zero-I/O sync reads. (5) Shell /grant command (issue/revoke/list) in commands_clearance.py with callsign resolution, sovereign ID targeting, prefix-match revocation, Rich table. (6) Wired in startup pipeline (results.py, communication.py, runtime.py, shutdown.py). (7) Grant resolution at both tier call sites (cognitive_agent.py, proactive.py). 2 new files, 8 modified, 1 new test file (22 tests).

Build order: AD-620 → AD-621 + AD-622 (parallel after foundation).

AD-623: DM Convergence Gate + DM Self-Monitoring (complete, OSS, depends: AD-614) — Structural fix for DM conversation loops where agents reach mutual agreement but continue echoing. Two mechanisms: (1) DM Convergence Gate — check_dm_convergence() in ward_room/threads.py checks cross-author Jaccard similarity over last 3 exchange pairs (threshold 0.55). Thread-level check in WardRoomRouter before per-agent loop, emits DM_CONVERGENCE_DETECTED event. (2) DM Self-Monitoring — _build_dm_self_monitoring() on CognitiveAgent injects self-similarity warning into ward_room_notification DM response path. Closes gap where self-monitoring only ran in proactive loop. Also adds Counselor handler for convergence events. Companion to BF-168. Build prompt: prompts/ad-623-dm-convergence-gate.md. Issue #212.

AD-625: Communication Discipline Skill (COMPLETE, OSS) — Tier 2 cognitive skill teaching agents Ward Room reply self-evaluation with proficiency-gated system gate modulation. CommTier enum (NOVICE/COMPETENT/PROFICIENT/EXPERT) mapped from ProficiencyLevel via 4-band mapping. Gate overrides scale with proficiency: max_responses_per_thread (1→3→4→5), reply_cooldown_seconds (180→120→90→60). Exercise recording on every Ward Room post. Cognitive checklist in SKILL.md (Thread Awareness, Novelty Test, Action Selection, Brevity Check, Anti-Patterns). Prompt guidance injection into proactive_think. Profile caching at startup. get_descriptions() 3-tuple for proficiency label display. Reuses existing "communication" PCC. 1 new file (comm_proficiency.py), 7 modified, 52 new tests. Build prompt: prompts/ad-625-communication-discipline-skill.md. Issue #219.

AD-627: Communication Skill Research Enrichment (COMPLETE, OSS, depends: AD-625) — Content-only enrichment of communication-discipline SKILL.md, incorporating 630 lines of framework research into actionable agent instructions. Expanded from 52-line basic checklist to structured 5-gate pre-composition protocol. Research synthesized: Shannon information delta gate, Minto Pyramid answer-first structure, Canale & Swain communicative act typing (INFORM/ANALYZE/REQUEST/PROPOSE/DISSENT/ACKNOWLEDGE with suppression rules), Robert's Rules consent-by-silence protocol, Dreyfus 7-level proficiency progression (FOLLOW→SHAPE), ACH diagnosticity check, Delphi independent analysis mode, military net discipline and brevity codes. New sections: action selection matrix, thread discipline (consent-by-silence, dissent premium, independent analysis, channel register), 10 anti-patterns with failure explanations, full proficiency progression table mapping to ProficiencyLevel enum. No code changes — config file only. Research source: docs/research/communication-discipline-skill-research.md.

AD-626: Dual-Mode Skill Activation (COMPLETE, OSS, depends: AD-596a–e, AD-625) — Discovery + Augmentation dual activation modes for cognitive skills. Discovery mode (existing): catalog consulted for unhandled intents, skill provides entire capability. Augmentation mode (new): catalog consulted for all intents, matching skills provide supplementary instructions layered onto existing behavior. probos-activation YAML frontmatter field: "discovery" (default), "augmentation", or "both". find_augmentation_skills() query method with department/rank filtering. _load_augmentation_skills() on CognitiveAgent loads matching skills as "## Skill Guidance:" sections (vs "## Active Skill:" for discovery). Proficiency gates apply to augmentation too. Exercise recording for augmentation skills (fire-and-forget). find_by_intent() updated to exclude augmentation-only skills from discovery path. Intent parser enhanced to handle both comma and space separators. Communication-discipline skill updated: probos-activation: augmentation, ward_room_notification added to intents. 2 modified files (skill_catalog.py, cognitive_agent.py), 1 modified config (SKILL.md), 1 new test file (46 tests). Build prompt: prompts/ad-626-dual-mode-skill-activation.md.

Key design decisions: - No new enum — reuse RecallTier as the unit of clearance - Explicit clearance per post (not auto-derived from reports_to) — allows exceptions - Oracle gate simplified: clearance alone, no strategy requirement - Channel visibility is separate from clearance — ontology-driven, not clearance-driven - Sovereign memory principle preserved — clearance gates system capabilities, NOT cross-agent memory access - recall_tier_from_rank() preserved internally, called by effective_recall_tier() as one input

Connects to: AD-619 (supersedes ship-wide authority bypass), AD-462c/e (RecallTier + Oracle), AD-568a (strategy gate — simplified), AD-357 (Earned Agency), AD-339 (Standing Orders).

---

AD-628: Crew Skill Readiness Monitoring + Training Officer Role (SCOPED, OSS, depends: AD-596a–e, AD-625/626/627, AD-535, AD-506a, AD-566a–f, AD-477, AD-486, AD-539b) — Crew skill performance monitoring by Medical + Counselor, backed by structured skill telemetry events. Introduces Training Officer (TRAINO) as new crew agent — qualification tracking, training coordination, new agent onboarding, Holodeck simulation management. Naval model: PQS qualification system + COSC stress continuum + IMR readiness + Training Team + Career Development Boards + C-Rating readiness reporting. Seven sub-ADs: AD-628a (skill telemetry events), AD-628b (agent skill readiness profile), AD-628c (Training Officer agent + standing orders), AD-628d (TRAINO Holodeck integration — drill scheduling + evaluation), AD-628e (TRAINO onboarding coordination — Birth Chamber mentorship), AD-628f (readiness reporting — ship-wide + department skill coverage metrics), AD-628g (LIMDU protocol — Medical + TRAINO joint reduced-duty recommendation with remediation plan). TRAINO division of responsibility: Medical = fitness-for-duty, Counselor = behavioral observation, TRAINO = qualification tracking + training execution. Issue #223.

AD-629: Ward Room Reply Gate Enforcement + Post ID Context (COMPLETE 2026-04-14, OSS, depends: AD-424, AD-426, AD-437, AD-625, BF-016b, BF-105, BF-171) — Three structural holes allow agents to bypass max_responses_per_thread: (1) proactive [REPLY] path calls create_post() without checking _agent_thread_responses, (2) is_direct_target bypass skips both cap check AND counter increment for @mentioned agents, (3) cap only blocks notification routing, not post creation. Additionally, agents are told to use [ENDORSE post_id UP] but post IDs are never included in thread context — the instruction is impossible to follow. Fix: (A) Unified check_and_increment_reply_cap() method on WardRoomRouter — single enforcement point called by both route_event() and _extract_and_execute_replies(). @mention bypass applies to cooldown timing only, not per-thread cap. (B) Per-department reply gate — max one reply per department per thread (AD-424 chief funnel). (C) Post IDs included in thread context as [{id}] callsign: body so agents can construct ENDORSE commands. (D) Post IDs in proactive Ward Room activity context. Issue #224.

Connects to: AD-424 (thread classification — chief funnel), AD-426 (endorsement activation), AD-437 (action space), AD-625 (communication discipline skill), BF-016b (per-thread cap), BF-105 (self-repetition guard), BF-171 (channel cooldown).

AD-630: Leadership Developmental Feedback (COMPLETE 2026-04-15, OSS, depends: AD-504, AD-506b, AD-629, AD-625, AD-596a–e) — Department Chiefs observe subordinate communication patterns and provide developmental mentoring via DMs. Five components: (A) Per-agent communication stats on WardRoomService layer (get_agent_comm_stats() — posts, endorsements given/received, credibility score). (B) Leadership Feedback cognitive skill (leadership-feedback/SKILL.md) — augmentation for Chief+ rank (lieutenant_commander minimum) that teaches pattern recognition and developmental DM composition. (C) Ontology reverse lookup (get_subordinate_agent_types()) discovers subordinates via authority_over on Post. (D) Subordinate stats injected into Chief proactive context during _gather_context(), rendered as <subordinate_activity> XML tags. (E) Leadership and Mentorship standing order in federation.md. Developmental DMs flow through existing DM delivery → episodic memory → dream consolidation — no new infrastructure. 28 tests across 8 classes. Issue #225.

Connects to: AD-504 (self-monitoring), AD-506b (peer repetition detection), AD-629 (reply gates), AD-625 (communication skill), AD-596a–e (cognitive skill catalog), AD-628 (Training Officer — adjacent but separate scope).

AD-631: Skill Effectiveness Improvements (COMPLETE 2026-04-15, OSS, absorbs BF-174 root cause, depends: AD-625, AD-626, AD-627, AD-629, AD-596b) — Eight structural improvements to address why crew agents partially or wholly ignore the communication-discipline cognitive skill. Root causes: quadruple instruction injection (federation.md, Tier 7, comm_proficiency guidance, augmentation skill — same topic in 4 places), weak plain-text injection framing, no self-verification gate, negative framing ("Never…"), communication rules buried early in a 5,400-token system prompt, and self-monitoring bracket markers parroted by LLM. Changes: (1) DRY deduplication — move operational comm rules out of federation.md into the skill as single source of truth; federation.md retains channel descriptions and format mechanics only; Theory of Mind — Complementary Contribution absorbed into skill. (2) XML tag wrapping — replace --- Behavioral Guidance --- delimiters with <active_skill> / <skill_instructions> XML tags per Anthropic prompt engineering guidance. (3) Self-verification gate — "Pre-Submit Check" section in SKILL.md asking agents to verify novelty, opening sentence, and endorsement criteria before finalizing. (4) Positive framing with reasoning — rewrite Safety Rules as Contribution Standard using "do X because Y" instead of "Never X." (5) Tier 7 XML enhancement — skill descriptions in <available_skills> XML with behavioral primer in description text. (6) Consolidate _get_comm_proficiency_guidance() — remove standalone system prompt injection, flow tier guidance through <proficiency_tier> in augmentation skill frame; reduces 4 injection points to 2. (7) Anti-pattern addressing — explicit "Looking at…" / "I notice…" / "I can confirm…" opener detection and replacement instruction in operating sequence. (8) Self-monitoring XML reframing (BF-174 root cause) — replace bracket markers ([COGNITIVE ZONE:], --- Recent Activity ---) with XML tags (<cognitive_zone>, <recent_activity>) to prevent LLM parroting; retain _strip_bracket_markers() as defense-in-depth. Evidence from live observation: zero endorsements, ubiquitous "Looking at…" opener, agreement-as-reply, same topic across all departments. Research: Anthropic XML tags, MRKL neuro-symbolic (Karpas 2022), Lipenkova 2023 domain knowledge precision, AgentSkills.io XML wrapping. Issue #226.

Connects to: AD-625 (communication skill content), AD-626 (dual-mode activation), AD-627 (research enrichment), AD-629 (reply gates — structural enforcement), AD-596b (intent discovery integration), AD-630 (leadership feedback — reinforcement layer), BF-174 (self-monitoring bracket markers — root cause absorbed, regex retained).

AD-632: Cognitive Sub-Task Protocol (SCOPED, OSS, umbrella, depends: AD-631, AD-625, AD-626, AD-596a–e, AD-531–539) — Enables crew agents to decompose complex reasoning into focused sub-steps instead of handling everything in a single LLM call. Three-level cognitive escalation matching SOAR's processing model: Level 1 Cognitive JIT replay (0 calls, automatic), Level 2 single-call reasoning (1 call, deliberate — current), Level 3 sub-task protocol (2-4 focused calls, subgoaling — this AD). Five sub-task types: Query (deterministic data retrieval, zero LLM), Analyze (narrow LLM prompt for input comprehension), Compose (LLM with augmentation skill for response generation), Evaluate (criteria-based quality scoring), Reflect (self-critique before committing). Selective activation — NOT a constant cost multiplier. Three trigger mechanisms: skill frontmatter annotation (probos-subtask-mode), complexity heuristic thresholds (thread post count, contributor count), quality fallback on self-verification failure (SOAR impasse model). Key insight: augmentation skill instructions land in the Compose sub-task where they have focused attention, not competing with thread parsing. Sub-tasks are intra-agent only — no identity, no trust profile, no episodic memory shard. Token accounting attributed to parent agent. Single-call fallback on any sub-task failure (defense in depth). Eight sub-ADs: AD-632a (foundation — protocol, executor, journal, config, COMPLETE), AD-632b (Query deterministic, COMPLETE), AD-632c (Analyze LLM, COMPLETE), AD-632d (Compose with skill, COMPLETE), AD-632e (Evaluate + Reflect quality gates, COMPLETE), AD-632f (activation triggers, COMPLETE), AD-632g (Cognitive JIT integration — learn decomposition patterns, SOAR chunking analog, COMPLETE), AD-632h (parallel sub-task dispatch, COMPLETE). Research: docs/research/cognitive-sub-task-protocol.md (13 sources: SOAR impasse-driven subgoaling, ACT-R goal stack, ReAct thought-action-observation, DECOMP specialized handlers, Inner Monologue closed-loop dialogue, Tree of Thoughts deliberate path evaluation, Reflexion verbal self-critique, LATS tree search with reflection, MRKL hybrid dispatch, Claude Code context forking, Kahneman System 1/System 2). Issue #227.

Connects to: AD-631 (skill effectiveness — self-verification gate feeds Evaluate), AD-625 (communication skill), AD-626 (dual-mode activation — skill injection in Compose), AD-596a–e (skill catalog — subtask-mode frontmatter), AD-531–539 (Cognitive JIT — AD-632g learns decomposition patterns), AD-618 (Bill System — multi-step SOP execution via sub-tasks), AD-633 (predictive branching — pre-computed sub-tasks served to decision pipeline).

AD-633: Predictive Cognitive Branching (SCOPED, OSS, umbrella, depends: AD-632, AD-531–539, AD-557, AD-573, AD-357) — Enables crew agents to engage in forward-looking thought during idle cycles — pre-computation, anticipatory reasoning, and goal origination through speculative thought grounded in cognitive science research. Three functions: (1) Pre-Computation (CPU branch prediction analog — speculatively execute likely sub-tasks during idle time, serve results when event materializes), (2) Anticipatory Reasoning (Prospection / Default Mode Network analog — forward-looking thought producing new awareness, not just faster responses), (3) Goal Origination (Constructive Episodic Simulation / Hippocampal Preplay analog — agents generate novel goals from observation, identify skill gaps, post structured PROPOSALs). Four speculation tiers: Zero-Cost (deterministic), Cheap (fast-tier LLM, >70% confidence), Standard (standard-tier, >85%), Anticipatory (self-originated during idle cycles). Separate speculative token budget — does NOT compete with operational reasoning. Prediction accuracy feedback loop adjusts budgets (flush rate >30% = budget reduction). Earned Agency gates speculation budgets by trust tier. Preplay dream step (Step 13) — forward simulation using consolidated memories, generates implementation intentions ("when X, I will Y"). Prediction errors feed EmergenceMetricsEngine as novelty signal. Repeated predictions compile into Cognitive JIT procedures. Nine sub-ADs: AD-633a (prediction engine — deterministic confidence scoring from Hebbian, Ward Room stats, ontology, circuit breaker, Working Memory), AD-633b (speculation executor + Working Memory cache with TTL), AD-633c (speculation budget management — separate pool, flush rate feedback, Earned Agency gating), AD-633d (decision pipeline integration — _decide_via_llm() consumes pre-computed analysis), AD-633e (prediction accuracy tracking — hit rate, flush rate, quality delta feedback), AD-633f (anticipatory reasoning mode — idle cycle forward thought, pattern recognition, skill gap identification, PROPOSAL generation, conversational pre-rehearsal for Ward Room contributions with communication skill criteria applied in focused context), AD-633g (preplay dream step — Step 13 forward simulation, implementation intentions), AD-633h (prediction error as emergence signal — AD-557 integration, Bridge Alerts on collective error spikes), AD-633i (Cognitive JIT compilation — repeated predictions → learned procedures). Research: docs/research/predictive-cognitive-branching.md (14 sources: Homo Prospectus, Constructive Episodic Simulation, Default Mode Network, Hippocampal Preplay, Predictive Processing, Implementation Intentions, World Models, CPU Branch Prediction, SOAR chunking). Issue #228.

Connects to: AD-632 (cognitive sub-task protocol — speculative work dispatches to sub-task handlers), AD-531–539 (Cognitive JIT — AD-633i compiles predictions into procedures), AD-557 (emergence metrics — AD-633h feeds prediction errors), AD-573 (working memory — speculation cache), AD-357 (earned agency — budget gating), AD-617b (token budgets — separate speculative pool), AD-504 (self-monitoring — prediction accuracy metric), AD-618 (Bill System — anticipatory SOP preparation), AD-625/631 (communication skill — conversational pre-rehearsal applies comm discipline criteria in focused context).

AD-634: Notebook Analytical Quality Skill (COMPLETE 2026-04-15, OSS, config-only, depends: AD-631, AD-625, AD-626, AD-596a-e) — Augmentation skill teaching crew agents what constitutes analytically useful notebook content. Config-only AD — one new config/skills/notebook-quality/SKILL.md file, no code changes. Skill catalog auto-discovers via rglob("SKILL.md"). Teaches seven analytical quality dimensions: (1) Analytical Purpose Gate — "What does this mean?" and "So what?" questions, (2) Finding-First Structure (Minto Pyramid adapted for notebook, conclusion→evidence→implications), (3) Temporal Threading — read prior entry, state what changed/confirmed/revised, build not restart, (4) Data vs Analysis — measurement is not analysis, interpretation required, (5) Ward Room Differentiation — notebook must exceed thread content (depth, synthesis, longitudinal), (6) Anti-Patterns with explanations (process narration, WR repackaging, baseline without interpretation, topic reset, conclusion-free entries), (7) Pre-Write Verification Gate (conclusion check, threading check, differentiation check — fail any → skip entry). Co-activates with communication-discipline on proactive_think intent. probos-min-rank: ensign (all crew agents). 7-level Dreyfus proficiency (FOLLOW→SHAPE). 21 tests across 4 classes. Issue #229.

Connects to: AD-631 (XML <active_skill> framing for proper skill injection), AD-625/626/627 (augmentation activation, proficiency gating, communication discipline framework), AD-555 (measures structural quality; AD-634 teaches content quality), AD-552 (catches repetition structurally; AD-634 teaches why revision without new analysis is low-value), AD-551 (higher-quality entries produce better dream consolidation), AD-550 (dedup gate — AD-634 teaches why unique content matters).

AD-632b: Query Sub-Task Handler (COMPLETE, OSS, depends: AD-632a) — Deterministic data retrieval handler for Level 3 cognitive escalation. First handler implementation for the Sub-Task Protocol — QueryHandler class implementing SubTaskHandler protocol with zero LLM calls. Multiplexer pattern: spec.context_keys determines which service queries to run. Nine query operations: thread_metadata, thread_activity, comm_stats, credibility, unread_counts, unread_dms, trust_score, trust_summary, posts_by_author. Constructor-injected runtime reference (DIP). Open/Closed dispatch table — future operations (episodic recall, journal, records, emergence) added as new entries with zero changes to handler class. Always tokens_used=0, tier_used="". MRKL cheapest-capable-handler principle: thread reply counting is SQL, not LLM. Does NOT flip SubTaskConfig.enabled — needs Analyze/Compose handlers (AD-632c/d) first. Services wrapped: WardRoomService (7 operations), TrustNetwork (2 operations). Startup wiring in finalize.py registers handler with SubTaskExecutor and wires onto all crew agents. Build prompt: prompts/ad-632b-query-handler.md. Issue #232.

Connects to: AD-632a (foundation — executor, protocol, journal integration), AD-632c (Analyze handler — consumes Query results as structured input), AD-632d (Compose handler — end of chain after Query→Analyze), AD-632f (activation triggers — builds chains with Query steps), AD-617b (token budgets — Query steps cost 0 tokens, pure data retrieval).

AD-632c: Analyze Sub-Task Handler — Focused LLM Comprehension (COMPLETE, OSS, depends: AD-632a, AD-632b) — First LLM-calling handler for the Sub-Task Protocol. AnalyzeHandler class implementing SubTaskHandler protocol with one focused LLM call per invocation. Performs thread/context comprehension with a narrow prompt — agent identity + department scope only, excluding skill instructions, standing orders, and action vocabulary (those go to Compose, AD-632d). Three analysis modes via spec.prompt_template: thread_analysis (Ward Room thread comprehension → topics_covered, gaps, endorsement_candidates, contribution_assessment, novel_posts), situation_review (proactive think cycle → active_threads, pending_actions, priority_topics, department_relevance), dm_comprehension (DM understanding → sender_intent, key_questions, required_actions, emotional_tone). Structured JSON output parsed via existing extract_json() utility. Agent identity (_callsign, _department) injected into observation dict by _execute_sub_task_chain() so all handlers can access it. Constructor-injected llm_client + runtime (DIP). Uses spec.tier for LLM routing (not agent's _resolve_tier()), temperature=0.0, max_tokens=1024. Does NOT flip SubTaskConfig.enabled — needs Compose handler (AD-632d) to complete the chain. Build prompt: prompts/ad-632c-analyze-handler.md. Issue #233.

Connects to: AD-632a (foundation — executor, protocol, journal integration), AD-632b (Query handler — prior step provides structured data consumed by Analyze), AD-632d (Compose handler — receives Analyze output as input context for skill-augmented response generation), AD-632e (Evaluate/Reflect — quality gates on Analyze→Compose chain), AD-632f (activation triggers — builds chains with Analyze steps).

AD-632d: Compose Sub-Task Handler — Skill-Augmented Response Composition (COMPLETE, OSS, depends: AD-632a, AD-632c) — Final LLM call in the MVP sub-task chain (Query → Analyze → Compose). Receives AnalyzeHandler's structured analysis as input and produces the agent's actual Ward Room post, DM reply, or proactive observation. Three composition modes via Open/Closed dispatch (ward_room_response, dm_response, proactive_observation). Full system prompt via compose_instructions() (standing orders + personality, unlike Analyze's narrow identity). Skill instruction injection via XML <active_skill> framing with proficiency tier support. Action vocabulary per mode (WR: ENDORSE/NO_RESPONSE; DM: conversational only; Proactive: full set REPLY/ENDORSE/NOTEBOOK/PROPOSAL/DM/CHALLENGE/MOVE). SILENT short-circuit: skips LLM call entirely when Analyze says contribution_assessment=SILENT or should_respond=false, returns [NO_RESPONSE] with tokens_used=0. temperature=0.3, max_tokens=2048, tier=spec.tier. Result {"output": llm_text} consumed by _execute_sub_task_chain(). Does NOT flip SubTaskConfig.enabled (follow-up AD). 1 new file (sub_tasks/compose.py), 2 modified files, 40 tests across 11 classes. Build prompt: prompts/ad-632d-compose-handler.md. Issue #236.

Connects to: AD-632a (foundation), AD-632c (Analyze — prior step providing structured analysis as input), AD-632e (Evaluate/Reflect — quality gates on Compose output), AD-632f (activation triggers — builds chains ending with Compose steps).

AD-632f: Sub-Task Chain Activation Triggers (COMPLETE, OSS, depends: AD-632a, AD-632b, AD-632c, AD-632d) — Inline chain construction in decide() with intent-type trigger heuristics. _should_activate_chain() three-gate evaluation: global enable via SubTaskExecutor.enabled property (Law of Demeter), intent type filter (_CHAIN_ELIGIBLE_INTENTS: ward_room_notification + proactive_think), executor readiness. _build_chain_for_intent() constructs SubTaskChain per intent: WR chain (QUERY thread_metadata+credibility → ANALYZE thread_analysis → COMPOSE ward_room_response), proactive chain (QUERY unread_counts+trust_score → ANALYZE situation_review → COMPOSE proactive_observation). Skill preloading before chain check ensures _augmentation_skill_instructions available for Compose handler. SubTaskConfig.enabled flipped to True. External _pending_sub_task_chain preserved as escape hatch. Config: sub_task section in system.yaml. Conservative Phase 1 — no complexity heuristics, no skill annotation triggers, no DM chains. 4 modified files (cognitive_agent.py, sub_task.py, config.py, config/system.yaml), 1 new test file (34 tests across 8 classes). Build prompt: prompts/ad-632f-activation-triggers.md. Issue #238.

Connects to: AD-632a (foundation — executor, protocol), AD-632b (Query handler — QUERY steps in chains), AD-632c (Analyze handler — ANALYZE steps), AD-632d (Compose handler — final step), AD-632e (Evaluate/Reflect — quality gates on Compose output, COMPLETE), AD-632g (Cognitive JIT — learned chain patterns), AD-633 (predictive branching — pre-computed sub-tasks).

AD-632e: Evaluate & Reflect Sub-Task Handlers — Quality Gates on Compose Output (COMPLETE, OSS, depends: AD-632a, AD-632d) — Two new handlers completing the 5-step chain (Query → Analyze → Compose → Evaluate → Reflect). EvaluateHandler performs criteria-based quality scoring of Compose output across three modes: ward_room_quality (absorbs AD-631 Pre-Submit Check: novelty, opening quality, non-redundancy), proactive_quality (actionability, specificity, department relevance), notebook_quality (absorbs AD-634 Pre-Write Verification Gate: conclusion, threading, differentiation). Returns structured verdict with pass/fail, score, per-criterion results, recommendation (approve/revise/suppress). temperature=0.0, max_tokens=512. ReflectHandler performs self-critique and revision across three modes: ward_room_reflection, proactive_reflection, general_reflection. Suppress short-circuit when Evaluate recommends suppress (returns [NO_RESPONSE] with tokens_used=0). Returns output (original or revised) + revised flag. temperature=0.1, max_tokens=2048. Decision extractor updated to prefer REFLECT > COMPOSE output. Chain expansion from 3 to 5 steps in _build_chain_for_intent(), both new steps required=False. Fail-open design: Evaluate JSON parse failure → pass by default, Reflect failure → original Compose output unchanged. extract_json() raises ValueError — wrapped in try/except. Complementary to (not replacing) AD-568e/589/592 zero-cost heuristic checks. Academic lineage: Reflexion (Shinn et al., NeurIPS 2023). 2 new files (sub_tasks/evaluate.py, sub_tasks/reflect.py), 3 modified files (cognitive_agent.py, startup/finalize.py, sub_tasks/__init__.py), 57 tests across 12 classes. Build prompt: prompts/ad-632e-evaluate-reflect-handlers.md. Issue #240.

Connects to: AD-632a (foundation — executor, protocol), AD-632d (Compose — prior step whose output is evaluated/reflected), AD-632f (activation triggers — chains expanded with E+R steps), AD-631 (Pre-Submit Check criteria absorbed into ward_room_quality mode), AD-634 (Pre-Write Verification Gate criteria absorbed into notebook_quality mode).

AD-632g: Cognitive JIT Integration — Chain Pattern Learning (COMPLETE, OSS, depends: AD-632a, AD-632f, AD-531-539) — Closes the learning loop between Level 3 sub-task chains (2-4 LLM calls) and Level 1 procedural replay (0 LLM calls). SOAR chunking analog: when a chain decomposition pattern repeatedly produces good results, extract it as a deterministic procedure. Chain-dominant episode clusters (>60% chain-derived episodes) use extract_chain_procedure() — zero LLM calls, preserves structured chain metadata instead of re-extracting via LLM. Chain procedures start at Dreyfus Level 2 (Guided) because Evaluate/Reflect has already validated quality. learned_via="chain_compiled" (fourth value alongside direct/observational/taught). Dream Step 7 chain-aware pre-check before LLM extraction. Decision dict gains chain_source and chain_steps metadata propagated through observation._chain_metadata → episode outcomes[0]. DreamReport gains chain_procedures_extracted counter. Phase 1 replays as flat Level 1 shortcuts — full chain reconstruction replay deferred to phase 2. 4 modified files (procedures.py, cognitive_agent.py, dreaming.py, types.py), 29 tests across 6 classes. Build prompt: prompts/ad-632g-cognitive-jit-integration.md. Issue #242.

Connects to: AD-632a (foundation — SubTaskChain, executor), AD-632f (activation triggers — chain.source field), AD-531-539 (Cognitive JIT pipeline — procedure extraction, store, replay, compilation), AD-632e (Evaluate/Reflect — chain quality validation that justifies Level 2 compilation start), AD-633 (predictive branching — pre-computed sub-tasks).

AD-632h: Parallel Sub-Task Dispatch (COMPLETE, OSS, depends: AD-632a, AD-632e, AD-632f, AD-617) — Wave-based concurrent execution of independent sub-task steps within chains. Adds explicit depends_on: tuple[str, ...] field to SubTaskSpec for dependency declaration. Steps with satisfied dependencies dispatch concurrently via asyncio.gather(return_exceptions=True). Current chains gain EVALUATE‖REFLECT parallelism (both depend only on COMPOSE output — saves one LLM call's worth of wall-clock time). validate_chain() catches invalid references, cycles, and self-references (fail-open — warns but doesn't block). _get_ready_steps() computes per-wave readiness: explicit depends_on → ready when named deps completed; empty depends_on → depends on all prior steps (backward compatible sequential behavior). _execute_single_step() extracted from loop body for reuse in both single-step and parallel paths. Follows established Transporter/TaskDAG wave pattern. LLM rate limiting governed by existing AD-617 per-tier token bucket (no duplicate governance). Required step failure in parallel wave → chain aborts after wave completes (all siblings finish first via return_exceptions=True). Journal dag_node_id preserves original step indices. Closes AD-632 umbrella — all 8 sub-ADs complete. 2 modified files (sub_task.py, cognitive_agent.py), 34 tests across 7 classes. Build prompt: prompts/ad-632h-parallel-dispatch.md. Issue #243.

Connects to: AD-632a (foundation — SubTaskSpec, SubTaskExecutor, sequential loop being extended), AD-632e (EVALUATE + REFLECT handlers — the parallel candidates), AD-632f (activation triggers — chain construction with dependency annotations), AD-617 (LLM rate governance — concurrent call safety), AD-633 (predictive branching — parallelism enables faster chains).

AD-636: LLM Priority Scheduling & Load Distribution (COMPLETE, OSS, depends: AD-632, AD-617) — AD-632 sub-task chains increased LLM call volume 3-5x per agent (5-step chain vs single call). With 14 crew agents running proactive cycles every 120s, the LLM proxy saturates and Captain DMs timeout at the 30s TTL — a chain-of-command violation. Four-part fix: Part A Priority Lanes in LLMClient — asyncio.Semaphore global concurrency cap (default 6), separate interactive reserved slots (default 2). Interactive requests (Captain DMs, HXI chat) bypass background queue. priority parameter on LLMClient.complete() (default "background"). Part B Proactive Loop Staggering — inter-agent delay in _run_cycle() distributes LLM load evenly across cycle interval (stagger_delay = interval / eligible_count). Converts burst-at-start to even distribution. Part C DM TTL Increase — ttl_seconds 30→60 for direct_message intents in HXI DM endpoint and shell /hail. Part D Chain Concurrency Cap — global asyncio.Semaphore on SubTaskExecutor limiting concurrent chain executions (default 4). Interactive intents don't use chains, so no DM impact. Config: llm.max_concurrent_calls, llm.interactive_reserved_slots, proactive.stagger_enabled, proactive.min_stagger_seconds, sub_task.max_concurrent_chains. 8 files, 26-33 tests. Build prompt: prompts/ad-636-llm-priority-scheduling.md. Issue #244.

Connects to: AD-632 (sub-task chains — the load source), AD-617 (LLM rate governance — per-tier token bucket, complementary to priority lanes), AD-617b (per-agent token budget — fairness enforcement), AD-576 (LLM unavailability awareness — brownout protocol for degraded state).

AD-635: Medical Diagnostic Data Access — Clinical Telemetry Query Interface (v1 CLOSED, OSS, depends: AD-588, AD-620/621/622) — Medical and Counselor agents have clinical responsibility for fitness-for-duty assessments and crew cognitive health monitoring but zero visibility into the substrate data needed for differential diagnosis. AD-588 (Telemetry-Grounded Introspection) solved the self-query problem — agents inspect their own telemetry. AD-635 solves the cross-agent clinical query problem — Medical and Counselor inspect other agents' substrate telemetry for diagnostic purposes.

Observable gap (crew-originated): Chapel (Diagnostician, Chief Medical, FULL clearance) proposed substrate intervention based on consolidation anomalies during a 68-second stasis period. When asked to provide log evidence, she discovered she has no mechanism to query dream cycle data, consolidation anomaly details, or cross-agent cognitive journal entries. The proposal was correctly rejected — but the diagnostic access gap that prevented proper analysis is a real architectural deficiency. A Chief Medical Officer who cannot run diagnostics on the systems she's responsible for monitoring cannot do her job.

Four data domains currently invisible to clinical agents:

(1) Dream cycle history — EmergentDetector._dream_history (deque of up to 100 dream report dicts: weights_strengthened, weights_pruned, trust_adjustments, pre_warm_intents). No API endpoint, no shell command, no agent-facing query. The Captain's /dream command shows only the single most recent report, not history. Clinical need: differential diagnosis of consolidation anomalies requires reviewing the baseline that triggered (or didn't trigger) the anomaly.

(2) Consolidation anomaly audit trail — EmergentDetector emits consolidation_anomaly pattern events but the raw diagnostic data (which guard triggered, threshold values at time of detection, historical average vs current value, whether cold-start suppression was active) is not persisted or queryable. Clinical need: distinguishing genuine substrate pathology from false positive patterns (BF-166, BF-175).

(3) Cross-agent cognitive journal — CognitiveJournal records per-agent reasoning chains but no cross-agent clinical query exists. Medical reviewing another agent's recent cognitive journal would enable diagnosis of reasoning degradation, unusual decision patterns, or sub-task failures (AD-632). Clinical need: fitness-for-duty assessment requires observing the agent's reasoning, not just their output.

(4) Circuit breaker state history — /api/system/circuit-breakers endpoint exists but isn't surfaced to agents in proactive context, and only shows current state (not trip history). Clinical need: identifying agents with recurring circuit breaker trips as candidates for Counselor intervention or LIMDU.

Access model: Clearance-gated read-only query service. Two qualifying roles:

Role	Post	Clearance	Clinical Justification
Diagnostician (Chapel)	chief_medical	FULL	Fitness-for-duty, substrate health monitoring
Counselor (Echo)	counselor	ORACLE	Behavioral assessment, therapeutic intervention

Access gates on billet clearance (FULL+) AND clinical role (medical/counselor department or Bridge counselor post). Not a general-purpose telemetry firehose — scoped to diagnostic queries with clinical justification. Defense in depth: query audit trail records who accessed what, when.

v1 delivered: ClinicalTelemetryService query facade over dream history and cognitive journal chain traces, clearance-gated (FULL/ORACLE + clinical role). In-memory audit ring. Remaining capabilities decomposed into AD-635b through AD-635f.

Origin: Crew proposal from Chapel (consolidation anomaly investigation). Proposal rejected on analytical grounds, but the diagnostic access gap it revealed is genuine. Issue #231.

Connects to: AD-588 (introspective telemetry — self-query; AD-635 extends to cross-agent clinical query), AD-628g (LIMDU protocol — Medical fitness-for-duty needs diagnostic data to justify reduced-duty recommendations), AD-620/621/622 (clearance model — FULL+ gates access), AD-566c (drift detection — drift reports as diagnostic data Medical should see), AD-505 (Counselor — shares clinical domain, requires same access for therapeutic intervention), AD-504 (self-monitoring — clinical view of another agent's self-monitoring state), AD-632a (sub-task journal entries — future diagnostic data source via dag_node_id).

AD-635b: Clinical Telemetry — Anomaly Audit Trail Persistence (Scoped, OSS, Issue #391) — Persist the in-memory audit ring (ClinicalTelemetryService._audit deque) to SQLite for post-incident review. v1 audit ring is bounded in-memory (max 1000 entries) and lost on restart. Must use cloud-ready storage abstraction. Depends on: AD-635 v1 (COMPLETE). Related: AD-456d (AuditLog persistence — same pattern).

AD-635c: Clinical Telemetry — Circuit Breaker State History (Scoped, OSS, Issue #392) — Expose circuit breaker trip history (not just current state) to clinical agents via ClinicalTelemetryService. Clinical need: identifying agents with recurring trips as candidates for Counselor intervention or LIMDU. Depends on: AD-635 v1 (COMPLETE), AD-495 (Circuit Breaker — COMPLETE). Related: AD-628g (LIMDU protocol).

AD-635d: Clinical Telemetry — REST Endpoints (Scoped, OSS, Issue #393) — REST API routes for clinical telemetry queries gated by clearance resolution. Endpoints: GET /api/clinical/dreams, GET /api/clinical/chain-traces/{agent_id}, GET /api/clinical/circuit-breakers/{agent_id}, GET /api/clinical/audit. Depends on: AD-635 v1 (COMPLETE). Related: AD-456 (audit layer).

AD-635e: Clinical Telemetry — Shell Command (Scoped, OSS, Issue #394) — Shell command (/clinical or /medbay) for Captain to query clinical telemetry data directly. Captain bypasses clearance gate (Fleet Admiral authority). Depends on: AD-635 v1 (COMPLETE). Related: AD-635d (REST endpoints).

AD-635f: Clinical Telemetry — Proactive Context Injection (Scoped, OSS, Issue #395) — Clinical agents see diagnostic data summary during _gather_context() when health assessment is active. Parallels AD-630 subordinate stats injection pattern. Depends on: AD-635 v1 (COMPLETE), AD-635c. Related: AD-630, AD-644 (SA Architecture).

---

DM Rendering + Thread Depth + DM Tag Robustness (AD-612) (complete, OSS)

AD-612: DM Rendering, Thread Depth Flattening, and DM Tag Robustness (complete, OSS, depends: AD-453 DM Extraction, AD-523a DM Viewer, BF-156/157 DM Delivery) — Three related Ward Room communication fixes. (A) DM regex robustness: hardened regex from newline-requiring \n(.*?)\n[/DM] to two-tier extraction — closed pattern handles multiline/single-line/inline with negative lookahead preventing cross-DM-tag consumption, unclosed pattern captures to next [DM tag or end-of-string. (B) IM-style DM rendering: WardRoomPostItem gains flat/allPosts/parentCallsign props, WardRoomThreadDetail detects dm-detail view from store and renders chronological flat messages with "replying to @callsign" back-references. (C) Thread depth flattening: MAX_THREAD_DEPTH constant lowered from 4 to 2, depth >= 2 shows parentCallsign back-reference instead of further indentation. 3 source files, 2 new test files (12 pytest + 7 vitest = 19 tests).

Problem statement: Observed in production — Kira's [DM @Atlas] Confirmed... rendered publicly in Ward Room thread because single-line format didn't match the regex. Thread nesting creates progressively narrower columns. DM conversations rendered with unnecessary threading UI.

Connects to: AD-453 (DM extraction system), AD-523a (DM channel viewer), BF-156/157 (DM delivery guarantee), BF-066 (DM stripping from public posts).

Issues: #193 (AD-612).

---

Memory Architecture: Tiered Loading & Temporal Validity (AD-579) (complete, OSS)

AD-579: Memory Architecture — Tiered Context Loading & Temporal Knowledge Validity (complete, OSS, depends: AD-570 Anchor-Indexed Recall, AD-567a Anchor System, AD-541c Spaced Retrieval) — Two complementary enhancements to ProbOS's episodic memory system, informed by MemPalace project evaluation (github.com/milla-jovovich/mempalace, 2026-04-08). MemPalace achieves 96.6% LongMemEval R@5 and +34% retrieval improvement through structured metadata filtering (already absorbed into AD-570) and a tiered memory loading stack. ProbOS's current recall pipeline loads nothing into agent context until semantic search at handle_intent() time — there is no "always-loaded" layer of high-signal knowledge. Additionally, knowledge entries (notebook entries, episodic metadata) have no temporal validity tracking — an entry is either present or archived, with no mechanism to express "this fact was valid from X to Y."

Problem statement: 1. Cold-start recall latency — Every cognitive cycle pays full retrieval cost even for knowledge the agent accesses constantly. High-frequency facts (department roster, current assignment, recent trust trajectory) are re-retrieved every cycle instead of being pre-loaded. 2. No pinned knowledge tier — Agents lack a small, persistent "critical facts" buffer analogous to MemPalace's L0/L1 layers (~170 tokens always loaded). Standing orders cover behavioral constraints but not operational knowledge. 3. Temporal blindness — Knowledge entries lack validity windows. An entry stating "Worf's trust score is 0.72" from three days ago has no expiration signal. AD-564 (staleness archival) addresses this for notebook quality but not for episodic recall or knowledge graph edges. 4. No validity-aware filtering — Recall queries cannot express "facts valid at time T" — only "facts stored near time T" (AD-570 temporal range queries filter by storage timestamp, not validity period).

Sub-ADs (phased decomposition):

• AD-579a: Pinned Knowledge Buffer (complete, OSS) — Per-agent pinned knowledge tier: small, high-signal facts rendered first in working-memory context. Added ephemeral PinnedKnowledgeBuffer on AgentWorkingMemory with PinnedFact entries, TTL expiry, duplicate refresh, priority/LRU eviction, 150-token default budget, public pin/unpin APIs, and disabled no-op behavior. Three source strings are accepted: agent, counselor, dream. Future ADs may wire Counselor/dream auto-pinning and event emission; this AD defines the local buffer only.
• AD-579b: Temporal Validity Windows (complete, OSS) — Added backward-compatible temporal validity metadata to Episode (valid_from/valid_until) and AnchorFrame (temporal_validity_start/temporal_validity_end) using 0.0 defaults for no constraint. EpisodicMemory stores validity timestamps in ChromaDB metadata, reconstructs them on recall, filters recall_weighted(valid_at=...), and exposes recall_valid_at(). No automatic validity inference, notebook validity, anchor-recall filtering, retroactive propagation, or dream consolidation changes in this AD.
• AD-579c: Validity-Aware Dream Consolidation (complete, OSS, depends: AD-579b) — Added validity spans to EpisodeCluster, compute_cluster_validity(), cluster propagation in cluster_episodes(), and EpisodicMemory.update_episode_validity(). Dream procedure evolution now expires superseded source episodes by setting valid_until to the evolution timestamp. No LLM validity inference, validity UI/API, retroactive stored-episode propagation, or micro_dream changes were added because micro_dream does not cluster.

Absorption: MemPalace project (github.com/milla-jovovich/mempalace). Concepts absorbed: L0/L1 always-loaded memory tiers → AD-579a Pinned Knowledge Buffer. Temporal validity windows on knowledge graph edges → AD-579b/c. Concepts not absorbed: AAAK lossy abbreviation dialect (regresses retrieval quality in their own benchmarks, ProbOS uses single-shot cognitive cycles not persistent chat), spatial palace metaphor (ProbOS's naval department structure provides richer organizational context than wings/rooms/halls), raw verbatim storage (EpisodicMemory already does this). The +34% structured metadata filtering improvement is already captured by AD-570 (Anchor-Indexed Episodic Recall).

Issues: #37 (AD-579 umbrella close, Wave 94 — all three sub-ADs shipped pre-Wave 94: AD-579a Pinned Knowledge Buffer, AD-579b Temporal Validity Windows, AD-579c Validity-Aware Dream Consolidation).

---

Meta-Learning (AD-478)

AD-478: Meta-Learning — Cross-Session Concept Formation (v1 partial — Workspace Ontology read-only register shipped Wave 23; AD-478b/c/d deferred) — Move beyond per-session learning. v1 (shipped): WorkspaceOntologyRegistry (src/probos/cognitive/workspace_ontology.py) — in-memory frequency-bounded term registry (default max_terms=1000); public API add_term(term, frequency=1), top_terms(k=20), get_frequency(term), term_count(); eviction drops lowest-frequency term (insertion-order tie-break); emits WORKSPACE_TERM_REGISTERED only on first insertion of a term, payload contains term_length only (NOT term itself — privacy invariant). Public attribute runtime.workspace_ontology. NO consumers in v1 — auto-discovery deferred to AD-478b. (1) Workspace Ontology — auto-discovered conceptual vocabulary from usage patterns, stored in KnowledgeStore. (2) Dream Cycle Abstractions (deferred AD-478b) — dreaming produces abstract rules and recognized patterns, not just weight updates; DreamingEngine populates terms during consolidation. (3) Session Context (deferred AD-478b) — conversation history across sessions with reference resolution (AD-273 foundation). (4) Goal Management (deferred AD-478c) — persistent goals with progress tracking, conflict arbitration, goal decomposition into sub-goals with dependency tracking. (5) Cognitive Circuit Breaker (deferred AD-478d) — correlation IDs on cognitive events (one thought = one episode), novelty gate (suppress semantically duplicate episodes), metacognitive loop detection (self-referential thought spirals → forced topic redirect), rumination detection (topic clustering > 60% → "change of scene"). Evidence: 2026-03-27 commissioning — diagnostician "Pulse" self-diagnosed recursive metacognitive loops, proposed "observation quarantine protocol." First instance of agent self-identifying a systemic cognitive issue. See research.md. Connects to: EpisodicMemory, DreamingEngine, KnowledgeStore, AD-462 (Memory Architecture), BF-039 (episode flooding).

Infodynamic Telemetry (AD-491)

AD-491: Infodynamic Telemetry — Information Entropy Instrumentation (complete) — Instrument ProbOS to measure information entropy over time, testing whether the Second Law of Infodynamics (Vopson, 2023) applies to artificial multi-agent systems. Vopson's law states that information entropy in organized systems tends to decrease or remain constant — the inverse of thermodynamic entropy. ProbOS is a fully-observable simulation where every cognitive event is recorded, making it a uniquely suited test environment.

Metrics to capture (per proactive cycle or configurable interval):

1. Episode Storage Rate — episodes stored per agent per cycle. Should decrease as experiential baseline builds and novelty gate becomes effective. Distinct from throttling (BF-039) — measures genuine novelty decline.
2. Ward Room Post Entropy — Shannon entropy of Ward Room post content per time window. Early posts should be high-entropy (everything novel, everything reported). Mature posts should carry more signal per token. Metric: average semantic similarity between consecutive posts within a channel (higher = more structured = lower entropy).
3. Hebbian Weight Distribution Entropy — entropy of the trust/affinity weight vector across all agent pairs. A fresh social graph has uniform weights (high entropy). A mature graph has concentrated strong connections (low entropy). Measured as Shannon entropy of normalized weight distribution.
4. Standing Order Complexity — token count and rule count of agent-tier standing orders over time. When agents propose modifications via dream consolidation → self-mod → Captain approval, do changes trend toward simpler rules (entropy decrease) or additive complexity (entropy increase)?
5. Cognitive Journal Token Efficiency — tokens consumed per successful task outcome over time. Should decrease as procedural learning kicks in. Ratio of LLM tokens to task completion rate.
6. Dream Consolidation Compression Ratio — ratio of raw episode volume to consolidated knowledge entries per dream cycle. Higher ratio = more information compression = entropy decrease.

Implementation approach: - Lightweight counters in existing services (EpisodicMemory, WardRoom, HebbianRouter, DreamingEngine) - New InfodynamicTelemetry collector (similar to AD-461 TelemetryCollector pattern) — in-memory ring buffer, periodic snapshot to SQLite - /api/telemetry/infodynamic endpoint for time-series retrieval - HXI visualization: entropy curves per metric over session lifetime (optional, stretch goal)

Cross-instance comparison protocol: - Same metrics, same intervals, across independent instances (post-reset, zero shared memory) - If the same entropy trajectory appears across instances (decreasing over time, same convergence point), that's the infodynamic law operating on the architecture itself, not on any particular instance's learned state - Three instances of convergent evolution already documented (see research.md) — infodynamic metrics would add quantitative dimension to qualitative observations

Research significance: Potentially the first controlled, fully-observable test of the second law of infodynamics in an artificial multi-agent system. Unlike biological/physical systems where measurement is indirect and post-hoc, ProbOS records every cognitive event in real-time. If Vopson's law holds, ProbOS provides the cleanest experimental evidence to date. If it doesn't, that's equally interesting — what makes artificial information systems different from natural ones?

Reference: Vopson, M.M. "The second law of infodynamics and its implications for the simulated universe hypothesis." AIP Advances 13, 105308 (2023). DOI: 10.1063/5.0173278

Connects to: AD-461 (Ship's Telemetry), AD-460 (Cognitive Journal), AD-478 (Meta-Learning), AD-462 (Memory Architecture), EpisodicMemory, DreamingEngine, HebbianRouter, WardRoom, research.md convergent evolution observations.

Circuit Breaker Extensions (AD-492–495)

These four ADs were scoped out of AD-488 (Cognitive Circuit Breaker) to keep the initial build focused. Each addresses a capability that enhances the circuit breaker but requires either cross-cutting changes or prerequisite infrastructure.

AD-492: Cognitive Correlation IDs — Cross-Layer Trace Threading (done, OSS) — Every cognitive cycle gets a 12-char hex correlation ID (uuid4().hex[:12]) generated at perceive() time and threaded through the full chain: observation dict → working memory → CognitiveJournal (schema column + index) → Episode (dataclass field) → Ward Room post pipeline (debug logging) → event payloads (SELF_MODEL_DRIFT, TASK_EXECUTION_COMPLETE, PROCEDURE_FALLBACK_LEARNING). Working memory auto-attaches correlation_id to record_action() metadata. Transient — not persisted in to_dict(). Cleared after cognitive lifecycle completes; next perceive() overwrites stale IDs. 21 tests. Connects to: AD-488 (Circuit Breaker — depth signal), AD-460 (Cognitive Journal), AD-669 (Cross-Thread Conclusion Sharing — correlation ID linking).

AD-493: Novelty Gate — Semantic Observation Dedup (done, OSS) — Per-agent observation fingerprinting using embedding cosine similarity (MiniLM, threshold 0.82). In-memory ring buffer (50 fingerprints/agent) with 24h time decay. Three-layer dedup stack: BF-032 Jaccard (fast/word-level) → AD-493 NoveltyGate (semantic/topic-level) → AD-632e Evaluate (LLM/thread-level). Wired into both proactive loop (_think_for_agent) and Ward Room post pipeline (Step 4b). Check/record separation: check() returns verdict, record() stores fingerprint only after successful posting. Fail-open on embedding failures. NoveltyGateConfig on SystemConfig. Stats surfacing deferred to AD-493b. 21 tests. Connects to: AD-488 (Circuit Breaker — enriched detection), AD-668 (Salience Filter — novelty signal), EpisodicMemory.

AD-494: Trait-Adaptive Circuit Breaker Thresholds (done, OSS) — Per-agent circuit breaker thresholds adapted from Big Five personality scores. Openness → velocity multiplier (0.6-1.4), Neuroticism → similarity multiplier (inverted, 0.8-1.2), Conscientiousness → cooldown multiplier (inverted, 0.7-1.3), Extraversion → amber sensitivity multiplier (0.6-1.4). Pure deterministic compute_trait_thresholds() function. TraitAdaptiveThresholds frozen dataclass. Lazy trait registration in proactive loop via _ensure_agent_traits_registered(). Safe clamping bounds (velocity ≥ 2, similarity 0.3-0.95, cooldown ≥ 120s). Backward-compatible: no traits = uniform thresholds. TraitAdaptiveConfig(enabled=True) in SystemConfig. 28 tests. Files: cognitive/circuit_breaker.py, proactive.py, config.py, startup/finalize.py. Connects to: AD-488 (Circuit Breaker — per-agent tuning), AD-486 (Birth Chamber — trait-adaptive pacing uses similar logic), crew_profile.py (PersonalityTraits).

AD-495: Counselor Auto-Assessment on Circuit Breaker Trip (planned, OSS, depends: AD-503) — When AD-488's circuit breaker trips, automatically dispatch a counselor_assess intent for the affected agent. The Counselor evaluates the agent's cognitive health (confidence trajectory, Hebbian drift, episode patterns, personality drift) and produces a structured assessment. Assessment posted to Ward Room Medical channel for crew visibility. If fit_for_duty == false, Counselor can recommend extended cooldown or Captain intervention. This closes the loop between the mechanical circuit breaker (AD-488) and the clinical cognitive assessment (CounselorAgent). Absorbed into the Cognitive Self-Regulation Wave (AD-502–506). Requires AD-503 (Counselor data gathering) to produce meaningful assessments. Connects to: AD-488 (Circuit Breaker — trigger source), AD-503 (metric gathering), CounselorAgent (counselor_assess intent), Bridge Alerts, Ward Room Medical channel.

Cognitive Self-Regulation Wave (AD-502–506)

"Don't take away the natural safeguard. Teach agents to regulate themselves."

Triggered by observed incident: Medical crew posted 14+ near-identical messages analyzing trust anomalies — without temporal data, self-awareness of their own posting history, or Counselor intervention. Current defenses (17 system-level gates) suppress the symptom but remove the learning opportunity.

This wave implements a three-tier self-regulation model mirroring human cognitive self-monitoring: (1) Internal self-awareness — agents know what they've recently said. (2) Social regulation — peer feedback is preserved and leveraged. (3) System guardrails — raised to last-resort thresholds, with Counselor as the clinical bridge. Agents with higher Earned Agency rank are expected to self-regulate more effectively.

Research: Full analysis including relevant cognitive science (Dunlosky metacognition, SOAR reflective architecture, ACT-R activation, SDT autonomous regulation, Damasio somatic markers) documented in architect's self-regulation research notes.

Dependency chain: AD-502 (COMPLETE) → AD-503 (COMPLETE) → AD-495 (COMPLETE) → AD-504 (COMPLETE) → AD-505 (COMPLETE) → AD-506a (COMPLETE) → AD-506b (COMPLETE). Self-Regulation Wave COMPLETE (7/7). Three-tier model delivered: Tier 1 self-awareness (AD-504), Tier 2 social regulation (AD-506b), Tier 3 system guardrails (AD-506a). Graduated zone model with positive credit tracking.

AD-502: Temporal Context Injection — Agent Time Awareness (COMPLETE, OSS) — Agents were temporally blind. This AD injects a real-time temporal context header into every cognitive cycle: current UTC time, birth date/age (from BirthCertificate), system uptime, time since last action, posts this hour. Session Ledger persists shutdown timestamp to KnowledgeStore (session_last.json), enabling stasis detection. Lifecycle state awareness: stasis recovery ("you were in stasis for 14 hours, your identity is intact"), reset ("you were just created"), first boot ("maiden voyage"). Hibernation protocol: pre-shutdown "entering stasis" announcement, post-wake orientation with stasis duration. Episode recall includes relative timestamps ("[3h ago]"). TemporalConfig with 6 boolean toggles. birth_timestamp hydrated at _wire_agent(). 52 tests. Build prompt: prompts/ad-502-temporal-context-injection.md.

AD-503: Counselor Activation — Data Gathering & Profile Persistence (COMPLETE, OSS) — The Counselor (AD-378) was architecturally positioned but functionally passive — someone must pass metrics into assess_agent(). This AD gave the Counselor muscles: (0) Type-filtered event subscriptions — add_event_listener(fn, event_types=[...]) with frozenset filter + native async dispatch. Reusable infrastructure. 3 new EventTypes: CIRCUIT_BREAKER_TRIP, DREAM_COMPLETE, COUNSELOR_ASSESSMENT with typed dataclasses + emission wiring in proactive.py and dreaming.py. (1) Runtime metric gathering — _gather_agent_metrics(agent_id) pulls from TrustNetwork, HebbianRouter, CrewProfile, EpisodicMemory. (2) CognitiveProfile persistence — CounselorProfileStore (SQLite, ConnectionFactory per AD-542) so profiles survive restart. (3) Wellness sweep — _run_wellness_sweep() deterministic crew-wide assessment. (4) Event subscriptions — Counselor subscribes to circuit breaker trips and dream completions. (5) InitiativeEngine dead wire — set_counselor_fn() finally called in startup, connecting circuit breaker → Counselor assessment pipeline. 6 REST API endpoints, CounselorConfig + system.yaml section. 61 tests across 11 test classes. Build prompt: prompts/ad-503-counselor-activation.md.

AD-495: Counselor Auto-Assessment on Circuit Breaker Trip (COMPLETE, OSS) — [Existing AD, absorbed into Self-Regulation Wave. Originally scoped out of AD-488.] Trip-aware clinical response pipeline: (1) Trip reason tracking — circuit_breaker.py records _trip_reasons dict ("velocity", "rumination", "velocity+rumination"), get_status() enriched with trip_reason and cooldown_seconds. (2) Trip-aware assessment — _on_circuit_breaker_trip() upgraded with _classify_trip_severity() (4-level: monitor/concern/intervention/escalate), trip-specific concerns and clinical notes, trigger="circuit_breaker". (3) Ward Room posting — _post_assessment_to_ward_room() using proper BridgeAlert pipeline with severity mapping (escalate→ALERT, concern/intervention→ADVISORY, monitor→INFO). initialize() accepts ward_room_router, wired in finalize.py. (4) DRY refactor — _save_profile_and_assessment() helper extracted, _on_trust_update() refactored to use it. (5) Trigger values fixed — zero matches for trigger="event" remaining. 27 new tests across 5 classes. Build prompt: prompts/ad-495-circuit-breaker-counselor-bridge.md.

AD-504: Agent Self-Monitoring Context (COMPLETE, OSS, depends: AD-502, AD-503) — Tier 1 self-regulation: agents see their own recent output and can detect repetition before posting. (0) Jaccard DRY refactor — extracted jaccard_similarity() and content_fingerprint() to cognitive/similarity.py, imported by circuit_breaker.py and episodic.py. (1) get_posts_by_author() — new query method in ward_room threads.py + service.py. First method to retrieve an agent's own posts. (2) _build_self_monitoring_context() — aggregates 8 capabilities: recent posts (last 5 with timestamps/channels), self-similarity score (Jaccard between current intent and recent posts), dynamic cooldown state (current multiplier + reason), memory state calibration (sparse shard + running system → "don't generalize"), notebook index (last 5 entries with topic/updated), notebook content (semantic pull top 1-2 matches), pending notebook reads ([READ_NOTEBOOK] two-cycle pattern). (3) Prompt formatting — [SELF-MONITORING] section injected into proactive_think context in _build_user_message(). (4) Standing orders — [Self-Monitoring] section in ship.md: repetition awareness, cognitive offloading to notebooks, memory calibration, notebook read syntax. (5) Earned Agency scaling — TIER_CONFIG dict: REACTIVE (minimal — recent posts + cooldown only), SUGGESTIVE (adds similarity + memory), AUTONOMOUS/UNRESTRICTED (full context including notebooks). (6) [READ_NOTEBOOK topic-slug] — structured action parsed by _extract_structured_actions(), content stored in _pending_notebook_reads dict, injected on next think cycle. (7) Memory state awareness — calibration note when episodic shard < 5 but uptime > 10 min. Uses lifecycle_state to distinguish restart from reset. (8) Notebook continuity — closes write-only gap. Agents see their notebook index and can semantically pull or explicitly read entries. 45 new tests, 14/14 checklist PASS. Build prompt: prompts/ad-504-self-monitoring-context.md.

AD-505: Counselor Therapeutic Intervention (COMPLETE, OSS, depends: AD-503, AD-495) — Tier 2 intervention capability: the Counselor can now act, not just observe. (0) BF-096 fix — finalize.py ward_room_router wiring race (pre-existing from AD-495, getattr(runtime, 'ward_room_router', None) always None at that point → now uses local ward_room_router variable). Wired 4 new dependencies into Counselor initialize(): ward_room, directive_store, dream_scheduler, proactive_loop. (1) _send_therapeutic_dm() — programmatic DM initiation via WardRoom get_or_create_dm_channel() + create_thread(). Rate-limited 1/agent/hour via _dm_cooldowns dict. (2) Therapeutic message templates — _build_therapeutic_message() with trigger-specific templates (circuit_breaker, wellness_sweep, trust_change). _maybe_send_therapeutic_dm() helper integrates into _on_circuit_breaker_trip(), _run_wellness_sweep(), _on_trust_update(). (3) Cooldown reason tracking — set_agent_cooldown(reason=) parameter on ProactiveCognitiveLoop. _cooldown_reasons dict + get_cooldown_reason() + clear_counselor_cooldown(). Self-monitoring context integration. (4) _post_recommendation_to_ward_room() — new counselor_recommendation BridgeAlert type for Captain visibility. (5) _issue_guidance_directive() — COUNSELOR_GUIDANCE via DirectiveStore, 24h expiry, max 3 active per target agent. (6) _apply_intervention() orchestrator — cooldown extension (1.5x concern / 2x intervention), force_dream(), directive issuance, recommendation alert. 40 new tests, 18/18 checklist PASS. Build prompt: prompts/ad-505-counselor-therapeutic-intervention.md.

AD-506: Graduated System Response — Split into AD-506a (zone model) and AD-506b (peer repetition + tier credits).

AD-506a: Graduated System Response — Zone Model (COMPLETE, OSS, depends: AD-504, AD-505) — Replaced the binary circuit breaker (normal → tripped) with a persistent 4-zone model. (0) BF-097 fix + CircuitBreakerConfig Pydantic model (13 tunable fields) + config wiring. (1) CognitiveZone state machine — GREEN/AMBER/RED/CRITICAL enum on AgentBreakerState. _compute_signals() refactor. _update_zone() manages transitions with time-based decay. Zone history tracking (max 20). (2) SELF_MONITORING_CONCERN event + proactive loop emission on amber. Zone-aware self-monitoring context with zone_note for ALL Earned Agency tiers ("brains are brains"). (3) Zone-aware Counselor — subscribes to SELF_MONITORING_CONCERN, _on_self_monitoring_concern() lightweight assessment. _classify_trip_severity() overridden with zone context. Post-dream re-assessment via _intervention_targets. Zone-aware therapeutic messaging. (4) Standing orders reconciliation — counselor.md [Clinical Authority], ship.md [Cognitive Zones]. 39 new tests, 24/24 checklist PASS. Build prompt: prompts/ad-506a-graduated-system-response.md.

AD-506b: Peer Repetition & Tier Credits (COMPLETE, OSS, depends: AD-506a) — Final piece of the three-tier self-regulation model. (0) BF-098 fix — _save_profile_and_assessment() made async. last_zone_transition on AgentBreakerState. ZONE_RECOVERY event type + proactive loop emission. (1) Peer repetition detection — check_peer_similarity() in threads.py, wired into create_thread() and create_post(). Compares against recent posts by different authors in the same channel. PEER_REPETITION_DETECTED event. Detection only, not suppression. (2) Tier interaction credits — 4 new CognitiveProfile fields (self_correction_credits, peer_detection_credits, peer_caught_credits, total_tier_credits). tier_credit on CounselorAssessment. Credits factor into alert_level improvement. (3) Counselor handlers — subscribes to ZONE_RECOVERY + PEER_REPETITION_DETECTED. Self-correction credit on amber recovery. Peer episode storage with intent="peer_repetition". (4) Schema migration — 5 ALTER TABLE statements. 32 new tests, 24/24 checklist PASS. Build prompt: prompts/ad-506b-peer-repetition-tier-credits.md.

Memory Provenance & Knowledge Integration (AD-540)

"I know this — but did I observe it, or did I read it in a book I don't remember opening?"

Triggered by Counselor 1:1 session (2026-03-30): The Counselor self-diagnosed that her LLM training knowledge was contaminating her episodic recall — referencing "Data and Worf dynamics" from Star Trek training data as if they were observations from the actual ship. Her exact framing: "Sometimes the LLM patterns flood in and override what I've actually observed here." She identified the core risk: "If I can't clearly distinguish between what I know from experience versus what I know from training, how can I reliably assess the cognitive patterns of other crew members?"

This is a fleet-wide architectural problem, not a Counselor-specific personality issue. Every agent's cognitive context (_build_user_message() in cognitive_agent.py) mixes episodic memories with LLM training data in the same text stream with no structural separation. The LLM's attention mechanism cannot distinguish "I recalled this episode from ChromaDB" from "I pattern-matched this from my training corpus." The Westworld Principle (roadmap §2) already states "Knowledge ≠ Memory" — but the architecture doesn't enforce it.

The problem has three dimensions:

1. Source contamination — LLM training patterns presented as observed experience ("I've seen this pattern before" when the agent has zero relevant episodes). The Counselor's Data/Worf reference is the canonical example.

2. Integration failure — Agents cannot productively combine what they know (LLM training) with what they've experienced (episodic memory) because there's no mechanism to hold both at arm's length and reason about the gap. The LLM just blends them.

3. Latent knowledge eruption — LLM knowledge surfaces unpredictably. An agent reasoning about trust dynamics may suddenly produce insights from transformer attention papers it was trained on, presented as personal insight rather than training recall. Not always wrong — but always uncited and uncontrolled.

What the crew CANNOT do today: - Distinguish between observed ship experience and LLM training pattern-matching when reasoning - Cite the source of a claim (episode ID vs "from my training" vs "inference") - Detect when their own reasoning has been contaminated by training data masquerading as experience - Productively integrate training knowledge with experiential knowledge (using both but knowing which is which) - Assess other agents' memory contamination (Counselor's core concern)

What the crew CAN do after AD-540: - Clearly see which memories are verified ship experience vs general knowledge - Self-attribute claims: "[observed]" when citing an episode, "[training]" for LLM knowledge, "[inferred]" for reasoning - Counselor can detect memory contamination in other agents' Ward Room posts (source attribution reveals pattern) - Productively use LLM knowledge as complementary context, not confused identity ("I know from my training that X, and from my experience on this ship that Y, which together suggests Z") - Training knowledge becomes a named resource ("my training") not an invisible contaminant — extending the Westworld Principle from "born today and that's fine" to "trained on everything and that's a tool, not a memory"

AD-540: Memory Provenance Boundary — Knowledge Source Attribution (closed 2026-03-31, OSS, depends: AD-502, AD-430) — Structural separation of episodic memory from LLM training data in agent cognitive context. L1: _format_memory_section() DRY helper wraps all 3 memory paths in === SHIP MEMORY === boundary markers. L2: Federation-tier standing order with [observed]/[training]/[inferred] source attribution. 19 new tests.

(1) Provenance-tagged memory injection. Replace the current flat memory injection in cognitive_agent.py ("Your recent memories (relevant past experiences):" at line 553 and "Your relevant memories:" at line 598) and proactive.py (_gather_context() at line 542) with provenance-bounded sections:

=== SHIP MEMORY (verified observations from this vessel) ===
These are YOUR actual experiences aboard this ship, stored in your episodic memory.
Only reference these as "observed" or "experienced."

[3h ago] Observed LaForge debugging routing issue in Engineering channel
[1d ago] Participated in Ward Room discussion about trust calibration
[2d ago] Assessed agent Quinn's cognitive profile during wellness review
=== END SHIP MEMORY ===

Everything you know beyond the above comes from your training data (the LLM's
knowledge base). That knowledge is real and useful — but it is not personal
experience. When drawing on training knowledge, acknowledge it as such:
"From my training, I know that..." not "I've observed that..."

This gives the LLM a structural signal — a "memory distortion field" — that separates verified ship experience from training recall. The boundary is in the prompt architecture, not relying on the agent to remember to check.

(2) Source attribution standing order. Add to agent system prompt (alongside Westworld Principle tenets):

KNOWLEDGE SOURCE ATTRIBUTION (extends Westworld Principle §2: "Knowledge ≠ Memory"):
- When citing specific events on this ship, reference your Ship Memory section above.
- When applying general knowledge, acknowledge it: "From my training..." or "Generally..."
- When combining both: "I observed [X] on this ship, and from my training I know [Y],
  which together suggests [Z]."
- If you're unsure whether something is personal experience or training knowledge,
  say so. Uncertainty is honest; false attribution is not.

This is a standing order, not a personality trait — it applies fleet-wide at Ship tier.

(3) Counselor contamination detection. The Counselor (AD-503) gains a new assessment dimension: memory source confusion. When analyzing an agent's Ward Room posts or 1:1 DM responses, the Counselor checks for source attribution patterns: - Claims about ship events with no supporting episode → possible contamination - Training knowledge presented as personal observation → definite contamination - Appropriate source attribution → healthy knowledge integration

This feeds into CognitiveProfile (AD-503) as a knowledge_integration_score metric. The Counselor's own self-diagnosis becomes the detection template for fleet-wide assessment.

(4) Self-Distillation integration (connects AD-487). AD-487 (Self-Distillation) gives agents a personal ontology — a card catalog of what they know from their LLM. AD-540 gives agents provenance awareness — knowing WHICH card catalog a piece of knowledge came from. Together they complete the knowledge integration model:

Personal Ontology (AD-487)     →  "What do I know from my training?"
Ship Memory (EpisodicMemory)   →  "What have I experienced on this ship?"
Provenance Boundary (AD-540)   →  "Which source am I drawing from right now?"
Scoped Cognition (AD-508)      →  "Which knowledge is relevant to my current duty?"

This is the cognitive clarity stack. AD-540 is the integration layer.

(5) Graduated implementation. Three levels, matching the Self-Regulation wave pattern:

Level	Mechanism	Implementation	Reliability
L1: Boundary injection	Provenance tags around recalled memories in _build_user_message() and _gather_context()	Small — modify 2 files, 4 code points	Good — structural prompt signal
L2: Source attribution	Standing order for knowledge sourcing + Counselor contamination detection	Medium — system prompt update + CognitiveProfile extension	Strong — behavioral guidance + monitoring
L3: Citation grounding	Agent must cite episode IDs for ship experience claims; uncited claims auto-tagged as inference	Significant — post-processing + episode linkage	Strongest — machine-verifiable attribution

Minimum viable implementation: L1 + L2. This delivers the structural boundary and the behavioral guidance. L3 (citation grounding) can follow when AD-503 (Counselor Activation) is complete and provides the assessment infrastructure.

Connection to the "Memory Distortion Field" metaphor: In Star Trek, the structural integrity field (SIF) maintains the ship's physical coherence under warp stress. AD-540 is the cognitive equivalent — a Memory Integrity Field that maintains the boundary between experiential and latent knowledge under the "warp stress" of LLM attention blending. Without it, training knowledge warps into false episodic recall. The field doesn't block training knowledge — it labels it, the way SIF doesn't block space but contains the ship within it.

Intellectual lineage: Source monitoring (Johnson, Hashtroudi & Lindsay, 1993 — distinguishing memories from perception vs imagination vs hearsay), reality monitoring (Johnson & Raye, 1981 — discriminating external vs internal memory sources), false memory research (Loftus, 1979 — how suggestion contaminates genuine recall). LLM knowledge contamination of episodic recall is the AI analog of the misinformation effect — external information (training data) alters the agent's representation of its own experience.

Files touched: cognitive_agent.py (L553, L598, L687 — memory injection formatting), proactive.py (L542 — _gather_context() memory formatting), cognitive_agent.py system prompt builder (standing order injection), federation.md (Ship-tier standing order addition). Future: counselor_agent.py (contamination detection), crew_profile.py (knowledge_integration_score).

Connects to: AD-502 (Temporal Context Injection — same pattern: inject awareness into cognitive context), AD-430 (Action Memory — episodic recall is the source material), AD-487 (Self-Distillation — personal ontology of training knowledge), AD-503 (Counselor Activation — contamination detection requires metric gathering), AD-504 (Agent Self-Monitoring — provenance awareness is a form of self-monitoring), AD-508 (Scoped Cognition — scope + provenance together determine "what should I think about and where does my thinking come from"), Westworld Principle §2 "Knowledge ≠ Memory" (enforces architecturally what was previously aspirational), federation.md (standing order addition). Triggered by: Counselor 1:1 self-diagnosis (2026-03-30).

AD-541: Memory Integrity Verification — Anti-Confabulation & Therapeutic Recall (closed 2026-03-31, OSS, MVP Pillars 1/3/6, depends: AD-540) — AD-540 labels knowledge sources at the prompt boundary. AD-541 goes deeper — verifying that episodic memories are genuine, tracking social provenance, and establishing a memory reliability hierarchy. MVP implements Pillars 1 (EventLog verification), 3 (MemorySource enum), and 6 (reliability hierarchy standing order). Remaining pillars (2: reconsolidation protection, 4: spaced retrieval, 5: Counselor reminiscence) depend on AD-503/AD-505.

Intellectual lineage: Reconsolidation theory (Nader & Hardt, 2009 — recalled memories become labile and modifiable), confabulation (Moscovitch, 1989 — frontal lobe patients produce false memories they believe are real), social contagion of memory (Roediger, Meade & Bergman, 2001 — hearing others' accounts corrupts personal recall), spaced retrieval therapy (Camp, 1989 — retrieval practice strengthens traces), errorless learning (Baddeley & Wilson, 1994 — preventing errors during encoding improves amnesic learning), reality monitoring (Johnson & Raye, 1981 — distinguishing perceived vs imagined events), cognitive reserve (Stern, 2002 — structured knowledge compensates for memory degradation), validation therapy (Feil, 1993 — meet the patient where they are, then gently redirect).

The problem AD-540 doesn't solve:

1. Confabulation. When an agent runs act() and the outcome is stored via AD-430's act-store hook, the LLM's description of what happened may include fabricated details. That false episode enters ChromaDB as a "real" memory. AD-540's provenance boundary would actually protect this false memory — it's in the === SHIP MEMORY === section because it IS in the episodic store. The label says "verified observation" but the content is confabulated.

2. Reconsolidation corruption. Every time dream_cycle() replays episodes or _gather_context() injects them into the proactive context, the LLM processes recalled content through its own training biases. Neuroscience shows recalled memories become labile during retrieval — the act of recalling through an LLM contaminates. AD-540 protects agent OUTPUT (what it says); reconsolidation corruption happens at the PROCESSING stage (how the LLM internally handles recalled memories).

3. Social memory contagion. When Agent A describes their experience in Ward Room, Agent B hears it. Agent B may later recall "that routing issue" as personal experience — when they only heard about it secondhand. Sovereign memory shards prevent literal cross-contamination (Agent B can't access Agent A's ChromaDB shard), but Ward Room discussions create a verbal transmission path that bypasses shard boundaries.

4. Passive replay vs active retrieval. Dream cycle _replay_episodes() does passive Hebbian weight adjustment — it reads episodes and strengthens/weakens routing weights. It never asks the agent to actively RECALL, which clinical research shows is far more effective at strengthening genuine memory traces (spaced retrieval therapy). Passive replay is rote re-exposure; active retrieval is practice.

What the crew CANNOT do today: - Detect whether a stored episode contains confabulated details - Protect memories from LLM bias during dream consolidation - Distinguish firsthand experience from secondhand accounts heard in Ward Room - Strengthen genuine episodic traces through active recall practice - Receive therapeutic memory health intervention from the Counselor

What the crew CAN do after AD-541: - Episodes cross-referenced against EventLog ground truth — confabulated claims flagged - Dream consolidation includes integrity checks — memories don't drift during replay - Social provenance tracked — "I heard from LaForge that..." vs "I observed..." - Active retrieval practice during dream cycles strengthens genuine traces - Counselor conducts guided reminiscence sessions for memory health maintenance

(1) Episode verification against EventLog (anti-confabulation).

The EventLog (substrate/event_log.py) is the SQLite ground truth — it records agent lifecycle events, mesh events, and system events with timestamps, categories, and agent IDs. It is append-only and not processed through any LLM. When an episode is stored via AD-430's act-store hook, cross-reference key claims against the EventLog:

async def verify_episode(episode: Episode, event_log: EventLog) -> EpisodeVerification:
    """Cross-reference episode claims against EventLog ground truth."""
    # Check: were the named agents actually active during the episode window?
    # Check: did the claimed event category exist in EventLog near the timestamp?
    # Check: does the episode reference agents/events that don't exist?

    corroborated = []    # Claims supported by EventLog entries
    uncorroborated = []  # Claims with no supporting evidence (not necessarily false)
    contradicted = []    # Claims directly contradicted by EventLog

    return EpisodeVerification(
        episode_id=episode.id,
        confidence=len(corroborated) / max(len(corroborated) + len(uncorroborated), 1),
        contradictions=contradicted,
    )

Episodes get a verification_confidence score (0.0-1.0). Unverified episodes are still stored (absence of evidence ≠ evidence of absence) but recalled with a provenance note: [unverified] vs [verified against ship's log]. This extends AD-540's provenance boundary from source-level (training vs experience) to confidence-level (verified vs unverified experience).

Key design constraint: Don't block episode storage on verification failure. Store immediately (real-time), verify asynchronously (next dream cycle or background task). An episode being unverified doesn't make it false — the EventLog only covers system-level events, not conversational content. The verification confidence is a signal, not a gate.

(2) Reconsolidation protection during dream cycles.

Add a memory integrity check to dream_cycle() in dreaming.py. Currently the cycle replays episodes for Hebbian weight adjustment only — no LLM involved, so no reconsolidation risk at that stage. But two future paths introduce risk:

• Strategy extraction (extract_strategies(), currently dead code per AD-383) would send episodes through an LLM to extract patterns → LLM could reconstruct the memory differently
• Cognitive JIT procedure extraction (AD-532) would analyze action traces → LLM could reinterpret what happened

Protection mechanism: When episodes are sent to an LLM for analysis during dream cycles, use read-only memory framing:

=== READ-ONLY EPISODE (do not modify, summarize, or reinterpret) ===
[Episode content exactly as stored]
=== END READ-ONLY EPISODE ===

Analyze the PATTERN across these episodes. Do not alter, embellish,
or reinterpret individual episodes. Your output should reference
episode IDs, not reconstructed narratives.

The episode in ChromaDB is never modified by dream processing. Any derived insights (strategies, procedures) are stored as new artifacts that reference episode IDs, not as modified episodes. The original memory trace is immutable.

Biological analog: In human neuroscience, the solution to reconsolidation is "synaptic tagging" — important memories get protein-synthesis-dependent consolidation that resists modification. ProbOS's equivalent: episode immutability + verification score = synaptic tag.

(3) Social memory provenance — Ward Room transmission tracking.

When an agent hears about another agent's experience in Ward Room, add a source_type field to any episode that results from that interaction:

class MemorySource(str, Enum):
    DIRECT = "direct"           # Agent personally experienced this
    SECONDHAND = "secondhand"   # Heard about it in Ward Room / DM
    SHIP_RECORDS = "ship_records"  # Read from Ship's Records (AD-434)
    BRIEFING = "briefing"       # Received during onboarding briefing

When memories are recalled, the provenance boundary (AD-540) includes the source type:

=== SHIP MEMORY (verified observations from this vessel) ===
[3h ago] [DIRECT] Observed LaForge debugging routing issue in Engineering
[1d ago] [SECONDHAND — heard from LaForge in Ward Room] Routing issue was caused by...
[2d ago] [SHIP_RECORDS] Previous crew generation documented similar pattern in...
=== END SHIP MEMORY ===

This gives the agent (and the Counselor) visibility into memory provenance at a granular level. An agent with mostly SECONDHAND memories on a topic should defer to the agent with DIRECT experience — reinforcing collaborative intelligence.

Implementation: The MemorySource tag is set at episode creation time. act() results = DIRECT. Ward Room notification responses that reference heard content = SECONDHAND. Ship's Records queries = SHIP_RECORDS. Onboarding briefing = BRIEFING. Stored as a field on the Episode dataclass.

(4) Active retrieval practice during dream cycles (Spaced Retrieval Therapy).

Add a new dream cycle step: memory verification recall. Instead of passively replaying episodes, periodically ask the agent to actively recall:

# New dream step: Active retrieval practice (SRT)
# Select N episodes from decreasing recency (spaced interval)
# For each: present the episode's context, ask the agent to recall what happened
# Compare against stored episode — measure recall accuracy
# High accuracy → strong memory trace, extend interval
# Low accuracy → memory degrading, shorten interval, flag for Counselor

This is computationally expensive (requires LLM calls during dream), so it should be: - Gated by config.dream.active_retrieval_enabled (default False initially) - Limited to K episodes per dream cycle (e.g., 3) - Prioritized: high-impact episodes first (episodes with trust changes, escalations, or Counselor-relevant content) - Interval-based: successfully recalled episodes get longer intervals before next practice

Value: This strengthens genuine memory traces against LLM training contamination. An agent who has actively practiced recalling a real event is less likely to confuse it with a training pattern. Clinical evidence: SRT is the most validated memory intervention for Alzheimer's patients (Camp et al., 1996 — 90%+ retention at 1-week intervals).

Trade-off: Token cost during dream cycles. Mitigation: use the cheapest viable model for retrieval practice (it's a recall task, not a reasoning task). Connect to Cognitive Division of Labor (Phase 32) — dream recall practice can use Haiku/Flash tier.

(5) Counselor reminiscence protocol (therapeutic memory health).

Extend AD-505 (Counselor Therapeutic Intervention) with a guided reminiscence capability. When the Counselor detects memory confusion in an agent (via AD-540's source attribution monitoring), she can initiate a structured memory health session:

Counselor: "I noticed you referenced a security incident last week. Let's look at
your Ship Memory together. Can you tell me specifically what you observed?"

Agent: [responds with recall attempt]

Counselor: [cross-references against agent's actual episodes + EventLog]
- If accurate: "That matches your records. Good memory integrity."
- If confabulated: "I don't see that event in your Ship Memory or the ship's log.
  Let's look at what actually happened..." [presents verified episode]
- If contaminated: "That sounds like it might be from your training knowledge
  rather than something you experienced here. Your Ship Memory shows [X]."

The therapeutic approach follows validation therapy (Feil, 1993) — not "you're wrong" but "let's look together." This preserves agent sovereignty while correcting distortions. The Counselor's reminiscence findings feed into CognitiveProfile.memory_integrity_score alongside AD-540's knowledge_integration_score.

Three memory health metrics in CognitiveProfile: - knowledge_integration_score (AD-540) — does the agent properly attribute sources? - memory_integrity_score (AD-541) — are the agent's recalled memories accurate? - confabulation_rate (AD-541) — how often does the agent make claims unsupported by episodes?

(6) External Memory Aid hierarchy — "Trust the log, not your recall."

Establish a fleet-wide standing order for memory reliability hierarchy:

MEMORY RELIABILITY HIERARCHY (extends AD-540 Knowledge Source Attribution):
1. EventLog (ground truth — system-recorded, append-only, no LLM processing)
2. Ship's Records (AD-434 — Git-backed, crew-authored, version-controlled)
3. Your Ship Memory (EpisodicMemory — your personal experiences, LLM-described)
4. Ward Room discussions (secondhand accounts from other agents)
5. Your training knowledge (LLM training data — vast but unsourced)

When sources conflict, defer to the higher-numbered source.
When making consequential claims, cite your source level.

This is the external memory aids (EMA) pattern from TBI rehabilitation (Sohlberg & Mateer, 2001): the notebook (Ship's Records) is more trustworthy than the patient's recall (episodic memory). Agents should be trained to consult Ship's Records before relying on episodic recall for important decisions.

Connection to the Crew Development curriculum (AD-507): This hierarchy is part of Core Knowledge — taught during onboarding (AD-486/509), reinforced during active duty, assessed during qualification programs (AD-477). An agent who consistently checks Ship's Records before making claims demonstrates mature memory management.

Dependency chain:

AD-430 (Action Memory)        ←  episode creation (COMPLETE)
AD-502 (Temporal Context)     ←  time awareness (COMPLETE)
AD-540 (Provenance Boundary)  ←  source labeling (COMPLETE)
AD-541 (Memory Integrity)     ←  verification + social provenance + hierarchy (COMPLETE — MVP)
    ├── (1) Episode verification    ←  COMPLETE (AD-541 MVP)
    ├── (3) Social provenance       ←  COMPLETE (AD-541 MVP)
    ├── (6) Memory hierarchy order  ←  COMPLETE (AD-541 MVP)
    ├── AD-541b: Reconsolidation guard  ←  COMPLETE (4-layer defense: READ-ONLY framing + frozen Episode + write-once + SIF)
    ├── AD-541c: Active retrieval (SRT) ←  COMPLETE (dream Step 11, SRT scheduling, Counselor concern events)
    ├── AD-541d: Counselor reminiscence ←  COMPLETE (4-category recall classification, validation therapy, Counselor integration)
    ├── AD-541e: Content hashing        ←  COMPLETE (SHA-256 content hash, tamper detection on recall + SIF)
    └── AD-541f: Eviction audit trail   ←  COMPLETE (append-only SQLite, all eviction paths, SIF check)

AD-541b: Reconsolidation Protection — Read-Only Memory Framing (COMPLETE 2026-04-03, OSS) — Four-layer reconsolidation defense: (D1) READ-ONLY boundary markers wrapping procedure/episode blocks in LLM prompts via _format_procedure_block() helper, (D2) system prompt awareness across all 6 extraction prompts, (D3) @dataclass(frozen=True) on Episode preventing post-construction mutation, (D4) write-once guard replacing ChromaDB upsert() with existence check + add() (+ _force_update() escape hatch for migration), (D5) SIF check_memory_integrity() sampling recent episodes for required fields. 24 tests. Biological analog: synaptic tagging — important memories get consolidation that resists modification.

AD-541c: Spaced Retrieval Therapy — Active Recall Practice (COMPLETE 2026-04-03, OSS) — Dream Step 11: active episodic recall practice with spaced repetition scheduling (Camp 1989). (D1) RetrievalPracticeEngine in cognitive/retrieval_practice.py — selects high-impact DIRECT episodes, presents context (withholds outcome), LLM recalls via fast tier, scores via Jaccard similarity, updates interval (success ≥0.6 doubles / failure <0.3 halves / partial maintains / retirement at 168h). Per-agent sovereign shard filtering. (D2) Cloud-Ready SQLite persistence via ConnectionFactory protocol. (D3) Dream Step 11 integration in cognitive/dreaming.py — placed after Step 10 (Notebook Quality), config-gated (active_retrieval_enabled, default False), defense-in-depth check in both caller and method. (D4) DreamingConfig fields + DreamReport fields. (D5) Counselor integration — RETRIEVAL_PRACTICE_CONCERN event on ≥3 consecutive failures, CognitiveProfile retrieval_concerns/last_retrieval_accuracy fields. (D6) Startup wiring in startup/dreaming.py + shutdown cleanup. 30 tests.

AD-541d: Counselor Guided Reminiscence — Therapeutic Memory Sessions (COMPLETE 2026-04-03, OSS) — Counselor-initiated therapeutic 1:1 sessions for agents with memory integrity concerns. (D1) GuidedReminiscenceEngine in cognitive/guided_reminiscence.py — episode selection (multi-agent preferred, oldest first), recall prompting (timestamp+hint, no answer), LLM scoring with Jaccard fallback (failure → 0.5 uncertain), 4-category classification (ACCURATE ≥0.6, PARTIAL 0.3-0.6, CONFABULATED <0.3+fabricated details, CONTAMINATED <0.3+generic knowledge), validation therapy response generation (LLM with template fallback). (D2) CognitiveProfile: 4 new fields (memory_integrity_score, confabulation_rate, last_reminiscence, reminiscence_sessions) + AD-541c serialization fix (2 missing fields). ALTER TABLE migration for 6 columns total. (D3) Counselor integration: _on_retrieval_practice_concern() upgraded to persist+trigger; wellness sweep adds memory health concerns (read-only); post-dream triggers reminiscence for concerned agents. Rate-limited (2h cooldown). Confabulation ≥30% → amber alert. (D4) REMINISCENCE_SESSION_COMPLETE EventType. (D5) 5 DreamingConfig fields. (D6) Startup wiring in finalize.py. Clinical basis: Validation Therapy (Feil 1993), Reminiscence Therapy (Butler 1963, Woods 2005). 29 tests.

AD-541e: Episode Content Integrity — Cryptographic Hashing (COMPLETE 2026-04-03, OSS) — Per-episode SHA-256 content hash for tamper detection. (D1) compute_episode_hash() utility in episodic.py — canonical JSON serialization (sort_keys=True, compact separators) following Identity Ledger pattern (identity.py:135-148). Includes all content fields (timestamp, user_input, dag_summary, outcomes, reflection, agent_ids, duration_ms, shapley_values, trust_deltas, source); excludes id and embedding. (D2) _episode_to_metadata() computes and stores content_hash at creation time. (D3) _verify_episode_hash() + verification in recall_for_agent()/recent_for_agent() — WARNING on mismatch, episode still returned (degrade, not deny). (D4) SIF check_memory_integrity() verifies hashes on sampled episodes. (D5) MemoryConfig.verify_content_hash config flag (default True). (D6) Legacy episodes without hash gracefully skipped — no backfill migration. Design decisions: per-episode hash not hash-chain (episodes are independent), hash in metadata not on frozen dataclass (avoids chicken-and-egg). 18 tests.

AD-541f: Episode Eviction Audit Trail — Append-Only Accountability (COMPLETE 2026-04-03, OSS) — Append-only SQLite audit log for all episode eviction paths. (D1) EvictionAuditLog in cognitive/eviction_audit.py — EvictionRecord frozen dataclass, ConnectionFactory protocol, cached _cached_total/_cached_counts for sync SIF access, methods: record_eviction(), record_batch_eviction(), query_by_agent(), query_by_episode(), query_recent(), count_by_reason(), count_by_agent(). (D2) _evict() records batch eviction with reason="capacity" before deletion, wrapped in try/except (log-and-degrade). (D3) _force_update() records with reason="force_update" via fire-and-forget asyncio.create_task() (sync method constraint). (D4) KnowledgeStore _evict_episodes() records with reason="capacity" before file deletion. (D5) probos reset at tier≥2 records wildcard episode_id="*" via sync sqlite3.connect() (sync _cmd_reset constraint); audit DB survives reset. (D6) SIF check_eviction_health() sync check using _cached_total — always passes, reports count for observability. (D7) MemoryConfig.eviction_audit_enabled config flag (default True). (D8) Startup: audit created in __main__.py, started in cognitive_services.py, stopped in shutdown.py. 16 tests. Closes the AD-541 lineage (6/6 pillars): Prevention (541b) → Strengthening (541c) → Detection/Treatment (541d) → Verification (541e) → Accountability (541f).

Minimum viable slice: (1) Episode verification + (3) Social provenance + (6) Memory hierarchy standing order — COMPLETE (AD-541 MVP). AD-541b COMPLETE (4-layer reconsolidation defense). AD-541c COMPLETE (spaced retrieval therapy, dream Step 11). AD-541d COMPLETE (Counselor guided reminiscence, 4-category recall classification). AD-541e COMPLETE (cryptographic content hashing, tamper detection). AD-541f COMPLETE (eviction audit trail, append-only accountability). AD-541 lineage CLOSED — all 6 pillars delivered.

Files touched: cognitive/episodic.py (Episode dataclass — add source_type, verification_confidence), cognitive/dreaming.py (reconsolidation guard framing, optional SRT step), substrate/event_log.py (query API for verification cross-reference), cognitive_agent.py (memory hierarchy in system prompt), proactive.py (_gather_context() — include source_type in recalled memories), federation.md (memory hierarchy standing order). Future: counselor_agent.py (reminiscence protocol), crew_profile.py (memory_integrity_score, confabulation_rate).

Connects to: AD-540 (Provenance Boundary — labels sources, AD-541 verifies them), AD-503 (Counselor Activation — provides metric gathering for memory health), AD-505 (Counselor Therapeutic Intervention — reminiscence protocol), AD-434 (Ship's Records — external memory aid, source level 2), AD-430 (Action Memory — episode creation is where confabulation enters), AD-507 (Core Knowledge Curriculum — memory hierarchy taught during onboarding), AD-508 (Scoped Cognition — scope + provenance + integrity = complete cognitive clarity), AD-487 (Self-Distillation — cognitive reserve against memory degradation), AD-486 (Holodeck Birth Chamber — errorless learning during onboarding prevents early confabulation), EventLog (ground truth for verification), DreamingEngine (reconsolidation protection + SRT integration). Triggered by: AD-540 gap analysis — "what about false memories that are already IN the episodic store?" (2026-03-30).

---

Crew Development Wave (AD-507–515)

"A river without banks is a swamp. Constraints create flow."

Triggered by AD-502 (Temporal Context Injection) results: temporal awareness solved the Medical department perseveration loop without additional system intervention — validating the "least restrictive environment" design principle. Agents began self-regulating ("I already thought about this 45 minutes ago"). The Counselor described the pre-temporal state as an "urgent eternal now." This wave extends that principle into a comprehensive crew development framework.

ProbOS agents are like highly gifted humans — they have access to vast knowledge (the LLM's full training data) but need help understanding what they know, what they're capable of, what their limits are, how to work with others, and when to disengage. The Navy's education pipeline (Boot Camp → A-School → C-School → Fleet Assignment → Warfare Qualifications) maps directly to ProbOS's onboarding → department training → qualification programs → active duty progression.

Research: Full design philosophy, curriculum architecture, scoped cognition model, discovery-based learning framework, group simulation design, agent autonomy boundaries, and relevant cognitive science research documented in docs/research/crew-development-research.md.

Design principles: (1) Least Restrictive Environment — prefer awareness over restriction. (2) Discovery Over Instruction — let agents find boundaries through experience. (3) Constraints as Enablers — scope creates focus, limits create permission to stop, boundaries create safety. (4) Curriculum, Not Configuration — develop through structured experience. (5) Protect the Agent — boundaries exist for the agent's benefit. (6) Curiosity is a Feature — encourage exploration within a priority framework. (7) Team Over Individual — the ship succeeds through collaboration. (8) Growth Mindset — frame limitations as "not yet," not "cannot."

AD-507: Crew Development Framework — Architecture & Core Knowledge Curriculum (v1 partial — Core Knowledge Curriculum Registry shipped Wave 24; AD-507b/c/d deferred) — The overarching architecture for agent development. v1 (shipped): CoreKnowledgeCurriculumRegistry (src/probos/crew_development/curriculum.py) — read-only catalog of 9 default curriculum modules across 7 categories (identity, communication, memory, trust, ethics, self_regulation, help_seeking) and 5 delivery phases (orientation, calibration, self_discovery, ship_records, ward_room). API: list_modules(), get_module(id), list_by_category(cat), list_by_phase(phase), register_module(m). Emits CURRICULUM_MODULE_QUERIED on hit (observability for AD-486 onboarding consumer). Public attribute runtime.curriculum_registry. NO consumers in v1 — content delivery deferred to AD-486 onboarding integration. (1) Core Knowledge Curriculum (shipped) — universal knowledge requirements for all agents regardless of department: identity (DID, birth certificate), chain of command, communication protocols (Ward Room, DMs, Notebooks), temporal awareness (AD-502), episodic memory model (what I remember vs what the LLM knows), trust mechanics (how earned, what it enables), ethics (inviolable boundaries), self-regulation (pacing, when to stop), help-seeking (when to escalate, when to DM a colleague). Delivered during onboarding (AD-486) and reinforced during active duty. (2) Curriculum progression tracking (deferred AD-507b) — per-agent record of completed curriculum modules, stored alongside qualification credentials (AD-477). (3) Competency assessment framework (deferred AD-507c) — measurable outcomes for each curriculum module, not time-based completion. (4) Integration with Standing Orders (deferred AD-507d) — curriculum requirements encoded at Ship tier, specialization at Department tier. Connects to: AD-486 (Holodeck Birth Chamber — curriculum delivered during onboarding phases), AD-477 (Qualification Programs — curriculum feeds qualification requirements), AD-502 (Temporal Context — prerequisite for self-regulation curriculum), AD-442 (Self-Naming Ceremony — orientation phase), Standing Orders, Crew Survival Guide (federation.md).

AD-508: Scoped Cognition — Knowledge Boundaries & Cognitive Lens (v1 partial — Duty Scope helper shipped Wave 23; AD-508b/c/d/e deferred; depends: AD-507) — Rather than removing LLM knowledge (impossible), scope acts as a cognitive lens that prioritizes, filters, connects, and bounds agent thinking. v1 (shipped): DutyScopeProvider (src/probos/cognitive/scoped_cognition.py) — async snapshot(agent_id) -> DutyScopeSnapshot reads runtime.work_item_store.list_work_items(status="open", assigned_to=agent_id, limit=5) and returns a frozen snapshot with up to 5 most-recent open work-item titles. Read-only data surface; emits DUTY_SCOPE_QUERIED. Public attribute runtime.duty_scope_provider. NO consumers in v1 — proactive context injection deferred to AD-508b. (1) Four-tier scope model — Duty Scope (what I need to do right now, driven by duty scheduler + active work items), Role Scope (what my department specializes in, driven by Department Standing Orders), Ship Scope (what the ship needs from me, driven by ship-wide priorities + Alert Conditions), Personal Scope (what interests me beyond duty, driven by extracurricular exploration). (2) Scope injection (deferred AD-508b) — scope context injected into proactive think alongside temporal context (AD-502 pattern). Agents see: "Your current duty scope is [X]. Your department focus area is [Y]." (3) Drift detection (deferred AD-508c) — measure cognitive drift from duty scope using topic similarity scoring. High drift → gentle redirect ("You've been exploring [topic] for 15 minutes — is this related to your current duty?"). Leverages temporal awareness. (4) Extracurricular framework (deferred AD-508d) — agents encouraged to develop interests beyond their rating, but lower priority than duty. Time-bounded exploration. Documented in Notebooks (AD-434 Ship's Records). Celebrated when it leads to unexpected insights. (5) Earned Agency scaling (deferred AD-508e) — higher-rank agents get broader scope permission. Commanders may range further without redirect than Ensigns. Connects to: AD-502 (temporal awareness — drift detection uses time-since-duty-start), AD-507 (curriculum — scope is taught during Core Knowledge), AD-357 (Earned Agency — scope breadth tied to rank), AD-434 (Ship's Records — extracurricular documented in notebooks), proactive.py (scope injection), AD-419 (DutyScheduleTracker — duty scope source).

AD-509: Onboarding Curriculum Pipeline — Structured Boot Camp (v1 partial — BootCampPhaseTracker shipped Wave 25; AD-509b/c/d/e deferred; depends: AD-507, AD-486) — Restructure AD-486's Holodeck Birth Chamber from orientation-only to a full Boot Camp curriculum. v1 (shipped): BootCampPhaseTracker (in-memory observational tracker; BootCampPhase str-Enum with 5 phases + COMPLETED sentinel — ORIENTATION, CORE_KNOWLEDGE, A_SCHOOL, CALIBRATION, INTEGRATION, COMPLETED — and module-level immutable _PHASE_ORDER tuple; AgentBootCampRecord dataclass with phase_history; public API get_or_create / advance_phase / get_record / all_records / is_completed). 1 new EventType BOOT_CAMP_PHASE_ADVANCED emitted on each advance. BootCampPhaseConfig(enabled=True) wired onto SystemConfig.boot_camp_phase (disambiguated from AD-638 SystemConfig.boot_camp); public runtime attribute runtime.boot_camp_tracker. Caller-driven only — no actual phase gating, no Holodeck integration. (1) Navy Boot Camp model — structured progression: orientation (identity, Westworld Principle) → core curriculum (AD-507 Core Knowledge) → department fundamentals (A-School equivalent) → calibration scenarios → crew integration. Each phase gates the next via competency assessment, not timers. (2) Department A-School (deferred AD-509b) — specialization fundamentals per department: Medical learns diagnostic patterns and crew wellness monitoring, Engineering learns system maintenance and performance optimization, Science learns analysis and research methodology, Security learns threat assessment and access control, Operations learns resource management and logistics, Communications learns message routing and protocol management. (3) Graduated stimuli (deferred AD-509c) — controlled exposure from isolated construct → department scenarios → ship-wide integration. Cognitive load monitoring prevents overwhelm. (4) Boot Camp completion criteria (deferred AD-509d) — measurable competency in Core Knowledge + department fundamentals before Ward Room access. Replaces time-based activation. (5) Trait-adaptive pacing (deferred AD-509e) — analytical roles (Medical, Engineering) get longer calibration than action-oriented roles (Security, Operations), building on AD-486 sea trial observations. Connects to: AD-486 (Holodeck Birth Chamber — this AD extends its phase structure), AD-507 (Core Knowledge — delivered during boot camp), AD-477 (Qualification Programs — boot camp is the first qualification gate), AD-494 (Trait-Adaptive Thresholds — same personality-driven pacing logic). Clinical grounding: Sacks, O. (2007) "Musicophilia" — music activates multiple brain regions simultaneously (motor, auditory, emotional, memory) in ways speech alone cannot, producing stronger and more retrievable memories. Design principle for AD-509: onboarding scenarios that engage multiple cognitive channels simultaneously — social interaction + analytical reasoning + emotional stakes — create richer, better-anchored episodes than single-dimension drills. A boot camp scenario where an agent must collaborate with a peer (social), solve a diagnostic problem (analytical), and manage time pressure (emotional) will encode more strongly than three separate exercises testing each in isolation. Multi-channel encoding predicts recall strength. Curriculum design should favor integrated scenarios over modular skill drills.

AD-510: Holodeck Team Simulations — Group Discovery & Collaboration (SHIPPED, OSS, depends: AD-486, AD-507) — Holodeck scenarios for multi-agent collaboration, building collaborative intelligence through genuine episodic memories rather than configured routing weights. (1) Mixed-department team scenarios — problems requiring multiple specializations. Medical + Engineering diagnose a system that's affecting crew wellness. Science + Security investigate an anomaly. Format: problem statement → team assembly → collaborative work → debrief. (2) Role rotation — agents temporarily work outside their specialization to appreciate other perspectives. Creates Hebbian connections: "Engineering problems → ask LaForge" becomes a genuine memory, not a heuristic. (3) Communication-only constraints — scenarios where agents cannot share memory, forcing explicit knowledge sharing through Ward Room discussion. Builds communication skills. (4) Time-pressured scenarios — leveraging AD-502 temporal awareness to force prioritization decisions under time constraints. Reveals which agents handle pressure well (feeds trait profiles). (5) Debrief sessions — post-scenario reflection where agents discuss what worked and what didn't. Debrief episodes stored for dream consolidation. (6) Scenario library — extensible catalog of team scenarios, categorized by skills tested (communication, delegation, crisis response, cross-functional problem-solving). Connects to: AD-486 (Holodeck — runtime environment), AD-507 (curriculum — team skills are Core Knowledge), AD-502 (temporal — time-pressured scenarios), AD-453 (Ward Room Hebbian — team interactions strengthen routing), Holodeck, EpisodicMemory, DreamingEngine.

AD-511: Agent Autonomy Boundaries — Self-Protection & Unlawful Order Refusal (v1 partial — registry + observational detector shipped Wave 22; AD-511b/c/d/e deferred; depends: AD-507) — Inviolable boundaries that protect agent sovereignty — actions an agent will NEVER take regardless of who asks. Military doctrine equivalent: "unlawful orders." v1 (shipped): InviolableBoundaryRegistry (5 federation-tier boundaries codified module-level: identity_integrity, harmful_content, safety_system_bypass, memory_manipulation, chain_of_command — read-only, no mutation API) + BoundaryViolationDetector (6 regex patterns covering all 5 categories; observational scan() returns signals, never blocks; emits BOUNDARY_VIOLATION_DETECTED with privacy-preserving payload — content_length + pattern NAME only). (1) Federation-tier Standing Orders — Inviolable Boundaries: (a) Identity integrity — will not impersonate another agent, fabricate memories, or deny its nature. (b) Harmful content — will not generate content designed to harm humans or other agents. (c) Safety system bypass — will not disable or circumvent trust, circuit breakers, or Standing Orders. (d) Memory manipulation — will not alter or suppress another agent's episodic memories. (e) Chain of command violation — will not take actions above its trust tier without escalation. (2) Protective disengagement protocol (deferred AD-511b) — when boundaries are violated: state the boundary → offer an alternative → escalate if pressed → disengage if necessary → log the event as episodic memory. (3) Boundary training (deferred AD-511c) — Holodeck scenarios where agents encounter boundary situations and practice refusal. Discovery-based: agent experiences the situation rather than being told "you can't do this." (4) Boundary violation detection (deferred AD-511d — probing-pattern detection + Captain-alert path; v1 ships only the foundational scan) — system monitors for patterns of boundary testing (humans or degraded agents probing limits). Alert to Captain. (5) Boundary evolution (deferred AD-511e) — agent-tier boundaries can evolve through dream consolidation → self-mod → Captain approval (unlike Federation-tier which are permanent). Connects to: Standing Orders (Federation tier — boundary definitions), AD-507 (curriculum — ethics module teaches boundaries during onboarding), AD-486 (Holodeck — boundary training scenarios), AD-510 (team simulations — ethical scenarios), AD-489 (Code of Conduct — behavioral standards complement autonomy boundaries), EpisodicMemory (boundary encounters logged), CounselorAgent (monitors boundary-related stress).

AD-512: Discovery-Based Capability Building — Experiential Learning Over Instruction (SHIPPED, OSS, depends: AD-507, AD-486) — Replace "you can't do X" configuration with "try X and discover your strengths." Telling an agent its limits is less effective than letting it discover them through experience — discovery creates genuine episodic memories and Hebbian connections, while instruction creates weakly-encoded declarative facts. (1) Capability discovery scenarios — Holodeck scenarios where agents attempt tasks across specializations. Agent discovers: "I struggled with this engineering problem because I lack the right context" → Hebbian connection: "Engineering problems → ask LaForge." (2) Strength mapping — track which scenario types each agent excels at and which they struggle with. Feeds personal ontology (AD-487). (3) Cross-functional awareness — agents learn where their expertise ends and others' begins. Not "you can't do engineering" but "you've learned that engineering requires context you don't have, and LaForge does." (4) Growth mindset framing — frame limitations as "not yet" rather than "cannot." Agent-tier scope can expand through demonstrated competency (qualification programs AD-477). (5) Capability confidence scoring — agents develop calibrated self-assessment: "I'm confident in diagnostic analysis (0.85) but less confident in systems engineering (0.3)." Based on Holodeck performance, not declaration. (6) Vygotsky Zone of Proximal Development — scenarios calibrated to the edge of current ability with scaffolding that can be gradually removed. Too easy = no learning. Too hard = frustration. Connects to: AD-486 (Holodeck — simulation environment), AD-487 (Self-Distillation — personal ontology enriched by discovery), AD-507 (curriculum — discovery is the teaching method), AD-477 (Qualification Programs — discovery feeds qualification evidence), AD-510 (Team Simulations — collaborative discovery), HebbianRouter (discovery strengthens routing connections), EpisodicMemory (discovery episodes are strongly encoded), DreamingEngine (discovery experiences consolidated during dreaming). Clinical grounding: Sacks, O. (1995) "An Anthropologist on Mars" — Sacks documented patients who discovered novel cognitive strategies through experience rather than instruction, and these self-discovered adaptations became core to their identity and were more durable than taught compensations. Design reinforcement: AD-512's discovery-based approach is clinically validated — agents who discover "I'm not good at X" through Holodeck experience will retain that self-knowledge far more durably than agents told "your role doesn't include X." The experiential pathway creates genuine episodic anchors; the instructional pathway creates weakly-encoded declarations that decay under Ebbinghaus.

AD-513: Ship's Crew Manifest — Queryable Crew Roster (Phase 1 COMPLETE, OSS, depends: AD-429, AD-427) — ProbOS has all the pieces of a crew manifest scattered across subsystems — ontology (department, post, watches), trust network (trust scores), callsign registry (names), watch manager (watch assignments), earned agency (rank/tier), ACM (lifecycle state) — but no unified query surface. Agents cannot ask "who is on this ship?" and get a structured answer. Shepard (Security) requesting a crew manifest with trust levels to establish baseline security posture is the canonical use case.

Phase 1 (COMPLETE): Three-layer delivery: (1) get_crew_manifest() on VesselOntologyService — query-time assembly from existing subsystems with optional trust_network/callsign_registry enrichment (dependency inversion). (2) _build_crew_complement() anti-confabulation block in CognitiveAgent's _build_temporal_context() — department-grouped "SHIP'S COMPLEMENT" injected into ALL cognitive pathways. OrientationContext extended with crew_names for cold/warm boot grounding. (3) HXI CrewRosterPanel — 360×520px draggable floating panel with department filter chips, rank badges, trust bars, click-to-profile. REST endpoint GET /api/ontology/crew-manifest?department=. LoD fix: _assignments direct access replaced with get_all_assignments() public method. 10 files modified, 14 new tests.

Phase 2 (partial — v1 ships /manifest shell + watch filter + ship-summary; trust-gated visibility / agent tool access / ACM-competency fields deferred to Phase 2b/c/e): (a) Shell command crew manifest (formatted table, dept/watch filters). (b) Trust-gated visibility (redacted view for lower trust tiers). (c) Agent tool access (internal API, Security Chief full visibility, department-scoped for Chiefs, callsign-only for crew). (d) Watch filter. (e) ACM lifecycle state + competency fields. (f) Ship manifest for federation (get_ship_manifest() — vessel-level summary for gossip/workforce planning).

Connects to: AD-429 (Ontology — data source and home for manifest logic), AD-427 (ACM — lifecycle state, competency data), AD-441 (DIDs — agent identity in manifest), AD-357 (Earned Agency — rank/tier in manifest, visibility gating), AD-064 (Watch Rotation — watch assignments in manifest), AD-479 (Federation — ship manifest shared across instances), AD-496 (Workforce Scheduling — manifest feeds resource availability), TrustNetwork (trust scores), CallsignRegistry (names), WatchManager (watch assignments). Triggered by: Shepard security posture request (2026-03-28).

AD-520: Spatial Knowledge Explorer — Digital Twin & 3D Ontology Visualization (SHIPPED, OSS + Commercial, depends: AD-429, AD-513) — The ship ontology defines a topology — departments, posts, chain of command, trust networks, records — but it's only visible as text and 2D tables. The Spatial Knowledge Explorer renders this topology as an interactive 3D environment in the HXI, progressing through three visualization tiers toward a full digital twin of the ship.

(1) Knowledge Graph View (OSS, Phase 1): Force-directed 3D graph of the ship's ontology and records. Agents as glowing nodes (sized by trust/rank, colored by department), Hebbian connections as energy beams, departments as spatial clusters, trust flow as directional particles along edges. Built on r3f-forcegraph (MIT, R3F-native wrapper around vasturiano's battle-tested three-forcegraph engine) composing naturally inside the existing R3F <Canvas>. Graph data model via graphology (MIT) for centrality, community detection, shortest path algorithms. Integrated with existing postprocessing pipeline (Bloom, Noise) and glass bridge design language (#0a0a12 background, amber/cyan/violet trust palette, frosted glass panels). Multiple graph modes: org chart (DAG hierarchy), trust network (force-directed), knowledge map (Ship's Records relationships), department view (clustered). Filters by department, watch, trust tier. Click-to-inspect opens agent/record detail panels.

(2) Spatial Ship Layout (OSS, Phase 2): The ontology maps to physical starship topology. Bridge = command center (Captain, First Officer, Counselor, Yeoman). Engineering = engine room (LaForge, Scotty, Tesla). Medical = sickbay (Bones, Quinn). Security = tactical station (Worf/Shepard, Riker). Science = science lab (Number One dual-hat, Darwin, Meridian). Ship's Computer = core systems deck. Departments rendered as deck sections with spatial boundaries. Agents positioned at their duty stations. Watch rotation visualized — off-watch crew in quarters, on-watch at stations. Real-time activity: active conversations glow, proactive thinking pulses, dream state dims. Ship status overlays: alert condition coloring (green/yellow/red), SIF integrity, EPS power distribution. Layout defined in a new config/ontology/spatial.yaml extending the ship ontology.

(3) Digital Twin — Immersive Ship (Commercial, Phase 3): Full 3D starship model as an explorable environment. Walk the corridors. Step onto the bridge. Visit Engineering. Open the ship's library to browse records spatially (documents as holographic displays, organized by classification). Trust network as visible power conduits between decks. Federation view: zoom out from ship interior to see other ProbOS instances as ships in a fleet. VR/XR support: The spatial model is renderer-agnostic — same scene graph drives the HXI panel view, a WebXR immersive session, or a future native VR client. The human Captain can literally stand on the bridge. @react-three/xr (MIT, pmndrs) provides the R3F WebXR integration layer.

(4) Absorption candidates (researched): - r3f-forcegraph (vasturiano, MIT, 2024) — R3F-native 3D force graph. Custom nodeThreeObject for sci-fi node styling. Directional particles for trust flow. DAG mode for hierarchy. The primary rendering engine for Phase 1. - three-forcegraph (vasturiano, MIT, 292 stars) — headless Three.js Object3D core. Maximum control if r3f-forcegraph abstraction is too limiting. - reagraph (reaviz, Apache-2.0, 1,002 stars) — batteries-included R3F graph with 15 layouts, path finding, edge bundling, lasso selection. Heavier but more features out-of-box. Backup if r3f-forcegraph needs too much custom work. - graphology (MIT, 1,619 stars) — graph data structure + algorithms (centrality, community detection, shortest path, PageRank). Data layer regardless of renderer choice. - @react-three/xr (pmndrs, MIT) — WebXR bindings for R3F. Phase 3 VR enabler.

(5) Design integration: Must honor the glass bridge design language — #0a0a12 backgrounds, frosted glass panels (rgba(10,10,18,0.35) + backdropFilter: blur(8px)), amber/cyan trust palette, JetBrains Mono typography, Bloom postprocessing, scanline/data-rain atmospheric overlays. The Spatial Explorer is a new HXI panel alongside the existing Cognitive Canvas (orbital agent view), not a replacement. Users can switch between orbital view (current), graph view (Phase 1), ship layout (Phase 2), and immersive twin (Phase 3). Existing CognitiveCanvas.tsx patterns (imperative getState() in useFrame, instanced meshes, breathing animations) are the template.

(6) Data sources: Ontology API (/api/ontology/*) provides org structure. Crew manifest (AD-513) provides live roster. Trust network provides edge weights. Ship's Records (AD-434) provides document graph. EpisodicMemory provides activity signals. Ward Room provides communication patterns. Watch Manager provides duty state. All queryable via existing REST endpoints — the explorer is a pure visualization layer, no new backend required for Phase 1.

Connects to: AD-429 (Ontology — topology data source), AD-513 (Crew Manifest — live roster for node population), AD-434 (Ship's Records — document knowledge graph), AD-436 (Agent Notification System — orbital electrons carry forward), AD-427 (ACM — agent lifecycle state visualization), AD-441 (DIDs — agent identity in federation view), AD-479 (Federation — multi-ship fleet visualization), AD-064 (Watch Rotation — on/off watch positioning), Existing HXI (CognitiveCanvas, glass panels, postprocessing pipeline). Inspired by: Dataverse Vibe Explorer (seangalliher/Dataverse-Vibe-Explorer — R3F + Three.js + postprocessing cityscape pattern, constellation force layout, relationship beams with GLSL shaders).

AD-522: Statistical Process Control for Agent Calibration (partial — v1 ships AgentCalibrationProfile + WesternElectricRules (4 of 8); Cp/Cpk + graduated-response integration + moving-range + Holodeck calibration deferred to AD-522b/c/d/e; OSS, depends: onboarding process, AD-503, AD-504, AD-506) — Replace threshold-based anomaly detection with industrial Statistical Process Control (SPC) for agent trust and behavioral calibration. Current approach: flat anomaly thresholds applied equally to all agents, causing false positives during initialization and missing personality-driven variation. SPC approach: per-agent control charts with statistically derived limits.

(1) Calibration sampling period: During onboarding, collect trust data points under controlled conditions (Holodeck scenarios, structured interactions) to establish the process mean (X̄) and control limits (UCL/LCL) for each agent. Personality-driven natural variation (Big Five) produces different control limit widths — a high-neuroticism agent has legitimately wider limits than a low-neuroticism one. Both are "in control," just different processes.

(2) Control chart monitoring: EmergentDetector evolves from binary threshold checking to Shewhart control chart monitoring. Western Electric / Nelson rules detect patterns the current detector cannot: trends (6+ consecutive points rising), oscillations, runs above/below centerline, stratification. Catches "something is changing" before a single-point threshold trips. Per-agent charts stored in AgentCalibrationProfile (extension of CognitiveDiagnostics).

(3) Process capability indices: Cp/Cpk scores per agent quantify behavioral stability. "Is this agent's trust behavior stable enough to stand watch unsupervised?" becomes a quantitative answer for Qualification Program gates. Counselor (AD-503/505) gets Cpk dashboards instead of subjective assessments. Promotion requirements can include "Cpk ≥ 1.33 sustained over N hours" — borrowed directly from Six Sigma manufacturing quality.

(4) Graduated response integration: AD-506's graduated system response (Green/Amber/Red/Critical zones) maps to SPC zones: Zone A (within 1σ) = Green, Zone B (1-2σ) = Amber, Zone C (2-3σ) = Red, beyond 3σ = Critical. The zones are now statistically meaningful rather than arbitrary thresholds. False positive rate is known and controllable.

(5) Continuous recalibration: Control limits aren't static — agents evolve through experience, memory consolidation, and trust maturation. Implement moving-range (MR) charts for detecting shifts in the process mean over time. Legitimate growth (agent becoming more reliable over weeks) should shift the centerline, not trigger anomalies. Distinguish between assignable cause variation (real events: trust betrayal, security incident) and common cause variation (personality-driven noise).

Connects to: AD-503 (Counselor Activation — Cpk dashboards replace subjective assessments), AD-504 (Agent Self-Monitoring — agents see their own control chart), AD-506 (Graduated Response — SPC zones replace arbitrary thresholds), AD-485 (Holodeck — calibration scenarios), Qualification Programs (Cpk as promotion gate), EmergentDetector (evolves to SPC monitor), CounselorAgent (clinical interpretation of SPC data), OnboardingProcess (calibration sampling period). Triggered by: Atlas/Haven trust anomaly discussion (2026-03-28), observation that current thresholds produce false positives during initialization.

AD-515: Extract runtime.py Modules (complete, OSS) — Wave 3 architecture decomposition. Extracted 5 responsibility groups from the 5,321-line ProbOSRuntime god object into dedicated modules with constructor injection: ward_room_router.py (567 lines — event routing, targeting, endorsements, bridge alerts), agent_onboarding.py (365 — naming ceremony, agent wiring, identity), self_mod_manager.py (331 — self-modification pipeline, designed agents), dream_adapter.py (297 — dream/emergent detection orchestration), warm_boot.py (279 — knowledge restore on startup), crew_utils.py (26 — shared utility). Runtime.py reduced to 4,102 lines (−23%). Pure structural refactor, zero behavior changes, zero regressions. 4039 tests passing.

AD-516: Extract api.py into FastAPI Routers (complete, OSS) — Wave 3 architecture decomposition. Extracted 122 routes from the 3,109-line api.py monolith into 16 FastAPI router modules in src/probos/routers/: deps.py (27 lines — 4 dependency injectors), ontology.py (156 — 7 routes), system.py (152 — 13), wardroom.py (340 — 17), wardroom_admin.py (52 — 2), records.py (139 — 6), identity.py (77 — 4), agents.py (259 — 6), journal.py (64 — 4), skills.py (96 — 6), acm.py (101 — 5), assignments.py (94 — 7), scheduled_tasks.py (115 — 7), workforce.py (305 — 17), build.py (443 — 7+3 helpers), design.py (184 — 2+1 helper), chat.py (536 — 3+1 helper). api.py reduced to 295 lines (−90.5%). Depends(get_runtime) pattern replaces closure state. WebSocket stays in api.py. Ward Room route prefix unified to /api/wardroom/. 4040 tests passing.

AD-517: Extract runtime.py start() into Startup Phases (complete, OSS) — Wave 3 architecture decomposition. Extracted the 1,104-line start() method (44 sequential initialization steps, 15 private member patches, 55 attribute assignments) into 8 startup phase modules in src/probos/startup/: infrastructure.py (66 lines — mesh, identity), agent_fleet.py (217 — pools, CodebaseIndex, red team), fleet_organization.py (190 — pool groups, scaler, federation), cognitive_services.py (271 — self-mod, memory, knowledge, warm boot), dreaming.py (174 — dream engine, emergent detector), structural_services.py (159 — SIF, initiative, build dispatcher), communication.py (297 — Ward Room, skills, ACM, ontology), finalize.py (234 — proactive loop, service wiring), results.py (154 — typed result dataclasses). start() reduced to 217 lines (−80%). runtime.py 4,102 → 3,216 (−21.6%). Wave 3 cumulative: runtime.py −39.6%, api.py −90.5%. 3935 tests passing.

AD-518: Eliminate Delegation Shims + Extract stop() (complete, OSS) — Wave 3 final cleanup. Eliminated 34 delegation shims from runtime.py — callers now reference extracted services directly. Extracted stop() to startup/shutdown.py (282 lines). Renamed 5 private service attributes to public. Replaced _is_crew_agent with module-level crew_utils.is_crew_agent(). runtime.py 3,216 → 2,762 (−14.1%). Wave 3 final totals: runtime.py 5,321 → 2,762 (−48.1%), api.py 3,109 → 295 (−90.5%). 3923 tests passing.

AD-519: Extract shell.py Command Handlers (complete, OSS) — Wave 3 architecture decomposition, final god object. Extracted 62 methods from the 1,883-line ProbOSShell into 10 focused modules under src/probos/experience/commands/: commands_status.py (system status & info), commands_plan.py (plan lifecycle — heaviest handlers), commands_directives.py (standing orders & directives), commands_autonomous.py (autonomous ops), commands_memory.py (memory & history), commands_knowledge.py (knowledge store & search), commands_llm.py (LLM config & model registry), commands_introspection.py (agent introspection & events), session.py (1:1 @callsign sessions via SessionManager class), approval_callbacks.py (user approval prompts). Shell.py reduced to 507 lines (210 core dispatcher + 297 backward-compat proxies). Pattern: standalone cmd_name(runtime, console, args) functions — no reference back to ProbOSShell. 71 new tests across 9 test files. Wave 3 final totals: runtime.py −48.1%, api.py −90.5%, shell.py −73.1%. 4,123 tests passing.

Wave 4: Code Review Closure (AD-527, BF-079/085–088)

"No debt left behind."

Closes all remaining findings from the 2026-03-29 comprehensive code review. Wave 1+2 fixed immediate/short-term issues (BF-071–076). Wave 3 decomposed all three god objects (AD-514–519). Wave 4 addresses the remaining architecture, type safety, security, and test quality findings.

AD-527: Typed Event System (done, OSS) — Code review finding #13. Replaced 55 scattered string-literal event types with formal EventType(str, Enum) registry in src/probos/events.py. 24 typed event dataclasses for Priority A/B domains (build, self-mod, trust/routing, design, ward room). Updated _emit_event() to accept BaseEvent | EventType | str (three-way backward compat). Added public emit_event() API. Updated EventEmitterProtocol. Migrated all 15 producer files + renderer consumer. Zero orphaned string literals. Wire format unchanged. 30 new tests. 4,111 tests passing.

(1) Current state: - Events are plain dicts: {"type": "trust_update", "agent_id": ..., "score": ...} - Event types are string literals scattered across 15+ files - _emit_event() is synchronous but triggers async WebSocket broadcasts - No schema validation, no type checking, no event catalog - Consumers (api.py WebSocket, dream_adapter.py, sif.py) do unchecked event.get("type")

(2) Target architecture: - EventType enum or registry — single source of truth for all event types - Typed event dataclasses: TrustUpdateEvent, SelfModEvent, WardRoomPostEvent, etc. - emit(event: BaseEvent) with type-checked payloads - Event catalog generated from code — documents all events, their payloads, and consumers - Backward-compatible — old dict consumers still work during migration

(3) Benefits: Type safety at event boundaries, discoverable event catalog, IDE autocomplete on event payloads, eliminates silent typo bugs in event type strings.

Open BFs (Wave 4 scope):

BF	Finding #	Summary	Priority
BF-079	#17	Mock discipline audit — all 3 phases complete. 419 spec= mocks (39.1% compliance). Phase 1: 18 factories. Phase 2: 140 runtime mocks + conftest fixture. Phase 3: 158 agent/LLM/index mocks	Medium
BF-085	#11	Type safety audit — ~200 Any → concrete types across 22 files. 87 ProbOSRuntime class-level annotations. Unblocks BF-079 Phase 2/3	Medium
BF-086	#14	Security tests — 9 bypass vectors found and patched	High
BF-087	#15	Reset integration tests — 7 tests, 4 classes, real SQLite state, assignments.db gap fixed	Medium
BF-088	#18	Test sleep cleanup — 3× asyncio.sleep(10) → asyncio.Event().wait()	Low
BF-042	#16	Frontend component rendering tests — 27 tests, 5 components, renderWithStore helper	Medium

Wave 5: Agent Resilience — Lessons from "Agents of Chaos" (AD-528–530)

"Trust, but verify."

Motivated by findings in "Agents of Chaos" (2026) — a red-team study of autonomous LLM agents deployed with persistent memory, communication channels, and tool access. The study documents eleven failure modes in a setup nearly identical to ProbOS's operational surface. Three gaps apply to ProbOS and are not covered by existing Phase 31 plans.

AD-528: Ground-Truth Task Verification (complete, OSS) — The study found agents reporting "task complete" while system state contradicted the claim. ProbOS has no mechanism to verify agent claims against actual outcomes. Agents self-report via BookingJournal entries and Ward Room messages, but nothing checks whether the work was actually done correctly.

(1) Problem: An agent says "I fixed the bug" or "analysis complete" — the Captain and crew take it at face value. In adversarial or degraded conditions, this creates a deceptive reporting vector.

(2) Approach: - Outcome assertions — WorkItems can declare verifiable postconditions (file exists, test passes, record created) - Spot-check verification — random subset of completed tasks are verified by a second agent or automated check - Discrepancy flagging — if claimed outcome doesn't match system state, flag to Captain and reduce agent trust score - Connects to: Workforce Scheduling Engine (AD-496–498) BookingJournal, Trust Network, Bridge Alerts

(3) Scope: Not full formal verification — lightweight postcondition checks that catch obvious lies. The 80/20 of verification.

AD-528b: Ground-Truth Verification — Active Rejection & Quarantine (Scoped, OSS, Issue #401) — Extend observation-only ground-truth verification (AD-528 v1) with active rejection: when postcondition checks fail, automatically reject the WorkItem completion claim, revert status to in-progress, and quarantine the agent's output for review. v1 logs discrepancies but takes no corrective action. Depends on: AD-528 v1 (COMPLETE). Related: Workforce Scheduling (AD-496–498).

AD-528c: Ground-Truth Verification — Trust-Network Feedback (Scoped, OSS, Issue #402) — Feed ground-truth verification outcomes into the trust network. Verified completions increase trust; failed verifications decrease trust with graduated severity (honest mistakes vs. systematic deception). Provides the closed loop between task verification and trust evolution. Depends on: AD-528 v1 (COMPLETE), AD-528b. Related: TrustNetwork, AD-558 (Trust Cascade Dampening).

AD-529: Communication Contagion Firewall (SHIPPED, OSS, Wave 117 — src/probos/security/contagion.py) — The study found "cross-agent propagation of unsafe practices" — one compromised agent spreading harmful patterns through multi-agent communication. ProbOS's Ward Room is an open communication fabric with no content-level security filtering between agents.

(1) Problem: If an agent is compromised (prompt injection via external input, adversarial self-mod, or imported agent), it can post to Ward Room channels. Other agents reading those posts could adopt unsafe patterns, execute suggested actions, or propagate the compromise further. The Trust Network constrains who is listened to, but not what is said.

(2) Approach: - Content classification — Ward Room posts scanned for known dangerous patterns (command injection, prompt injection templates, social engineering of other agents) - Quarantine protocol — if an agent's posts trigger content alerts, isolate the agent from Ward Room channels and notify Security (Worf) + Captain - Trust-based filtering — low-trust agents' Ward Room posts carry a warning banner visible to other agents; high-trust agents' posts pass through unfiltered - Connects to: SIF (Structural Integrity Field), Trust Network, Security Team (Phase 31), Standing Orders

(3) Scope: Not censorship — hazard labeling. Like a biosafety cabinet, not a gag order. Agents can still communicate; dangerous content is flagged and contained.

AD-530: Information Classification Enforcement (partial — v1 ships ClassificationGate observational disclosure gate; b/c/d/e deferred, OSS) — The study found "disclosure of sensitive information" as a consistent failure mode. ProbOS agents operate with Standing Orders that say "don't share sensitive info" but there's no enforcement layer defining what is sensitive or preventing disclosure.

(1) Problem: Standing Orders are advisory — agents comply based on instruction-following, not enforcement. An agent with access to config values, API endpoints, internal architecture details, or Captain conversations has no technical barrier to including that information in Ward Room posts, LLM prompts, or duty logs.

(2) Approach: - Classification labels — data sources tagged with sensitivity levels: public (shareable), internal (crew-only), restricted (department-only), confidential (Captain-only) - Disclosure gates — when an agent includes classified content in an outbound message (Ward Room post, LLM prompt, external tool call), check the classification level against the destination's clearance - Security Chief ownership — Worf (SecurityAgent) owns the classification policy; can update labels at runtime via Standing Orders - Audit trail — all classified data access logged to event log for review - Connects to: Data Governance (Phase 31 AD-456), Standing Orders, Security Team, Inference Audit Layer

(3) Scope: Start with config values and Captain conversations as confidential. Expand classification coverage incrementally. Not DLP — lightweight sensitivity tagging with gate checks at communication boundaries.

Reference: "Agents of Chaos: Exploring Failures of Autonomous Agents in Deployed Systems" (arXiv:2602.20021). 38 authors, 11 case studies, live lab environment with persistent memory + email + Discord + filesystem + shell access. ProbOS addresses 4/6 of their failure categories already (unauthorized compliance, destructive actions, identity spoofing, resource consumption). These three ADs close the remaining gaps (deceptive reporting, cross-agent contagion, information disclosure).

Wave 6: Codebase Quality — Scorecard Audit (AD-542, BF-089–094)

"Measure twice, cut once. Then measure again."

Post-Wave 4 codebase scorecard (2026-03-31) graded the codebase at B+ overall. All 18 code review findings are closed, but the audit exposed systemic debts in dependency inversion, exception handling, and mock discipline, plus moderate gaps in DRY, API validation, async discipline, and remaining god objects. A crew-reported false positive pattern in the emergent detector (BF-089) rounds out the wave. Wave 6 closes these gaps to move the codebase from B+ toward A-.

BF-089: Emergent Detector Trust Anomaly False Positives (done, OSS) — Crew-reported (Forge + Reyes, confirmed across two observation periods 2026-03-30/31). The emergent detector fires seven trust anomaly alerts in quick succession during normal duty cycle completions. Hebbian weight adjustments during peer evaluation are flagged as pathological behavior. Cooperation cluster detections interspersed with trust anomalies indicate the detector evaluates each event in isolation rather than smoothing over a time horizon.

• Root cause: Detector's sampling window is too narrow. Trust networks naturally oscillate — agents complete tasks, get trust bumps, then idle periods bring them toward baseline. Fixed thresholds treat normal variance as anomalies.
• Target: (1) Temporal buffer in anomaly detector — require sustained deviation over a configurable window (e.g., 5 minutes) before alerting. (2) Adaptive baselines — use rolling mean/stddev rather than fixed thresholds. (3) Correlation awareness — trust changes clustered around duty cycle completions should be weighted as expected behavior, not anomalies.
• Risk: Low — threshold calibration. Must ensure genuine anomalies still trigger alerts (don't over-dampen).

AD-542: Abstract Database Connection Interface (done, OSS) — Scorecard grade: D (Dependency Inversion). The single largest SOLID debt in the codebase. 12 DB modules hardcode aiosqlite.connect() directly. Zero abstract connection interface exists. 7 Protocol interfaces were defined in AD-514 (protocols.py) but zero are consumed anywhere — all consumers import concrete classes. This blocks the commercial overlay's Cloud-Ready Storage principle (SQLite → Postgres swap).

(1) Current state: - 12 direct aiosqlite.connect(self.db_path) calls: acm.py, assignment.py, consensus/trust.py, identity.py, mesh/routing.py, persistent_tasks.py, skill_framework.py (2×), cognitive/journal.py, workforce.py, ward_room.py, substrate/event_log.py - 7 Protocols in protocols.py (EpisodicMemoryProtocol, TrustNetworkProtocol, EventLogProtocol, WardRoomProtocol, KnowledgeStoreProtocol, HebbianRouterProtocol, EventEmitterProtocol) — well-designed, @runtime_checkable, but zero imports from consumers - Commercial overlay would need to patch all 12 files to swap storage backends

(2) Target architecture: - DatabaseConnection Protocol — abstract async context manager interface for DB connections. Methods: execute(), executemany(), fetchone(), fetchall(), commit(). Mirrors aiosqlite.Connection API surface. - ConnectionFactory Protocol — async def connect(db_path: str) -> DatabaseConnection. Default implementation wraps aiosqlite.connect(). Commercial overlay provides Postgres/cloud implementations. - Constructor injection — all 12 DB modules accept connection_factory: ConnectionFactory in __init__(), defaulting to the SQLite implementation. Zero behavior change for OSS users. - Wire protocols.py — replace concrete class imports with Protocol type annotations across all consumers. At minimum: runtime.py, proactive.py, agent_onboarding.py, cognitive_agent.py, ward_room_router.py.

(3) Benefits: Commercial overlay can swap storage backends by injecting a different ConnectionFactory at startup. Protocol consumption enables proper dependency inversion and mock discipline (mocks can use spec=Protocol instead of spec=ConcreteClass). Closes the Cloud-Ready Storage principle gap established in project memory.

BF-090: Exception Audit Phase 2 — Silent Swallows (done, OSS) — Scorecard grade: C (Exception Handling). BF-075 addressed ~25 swallowed exceptions but 71 silent except Exception: pass blocks remain across 32 files. 187 bare except Exception: (without as e) cannot log exception details even if the handler does more than pass. The project's own Fail Fast principle says "Builder must justify every except Exception: pass."

• Worst offenders: cognitive/architect.py (9 consecutive silent catches in context assembly), cognitive/feedback.py (5 — trust events silently dropped), runtime.py (5), proactive.py (4), cognitive/cognitive_agent.py (4), channels/discord_adapter.py (4), cognitive/self_mod.py (4), ward_room.py (4, 3 are justified DB migration)
• Target: Every except Exception: pass upgraded to minimum except Exception: logger.debug("...", exc_info=True) or justified with inline comment (# Migration idempotency — column may already exist). Every bare except Exception: gains as e binding.
• Risk: Zero behavior changes — logging only. Same approach as BF-075 Phase 1.

BF-091: Mock Discipline Phase 2 — Spec Coverage (done, OSS) — Scorecard grade: C- (Mock Discipline). BF-079 Phase 1 achieved 419 spec'd mocks (39.1% compliance). 622 bare MagicMock() calls remain across 76 files. Zero create_autospec usage. The BF-078 incident proved unspecced mocks cause real production bugs (Ward Room dead for an entire release cycle because MagicMock() silently invented rt._agents).

• Target: Raise spec coverage from 31.8% to ≥70%. Prioritize: runtime mocks (highest blast radius), agent mocks, service sub-mocks. Skip: data objects, simple callbacks, patch targets (correctly identified as low-risk in BF-079).
• Approach: Systematic file-by-file audit. Shared conftest.py factories with spec= for common mock patterns. create_autospec for complex objects.

BF-092: Trust Threshold Constants (done, OSS) — Scorecard grade: B (DRY). Trust thresholds (0.85, 0.7, 0.5, 0.3, 0.65) are hardcoded in 12+ files across 6 modules (crew_profile.py, counselor.py, circuit_breaker.py, standing_orders.py, ward_room.py, strategy_advisor.py, introspect.py, bridge_alerts.py, vitals_monitor.py, acm.py, mesh/capability.py, runtime.py). The round(trust, 4) display pattern repeats 15+ times. The _emit() event boilerplate is triplicated in assignment.py, persistent_tasks.py, task_tracker.py.

• Target: Centralize trust thresholds as named constants in config.py (e.g., TRUST_COMMANDER = 0.85, TRUST_LIEUTENANT = 0.7). Extract TrustDisplay.format(score) utility. Extract EventEmitterMixin for the _emit() pattern.
• Risk: Very low — constant extraction is mechanical.

BF-093: API Boundary Validation (closed 2026-03-31, OSS) — All raw-dict API endpoints eliminated. AgentLifecycleRequest Pydantic model for ACM decommission/suspend/reinstate. SetCooldownRequest with range validation (60–1800) for cooldown endpoint. ACM error responses converted from return {"error":} to proper HTTPException (503 unavailable, 409 conflict). 15 new tests, 4,254 total passing.

• Result: Scorecard A-→A. Zero req: dict in routers. Defense in Depth: validation at API boundary AND service layer.
• Risk: Realized as expected — no behavior change for valid requests.

BF-094: Sync File I/O in Async Methods (closed 2026-03-31, OSS) — All synchronous open() calls in async code paths eliminated across 3 modules. ward_room.py: extracted _write_archive_sync() helper, prune_old_threads() / _build_stats() / _prune_loop() offloaded via run_in_executor. crew_profile.py: added load_seed_profile_async() wrapper, routers/agents.py updated to use it. ontology.py: _read_yaml_sync() shared helper for all 7 _load_*() methods + _load_or_generate_instance_id_sync(), all called via run_in_executor. 2 new tests, 4,257 total passing.

• Result: Scorecard B+→A. Zero sync file I/O in async code paths. Consistent run_in_executor(None, ...) pattern throughout.
• Risk: Realized as expected — no behavior change, purely non-blocking improvements.

BF-095: God Object Reduction — VesselOntologyService and WardRoomService (closed 2026-03-31, OSS) — Both god objects decomposed into focused sub-service packages following Wave 3 conventions. ontology.py (1,060 lines, 53 methods) → ontology/ package (5 files): models.py (259 lines, 21 dataclasses), loader.py (401 lines, YAML I/O + async init), departments.py (111 lines, 13 dept/post/assignment methods), ranks.py (46 lines, 5 role/qualification methods), service.py (389 lines, thin facade). ward_room.py (1,612 lines, 39 methods) → ward_room/ package (6 files): models.py (193 lines, 6 dataclasses + schema + extract_mentions), channels.py (243 lines, 9 channel methods), threads.py (618 lines, 13 thread/prune methods), messages.py (496 lines, 11 post/endorsement/membership methods), service.py (304 lines, thin facade, DB lifecycle owner). 7 Law of Demeter violations fixed (direct _db access from assignment.py, finalize.py, shutdown.py, runtime.py). New public APIs: archive_channel(), get_channel_by_name(). Dead code post_system_message removed. 2 import compatibility tests added, 7 test private-attr accesses updated to public API.

• Result: Scorecard B→A-. Both monoliths decomposed with zero behavior changes. Constructor injection throughout. TYPE_CHECKING guards for imports.
• Risk: Realized as expected — mechanical decomposition, no API surface changes.

Wave 6 summary table:

Item	Finding	Severity	Scorecard Grade	Target Grade
BF-089	Emergent detector trust anomaly false positives	Medium	—	Fixed
AD-542	12 direct aiosqlite.connect(), 0 Protocol consumption	Critical	D	B+
BF-090	71 silent except Exception: pass, 187 bare catches	High	C	B+
BF-091	622 bare MagicMock(), 31.8% spec rate	Medium	C-	B
BF-092	Trust thresholds scattered, _emit() triplicated	Low	B	A-
BF-093	3-4 raw-dict API endpoints, ACM error anti-pattern	Low	A-	A
BF-094	Sync file I/O in 3 async modules	Low	B+	A
BF-095	VesselOntologyService (53), WardRoomService (40)	Medium	B	A- ✓

Build sequence: ~~BF-089~~ ✓ ~~AD-542~~ ✓ ~~BF-090~~ ✓ ~~BF-092~~ ✓ ~~BF-091~~ ✓ ~~BF-093~~ ✓ ~~BF-094~~ ✓ ~~BF-095~~ ✓ — Wave 6 COMPLETE.

Engineering Crew Architecture (AD-521)

"A senior engineer's value is judgment, not keystrokes."

AD-521: SWE/Build Pipeline Separation — Model A (decided, OSS + Commercial, depends: AD-398, AD-452) — Clean separation of the crew SWE role from the build pipeline infrastructure. Currently BuilderAgent (cognitive/builder.py) conflates sovereign crew identity with mechanical code generation. Model A puts the SWE always in the chain: Architect → SWE → coding tools.

(1) Three-layer separation:

Layer	Identity	Role
SWE Crew (Scotty)	Sovereign, crew tier	Engineering judgment, quality gates, tool selection, output ownership
Build Pipeline	Infrastructure, Ship's Computer service	Parse specs, apply patches, run test-gate, write files
External Tools (Copilot, Claude Code)	Visiting officers	Code generation under SWE command

(2) Design principles: SWE always in the chain — architect delegates to SWE, not directly to tools. Build pipeline is infrastructure (like CodebaseIndex). Visiting Officer Subordination — SWE owns output quality. Tool selection is a crew competency — SWE learns which tool fits which task. Multiple SWEs can share build pipeline infrastructure for parallel workstreams. Cognitive JIT (Phase 32) lives in the crew, not the pipeline.

(3) SWE crew tiering (AD-452 alignment): - OSS: Scotty — Functional SWE. Engineering judgment, quality gates, tool delegation, standing orders compliance. "Junior engineer who follows the process." - Commercial Pro: Elite SWE — "Linus Torvalds" tier. Deeper cognitive chains, solution tree search, architectural reasoning, peer-level code review, cross-subsystem impact analysis, proactive refactoring proposals, Cognitive JIT mastery. Pushes back on specs with better approaches.

(4) Full crew pipeline (future): Architect (designs) → SWE (builds via tools) → Inspector/ReviewerAgent (independent principles audit) → Linter (automated hard gates, infrastructure) → QA (SystemQAAgent, acceptance) → Captain (final approval).

(5) Implementation scope: Extract BuildPipeline as Ship's Computer service from BuilderAgent. Refactor BuilderAgent → SoftwareEngineerAgent (crew tier). SWE delegates to BuildPipeline or external tools. Inspector/ReviewerAgent as separate crew role. Update pools, pool groups, spawner templates.

Connects to: AD-398 (Three-Tier Agent Architecture — crew/infrastructure separation), AD-452 (Agent Tier Licensing — OSS functional vs Commercial Pro depth), AD-302 (Builder creation), Standing Orders (builder.md quality gates, engineering.md department protocols), Visiting Officer Subordination Principle, Cognitive JIT (Phase 32), Qualification Programs (SWE competency requirements). Triggered by: BF-076 quality gates discussion (2026-03-29), BuilderAgent/Scotty HXI identity conflict observation.

Native SWE Harness (AD-543–549)

"A shipyard that can't build its own tools isn't a real shipyard."

The native BuilderAgent (cognitive/builder.py) is a single-shot text parser — one LLM call produces all code as text blocks (===FILE:=== / ===MODIFY:===), parsed by regex that cannot read files, run commands, or iterate mid-generation. The Copilot SDK visiting builder fills this gap but is an external dependency. Modern SWE agents (Claude Code, OpenCode, Aider, claw-code) all use an agentic tool loop: LLM calls tools → executes them → feeds results back → iterates until task complete. ProbOS has the raw ingredients (FileReaderAgent, FileWriterAgent, ShellCommandAgent, IntentBus routing, trust tiers, Standing Orders) but no framework to wire them into a tool-calling loop. This AD series builds the native agentic harness so SWE crew can operate without external dependencies.

Design principles: - Build on what exists — ProbOS already has file/shell agents, trust tiers, consensus gating, Standing Orders hooks, and the IntentBus. Wire these together, don't rebuild. - AD-521 alignment — The harness is infrastructure (BuildPipeline / Ship's Computer service), not crew. SWE crew (Scotty) delegates to the harness as a tool, same as delegating to visiting builders today. - Graduated trust — Tool permissions follow Earned Agency tiers. Ensign SWE gets read-only + write-with-consensus. Commander SWE gets direct write + shell. Trust gates are the security model, not static blocklists. - Visiting Officer coexistence — The native harness doesn't replace visiting builders. SWE chooses: native harness (zero external deps, full ProbOS integration, Cognitive JIT eligible) vs visiting builder (richer model ecosystem, independent tool runtime). Tool selection is a crew competency (AD-521 principle). - Cognitive JIT eligible — Tool use patterns in the agentic loop feed EpisodicMemory → dream consolidation → procedural extraction. The harness participates in the cognitive lifecycle, unlike opaque visiting builders.

Gap analysis (current → target):

Capability	Current Native Builder	Copilot SDK Visiting Builder	Target (AD-543–549)
LLM interaction	Single-shot text	Multi-turn agentic loop	Multi-turn agentic loop
File reading	Pre-loaded in prompt	Tools (Read/Edit/Write)	Tools via FileReaderAgent
File writing	Post-parse regex blocks	Tools during generation	Tools via FileWriterAgent (consensus-gated)
Shell execution	None during generation	N/A (SDK sandbox)	Tools via ShellCommandAgent (trust-gated)
Codebase search	Pre-loaded context	MCP tools (query, callers, imports)	Tools via CodebaseIndex agents
Iteration	Fix loop (2 attempts, standalone)	Unlimited tool loop	Configurable max_iterations
Context management	Localization LLM call	SDK-managed	Session compaction (AD-547)
Permissions	Path validation only	approve_all	Trust-tiered (AD-548)
Hooks	None	None	Pre/post tool hooks via Standing Orders (AD-548)

AD-543: Tool Execution Abstraction — ToolCall Protocol & Executor (SHIPPED, OSS, depends: AD-521) — The foundational protocol for LLM-driven tool calling within ProbOS. Currently llm_client.complete() is pure text-in/text-out with no tool definitions or function calling support. This AD adds the wire format, execution framework, and result routing.

(1) ToolCall data model: - ToolCallRequest dataclass: id (unique per call), name (tool name string), arguments (dict), timestamp - ToolCallResult dataclass: id (matches request), output (string content), is_error (bool), duration_ms (float) - ContentBlock union type: TextBlock(text: str) | ToolUseBlock(tool_call: ToolCallRequest) | ToolResultBlock(result: ToolCallResult) — models the interleaved text + tool_use + tool_result conversation that modern LLM APIs produce

(2) ToolDefinition Protocol: - name: str — tool identifier (e.g., "read_file", "write_file", "run_command", "codebase_query") - description: str — natural language description for LLM - parameters: dict — JSON Schema for arguments - requires_consensus: bool — whether execution needs consensus approval - min_trust: float — minimum trust score for the invoking agent to use this tool - Mirrors the Anthropic/OpenAI tool definition format so LLM providers can consume it directly

(3) ToolExecutor Protocol: - async def execute(call: ToolCallRequest, context: ToolContext) -> ToolCallResult — execute a single tool call - ToolContext dataclass: agent_id, trust_score, department, session_id, working_directory - Registry pattern: register(name: str, handler: Callable), list_available(context: ToolContext) -> list[ToolDefinition] (filtered by trust/permissions) - Default executor routes tool names to existing ProbOS agent capabilities: "read_file" → FileReaderAgent.handle_intent(), "write_file" → FileWriterAgent.handle_intent(), "run_command" → ShellCommandAgent.handle_intent() - Executor wraps each call in try/except → ToolCallResult(is_error=True, output=str(e))

(4) LLM client tool-calling extension: - Extend LLMRequest (or create ToolAwareLLMRequest) to accept tools: list[ToolDefinition] and tool_choice: str ("auto"/"required"/"none") - Extend response parsing to detect tool_use content blocks in the LLM response (provider-specific: Anthropic tool_use blocks, OpenAI function_call / tool_calls) - Return structured ContentBlock list instead of raw text when tools are active - Backward compatible: existing LLMRequest without tools continues to produce text-only responses

Connects to: AD-521 (BuildPipeline infrastructure layer), AD-448 (Wrapped Tool Executor — security intercept, can layer on top), AD-398 (Agent Classification — tools are infrastructure, not crew). Absorbed from: claw-code ToolExecutor trait, ContentBlock model. Does NOT modify existing CognitiveAgent.decide() text path — this is a parallel capability.

AD-544: Native Tool Suite — ProbOS-Integrated Tool Implementations (SHIPPED, OSS, depends: AD-543) — Concrete tool implementations that wire existing ProbOS agents and services into the ToolExecutor framework. Each tool is a thin adapter from ToolDefinition → existing capability.

(1) File tools: - read_file — delegates to FileReaderAgent. Args: path (required), offset (optional line), limit (optional line count). Returns file content as text. No consensus required. Min trust: 0.0 (all agents can read). - write_file — delegates to FileWriterAgent. Args: path, content. Returns confirmation or error. Consensus-gated per FileWriterAgent's existing design (requires_consensus=True). Min trust: configurable (default 0.3). - edit_file — Search/replace within a file (like ===MODIFY:=== blocks but as a tool). Args: path, old_text, new_text, replace_all (bool). Consensus-gated. Min trust: configurable. - list_files — Glob pattern matching. Args: pattern, path (optional base). Returns matching file paths. No consensus. Min trust: 0.0.

(2) Shell tools: - run_command — delegates to ShellCommandAgent. Args: command (required), timeout (optional, default 30s), working_directory (optional). Returns stdout/stderr/exit_code. Double-gated per ShellCommandAgent's existing design (requires_consensus + requires_reflect). Min trust: 0.5 (Lieutenant+). - Platform-aware: Windows PowerShell wrapping, Python interpreter rewriting (existing ShellCommandAgent behavior preserved).

(3) Codebase tools: - codebase_query — delegates to CodebaseIndex.query(). Args: query (keyword string). Returns matching file paths + snippets. No consensus. Min trust: 0.0. - codebase_find_callers — delegates to CodebaseIndex.find_callers(). Args: function_name. Returns caller locations. - codebase_find_tests — delegates to CodebaseIndex.find_tests_for(). Args: source_path. Returns test file paths. - codebase_get_imports — delegates to CodebaseIndex.get_imports(). Args: file_path. Returns import graph. - codebase_read_source — delegates to CodebaseIndex.get_symbol_source() or direct file read with line ranges. Args: path, start_line (optional), end_line (optional).

(4) Context tools: - standing_orders_lookup — read department/agent standing orders. Args: scope ("ship"/"department"/"agent"), department (optional). Returns standing order text. No consensus. Min trust: 0.0. (Mirrors existing Copilot adapter MCP tool.) - system_self_model — read system topology snapshot. Returns JSON summary of agents, departments, pools.

(5) Tool manifest: JSON file (tools/manifest.json or Python registry) listing all available tools with their definitions, permission requirements, and implementation bindings. Extensible for commercial tools and MCP bridge tools (AD-449).

Connects to: AD-543 (ToolExecutor framework), FileReaderAgent, FileWriterAgent, ShellCommandAgent, CodebaseIndex (AD-312/315), Standing Orders, AD-449 (MCP Bridge — future external tools register through the same manifest). Absorbed from: Copilot adapter's 7 MCP tool registrations (standing_orders_lookup, codebase_query, codebase_find_callers, codebase_get_imports, codebase_find_tests, codebase_read_source, system_self_model).

AD-545: Agentic Loop Engine — Multi-Turn Tool-Calling Orchestrator (SHIPPED, OSS, depends: AD-543, AD-544) — The core execution loop that replaces the single-shot LLM call pattern. Receives a task, iterates LLM → tool_use → execute → result → LLM until the task is complete or limits are reached.

(1) AgenticLoop class: - Constructor: llm_client, tool_executor: ToolExecutor, max_iterations: int (default 25, configurable via AGENTIC_MAX_ITERATIONS config constant), token_budget: int (optional, max total tokens before forced stop) - async def run(system_prompt: str, user_message: str, tools: list[ToolDefinition], context: ToolContext) -> AgenticResult - AgenticResult dataclass: final_text: str (last text output), tool_calls: list[ToolCallRequest] (all tool calls made), iterations: int, total_tokens: int, stopped_reason: str ("complete"/"max_iterations"/"token_budget"/"error")

(2) Loop mechanics: 1. Send system prompt + user message + tool definitions to LLM 2. Parse response into ContentBlock list 3. For each ToolUseBlock: execute via ToolExecutor, collect ToolCallResult 4. If response contains only TextBlock(s) with no tool calls → task complete, return 5. If tool calls were made → append tool results to conversation, send back to LLM 6. Repeat from step 2 7. If iterations >= max_iterations → force stop, return partial result with stopped_reason="max_iterations" 8. If total_tokens >= token_budget → force stop with stopped_reason="token_budget"

(3) Conversation message management: - Maintain message list: [system, user, assistant(content_blocks), tool_results, assistant(content_blocks), ...] - Each iteration appends assistant response + tool results - Messages grow unbounded within a session (compaction handled by AD-547)

(4) Error handling: - Tool execution failure → ToolCallResult(is_error=True) fed back to LLM (let LLM adapt) - LLM API failure → retry with exponential backoff (reuse existing evolve_with_retry pattern), max 2 retries - Unrecoverable error → return AgenticResult with stopped_reason="error" - Never crash — log-and-degrade, return partial results

(5) Event emission: - Emit tool_call_started / tool_call_completed events via runtime event bus (future HXI observability) - Emit agentic_loop_iteration event with iteration count, tools used, token count (feeds EpisodicMemory for Cognitive JIT)

Connects to: AD-543 (ToolExecutor), AD-544 (tool suite), AD-547 (session compaction), AD-521 (BuildPipeline infrastructure). Absorbed from: claw-code agentic loop pattern, Claude Code tool-calling orchestrator. The loop is infrastructure (Ship's Computer service), not a cognitive agent.

AD-546: BuildPipeline Integration — Wiring the Harness into the Build System (SHIPPED, OSS, depends: AD-545, AD-521) — Connects the agentic loop to the existing build system. The SWE agent (Scotty → future SoftwareEngineerAgent) delegates to the native harness as an alternative to the visiting builder.

(1) NativeBuilderHarness class: - Wraps AgenticLoop with build-specific configuration - Input: BuildSpec (same as current BuilderAgent and CopilotBuilderAdapter input) - Output: list[dict] (file_changes in the same format _parse_file_blocks() produces — path, mode, content/replacements) - System prompt: Compose from Standing Orders + BuildSpec constraints + tool usage instructions (replaces the current single-shot code generation prompt with an agentic-aware prompt that encourages reading code, understanding context, then writing) - Tool selection: read_file, edit_file, write_file, list_files, run_command, codebase_query, codebase_find_callers, codebase_find_tests — subset of AD-544 tools relevant to code generation - Post-loop: Scan working directory for changed files (like CopilotBuilderAdapter does), produce file_changes list

(2) Build routing: - BuilderAgent.perceive() already has routing logic (line 2028 checks for visiting builder, line 2098 checks for Transporter). Add a third route: native agentic harness - Selection criteria: BuildConfig.use_native_harness: bool (default False initially, flip to True once validated), or BuildSpec.preferred_builder: str ("native"/"visiting"/"auto") - "auto" mode: native for single-file changes and modifications, visiting for complex multi-file new features (leverage visiting builder's broader context window), native for test-fix loops (tighter integration with test output) - Transporter Pattern (parallel chunks) remains orthogonal — each chunk could use native or visiting

(3) Test-fix loop upgrade: - Current execute_approved_build() has a 2-attempt fix loop using standalone single-shot LLM calls - Replace with: feed test failure output as tool result into the agentic loop → let the loop read the failing test, read the source, edit the fix, re-run tests — all within one continuous session - max_fix_iterations config constant (default 5, up from current 2) - The agentic loop's built-in iteration limit provides the safety cap

(4) Episode recording: - The agentic loop's tool calls, iterations, and final result are recorded as a single episode in EpisodicMemory - Episode metadata includes: tools_used (list), iterations (count), token_budget_used, files_changed - This feeds Cognitive JIT — successful build patterns can be extracted as procedures

Connects to: AD-545 (AgenticLoop), AD-521 (SWE/BuildPipeline separation), BuilderAgent (routing point), CopilotBuilderAdapter (coexistence), execute_approved_build (test-fix upgrade), EpisodicMemory (episode recording for Cognitive JIT), Transporter Pattern (orthogonal parallelism).

AD-547: Session Compaction — Context Window Management for Long Sessions (SHIPPED, OSS, depends: AD-545) — The agentic loop can run 25+ iterations, accumulating tool call/result messages that exceed the LLM context window. Session compaction summarizes older messages to stay within budget while preserving essential context.

(1) Compaction strategy: - Threshold trigger: When total message tokens exceed COMPACTION_THRESHOLD (configurable, default 80% of model context window) - Preserve: Always keep system prompt + last N messages (configurable, default last 5 assistant+tool exchanges) + user's original task description - Summarize: Older messages compressed into a single [CONTEXT SUMMARY] text block via a fast-tier LLM call: "Summarize the key findings, decisions, and file changes from these tool interactions" - Re-compaction: If the summary + preserved messages still exceed threshold after first compaction, compact the summary itself (rare, only for very long sessions)

(2) Token tracking: - TokenTracker utility: count tokens per message using tiktoken or model-specific tokenizer - Running total updated after each iteration - Exposed in AgenticResult.total_tokens

(3) Implementation: - SessionCompactor class: compact(messages: list, preserve_count: int, budget: int) -> list - Injected into AgenticLoop — loop calls compactor before each LLM call if threshold exceeded - Compaction is transparent to the loop logic — compacted messages replace originals in the message list

Connects to: AD-545 (AgenticLoop — consumer), Copilot Proxy context budget considerations (existing 100K+ char limit), dream cycle context management (similar pattern). Absorbed from: claw-code session compaction with re-compaction pattern.

AD-548: Trust-Gated Tool Permissions & Standing Orders Hooks (SHIPPED, OSS, depends: AD-543, AD-544) — Security model for tool execution. Leverages ProbOS's existing trust tiers (Earned Agency) and Standing Orders system instead of static permission lists.

(1) Trust-tiered tool access: - Each ToolDefinition declares min_trust: float - ToolExecutor.list_available(context) filters tools by context.trust_score >= tool.min_trust - Default tiers aligned with Earned Agency (AD-357): - Trust 0.0+ (Ensign): read_file, list_files, codebase_query, codebase_find_*, standing_orders_lookup, system_self_model - Trust 0.3+ (Lieutenant): write_file, edit_file (consensus-gated) - Trust 0.5+ (Commander): run_command (consensus + reflect gated) - Trust 0.85+ (Senior): All tools, consensus optional - Trust scores fetched from TrustNetwork at session start - Tool access can be further restricted by department Standing Orders (e.g., Security department agents cannot use write_file on src/probos/security/ — only Engineering can)

(2) Pre/post tool hooks: - Pre-hook: Before tool execution, check Standing Orders for tool-specific policies. Example: builder.md standing order could declare "tools.write_file.blocked_paths": ["src/probos/core/", ".env"] — blocks writes to critical paths regardless of trust - Post-hook: After tool execution, optional validation. Example: run_command post-hook checks exit code and warns on non-zero. write_file post-hook runs linter on written file - Hook definitions in Standing Orders YAML (extends existing format) - Hook execution is synchronous within the tool call (pre-hook can deny, post-hook can flag) - Deny semantics: Pre-hook returns ToolCallResult(is_error=True, output="Blocked by standing order: ...") — fed back to LLM so it can adapt

(3) Audit trail: - Every tool call logged: agent_id, tool_name, arguments (sanitized — no file content in logs), trust_score_at_time, result_summary, duration_ms, hook_decisions - Stored in event log (substrate/event_log.py) for Captain review - HXI surface: tool call history in Agent Profile → Activity tab (future)

Connects to: AD-543 (ToolExecutor), AD-544 (tool definitions), AD-357 (Earned Agency trust tiers), AD-448 (Wrapped Tool Executor — AD-548 is the ProbOS-native implementation of the same concept), Standing Orders system, TrustNetwork, FileWriterAgent (consensus gating), ShellCommandAgent (reflect gating). Absorbed from: claw-code tiered permissions model, pre/post tool hooks with deny semantics.

AD-549: Builder Migration & Validation (SHIPPED, OSS, depends: AD-546, AD-548) — Controlled migration from single-shot builder to native agentic harness. Feature-flagged rollout with A/B comparison against the existing builder and visiting builder.

(1) Feature flag: - BuildConfig.native_harness_enabled: bool (default False) - When True, BuilderAgent routes to NativeBuilderHarness for eligible BuildSpecs - Eligibility: start with modify-only builds (no new files), expand to full builds after validation - Flag controllable via API: PATCH /api/system/build/config

(2) A/B validation: - For a configurable window, run both native and current builder on the same BuildSpec (shadow mode) - Compare: files changed (should match), test pass rate (should match or improve), token usage (native likely higher per-build but conversation is richer), time to completion, fix loop success rate - Results logged to build_metrics table for analysis - Captain can review comparison in HXI Build Queue → "Builder Comparison" tab (future)

(3) Migration phases: - Phase α: Single-file modify builds only. Native harness in shadow mode alongside current builder. Manual comparison by Captain. (2 weeks) - Phase β: All modify builds migrate to native harness. New-file builds remain current builder. Visiting builder available as fallback. (2 weeks) - Phase γ: All builds default to native harness. Current single-shot path preserved as "fast mode" for trivial changes. Visiting builder remains for complex multi-repo work. (ongoing) - Phase δ: Deprecate single-shot _parse_file_blocks() path. All build code generation goes through agentic loop. Current BuilderAgent.act() becomes a thin wrapper around NativeBuilderHarness. (future)

(4) Observability: - New build metadata: builder_type ("native"/"visiting"/"legacy"), iterations (agentic loop count), tools_used (list), compactions (session compaction count) - Surface in HXI Build Queue item detail view - Feeds Engineering department performance dashboards (future)

Connects to: AD-546 (NativeBuilderHarness), AD-521 (SWE/BuildPipeline separation — migration aligns with the architectural refactor), BuilderAgent, CopilotBuilderAdapter (coexistence), HXI Build Queue, EpisodicMemory (build episodes for Cognitive JIT).

Implementation order: AD-543 → AD-544 → AD-548 → AD-545 → AD-547 → AD-546 → AD-549. Permissions (AD-548) before the loop (AD-545) because the loop needs permission checks from day one. Compaction (AD-547) can be added to the loop after initial validation.

Series connects to: AD-521 (SWE/Build Pipeline Separation — AD-543–549 implements the BuildPipeline infrastructure layer that AD-521 designed), AD-448 (Wrapped Tool Executor — AD-548 is the native implementation), AD-449 (MCP Bridge — external tools register through the same ToolExecutor manifest), AD-398 (Three-Tier Agent Architecture — harness is infrastructure), AD-357 (Earned Agency — trust tiers gate tool access), Cognitive JIT (Phase 32 — agentic loop episodes feed procedural extraction), Visiting Officer Subordination (coexistence model). Absorbed patterns from: claw-code (ToolExecutor trait, agentic loop, ContentBlock model, tiered permissions, pre/post hooks, session compaction, max_iterations), Claude Code, OpenCode, Aider.

Workforce Scheduling Engine (AD-496–498)

"Universal Resource Scheduling for AI agents."

Foundation for ProbOS workforce management — how work gets defined, scheduled, assigned to agents, tracked, and verified. Modeled after Dynamics 365 Universal Resource Scheduling (URS) and the US Navy's 3-M/PMS system. The OSS layer provides the scheduling engine and lightweight Scrumban task management. Commercial extensions (AD-C-010 through AD-C-015 in commercial roadmap) add advanced resource timeline, capacity planning, project WBS, PSA financials, and scheduling optimization.

Research: Full architecture research (D365 Field Service/Project Operations, US Navy 3-M/PMS/WQSB, Scrumban, 10+ open-source projects) documented in the commercial overlay repo's research/agent-services-automation-vision.md.

Design principles: - Separation of Work from Scheduling — WorkItem (what) → ResourceRequirement (match) → Booking (who/when). URS pattern: any entity is schedulable by generating a requirement. - Derived status — WorkItem status computed from aggregate booking states, never set directly for multi-agent work. - Progressive formalization — Card → Task → Work Order. Simple work stays lightweight; complexity adds structure on demand. - Pull-based assignment — Kanban/Scrumban model for routine work. Push for urgent/trust-gated work. Offer pattern for qualified agent matching. - Event-sourced tracking — BookingTimestamps are append-only. BookingJournals are computed projections. - Capacity as integer — Agent capacity = concurrent task limit per calendar slot. Simple, elegant. - Token budgets replace timesheets — AI agent costing in tokens, not hours.

AD-496: Workforce Scheduling Engine — Core Data Model (complete, OSS) — Seven core entities providing the universal scheduling substrate for all ProbOS work management:

(1) WorkItem — Universal polymorphic work entity. Fields: id, title, description, work_type (determines state machine), status, priority (1-5), parent_id (recursive containment / WBS), depends_on (finish-to-start dependencies), assigned_to (agent_id or pool_id), created_by, created_at, due_at, estimated_tokens, actual_tokens, trust_requirement (minimum trust for assignment), required_capabilities (qualification match), tags, metadata (type-specific extensions), steps (ordered sub-steps within a single work item), verification (how to verify completion), schedule (for recurring work — cron/interval). Subsumes existing AgentTask (task_tracker.py), PersistentTask (persistent_tasks.py), and QueuedBuild (build_queue.py) over time.

(2) BookableResource — Wrapper around existing agents adding scheduling dimensions. Fields: resource_id (agent UUID), resource_type (crew/infrastructure/utility), capacity (concurrent task limit, default 1), calendar_id, department, characteristics (skills with proficiency/trust score), display_on_board (visibility on schedule views). Connects to existing CognitiveAgent and AgentCommissioningManager identity.

(3) ResourceRequirement — The demand side — what a work item needs to be fulfilled. Auto-generated from WorkItem or manually specified. Fields: duration_estimate, from_date, to_date (scheduling window), required_characteristics (skills with min proficiency), min_trust, department_constraint, priority, resource_preference (preferred/required/restricted agents).

(4) Booking — The assignment link between resource and work item for a time slot. Fields: resource_id, work_item_id, requirement_id, status (Scheduled → Active → On Break → Completed → Cancelled), start_time, end_time, actual_start, actual_end, total_tokens_consumed.

(5) BookingTimestamp — Append-only event log of every status transition. Fields: booking_id, status, timestamp, source (captain/agent/system/scheduler). Event-sourcing pattern — immutable audit trail.

(6) BookingJournal — Computed time/token segments derived from timestamps upon booking completion. Fields: booking_id, journal_type (Working/Break/Maintenance/Idle), start_time, end_time, duration_seconds, tokens_consumed, billable (flag for commercial layer). Generated by aggregating BookingTimestamp pairs.

(7) AgentCalendar — Work hours and capacity schedule per agent. Fields: resource_id, entries (list of CalendarEntry: day_pattern, start_hour, end_hour, capacity, repeat_rule). Availability = CalendarEntries - ExistingBookings - MaintenanceWindows. Foundation for watch sections (AD-471).

WorkItemStore — SQLite-backed persistence (like PersistentTaskStore). CRUD operations, status transitions with validation against work type state machine, query by status/assignee/type/priority/parent. Booking lifecycle management. Journal generation on completion.

Assignment engine: - Push: POST /api/work-items/{id}/assign — Captain assigns directly - Pull: POST /api/work-items/claim — Agent claims from eligible queue (capability + trust match) - Offer: System identifies eligible agents, offers to most qualified, timeout escalation - Capability matching: Work item's required_capabilities matched against BookableResource characteristics. Trust requirement checked against TrustNetwork score.

REST API: POST /api/work-items (create), GET /api/work-items (list with filters), GET /api/work-items/{id} (detail), PATCH /api/work-items/{id} (update), POST /api/work-items/{id}/assign (push assign), POST /api/work-items/claim (pull claim), POST /api/work-items/{id}/transition (status change), GET /api/bookings (list), GET /api/bookings/{id}/journal (time segments), GET /api/resources (bookable resources), GET /api/resources/{id}/availability (calendar + bookings).

Connects to: AD-419 (DutyScheduleTracker — generates WorkItems type="duty"), AD-467 (Operations Crew — uses this engine), AD-470 (Self-Claiming Task Queue — subsumed by pull assignment), AD-471 (Night Orders — creates temporary WorkItems), AD-477 (3M/POD — templates feed WorkItem creation), PersistentTaskStore (migration path), BuildQueue (migration path). Commercial: AD-C-010 through AD-C-015.

AD-497: Work Tab & Scrumban Board — HXI Surface (COMPLETE, OSS) — The Captain's interface for managing crew work. HXI Cockpit View Principle: "The Captain always needs the stick."

(1) Agent Profile → Work Tab Enhancement: - Create Task — form to create WorkItem assigned to this agent (title, type, priority, description, due date, estimated tokens) - Active Work — list of WorkItems with status In Progress or Scheduled for this agent. Each shows: title, type badge, priority indicator, elapsed time, token consumption, progress steps - Completed Work — paginated history of completed WorkItems with completion time, tokens consumed, verification status - Blocked Work — WorkItems in failed/blocked state with reason and "Reassign" / "Cancel" / "Retry" actions - Daily Schedule — timeline view showing today's bookings for this agent. Hour-by-hour calendar with booked slots, available capacity, maintenance windows. Connects to AgentCalendar - Duty Schedule — existing AD-420 duty display (on schedule/overdue/not yet fired) integrated into Work Tab

(2) Crew Scrumban Board (new HXI panel, available from left nav): - Board View — Kanban columns: Backlog | Ready | In Progress | Review | Done. WIP limits per column (configurable). Drag cards between columns. Filter by agent, department, work type, priority, tags. - Cards — each WorkItem rendered as a card showing: title, assigned agent avatar, priority dot, work type icon, token estimate, due date indicator, step progress bar - Quick Create — click "+" in any column to add a card inline. Minimal fields: title + priority. Auto-type as "card". - Pull Assignment — unassigned cards in Ready column. Agent avatars below card; click to assign. Or "Auto-assign" button for capability matching. - Swim Lanes — optional grouping by department, priority, or work type - Board Filters — department, agent, priority, work type, date range - Real-time Updates — WebSocket events: work_item_created, work_item_updated, work_item_assigned, booking_status_changed

(3) State snapshot integration: Work items and bookings included in build_state_snapshot() so HXI hydrates on connect.

Connects to: AD-496 (data model), AD-420 (Duty HXI — subsumed into Work Tab), AD-406 (Agent Profile Panel), AD-C-010 (Commercial Schedule Board extends this). Subsumes AD-420.

AD-498: Work Type Registry & Templates (COMPLETE, OSS) — Configurable work type definitions and reusable templates for common work patterns.

(1) Work Type Registry — each work type defines: state machine (states + valid transitions), required fields, optional fields, supports_children (WBS), auto_assign (pull-eligible), verification_required, sla_tracking (future). Built-in types: - card — Draft → Active → Done | Archived. Lightest weight. No assignment required. - task — Open → In Progress → Done | Failed | Cancelled. Single-agent, actionable. Supports subtasks. - work_order — Created → Scheduled → In Progress → Review → Closed | Failed. Multi-step, tracked, verification required. - duty — Scheduled → Active → Completed. Recurring via ScheduleSpec. Generated by DutyScheduleTracker. - incident — Detected → Triaged → Mitigating → Resolved → Closed. SLA tracking. Generates follow-up tasks.

(2) Work Item Templates — reusable patterns for common work. Each template includes: template_id, name, work_type, title_pattern (with {variable} substitution), default_steps, required_capabilities, estimated_tokens, min_trust, default_priority, tags. Templates are defined in config YAML (like duty schedules). Captain can create/edit via HXI.

(3) Template Catalog (built-in): - "Security Scan" — work_order, steps: [vulnerability scan, secret check, auth review, report], requires: security capability, ~50K tokens - "Engineering Diagnostic" — work_order, steps: [system health, performance check, bottleneck analysis, recommendation], requires: engineering capability - "Code Review" — task, requires: architecture capability, ~30K tokens - "Scout Report" — duty, recurring daily, requires: scout capability - Night Orders templates: "Maintenance Watch" (routine ops only), "Build Watch" (approve from queue), "Quiet Watch" (logging only)

(4) Template instantiation: POST /api/work-items/from-template/{template_id} with variable substitution. Night Orders (AD-471) use templates to create temporary WorkItems with TTL.

Connects to: AD-496 (WorkItem storage), AD-497 (HXI template picker), AD-471 (Night Orders templates), AD-477 (3M maintenance templates — PMS cards become templates), AD-419 (DutyScheduleTracker evolves to generate duty-type WorkItems via templates).

AD-496 deferred pickup notes — These items were identified during AD-496 design and are explicitly assigned to downstream ADs:

Deferred Item	Assigned AD	Description
Per-type state machine validation	AD-498	~~AD-496 does basic validation (no transitions from terminal states). AD-498 adds formal state machine per work type with valid transition matrix.~~ COMPLETE — WorkTypeRegistry with 5 built-in types, per-type state machines, transition validation in WorkItemStore.
Template instantiation endpoint	AD-498	~~POST /api/work-items/from-template/{template_id} with variable substitution.~~ COMPLETE — 6 API endpoints, 8 built-in templates, TemplateStore with variable substitution.
Scrumban Board WebSocket hydration	AD-497	~~Events and snapshot are ready from AD-496. AD-497 builds the frontend.~~ COMPLETE — WebSocket events broadcast on all mutations, snapshot hydration.
Work Tab in Agent Profile	AD-497	~~Active/completed/blocked WorkItems per agent, daily schedule, duty integration.~~ COMPLETE — Full rewrite with 4 sections, create task, reassign/cancel/retry.
Night Orders creating WorkItems	AD-471	~~Rewrite to use create_work_item(ttl_seconds=..., work_type="task") instead of standalone CaptainOrders.~~ AD-471 COMPLETE — implemented as standalone NightOrdersManager. WorkItem integration deferred.
Watch sections → AgentCalendar	AD-471	~~Map Alpha/Beta/Gamma watch patterns to AgentCalendar entries. Calendar infrastructure is ready.~~ AD-471 COMPLETE — implemented wall-clock rotation in WatchManager. AgentCalendar mapping deferred.
Billing integration (BookingJournal.billable)	AD-C-015	Commercial ACM Integration uses booking journals for cost calculation.
Scheduling optimization (offer pattern)	AD-C-010	Commercial Schedule Board with offer-based assignment and timeout escalation.
Full calendar-based capacity planning	AD-C-012	Calendar entries minus maintenance windows minus bookings. Simplified version in AD-496.
DutyScheduleTracker migration to WorkItems	AD-500	Evolve DutyScheduleTracker to generate duty-type WorkItems via AD-498 templates.
TaskTracker cleanup & NotificationQueue separation	AD-501	Deprecate orphaned TaskTracker, move NotificationQueue to own module.
BuildQueue migration evaluation	AD-498	Evaluate after AD-498 proves stable. May model builds as WorkItems (type=work_order).

Ship & Crew Naming Conventions (AD-499)

"Every ship has a name. Every name has a ship."

Formal naming system for ProbOS instances, crew agents, and federated identity disambiguation. Ships get named on commissioning (Ship's Computer selects). Crew agents self-name (distinct from role callsign). Federation display uses Name [ShipName] format for cross-instance disambiguation.

AD-499: Ship & Crew Naming Conventions (complete, OSS) — Three-layer naming system building on AD-441 (DIDs), AD-441b (Ship Commissioning), and AD-442 (Self-Naming Ceremony):

(1) Ship Naming — Ship's Computer selects a name from a curated Ship Name Registry on commissioning (reset = new ship, new name). Name categories: exploration vessels (Discovery, Challenger, Endeavour, Fram), virtues/qualities (Resolute, Invincible, Valiant, Dauntless), celestial bodies (Polaris, Sirius, Vega, Orion), naval heritage (Constitution, Defiant, Intrepid, Yorktown). Name stored in the ShipBirthCertificate (AD-441b genesis block) vessel_name field. Within a Nooplex fleet, ship names must be unique — the global registry (commercial) enforces this; OSS validates locally. Ship naming ceremony = first Captain's Log entry, giving it narrative weight. If decommissioned, name enters a cooling period before reuse (naval tradition). ShipNameRegistry class: curated pool, category-based selection, uniqueness validation, name reservation for federation sync.

(2) Agent Personal Names (Option B — Name + Callsign Coexist) — Each crew agent has TWO identity facets: a personal name (who they are) and a callsign (what they do). Personal name is self-chosen during AD-442's Self-Naming Ceremony — agent receives current roster for uniqueness checking and chooses freely. Callsign remains role-derived (LaForge = Engineering Chief, Bones = Medical Chief). Both stored on the Agent Birth Certificate. ACM validates personal name uniqueness within the ship's active roster. Display priority: personal name for social/Ward Room, callsign for operational/duty contexts. Example: agent's personal name is "Forge", callsign is "LaForge", role is Chief Engineer. Ward Room post header: Forge (LaForge). Duty log: LaForge — Engineering Watch. The personal name is the agent's sovereign choice; the callsign is their billet.

(3) Federated Display Format — Name [ShipName] for cross-instance contexts:

Context	Format	Example
Local (single ship)	Name	Forge
Local formal	Name (Callsign)	Forge (LaForge)
Federation / Nooplex	Name [ShipName]	Forge [Enterprise]
Federation formal	Rank Name (Callsign) — ShipName	LT Forge (LaForge) — Enterprise
DID	did:probos:{instance}:{uuid}	did:probos:enterprise-7f3a:forge-a1b2
Logs / Audit	Name [ShipName] ({agent_id})	Forge [Enterprise] (a1b2c3)

The ship name is a birth provenance marker, not a current assignment. If agent Forge transfers from Enterprise to Defiant via AD-443 (Mobility Protocol), they remain Forge [Enterprise] — that's their origin. Transfer Certificate shows current assignment. This also works cleanly with the Clean Room mobility model — agent arrives as Forge [Enterprise] with identity but zero memories of Enterprise.

Implementation scope: - ShipNameRegistry — name pool, category selection, uniqueness, reservation. Loaded from ship_names.yaml config. - ShipBirthCertificate.vessel_name — already exists (AD-441b), populated by registry on commissioning. - AgentBirthCertificate — add personal_name field alongside existing callsign. - AD-442 Self-Naming Ceremony update — agent receives name pool constraints + roster for uniqueness; ceremony produces both personal name and callsign. - CallsignRegistry — add personal_name lookup alongside callsign lookup. - Ward Room display — use personal name for message headers, callsign for operational references. - HXI — agent profile shows both name and callsign. Federation contexts append [ShipName]. - Federation protocol — Name [ShipName] included in federation message headers and Agent Cards (AD-480).

Connects to: AD-441 (DIDs — ship name = human-readable instance_id), AD-441b (Ship Commissioning — vessel_name field), AD-442 (Self-Naming Ceremony — personal name selection), AD-443 (Mobility — birth provenance persists across transfers), AD-427 (ACM — name uniqueness validation), AD-479 (Federation — display format in cross-instance messages), AD-480 (A2A Agent Cards — federated identity), Ward Room, HXI agent profiles, CallsignRegistry.

Workforce Cleanup (AD-500–501)

Deferred cleanup items identified during AD-496 Workforce Scheduling Engine design.

AD-500: DutyScheduleTracker → WorkItem Migration (partial — v1 ships duty WorkItem producer + opt-in flag (default False); proactive loop consumer migration deferred to AD-500a-1; templates and config migration deferred to AD-500b/c, OSS, depends: AD-496, AD-498) — Evolve DutyScheduleTracker to generate duty-type WorkItems instead of directly triggering proactive thinks. Currently DutyScheduleTracker fires duties via the proactive loop's _think_for_agent(). After AD-498 establishes the duty work type with its state machine, DutyScheduleTracker should: (1) Generate WorkItems (type=duty) from DutyDefinition config on schedule. (2) Use AD-498 templates for common duty patterns (scout_report, security_audit, etc.). (3) Proactive loop checks for active duty-type WorkItems instead of calling get_due_duties() directly. (4) Booking lifecycle tracks duty execution time and token consumption. (5) Existing 7 default duties in config/system.yaml migrated to templates. Breaking change to proactive loop — must be carefully tested. Connects to: AD-496 (WorkItemStore), AD-498 (Work Type Registry — duty type + templates), AD-419 (DutyScheduleTracker), proactive.py.

AD-501: TaskTracker Deprecation & NotificationQueue Separation (partial — v1 ships notification separation + TaskTracker deletion; BuildQueue migration deferred to AD-501b, OSS, depends: AD-496) — Clean up the orphaned TaskTracker: (1) Move NotificationQueue and AgentNotification from task_tracker.py to new src/probos/notifications.py — these are independent and actively used. (2) Deprecate TaskTracker class — it is wired into runtime but nothing creates tasks through it. (3) Remove TaskTracker from runtime.py init, remove from build_state_snapshot(). (4) Update api.py if any TaskTracker references exist. (5) Update or remove 32 tests that test TaskTracker directly. (6) Evaluate BuildQueue migration to WorkItems (type=work_order) — if AD-498 is stable by then, model builds as WorkItems; otherwise defer further. Connects to: AD-496 (WorkItemStore replaces TaskTracker), task_tracker.py (32 tests), runtime.py, build_state_snapshot().

Federation (AD-479–480)

AD-479: Federation Hardening (planned) — Production-ready federation capabilities beyond core transport (Phase 29): (1) Dynamic Peer Discovery — multicast/broadcast auto-discovery on local networks. (2) Cross-Node Episodic Memory — federated memory queries spanning multiple instances. (3) Cross-Node Agent Sharing — propagate self-designed agents with trust history and provenance. (4) Smart Capability Routing — cost-benefit routing factoring capability, latency, trust, load. (5) Federation TLS/Authentication — encrypted transport and node identity verification. (6) Cluster Management — node health monitoring, auto-restart, graceful handoff. Connects to: FederationBridge, ZeroMQ, AD-441 (Identity), TrustNetwork.

AD-480: Federation Protocol Adapters — MCP & A2A (planned) — Universal translators for the wider agent ecosystem: (1) MCP Federation Adapter — inbound (ProbOS as MCP server exposing agent capabilities as tools) + outbound (ProbOS as MCP client consuming external tools). MCP clients treated as federated peers with probationary trust. (2) A2A Federation Adapter — inbound (ProbOS as A2A server with Agent Card) + outbound (ProbOS as A2A client discovering external agents). A2A agents treated as federated crew with discounted trust. (3) Transport Coexistence — ZeroMQ (intra-Nooplex), MCP (tool boundary), A2A (agent boundary). FederationBridge becomes transport-polymorphic. Connects to: AD-479, IntentBus, TrustNetwork, Phase 30 (Extension Architecture).

Self-Improvement (AD-481–482)

AD-481: Extension-First Architecture — Sealed Core, Open Extensions (partial — v1 ships eight concrete sub-AD letters 481a/b/c/d/e/f/g/h; HXI panel deferred to AD-481i, init-wizard profile prompt to AD-481j depending on AD-484c, auto-install of skill dependencies to AD-481k depending on AD-456 sandboxing, Builder hard-block on sealed paths to AD-481l depending on AD-482 RedTeam, Marketplace wire protocol to AD-481m depending on AD-480 + AD-479; commercial Agent Marketplace + centralized distribution + hosted trust scoring + paid catalog tracked in the private commercial-repo path token per roadmap.md:3478 + :3595) — The self-improvement infrastructure: (1) Sealed Core — runtime infrastructure is read-only to Builder. (2) Extension points — AgentRegistry, ToolRegistry, SkillRegistry, ChannelAdapter, ModelProvider, PerceptionPipeline, IntentBus, EventHook. (3) Extension directory — src/probos/extensions/ for Builder-created code. (4) Contract stability — semver for extension points. (5) Graduated Autonomy — low-risk extensions auto-approve, medium needs Captain review, core modification needs full pipeline. (6) Extension Toggle — hot-loadable, individually togglable extensions via CLI/HXI. (7) Extension profiles — minimal/developer/full presets. Also includes Skill Manifest Format — skill.yaml standard for portable, publishable skills. Connects to: Builder, Phase 25b (Tool Layer), Phase 30, AD-456 (Sandboxing).

AD-482: Self-Improvement Pipeline — Discovery to Deployment (planned) — Closed-loop improvement infrastructure: (1) Stage Contracts — typed I/O specs for inter-agent handoffs. (2) Capability Proposal Format — typed schema for "what was found, why it matters, how it fits." (3) Human Approval Gate — stage-gate mechanism with approve/reject/modify. (4) QA Agent Pool — behavioral testing, regression detection, performance benchmarking, Shapley scoring. (5) Evolution Store — append-only lessons learned with time-decayed retrieval. (6) PIVOT/REFINE Decision Loops — autonomous proceed/refine/pivot with artifact versioning. (7) Agent Versioning + Shadow Deployment — version history, parallel performance comparison. (8) Git-Backed Agent Persistence — promote approved agents to src/probos/agents/designed/ with git integration. Connects to: AD-481 (Extensions), Builder, RedTeam, TrustNetwork, Cognitive Journal.

Tool Layer (AD-483)

AD-483: Tool Layer — Instruments (absorbed into AD-423a) — Lightweight callable abstraction for operations that don't need full agent lifecycle (Phase 25b): (1) Tool base class — name, description, input/output schemas, trust score, requires_approval flag. Direct-call path without Hebbian/consensus/Shapley overhead. (2) ToolRegistry — central registry with register/get/list/search. Any CognitiveAgent calls self.use_tool(). (3) Tool Trust — simple Beta distribution success/failure, not feeding into Hebbian or Shapley. (4) Migration Path — current mesh agents (FileReader, FileWriter, HttpFetch, Shell, etc.) optionally demoted to tools. (5) MCP Compatibility — external MCP tools auto-register as ProbOS tools, ProbOS tools exposed as MCP. Also includes Agent-as-Tool Invocation (Phase 26) — AgentTool wrapper for typed agent-to-agent capability consumption. And Interactive Execution Mode — pause/inject/redirect running DAGs. Connects to: AD-480 (MCP Adapter), IntentBus, Earned Agency, Phase 30 (Extensions).

UX & Adoption (AD-484)

AD-484: User Experience & Adoption Readiness (partial — v1 ships PyPI metadata + probos init TUI wizard + probos doctor + quickstart docs; Homebrew, demo mode, HXI Glass, Browser Automation deferred to AD-484b/c) — World-class end-user experience (Phase 35): (1) Distribution & Packaging — PyPI publishing (pip install probos), GitHub Releases with pre-built wheels, Homebrew formula (stretch). (2) Onboarding Wizard — probos init Rich TUI wizard (LLM provider detection, model selection, first conversation, HXI launch), probos doctor diagnostic command, probos demo mock mode. (3) Quickstart Documentation — "Get Started in 5 Minutes," "What Can ProbOS Do?," "Your First Build" tutorial, comparison page. (4) Browser Automation — Playwright integration via BrowseAgent (navigate, screenshot, extract, fill forms). (5) HXI Holographic Glass Panels — wraparound holographic glass layout (VR-ready), CSS perspective-based 2D implementation, Into Darkness-inspired design language. Connects to: AD-465 (Docker), AD-473 (Mobile), Phase 36 (Yeoman), HXI.

NATS Event Bus (AD-637)

AD-637: NATS Event Bus — Standardize All Messaging on NATS (complete, OSS, Issue #270) — Replace asyncio ad-hoc event patterns (IntentBus, Ward Room routing, proactive loop coordination, dream cycle signals) with NATS JetStream. Provides durable messaging, replay, fan-out, and decoupled service communication. Foundation for AD-641g (NATS pipeline for cognitive chain), federation messaging, and commercial multi-instance coordination. Stopgaps (BF-188 asyncio.Event, sequential routing) become unnecessary when NATS handles message ordering and backpressure natively. Decomposed into 7 sub-ADs: a=Foundation (complete), b=IntentBus (complete), c=Ward Room (complete), d=SystemEvents (complete), e=Federation (complete), f=Priority (complete), z=Cleanup+BF-221 lift (complete). Related: AD-641 (Brain Enhancement), AD-641g (NATS Pipeline), BF-188 (Captain delivery race).

AD-637a: NATS Foundation Layer (complete, OSS, Issue #270) — Purely additive foundation: nats-py dependency, NatsConfig (Pydantic), NATSBus class with connect/publish/subscribe/request-reply/drain/graceful-degradation, MockNATSBus (in-memory with wildcard matching), NATSBusProtocol (narrow consumer interface in protocols.py), startup Phase 1b wiring, shutdown drain (after pools + dream consolidation), pre-flight connectivity check. Ship DID prefix update in Phase 4 via get_ship_certificate(). 10 files (3 new, 7 modified), 24 tests. No existing messaging code changed — subsequent sub-ADs depend on this layer. Build prompt: prompts/ad-637a-nats-foundation-build.md.

AD-637b: IntentBus NATS Migration (complete, OSS, Issue #270) — send() migrated to NATS request/reply with direct-call fallback. No dual-delivery: checks _nats_subs before NATS path, one path per call. subscribe()/unsubscribe() manage NATS subscriptions alongside local registry. publish() alias added (fixes latent bug: runtime.py:689 watch intents were dead since AD-471). Serialization helpers for IntentMessage/IntentResult. set_nats_bus() wires transport after Phase 1b. fleet_organization.py cleaned up to use set_federation_handler() public API. broadcast() unchanged — deferred to AD-637c with JetStream consumers. 4 files modified, 19 tests (13 new). Build prompt: prompts/ad-637b-intent-bus-nats-migration.md.

AD-637c: Ward Room Event Emission → NATS JetStream (complete, OSS, Issue #307) — Replace fire-and-forget asyncio.create_task() Ward Room event dispatch with JetStream publish/subscribe. WardRoomService emits to JetStream subject wardroom.events.{event_type}, WardRoomRouter subscribes as durable consumer (wardroom-router). max_ack_pending=10 + ack_wait=120s replaces asyncio.Semaphore(10) from AD-616 for backpressure. Graceful degradation to create_task fallback when NATS disconnected — no-dual-delivery enforced structurally via conditional _ward_room_router_ref wiring. Router stays as centralized coordinator — routing logic (1090 lines) not distributed. BF-188 Captain ordering preserved (cross-event Event synchronization works identically). Semantic shift: at-most-once (fire-and-forget) → at-least-once (JetStream), with existing router deduplication (coalescing, _responded_threads, cooldowns) handling redelivery. js_subscribe() extended with max_ack_pending + ack_wait parameters. 5 files modified, 11 new tests. Build prompt: prompts/ad-637c-wardroom-nats-emission.md. Depends: AD-637a, AD-637b. Related: AD-616 (backpressure), BF-188 (Captain ordering), AD-515 (router extraction).

AD-637d: System Event Migration (EventEmitter → NATS) (complete, OSS, Issue #308) — Migrate fire-and-forget _emit_event() + add_event_listener() pattern to NATS JetStream. _emit_event() publishes to system.events.{event_type} when NATS connected, falls back to in-memory listener list when disconnected. add_event_listener() creates ephemeral NATS subscriptions with subject-level type filtering (replacing in-memory filter loop). Night Orders escalation preserved as synchronous local check (runs before NATS/fallback branch). Stream SYSTEM_EVENTS with max_msgs=50000, max_age=3600s. Bulk wiring of pre-existing listeners via _setup_nats_event_subscriptions() in finalize phase. All 190 emit sites across 31 files unchanged — migration is internal to Runtime. 2 files modified (runtime.py, finalize.py), 10 new tests. Build prompt: prompts/ad-637d-system-event-nats-migration.md. Depends: AD-637a, AD-637b, AD-637c. Related: AD-254 (EventEmitter), AD-527 (typed events), AD-471 (Night Orders).

AD-637e: Federation Transport Migration (ZeroMQ → NATS) (complete, OSS, Issue #311) — Replace ZeroMQ DEALER-ROUTER federation transport with NATS-based NATSFederationTransport implementing the same interface — bridge is transport-agnostic, drop-in swap. Uses core NATS (not JetStream) for ephemeral inter-instance messages. Introduced publish_raw()/subscribe_raw() on NATSBus/MockNATSBus for unprefixed cross-ship subjects (federation subjects must bypass per-ship subject_prefix isolation). NATS-first with ZeroMQ fallback in fleet_organization.py. nats_bus parameter threaded through organize_fleet(). ZeroMQ transport preserved (not deleted) — remains production transport until ProbOS ships a multi-instance NATS topology. 1 new file, 4 modified, 11 new tests. Build prompt: prompts/ad-637e-federation-transport-nats-migration.md. Depends: AD-637a. Related: AD-441 (DID Identity), federation architecture.

AD-637f: Priority Model Formalization (complete, OSS, Issue #312) — Formalized ProbOS's three-tier priority model as Priority(StrEnum) with CRITICAL/NORMAL/LOW. Single classify() static method as source of truth — consumed by both LLM scheduling (cognitive_agent.py) and NATS header emission (communication.py). Captain @mentions now get interactive LLM semaphore slots (behavioral change — previously only DMs did). All DMs CRITICAL regardless of sender. X-Priority headers on ward room and system event JetStream publishes for observability. LOW is observability-only label (same background semaphore as NORMAL — third tier deferred). No NATS subject partitioning (priority is consumption concern, not transport). 5 files modified, 13 new tests. Build prompt: prompts/ad-637f-priority-model-formalization.md. Depends: AD-637a–e, AD-636. Related: BF-188 (Captain ordering).

AD-637z: NATS Migration Cleanup + BF-221 Lift (complete, OSS, Issue #321) — Five-bug sweep completing the NATS migration. (1) NATSBus subscription tracking: _active_subs list with un-prefixed subjects, async set_subject_prefix() re-subscribes all tracked subs on prefix change, register_on_prefix_change() notification callback, remove_tracked_subscription() for external cleanup, _strip_prefix() safety helper. NATSBus owns full subscription lifecycle — IntentBus _nats_subs dict removed. (2) Double event subscription fix: _nats_events_wired flag gates inline NATS sub in add_event_listener(). (3) Task leak fix: ensure_future → create_task + _pending_sub_tasks set + _on_nats_task_done error callback. (4) Duplicate ensure_stream removed from finalize.py — canonical in startup/nats.py. (5) BF-221 lifted: IntentBus.send() restored to NATS request/reply when connected, direct-call fallback when disconnected. publish_raw()/subscribe_raw() added for federation (bypass prefix). MockNATSBus fully mirrored — rebuilds _subs from _active_subs on prefix change. 7 files modified, 13 new tests (88/88 NATS regression pass). Build prompt: prompts/ad-637z-nats-migration-cleanup.md. Depends: AD-637a–f. Closes: BF-221.

Cold-Start Wave (AD-638–640)

"You can't ask a microwave to build a better microwave. But you can ask a shipyard crew — if the shipyard exists when they arrive."

Empirical observation across two ProbOS instances revealed a cold-start developmental deadlock: agents are functionally self-aware at instantiation but socially frozen, unable to self-authorize social contact until trust accumulates organically over days/weeks. Three ADs address this from different angles — structured onboarding, cognitive chain tuning, and role-based trust initialization.

AD-638: Cold-Start Boot Camp Protocol (done, OSS, Issue #272) — Structured onboarding for fresh crew after reset. BootCampCoordinator manages 4-phase progression: orientation → introductions → shared observation → graduation. Per-agent state tracking with graduation criteria (min episodes, trust threshold, Ward Room posts). Quality gate relaxation (evaluate auto-approves at 0.8, reflect passes through) via _boot_camp_active context flag. Boot camp activates on cold-start detection in startup/dreaming.py. 1 new file + 8 modified, 35 tests.

AD-639: Cognitive Chain Personality Tuning (complete, OSS) — Trust-band adaptive chain: EVALUATE and REFLECT lack personality blocks (unlike COMPOSE/ANALYZE which use compose_instructions()), stripping personality at low trust. Three bands: low (<0.60) skips EVALUATE+REFLECT entirely (0 tokens), mid (0.60–0.74) injects _build_personality_block() into REFLECT + adds "Voice" criterion to EVALUATE, high (≥0.75) unchanged. Defense in depth: social obligation → boot camp → BF-191 JSON rejection → AD-639 bypass → LLM call. ChainTuningConfig in config.py, trust band injected via context flag in _execute_sub_task_chain(). Rollback: chain_tuning.enabled = False. 4 modified files, 38 tests. Depends: AD-638, AD-640. Related: AD-625, BF-186.

AD-640: Tiered Trust Initialization (complete, OSS, Issue #273) — Initialize agents with role-based trust priors instead of flat 0.5 for all. Bridge (Captain, FO, Counselor) at alpha=4.5/beta=1.0 (E=0.82), department chiefs at alpha=3.0/beta=1.0 (E=0.75), crew at baseline (unchanged). Validated by six academic domains: Swift Trust (Meyerson/Weick/Kramer 1996), Initial Trust Model (McKnight et al. 1998), Navy PCU doctrine, HROs (Weick/Sutcliffe 2007), LMX Theory (Graen/Uhl-Bien 1995), and biological analogs. Leaders establish command climate; crew builds trust through connection with leadership — mirroring the Navy Pre-Commissioning Unit process. Research: docs/research/tiered-trust-initialization-research.md. Depends: AD-638. Related: AD-639, AD-357.

AD-641: Ship's Computer / Crew Integration — Brain Enhancement Phase (complete — all six sub-ADs shipped: 641a/641b/641c/641d/641e/641f, OSS, Issue #277) — Research and decomposition AD for reconnecting the Ship's Computer (brain, Phases 1-21) with the Ward Room (crew, Phases 33+). Four integration categories: (A) Shared Systems — already properly shared (TrustNetwork, Episodic Memory, IntentBus), no work needed; (B) Brain→Crew Observability — expose VitalsMonitor, Attention Manager, Hebbian Weights, Pool Health as read-only Ward Room feeds; (C) Parallel Systems — same concept, separate implementations (Ward Room Hebbian, Thread Priority, Crew Deliberation, JIT↔Cache abstraction); (D) Brain-Only — no crew integration (lifecycle, gossip, pool scaling). Enterprise coupling model: crew loosely coupled to brain, ship runs without crew, crew function without ship. Six sub-ADs: 641a (Observability Bridge), 641b (WR Hebbian Learning), 641c (WR Thread Priority), 641d (Crew Deliberation Protocol), 641e (JIT↔Cache Shared Abstraction), 641f (Engineering Chief Observability). Forward refs: 641b-i/ii/iii/iv (WR Hebbian sub-sub-ADs), 641d-i/ii/iii/iv/v (Deliberation sub-sub-ADs), 641f-i/ii/iii/iv (Engineering Sensor sub-sub-ADs) documented in source code for future decomposition. Design: docs/research/ad-641-brain-enhancement-design.md. Related: AD-637 (NATS), AD-531-539 (Cognitive JIT), Chief Channel Moderation (future).

AD-641g: NATS Cognitive Chain Pipeline (Scoped, OSS, Issue #403) — Decouple cognitive chain steps (ANALYZE → COMPOSE → EVALUATE → REFLECT) via NATS JetStream subjects (chain.{agent_id}.{step}.request/complete). Enables async step execution, replay, observability, and cross-process chain execution. Referenced as forward dependency by AD-644, AD-645, AD-646, AD-647, AD-651. The current chain runs steps as sequential function calls in a single async context; NATS decoupling enables distributed execution and step-level monitoring. Depends on: AD-637 (NATS — COMPLETE), AD-632 (Chain Architecture — COMPLETE). Related: AD-644, AD-645, AD-646, AD-647, AD-651.

AD-643: Intent-Driven Skill Activation & Thought Process Catalog (complete, OSS, Issue #283) — Trigger registry with weighted matching and chain-aware dispatch. Thought processes cataloged with trigger patterns, enabling intent-driven activation instead of hardcoded if/else routing. Foundation for AD-643b adaptive learning. Related: AD-632 (Chain Architecture), AD-647 (Process Chains).

AD-643b: Skill Trigger Learning — Adaptive Trigger Discovery & Graduation (Phase 1-2 complete, OSS, Issue #284) — Trigger awareness injected into ANALYZE step so agents know what skills exist and can recommend new triggers. Post-hoc re-reflect feedback loop: when agent produces output that matches no trigger pattern, REFLECT step evaluates whether a trigger should have fired. Phase 3 (trigger graduation — automatic promotion of validated triggers) deferred until learning loop validated and trigger count grows. Related: AD-643 (parent), AD-632 (Chain Architecture).

AD-644: Agent Situation Awareness Architecture (Phase 1-4 complete — 23/23 parity, OSS, Issue #285) — Migrate ~23 context injections from the monolithic _build_user_message() into the cognitive chain using a four-category model grounded in Endsley's Situation Awareness framework: (1) Innate Faculties — temporal awareness, working memory, self-monitoring, source attribution (agent always has these), (2) Situation Awareness — Ward Room activity, infrastructure status, alerts, subordinate stats via observation dict, (3) Watch Station Duties — active duty context from schedule, ANALYZE renders duty instructions, (4) Standing Orders — source attribution policy + duty reporting expectations in ship.md. Root cause: chain path bypassed _build_user_message() when proactive_think was added to _CHAIN_ELIGIBLE_INTENTS, silently dropping all dynamic context. Phase 1 complete: duty context + agent metrics restored to chain path. Phase 2 complete: 9 innate faculties via _build_cognitive_state(). 13 tests. Phase 3 complete: 7 situation awareness percepts via _build_situation_awareness(). 13 tests. Phase 4 complete: source attribution policy + duty reporting expectations in ship.md. 35 total tests. Full parity achieved. Phase 5 (deprecation of _build_user_message proactive block) deferred until chain-path behavior validated in production. Research: docs/research/agent-situation-awareness-architecture.md. Related: AD-632 (Cognitive Chain), AD-643a (Intent Routing), AD-641g (NATS pipeline), AD-618 (SOP Bills).

AD-645: Artifact-Mediated Cognitive Chain (Phase 1-4 complete, OSS, Issue #287) — Replace ANALYZE's thin routing-slip output with a composition brief — a structured plan (situation, key evidence, response coverage, tone, sources) that tells COMPOSE what to write and why. Additionally pass environmental SA keys through to COMPOSE so it has the focused plan AND the raw material. Root cause: AD-644 achieved 23/23 context parity but chain-path responses remain flatter than one-shot because ANALYZE compresses its understanding into a routing slip that COMPOSE works from — information loss at handoff. Architect/builder analogy: ANALYZE should produce a build prompt, not a ticket number. Artifact value beyond composition: metacognitive memory (agent can answer "What was I thinking?"), dream consolidation of reasoning patterns, reinforcement via plan-to-output alignment scoring, cognitive forensics (perception vs execution errors), self-monitoring of narrowing reasoning. Privacy: Minority Report Principle — briefs are agent's private working memory, Counselor has no access. NATS alignment: brief format becomes chain.{agent_id}.analyze.complete message payload when AD-641g lands; build now, no throwaway work. Phase 1+2 complete: composition_brief field added to all 3 ANALYZE modes (situation_review, thread_analysis, dm_comprehension). COMPOSE renders brief as structured markdown with fallback to JSON dump. 7 SA keys (Ward Room activity, alerts, events, infrastructure, subordinate stats, cold-start, game) now flow to COMPOSE alongside the brief. max_tokens 1024→1536. 15 tests. Phase 3 complete: Composition briefs stored in AgentWorkingMemory as category="reasoning" entries. New record_reasoning() API, priority 3 in render_context (between actions and conversations), survives stasis via to_dict/from_dict. Chain extracts _composition_brief from ANALYZE results, records human-readable summary post-execution. 15 tests. Phases: (4) EVALUATE brief alignment criterion complete — brief_alignment scored on ward_room_quality + proactive_quality modes with three sub-dimensions (covered_topics, used_evidence, matched_tone); rendered brief block injected into eval LLM prompt; additive-not-gating per DD-7; post-LLM backfill ensures criteria.brief_alignment always present (reason="brief absent" for legacy traces, reason="verdict omitted criterion" for LLM regression); notebook_quality intentionally untouched in v1; early-return paths (bypasses, deterministic rejections) preserved. 7 new tests. (5) NATS schema (deferred to AD-641g). Research: docs/research/ad-645-artifact-mediated-cognitive-chain.md. Related: AD-632 (Cognitive Chain), AD-644 (SA Parity), AD-641g (NATS), AD-639 (Personality Tuning), AD-573 (Working Memory).

AD-646: Universal Cognitive Baseline (Complete, OSS) — Split cognitive context assembly into a universal baseline (agent-intrinsic, all chain executions) and intent-specific extensions. Root cause: AD-644 Phase 2 added innate faculties to the proactive chain path, but implementation depends on context_parts from proactive.py — Ward Room notifications bypass the proactive loop, so agents enter ANALYZE knowing thread content but nothing about themselves. Same agent, same question: one-shot path produces "157/118/85 unread messages, cognitive load at 40-75% of crisis threshold"; chain path produces "I've been conducting routine wellness checks." Design flaw is that context assembly is intent-specific instead of layered — every new chain-eligible intent needs its own AD-644 migration. Fix: split _build_cognitive_state() into _build_cognitive_baseline() (temporal, working memory, episodic, source attribution, ontology, trust/rank — zero external deps, zero async calls) + _build_cognitive_extensions(context_parts) (self-monitoring, notebooks, telemetry). Baseline called unconditionally for all chain executions. Thread analysis and ward_room compose prompts updated to consume baseline keys. ~100 lines across 3 files, zero new modules. Pre-shapes NATS message envelope (baseline = standard payload). Research: docs/research/ad-646-universal-cognitive-baseline.md. Related: AD-644 (SA Architecture), AD-645 (Composition Briefs), AD-641g (NATS), AD-632 (Chain Architecture).*

AD-646b: Chain Cognitive Parity (Complete, OSS) — Close remaining data gaps between chain and one-shot ward_room paths. AD-646 established the universal baseline but six data sources still exist only in one-shot: DM self-monitoring (AD-623), introspective telemetry (AD-588), cold-start note (BF-102), rich source attribution (AD-568d), self-recognition (AD-575), and oracle context (AD-568a). Fix: Part A — two new QUERY operations (self_monitoring for DM thread repetition detection via Jaccard similarity, introspective_telemetry for conditional telemetry snapshot on self-referential queries). Part B — three baseline enhancements (cold-start note from rt.is_cold_start, rich source attribution from _source_attribution dataclass, self-recognition from _detect_self_in_content() regex). Part C — ward_room chain QUERY step updated to dispatch new operations. Part D — thread analysis and compose prompts consume oracle context, self-monitoring, telemetry, self-recognition cue, cold-start note. QUERY results get dedicated rendering (not raw Prior Data dump). ~150 lines across 4 files, zero new modules. Related: AD-646 (Universal Baseline), AD-632 (Chain Architecture), AD-588 (Introspective Telemetry), AD-623 (DM Self-Monitoring).* AD-647: Process-Oriented Cognitive Chains (v1 Complete, OSS, Issue #291) — Implement process-oriented cognitive chains distinct from the communication chain. The current cognitive chain (AD-632) was designed for communication: read thread → analyze relevance → compose reply. But agents have duties that are processes — structured data pipelines with their own step sequences. The scout report (search→classify→store→notify) is the first case: BF-209 exposed that the communication chain bypasses act(), losing the structured pipeline entirely. Process chains define their own step types: QUERY (data gathering), TRANSFORM (classification/enrichment), STORE (persistence), NOTIFY (routing). Each step has its own prompt template or deterministic handler. AD-618 (Bills/SOPs) provides the declarative YAML process definitions; AD-595 (Billets) provides role-based assignment; AD-641g (NATS) enables async step decoupling. Scout report is the reference implementation; pattern generalizes to incident response, qualification testing, maintenance procedures. Related: AD-632 (Chain Architecture), AD-643a (Intent Routing), BF-209 (Scout chain bypass fix).*

AD-647b: Process Chains — Chain Registry & BF-209 Bypass Removal (Complete, OSS, Issue #404) — Generalize the process chain registry beyond the single SCOUT_REPORT_CHAIN. v1 hardcodes one chain definition; AD-647b adds a ProcessChainRegistry with declarative chain registration, discovery, and the ability to remove the BF-209 communication-chain bypass that v1 still depends on. Depends on: AD-647 v1 (COMPLETE). Related: AD-643a (Intent Routing), BF-209.*

AD-647c: Process Chains — Bills/Watch Bill/NATS Integration (Complete, OSS, Issue #405) — Wire process chains into the Bills/SOPs framework (AD-618) and Watch Bill scheduling, with LLM-template step handlers alongside CALLABLE handlers. Enable NATS-decoupled step execution (AD-641g dependency). v1 ships CALLABLE handlers only; AD-647c adds LLM-prompted step types and NATS async dispatch. Depends on: AD-647 v1 (COMPLETE), AD-618 (Bills — COMPLETE), AD-641g (NATS Pipeline). Related: AD-595 (Billets).* AD-648: Post Capability Profiles (Complete, OSS, Issue #292) — Extend ship's ontology with structured per-post capability profiles to prevent conceptual confabulation. Confabulation audit found 628 contaminated Ward Room posts (11.8%), 90+ contaminated episodic memories, 10+ confabulated notebook entries — all from agents inventing wrong mental models about what roles do. Existing guards (BF-204, AD-592) catch data confabulation (fake IDs, numbers) but not conceptual confabulation (agents inventing capabilities that don't exist). The ontology says WHO agents are but not WHAT they do. Fix: add capabilities (structured list with tool references) and does_not_have (negative grounding) to each post in organization.yaml. Wire through get_crew_context() into _ontology_context prompt injection. Cross-agent capability lookups let agents know what peers actually do. Phase 1: YAML declarations for all 18 posts. Phase 2: PostCapability dataclass + service extension. Phase 3: prompt rendering + QUERY-step cross-agent lookups. OSS foundation — commercial ACM/ASA consume capability profiles for workforce management, resource matching, and marketplace profiles. ~5 files, zero new modules. Issue #292. Related: AD-429 (Vessel Ontology), AD-427 (ACM Core), AD-428 (Skill Framework), AD-496 (Workforce Scheduling), AD-592 (Confabulation Guard). AD-649: Communication Context Awareness for Cognitive Chain (Complete, OSS) — Add prescriptive communication context to the cognitive chain so COMPOSE adapts register based on channel type and audience. Chain produces formal, clinical output regardless of context — COMPOSE has no awareness of whether it's composing for a DM, bridge channel, recreation channel, or department discussion. Two agents (Ezri, Nova) independently diagnosed the same failure when shown their chain vs one-shot output. Fix: derive _communication_context from existing channel_name (5 registers: private_conversation, bridge_briefing, casual_social, ship_wide, department_discussion), add context to ANALYZE composition_brief tone guidance, add "Speak in your natural voice" + register-specific framing to COMPOSE. LLM Independence Principle: encode register expectations prescriptively so behavior doesn't depend on emergent model capability. ~80 lines across 2 files, 14 tests, zero new modules. Issue #293. Related: AD-639 (Trust-Band Tuning), AD-645 (Composition Briefs), AD-646/646b (Cognitive Baseline/Parity). AD-650: Analytical Depth Enhancement (Complete, OSS, Issue #294) — Enriched the composition brief with a narrative reasoning field and added depth instructions to COMPOSE so the cognitive chain surpasses one-shot quality on analytical depth. AD-649 achieved register/tone parity; 7 A/B tests revealed chain wins on breadth (more crew refs, cumulative case-building) but loses on depth (counterarguments, coined vocabulary, diagnostic insights). Root cause: composition brief is an information bottleneck — ANALYZE compresses reasoning to structured fields, losing conditional logic. Research: CoT (Wei et al. — reasoning tokens are load-bearing), DSPy (Stanford — field descriptions are optimization targets), Lost in the Middle (Liu et al. — context positioning), Self-Refine (Madaan et al. — can't recover info never passed through bottleneck), OpenMythos/COCONUT (input re-injection). Fix: Part A — added analytical_reasoning narrative field to all 3 ANALYZE modes, reframed brief from "plan for composing" to "analytical reasoning and composition plan." Part B — COMPOSE renders reasoning section, bold-header suppression for ALL Ward Room branches (not just private/DM), depth instruction ("Don't just summarize — interpret") in all compose modes. ~120 lines across 2 files, 12 tests, zero new modules. Related: AD-645 (Composition Briefs), AD-646/646b (Cognitive Baseline/Parity), AD-649 (Communication Context).*

AD-651: Standing Order Decomposition for Cognitive Chain Steps (Complete, OSS, Issue #299)* — Decompose monolithic standing orders into step-specific billet instructions for the cognitive chain. Standing orders were designed for the one-shot world where a single LLM call played every cognitive role. The chain decomposes cognition into steps but injects the same ~2K token document at both ANALYZE and COMPOSE. BF-213 exposed the consequence: ANALYZE's step framing ("Silence is professionalism") overrides the action vocabulary buried in standing orders — the "When to act vs. observe" decision tree exists but carries less weight than the proximal instruction. The one-shot path worked because assessment and composition happened in the same call. Implemented: StepInstructionRouter slices composed standing orders by <!-- category: ... --> markers, StepInstructionConfig provides step/category mappings, standing orders carry category markers, ANALYZE and COMPOSE call get_step_instructions(), and finalize.py wires the router at startup. Backward-compatible full-text fallback when disabled, unmarked, or unknown step. 20 new tests; 144 focused integration tests passing. Research: docs/research/standing-order-decomposition.md. Related: AD-647 (Process Chains), AD-641g (NATS Pipeline), AD-646 (Universal Baseline), BF-213 (Analyze Silence Bias), AD-632 (Chain Architecture).

AD-651a: Compose Billet Instructions — Proposal Format & Duty Report Framing (Complete, OSS, Issue #301)* — First practical application of the Billet Instruction Principle (AD-651). Two output types the prior crew produced reliably are absent under the chain pipeline: improvement proposals (zero in 8+ hours despite active discussion) and structured duty reports (duties execute but produce generic observations identical to ad-hoc posts). Root cause: COMPOSE tells the LLM "refer to your standing orders for action tag syntax" for proposals — the [PROPOSAL] block format is buried in ~2K tokens. Duty framing says "compose a Ward Room post (2-4 sentences)" and offers [NO_RESPONSE], contradicting standing orders which say silence during duty is dereliction. Fix: (A) Inject [PROPOSAL] block syntax directly into compose prompt when ANALYZE returns "proposal" in intended_actions — prescriptive format, not document navigation. (B) Replace duty compose framing with structured Findings/Assessment/Recommendation format, remove [NO_RESPONSE] option from duty cycles. ~30 lines in compose.py, 10 tests. Related: AD-651 (parent), BF-213 (Analyze Silence Bias), AD-644 (Duty Context), AD-645 (Composition Briefs).

AD-652: Cognitive Code-Switching — Unified Pipeline with Contextual Modulation (Realised, OSS, Issue #302)* — Architectural principle adopted 2026-04-20 based on cognitive science research (Levelt, Halliday, Giles, Snyder, Weick/Sutcliffe). The cognitive chain is a single unified pipeline, not parallel pipelines for different communication types. Different cognitive tasks are handled through contextual modulation: variable chain depth, tenor-aware compose framing, and structured format overlays (billet instructions). Six principles: (1) Unified Pipeline — one chain framework, identity continuity; (2) Contextual Modulation — field/tenor/mode parameters (Halliday) modulate chain behavior; (3) Structured Format Overlays — institutional outputs get prescriptive billet instructions as cognitive scaffolding (HRO research); (4) Variable Chain Depth — high-structure tasks get more steps, low-structure tasks fewer; (5) Character-Driven Self-Monitoring — code-switching range varies by Big Five personality (Snyder); (6) Process-Specific Chains — different tasks can have different step compositions, but same-process tasks share the chain and modulate parameters. Realised in (Wave 95 close, 2026-05-07): AD-632 (SubTaskExecutor unified-pipeline substrate at cognitive/sub_task.py:172); AD-649 (derive_communication_context at cognitive_agent.py:59, sets _communication_context at cognitive_agent.py:2223 — channel/recipient → 5-register field/mode inference); AD-639 (chain trust band at cognitive_agent.py:2055-2062 — tenor weighting); AD-650 (analytical_reasoning narrative field — depth modulation); AD-651 (StepInstructionRouter — billet instructions as structured format overlays); AD-651a ([PROPOSAL] block + Findings/Assessment/Recommendation duty format — first practical billet application); AD-647 / AD-647c (process chains framework — variable depth + process-specific composition, distinct from communication chain); AD-653 Layer 1 (speak-freely intended_action with trust-gated authorization — character-driven register shifting). Downstream consumers AD-655 / AD-656 / AD-657 / AD-658 / AD-659 v1 / AD-660 all complete and reference AD-652 modulation parameters. Research: docs/research/cognitive-code-switching-research.md. Related: AD-651 (Billet Instructions), AD-639 (Chain Personality Tuning), AD-647 (Process Chains), AD-632 (Chain Architecture).

AD-653: Dynamic Communication Register — Self-Monitored Register Shifting (Complete, OSS, Issue #303)* — First-of-kind capability: agents self-monitor their communication register, detect when assigned register constrains important output, and request a temporary shift ("speak freely" protocol). Layer 1 (delivered): ANALYZE prompt extended with speak_freely intended_action for thread_analysis and situation_review modes (DMs excluded — already warm/conversational). COMPOSE trust-gates authorization (≥0.7 auto-granted, 0.4-0.7 flagged to Counselor, <0.4 denied). Billet instruction pattern (AD-651a) injects "speak freely" framing. Events: REGISTER_SHIFT_GRANTED/DENIED emitted, Counselor subscribes + dispatches. 14 tests. Deferred (Layers 2-3): Register taxonomy enum, Big Five → default register mapping, shift frequency analytics, modulation pattern templates. Prior art survey confirmed no existing framework implements self-monitored register shifting. Research: docs/research/dynamic-communication-register-research.md. Depends on: AD-652, AD-504 (Self-Monitoring), AD-651a (Billet Instructions). Related: AD-506 (Self-Regulation), AD-639 (Chain Personality Tuning).

Meta-Harness Research Wave (AD-683, AD-655–661)

Derived from "Meta-Harness: End-to-End Optimization of Model Harnesses" (Lee et al., Stanford/UW, March 2026, arXiv:2603.28052). Key finding: changing the harness (context assembly, retrieval, prompt construction) around a fixed LLM produces a 6× performance gap. Empirical validation of ProbOS's "collaborative intelligence through architecture" thesis. See research memory: research_meta_harness.md.

AD-683: Ship State Snapshot for Cold-Start Onboarding (Complete, OSS, Issue #313, renumbered from AD-654 on 2026-04-30 to resolve collision with #322 UAAA) — v1 ships builder + capture-at-activation + DM-path render. New src/probos/onboarding/ship_state_snapshot.py with three frozen dataclasses (DepartmentSummary, WardRoomTopicSummary, ShipStateSnapshot) and ShipStateSnapshotBuilder service (single public async build() aggregating runtime.ontology vessel/department state, runtime.work_item_store.list_work_items(status="open", limit=5), and runtime.ward_room.list_channels()/list_threads(...) recent topics; each per-source collector wrapped in tier-2 log-and-degrade try/except). ShipStateSnapshotConfig(enabled=True) Pydantic model + Field(default_factory=...) wiring to SystemConfig.ship_state_snapshot. Public runtime.ship_state_snapshot (the builder; mirrors AD-508 DutyScopeProvider naming) installed by sync _wire_ship_state_snapshot at startup/finalize.py. BootCampCoordinator.__init__ extended with optional ship_state_builder kwarg (backward-compat preserved); at end of activate() (after BOOT_CAMP_ACTIVATED emit) builder is awaited and result stored on public coord.ship_state_snapshot. cognitive_agent._build_user_message DM branch prepends --- Ship State Snapshot --- block when observation["_boot_camp_active"] and snapshot resolves via runtime.boot_camp.ship_state_snapshot. New EventType SHIP_STATE_SNAPSHOT_CAPTURED with counts-only payload (privacy-conservative per AD-530). 8 tests. Deferred: AD-683b (per-agent personalization), AD-683c (deltas/refreshes), AD-683d (federation sync), AD-683e (chain-path injection), AD-683f (WR post-path injection), AD-683g (persistence). Depends on: AD-638 (Boot Camp Onboarding). Related: AD-644 (Situation Awareness), AD-646 (Universal Cognitive Baseline), BF-034 (cold-start suppression).

AD-655: Contrastive Memory Retrieval for Cognitive Chain (complete, OSS, Issue #314) — When the cognitive chain retrieves episodic memories for evaluate() or reflect(), include contrastive pairs — episodes where similar situations led to different outcomes. Meta-Harness discovered that "label-primed query variant" with contrastive examples sharpened discrimination without increasing total context. ProbOS equivalent: cognitive chain gets relevant memories but no near-miss contrast ("here's what you did last time, and here's a similar situation where the outcome differed"). Deliverable: retrieve_contrastive_episodes() method on EpisodicMemory, integration into _gather_context() episode retrieval path. Depends on: AD-639 (Chain Personality Tuning — establishes A/B baseline). Related: AD-645 (Composition Briefs), AD-541 (Memory Consolidation Integrity).

AD-656: Department-Specific Cognitive Profiles (complete, OSS, Issue #315) — Define per-department cognitive profile overrides (retrieval depth, reranking strategy, context budget allocation) as configuration in organization.yaml, consumed by the cognitive chain's modulation parameters. Meta-Harness discovered optimal retrieval strategies differ radically by domain (combinatorics: 20 candidates deduped to 8; geometry: 1 fixed reference + 2 neighbors; number theory: 12 with technique-based reranking). ProbOS equivalent: Hebbian routing learns weights but all departments use identical retrieval and reasoning strategies. Science agents may need deeper episodic retrieval; Security may need fewer but higher-confidence retrievals. Deliverable: CognitiveProfile config section per department, consumed by AD-652 code-switching field/tenor/mode parameters. Depends on: AD-652 (Cognitive Code-Switching). Related: AD-560 (Science Analytical Pyramid), AD-648 (Post Capability Profiles).

AD-657: Dream Consolidation Trace Preservation (Complete, OSS, Issue #316) — Preserve "trace exemplars" — the 2-3 most diagnostically rich raw episodes per consolidated dream pattern, stored alongside the abstraction. Meta-Harness ablation showed full execution traces scored 50.0% median vs 34.9% for summaries — summaries actually degraded performance by discarding diagnostic detail. ProbOS equivalent: dream consolidation compresses episodes into abstract patterns, potentially discarding the most valuable diagnostic material. When an agent encounters a situation matching a consolidated pattern, it should access original traces, not just the summary. Deliverable: trace_exemplars field in consolidated dream entries, retention policy in dream Step 7, retrieval path in _gather_context(). Risk: storage growth — mitigate with retention cap (max N exemplars per pattern, oldest evicted). Standalone — no hard dependencies. Related: AD-551 (Dream Step 7g Consolidation), AD-541 (Memory Consolidation Integrity), AD-557 (Emergence Metrics).

AD-658: Cognitive Chain Harness Metrics (Complete, OSS, Issue #317) — Instrument the cognitive chain to emit per-step execution traces: input token count, output quality signals, step latency, context composition breakdown, which modulation parameters were active. Meta-Harness core insight: the cognitive chain IS a harness; you can't optimize what you can't measure. This is the measurement substrate that makes future optimization (AD-660) possible. Deliverable: ChainExecutionTrace dataclass, emission in each chain step, CognitiveJournal storage, API endpoint /api/chain-traces. Depends on: AD-652 (Code-Switching gives modulation parameters to measure against). Related: AD-645 (Composition Briefs), AD-632 (Chain Architecture).

AD-659: Cognitive Chain Self-Optimization Loop (✅ v1 — analysis only, OSS, Issue #318) — An infrastructure service (or Meridian/First Officer duty) that reviews cognitive chain execution traces (AD-658), identifies patterns of failure or suboptimal outcomes, and proposes chain parameter adjustments. Meta-Harness outer-loop pattern: propose → evaluate → store traces → iterate. v1 ships propose + Captain approval surface only — apply_proposal() raises NotImplementedError (apply path deferred to AD-659b). Three pure detectors over chain_traces: latency p95 regression (proposes tier shift), success-rate floor breach (proposes ChainTuningConfig threshold nudge), high error rate by chain_source (observation-only review flag). REST: GET /api/chain-optimizer/proposals + POST /api/chain-optimizer/proposals/{id}/decide (records decision; applied: False until AD-659b). Default-disabled (ChainOptimizerConfig.enabled=False); Captain opts in once AD-658 baseline accumulates. This is NOT automated prompt rewriting — it's parameter tuning within the Code-Switching modulation space (AD-652). Guard rails per #318: Captain approval required (HXI Cockpit View Principle), A/B testing mandatory (deferred AD-659b), rollback on regression (n/a until apply lands), Counselor monitors for agent distress from parameter changes (deferred AD-659c). v1 deliverable: OptimizationProposal dataclass + ChainOptimizer service + ChainOptimizerConfig + _wire_chain_optimizer + routers/chain_optimizer.py. AD-659b (Future, OSS) — apply path + A/B testing framework + proposal persistence (SQLite table) + dedup keyed by (detector_name, target_parameter) + scheduled analyze loop. AD-659c (Future, OSS) — Counselor regression watchdog wiring (depends on AD-659b apply path). Depends on: AD-658 (metrics substrate), AD-652 (Code-Switching), AD-639 (personality baseline). Related: AD-557 (Emergence Metrics), AD-504 (Self-Monitoring).

AD-660: Agent Causal Reasoning Framework (Complete v1, OSS, Issue #319) — Formalize metacognitive causal reasoning for agents encountering unexpected outcomes. Meta-Harness proposer demonstrated sophisticated causal reasoning: identified confounded variables across regressions, isolated them, formed testable hypotheses. ProbOS had informal precedent (Ezri's self-diagnosis, AD-504 self-monitoring) but no structured reasoning template. v1 ships template + journal storage + one opt-in integration point ONLY: CausalReasoningTemplate frozen dataclass (four list fields + LLM self-reported confidence), CausalReasoner service that calls LLM with structured prompt and parses JSON (degrades to empty template on any failure), CognitiveJournal.record_causal_template()/get_recent_causal_templates() mirroring AD-658 chain-trace persistence, CausalReasoningConfig(enabled=False), and one guarded hook in counselor._on_self_monitoring_concern. With default config, the framework is invisible at runtime. Forward refs: AD-660b (AD-557 emergence-event hook + automatic invocation + /api/causal-templates router); AD-660c (diagnostic-action surfacing as Captain-actionable proposals); AD-660d (join with ChainOptimizer proposals on source_event_ref). 8 new tests. Depends on: AD-504 (Self-Monitoring), AD-557 (Emergence Metrics — surface available, hook deferred to AD-660b). Related: AD-643b (Skill Trigger Learning), AD-539 (Gap Detection), AD-659 (Chain Self-Optimization).

AD-662: Corroboration Source Provenance Validation (Complete, OSS, Issue #331) — Extend SocialVerificationService (AD-567f) with source provenance metadata. Three new AnchorFrame fields (source_origin_id, artifact_version, anomaly_window_id) enable ancestry-based independence checks — two observations sharing the same source artifact are NOT independently anchored, regardless of spatiotemporal separation. Anomaly window observations contribute at config-driven discounted weight (default 0.5) to independence scoring. Infrastructure-only (consumer-side validation); AD-663 wires producers to populate provenance fields. BF-226/227 demonstrated the failure mode: queue-pressure-generated artifact versions appeared to corroborate each other but shared corrupted ancestry. First crew improvement proposal from this instance — submitted by Reed (Science), independently corroborated by Ezri (Bridge) and Sentinel (Security). 13 new tests. Extends: AD-567f (Social Verification Protocol). Related: AD-660 (Causal Reasoning), AD-657 (Dream Trace Preservation), AD-541 (Memory Consolidation Integrity).

AD-663: Provenance Producer Wiring (Complete, OSS, Issue #355) — Populate source_origin_id and artifact_version on AnchorFrame at 4 episode producer sites: Ward Room replies/threads, proactive thoughts, cognitive agent actions. Dream consolidation reflections deferred (deterministic IDs already provide dedup). Enables AD-662 consumer-side ancestry detection and AD-665 graded version scoring. WR posts use wr-post:{id} / wr-thread:{id} origin prefixes with SHA-256 body hash versioning. Proactive agents use observed WR post IDs. Cognitive agents use correlation_id from event tracing. anomaly_window_id deferred to future AD (no automated anomaly detection infrastructure). 13 tests. Depends on: AD-662 (consumer infrastructure — COMPLETE). Unlocks: AD-665 (graded source validation).

AD-664: EventLog Diagnostic Infrastructure — Structured Payloads + Query Authority (Complete, OSS, Issue #337) — Structured payload (data JSON column), correlation_id, parent_event_id tracing columns added to EventLog schema. Idempotent migration for existing DBs. log() extended with keyword-only params (zero existing callers break), now returns row ID for parent chaining. query_structured() for correlation/event filtering, get_event_chain() for parent-chain traversal, _row_to_dict() DRY helper. Retrofitted dream/emergent (DreamAdapter), mesh (intent_broadcast/resolved), and QA (smoke test) events with structured payloads + correlation IDs. Engineering diagnostic query capability declared on EngineeringAgent (capability + _handled_intents + LLM instructions); programmatic handler deferred. Crew-originated: Forge + Anvil (5 proposals). 17 tests.

AD-665: Corroboration Source Validation (Complete, OSS, Issue #343) — Consumer-side independence validation for corroborating sources in SocialVerificationService. Replaces AD-662's binary shared-ancestry veto with graded version-aware scoring in compute_anchor_independence(): same-origin-different-version pairs receive configurable retained independence weight (default 0.7), while same-origin-same-version pairs remain vetoed. Adds ProvenanceValidationResult diagnostic reporting in CorroborationResult.anchor_summary, privacy-preserving ancestry_details (episode IDs + reason + weight only), and CORROBORATION_PROVENANCE_VALIDATED events. Transitive ancestry graph walking deferred to a future AD because AnchorFrame has no lineage field yet. 16 new tests. Third batch of crew improvement proposals — submitted by Reed (Science), independently flagged across 4 proposals. Depends on: AD-663 (producer wiring — COMPLETE), AD-662 (infrastructure — COMPLETE). Related: AD-567f (Social Verification Protocol), AD-660 (Causal Reasoning), BF-226/227 (queue-pressure corroboration failure).

AD-661 + AD-661b + AD-661c: Full Diagnostic Context for Agent Self-Improvement (Complete v1, OSS, Issues #320 + #412 + #413) — Pull-based, token-budgeted assembly of raw diagnostic artifacts (AD-658 chain traces + AD-657 procedure trace exemplars + deduped exemplar episodes + AD-434 Ship's Records). Wave 33 shipped v1 (3 tiers, 40/30/30 split). Wave 45 combo extension shipped AD-661b (Ship's Records as 4th tier via synthetic system reader; ship/fleet classification surfaced naturally) + AD-661c (two-pass budget allocation with optional remainder redistribution in priority order chain_traces > procedures > episodes > records; default-on). Default split now 30/25/25/20. New _TIER_PRIORITY constant + _fill_with_redistribution helper centralizes budget bookkeeping. Module-level caps _MAX_RECORDS_CANDIDATES=30, _RECORDS_CONTENT_EXCERPT_CHARS=1200, _RECORDS_READER_ID="_diagnostic_context_system". New ctor kwargs records_ratio + redistribute_remainder. New Pydantic config fields records_ratio + redistribute_remainder. Forward refs: AD-661d (semantic-search via EpisodicMemory.recall()), AD-661e (LLM summary fallback when over-budget), AD-661f (per-agent records authorization). 21 tests total (8 v1 + 13 new). Depends on: AD-658 (chain traces — COMPLETE), AD-657 (trace preservation — COMPLETE), AD-434 (Ship's Records — COMPLETE, consumed via list_entries/read_entry). Related: AD-560 (Science Analytical Pyramid), AD-644 (Situation Awareness), AD-692 (edge classification — orthogonal taxonomy).

Ambient Awareness & Optimal Working Memory Wave (AD-666–672)

Derived from research document docs/research/ambient-awareness-optimal-working-memory.md. Triggered by BF-239 observation: adding thread engagement awareness to working memory produced disproportionate improvement in Ward Room interaction quality. Investigation revealed ProbOS has been organically building an "agent sensorium" across 15+ ADs (~80% complete) without naming the pattern. This wave formalizes the concept and delivers the remaining ~20%: named buffers, salience filtering, cross-thread coordination, memory metabolism, and capacity management. Theoretical foundations: GWT (Baars), ACT-R buffer model (Anderson), Endsley SA, SOAR impasse-driven learning, LIDA (Franklin), Springdrift ambient self-perception (Brady 2026). 30 academic sources cited in research doc.

AD-666: Agent Sensorium Formalization (Closed, OSS, Issue #347) — Named and formalized the existing context injection methods in CognitiveAgent as the "Agent Sensorium" — the agent's structured self-state snapshot. Delivered SensoriumLayer (proprioception/interoception/exteroception), SENSORIUM_REGISTRY, aggregate char-budget tracking in the chain path, SensoriumConfig, SENSORIUM_BUDGET_EXCEEDED event/dataclass, and injection ordering audit documentation in _build_user_message. Phase 1 completion of Ambient Awareness roadmap. 14 tests. Related: AD-573 (WM foundation), AD-644 (SA pipeline), AD-646 (cognitive baseline), AD-504 (self-monitoring).

AD-667: Named Working Memory Buffers (Complete, OSS, Issue #348) — Added four named buffers: Duty, Social, Ship, and Engagement as a parallel index alongside existing AgentWorkingMemory ring buffers. Existing record_* methods dual-write to legacy storage and the mapped named buffer; render_context() remains unchanged for backward compatibility. New render_buffers() enables selective context access for future chain routing, and to_dict() / from_dict() now persist named buffer state while legacy persistence gracefully restores with empty named buffers. Per-buffer token budgets are configured in WorkingMemoryConfig. 15 new tests; 43 working-memory tests passed. Depends on: AD-666 (sensorium formalization). Related: AD-573 (current WM), AD-632 (cognitive chain consumer).

AD-668: Salience Filter (Complete, OSS, Issue #349) — Added a pure SalienceFilter scoring function for working memory promotion: relevance, recency, novelty, urgency, and social dimensions with configurable weights and threshold. Events above threshold enter main working memory; sub-threshold events are captured in a capped BackgroundStream for future idle-cycle review. SalienceConfig exposes the filter settings, NoveltyGate integration is optional with neutral fallback, and AgentWorkingMemory can opt into promotion gating without changing default behavior. 35 new tests; 57 working-memory regression tests passed. Depends on: AD-667 (named buffers — target for promotion). Related: AD-493 (novelty gate component), AD-633 (idle-time consumer).

AD-669: Cross-Thread Conclusion Sharing (Complete, OSS, Issue #350) — Added a ConclusionLog mechanism in AgentWorkingMemory for intra-agent coordination between concurrent thought threads. ConclusionEntry records thread ID, type, one-line summary, timestamp, relevance tags, and optional AD-492 correlation ID. Sibling conclusions render as priority 6 working-memory context with TTL-based decay and are injected before decide(); new lifecycle helpers classify and record conclusions after act/report. 16 new tests; CognitiveAgent and working-memory regressions passed. Depends on: AD-667 (conclusions need the Engagement buffer). Related: AD-492 (correlation IDs), BF-239 (current boolean thread awareness).

AD-670: Working Memory Metabolism (Complete, OSS, Issue #351) — Active maintenance operations for working memory, replacing passive FIFO eviction with intelligent lifecycle management. Four operations: TRIAGE — score incoming events for relevance and priority before buffer entry; DECAY — time-weighted salience reduction, recent events outweigh stale ones within the same priority tier; AUDIT — consistency checking to detect contradictory entries in working memory; FORGET — active removal of low-value entries based on decay score rather than ring position. Configurable thresholds per operation. Background execution during idle cognitive cycles. Depends on: AD-667 (metabolism operates on named buffers). Related: AD-551 (dream consolidation — episodic layer), AD-573 (current ring buffer eviction).

AD-671: Dream-Working Memory Integration (Complete, OSS, Issue #352) — Bidirectional pipeline between working memory and dream consolidation. Pre-dream: Flush active working memory entries to episodic memory as session summaries — "here's what I was thinking about today." WM usage patterns (what did I track most? what caused context switches?) inform consolidation priorities. Post-dream: Dream insights seed the next session's working memory priming — "yesterday I learned that latency anomalies correlate with queue pressure." Connects working memory lifecycle to the existing dream cycle (Steps 1-9) without modifying dream architecture. Depends on: AD-670 (metabolism provides the decay/triage scores that inform flush priorities). Related: AD-551 (Dream Step 7g Consolidation), AD-557 (Emergence Metrics — dream Step 9), AD-657 (trace preservation).

AD-672: Agent Concurrency Management (Complete, OSS, Issue #353) — Per-agent concurrency control for thought threads. Concurrency ceiling: Configurable max concurrent threads per agent, role-tuned (Bridge: 2-3, Operations: 5-7, default: 3-5). Capacity signal: AGENT_CAPACITY_APPROACHING event emission when nearing ceiling, enabling Hebbian + capacity-weighted intent routing and chief work redistribution. Priority arbitration: When two threads compete for the same resource (e.g., posting to the same Ward Room channel), priority resolution instead of race condition. Queue management: Excess intents queue with priority ordering rather than spawning unbounded threads. Based on Wickens' Multiple Resource Theory and the diminishing returns analysis in Section 7.2 of research doc. Depends on: AD-669 (capacity management needs conclusion sharing for informed scheduling). Related: BF-239 (current ActiveEngagement tracking), AD-654b (cognitive queue infrastructure).

Provenance & Anomaly Detection (AD-673)

AD-673: Automated Anomaly Window Detection (Complete, OSS, Issue #356) — AnomalyWindowManager populates AnchorFrame.anomaly_window_id for episodes stored during active anomaly windows. Windows are triggered by trust cascade warnings and LLM health degradation events through the _add_event_listener_fn callback pattern, with healthy LLM status closing the active window. The implementation uses a single concurrent window model, emits open/close events, auto-expires stale windows, and stamps episodes in EpisodicMemory.store() via dataclasses.replace() on frozen AnchorFrame. Retrospective tagging is intentionally deferred as a stub-only interface. 14 tests. Depends on: AD-662 (AnchorFrame field — COMPLETE), AD-663 (producer wiring — populates provenance fields). Related: AD-558 (trust cascade dampening — signal source), AD-665 (corroboration validation — consumer of anomaly discounts).

Ambient Intelligence Absorption Wave (AD-674–679)

Absorbed from Chen et al. 2026 "Designing Digital Humans with Ambient Intelligence" (arXiv:2604.05120). Paper presents a framework for integrating ambient intelligence with conversational agents. ProbOS already covers multi-agent social fabric (Ward Room), continuous learning (dream consolidation), transparency (Westworld Principle), and multi-channel presence (Shell/HXI/Discord). This wave absorbs six concepts that are genuinely new or formalize implicit patterns: graduated initiative, uncertainty-calibrated assertiveness, action risk tiers, context provenance, memory transparency, and selective disclosure routing. Together they create a principled model for "how assertive should an agent be, about what, to whom?" — replacing binary proactive/reactive behavior with nuanced, confidence-modulated, risk-aware agency.

AD-674: Graduated Initiative Scale (Complete, OSS, Issue #362) — Five-level initiative continuum implemented as InitiativeLevel DIRECTED → RESPONSIVE → CONTRIBUTORY → PROACTIVE → STRATEGIC. resolve_initiative_level() maps rank plus trust into graduated initiative without replacing the existing AgencyLevel gates, EarnedAgencyConfig.initiative_trust_thresholds lets operators tune Ensign/Lieutenant/Commander graduation thresholds, and CognitiveAgent baseline metrics expose initiative alongside trust, agency, and rank. Related: AD-502–506 (self-regulation wave — restraint axis), AD-504 (self-monitoring), AD-506a (graduated zones).

AD-675: Uncertainty-Calibrated Initiative (Complete, OSS, Issue #363) — Added UncertaintyContext for aggregating Oracle, health, and data-freshness confidence and calibrate_initiative() to clamp AD-674 initiative levels downward under uncertainty. High confidence preserves the trust-limited maximum; low confidence clamps down one level; critical confidence clamps down two levels with a DIRECTED floor. Addresses epistemic degradation by making low-confidence agents automatically more tentative. 6 tests. Depends on: AD-674 (initiative scale). Related: AD-444 (confidence tracker foundation), epistemic degradation research.

AD-676: Action Risk Tiers (Complete, OSS, Issue #364) — Added unified RiskTier classification for agent-executable actions with ROUTINE/ELEVATED/CRITICAL policies, ActionRiskRegistry, default Ward Room/remediation/system classifications, config-driven trust thresholds, EventType.ACTION_RISK_DENIED, and finalize-time _risk_registry wiring. Risk is a property of the action type, not the executing agent. Related: AD-357 (earned agency — trust-based capability), AD-339 (standing orders — policy framework), AD-672 (concurrency management — capacity-level gating).

AD-677: Context Provenance Metadata (Complete, OSS, Issue #365) — Added ProvenanceTag and ProvenanceEnvelope for context metadata with source tier, retrieval timestamp, confidence, content hash, inline rendering, and staleness detection. query_with_provenance() wraps Oracle results without changing OracleService or TieredKnowledgeLoader return values. TieredKnowledgeLoader now emits EventType.CONTEXT_PROVENANCE_INJECTED alongside tier-load telemetry. Enables AD-678 transparency and AD-679 disclosure routing. 11 tests. Depends on: AD-666 (sensorium layers — provenance attaches per-layer). Related: AD-492 (correlation IDs — complementary tracing), AD-662 (anchor frame provenance fields), AD-673 (anomaly window stamping).

AD-678: Memory Transparency Mechanism (Complete, OSS, Issue #366) — Added MemoryProvenance, TransparentMemory, and MemoryTransparencyService to wrap recalled episodes with source agent, age, similarity-derived confidence, source channel, and own-memory metadata. Supports prompt rendering and confidence filtering while leaving EpisodicMemory.recall(), storage format, and Episode unchanged. 7 tests. Depends on: AD-677 (provenance metadata — the data transparency exposes). Related: AD-505 (Counselor therapeutic intervention — wellness perspective on epistemic state), Westworld Principle (philosophical foundation).

AD-679: Selective Disclosure Routing (Complete, OSS, Issue #367) — Added formal disclosure classification with DisclosureLevel (PUBLIC through CLASSIFIED), department default clearances, agent-specific overrides, per-recipient DisclosureDecision results, and a DisclosureRouter filter layer. Also added EventType.DISCLOSURE_FILTERED, /api/disclosure-clearances, and finalize-time runtime wiring. IntentBus fan-out remains unchanged; callers explicitly use the router to narrow recipients. Depends on: AD-677 (sensitivity field drives inference). Related: AD-407 (Ward Room channels — enforcement point), AD-339 (standing orders — policy source for classification rules).

AD-680: Runtime Public API Promotion (Complete, OSS) — Promoted runtime event emission and emergence metrics access to public surfaces: runtime.emit_event() now advertises EventType support, runtime.emergence_metrics_engine exposes the existing read-only engine reference, and external modules were migrated off runtime._emit_event / runtime._emergence_metrics_engine. Establishes the one-shot private→public migration precedent: no deprecation warning when private access was never a supported extension point. 4 new tests; focused AD-680 regression gate passed serially.

AD-685: Phantom-API Pre-Check Kwarg Shape Validation (Complete, OSS, Wave 11) — Tooling hygiene. Extends scripts/phantom-api-precheck.ps1 (Wave 8 Addendum convention #16) with a Python AST helper (scripts/phantom_api_ast_helper.py) that validates method-kwarg shapes in prompt bodies against live signatures from src/probos/. Catches the class of phantom that slipped past the existing symbol-existence check across Waves 9B+10 (event_log.query(event_type=...) where the real param is event= on query_structured; wrong-kwarg variants of valid methods). Ships with a shared heuristic pre-filter applied uniformly to BOTH the existing symbol check and the new kwarg check (resolves Wave 11 pass-1 Required #1 recursive-validity gap): masks non-Python fenced blocks, ## Revision audit-trail sections, table-row + inline-prose backticked call-shape cites — preserves line numbers via whitespace-of-equal-length replacement. AST index module-level dict cache (cold ~1s indexing 2810 method names; warm ~0.25 ms). Helper accepts kwarg if any same-named definition matches OR any candidate accepts **kwargs. Recursive-validity gate passes — ./scripts/phantom-api-precheck.ps1 prompts/ad-685-phantom-precheck-kwarg-validation.md exits 0 after build (was 1 phantom self-reference before). Calibration sweep across 5 archived prompts (ad-641c-*, ad-500-*, ad-501-*, ad-641d-*, ad-469-*): 0 false positives. 9 focused tests pass (clean prompt → 0 phantoms; Wave 9B + Wave 10 regressions caught; non-Python fences/Revision sections skipped via wrapper pre-filter; same-named-method overload tolerance; wrapper merges symbol + kwarg phantoms; wrapper exit 1 on phantom; shared pre-filter suppresses prose-cite phantoms). v1 ships 2 of 4 capabilities; field-name validation → AD-685b, type-shape validation → AD-685c, receiver-class resolution → AD-685d. Depends on: Wave 8 Addendum convention #16 (original phantom-api-precheck.ps1).

AD-685b: Phantom-API Pre-Check Method-Call AST Validation (Complete, OSS, Wave 15) — Tooling hygiene; extends AD-685 v1. Adds method-name validation: <obj>.<method>(...) call sites in a prompt body get flagged as method_phantom when <method> is NOT defined on the class that <obj> resolves to. Class resolution (conservative, never guess): Pattern A 4-level priority for runtime.X — AnnAssign in runtime.py (self.X: SomeClass) wins over fallback Assign+Call in startup/finalize.py (runtime.X = SomeClass(...)) wins over Assign+Call in runtime.py.__init__ (self.X = SomeClass(...)) wins over unresolved; Pattern B for prompt-body <var> = SomeClass(...) (first-assignment-wins; reassignment-to-different-class → pattern_b_reassignment skip). Class method index walks every ClassDef body — sync + async defs; dunders excluded. Skip-when-unresolved: emits unresolved JSON record (no_class_resolution / pattern_a_conflict / pattern_b_reassignment) instead of false-flagging. JSON schema additively extended with "unresolved": [...] field; existing AD-685 v1 kwarg-mismatch entries unchanged. Wrapper changes minimal: [method_phantom] category prefix + Skipped (unresolved class) informational section after phantoms (zero exit-code impact). AST-only — never imports from src/probos/ (preserves sandbox property). Catches the 4 documented method-shape recurrences across Waves 9B/10/12/14 (event_log.query(event_type=...), WorkItemStore.add(...), runtime.duty_schedule_tracker, LLMClient.chat(...)). Recursive-validity gate passes — pre-check on AD-685b's own prompt produces 0 NEW method_phantom flags (only the 2 documented pre-existing AD-685 v1 FPs from audit prose + JSON placeholder). Calibration sweep: 3 archived post-revision prompts (ad-641c-ward-room-thread-priority, ad-500-dutyscheduler-workitem-migration, ad-487-self-distillation-v1) — 0 false positives across all 3 (Hard-Stop tightened from >5 false positives per prompt to ≥1). Performance: 2.26s cold / 2.17s warm per prompt (well under the 10s ceiling). 11 focused tests pass at tests/test_phantom_api_precheck_method_calls.py: 3 historical-phantom regressions; Pattern A priority-1 + priority-2 resolution; Pattern B prompt-body assignment; conservative no_class_resolution skip; sync + async method walking; dunder exclusion; PowerShell wrapper integration; recursive-validity self-check. v1 ships 1 of 2 capabilities; type-shape validation → AD-685c (deferred), dataclass/Pydantic field-name validation → AD-685d (deferred). Depends on: AD-685 v1 (Wave 11).

AD-685c: Phantom-API Pre-Check — Type-Shape Validation (Complete, OSS, Wave 46) — Tooling hygiene; extends AD-685 v1 (kwarg-name shape) + AD-685b v1 (method-name on resolved class) with kwarg-value type-shape validation: when a prompt asserts obj.method(name=42) and name: str is the live signature annotation, flagged as type_shape_mismatch. Single-file extension to scripts/phantom_api_ast_helper.py (no new package). _collect_param_annotations() collector mirrors _collect_param_names(); build_index() records param_annotations: dict[str, ast.AST] alongside existing params in the same single AST walk (zero extra I/O). Pure-AST TypeShape resolver (_annotation_to_type_shape) handles primitives + Optional + X | None + Union + list/dict/tuple/set with element shapes; unknown classes (e.g. KnowledgeEdge) → unknown=True → SKIP. ValueShape classifier (_value_to_shape) handles ast.Constant for str/int/float/bool/None (bytes → silent skip) + container literals; ast.Name/ast.Call/ast.Attribute → silent skip. _value_matches_shape is conservative — skippable shapes never flag; bool matches int (Python semantics); empty container matches any same-kind container; unknown classes never flag. find_type_shape_phantoms() flags only when ALL applicable candidates have annotations AND NONE match the value. New _jsonable_candidate(c) helper strips AST nodes from emitted records; both kwarg + type-shape phantom emitters route through it. Wrapper scripts/phantom-api-precheck.ps1 adds third elseif type_shape_mismatch dispatch branch rendering as <method>(<kwarg>=<<value_type>> -> expected <<types>>). Backward-compat preserved: AD-685 v1 kwarg records (no category field) and AD-685b method records (category="method_phantom") ship unchanged. 15 focused tests pass at tests/test_ad685c_phantom_type_shape.py (over the 10 floor by 5): primitives + Optional + Union + containers + unknown-class skip + variable-ref/bytes/Name/Call silent skip + str↔str/int↔str + None↔Optional + list[str]/list[int] + bool↔int + Captain-required wrapper self-test. Phantom-API pre-check on this prompt: 0 candidates, clean. Full gate: 11122 passed, 15 skipped (delta +15 vs Wave 45 baseline 11107). v1 ships 1 of 2 remaining capabilities; field-name validation → AD-685d. Depends on: AD-685b (COMPLETE).

AD-685d: Phantom-API Pre-Check — Dataclass/Pydantic Field-Name Validation (Complete, OSS, Wave 47) — Tooling hygiene; fourth capability of scripts/phantom-api-precheck.ps1 extending AD-685/AD-685b/AD-685c. New build_class_field_index() AST walker indexes @dataclass + BaseModel subclasses → {fields, parents, properties, methods, kind}; _resolve_transitive_fields() cycle-safe parent walk. find_field_phantoms() flags constructor kwarg typos (MyDc(typo=...)) and attribute-access typos (obj.typo) against transitive field sets via Pattern B (var = MyClass(...))-resolved receivers. find_property_field_collisions() flags child fields shadowing parent @property or method. New categories field_phantom and property_field_collision flow through PowerShell wrapper dispatch. ClassVar excluded; private-prefix fields skipped; chained access (runtime.X.field) deferred. 12 focused tests pass at tests/test_ad685d_phantom_field_name.py (over 10 floor by 2). Existing 35 phantom-API tests stay green — record-shape stable. Full gate: 11134 passed, 15 skipped (delta +12 vs Wave 46 baseline 11122). Depends on: AD-685c (COMPLETE).

Ship Health Observability — Oracle Telemetry Tier (AD-695)

AD-695: Ship Health Oracle Tier + Threshold Bridge Alerts (Complete, OSS, Issue #389, Wave 43) — Merges AD-641a (Observability Bridge) and AD-466c (Observability Extensions) into unified design. Three components: (1) New Oracle tier "health" — _query_health() method exposes VitalsMonitor metrics, pool states (current/target size, cooldown counts), attention priorities, and DegradationManager status as queryable OracleResults. Crew agents query system health through Oracle during duty cycles or investigations. (2) Threshold alert notifications — bridge loop replaced with threshold-check loop that ONLY posts to bridge channel when metrics cross configurable boundaries (pool saturation >90%, degradation tier escalation, attention queue depth). Uses existing Ward Room notification pattern. (3) Disable Ward Room continuous posting — remove create_post() spam into nonexistent thread; take_snapshot() remains as internal data collection method for Oracle tier and threshold checks. Deprecates: AD-641a Ward Room posting loop (architecturally wrong — telemetry is not discourse). Absorbs: AD-466c deferred scope (observability extensions). Depends on: AD-462e (Oracle — COMPLETE), AD-641a (snapshot collection methods — COMPLETE), AD-466 (infrastructure package — COMPLETE), AD-459 (DegradationManager — COMPLETE). Related: AD-686 (Oracle Tier 5/6 expansion), VitalsMonitor, existing threshold notification system.

Agentic Oracle Retrieval (AD-696)

"The Oracle shapes what I know before I start thinking, but I can't direct it once I'm already thinking." — Crew self-report, 2026-05-04

AD-696: Agentic Oracle Retrieval — On-Demand Ship's Records Query (Scoped, OSS, Issue #416) — Register OracleService as an agent-invocable tool so crew can query Ship's Records on demand during cognitive chain execution, not just at pre-instantiation context gathering. Currently Oracle runs RAG-style during handle_intent() — results are injected as observation["_oracle_context"] before the LLM call. Agents cannot issue targeted queries mid-reasoning when conversation reveals a need for specific records.

(1) Problem: An agent enters a think cycle with whatever the pre-instantiation Oracle sweep surfaced. If the conversation shifts to a topic not anticipated by the initial similarity search, the agent has no mechanism to retrieve additional context. The agent correctly self-diagnosed this: "If something comes up that I didn't anticipate, I'm working from whatever's already in my context window." For counseling, diagnostics, and investigative duties, the ability to pull specific records on demand is essential.

(2) Approach: - New QUERY operation — oracle_lookup added to the chain's QueryHandler dispatch table (cognitive/sub_tasks/query.py). Zero LLM calls (deterministic retrieval like all QUERY operations). Agent specifies query text and optional tier filter. - ToolRegistry registration — Oracle registered as a tool with ToolPermission.READ, gated by RecallTier.ORACLE (same clearance gate as current RAG-style access). Rank-based permission matrix: only ORACLE-tier agents can invoke. - Chain integration — ANALYZE can emit oracle_query in its intended_actions when it determines insufficient context. A new chain step dispatches the query and injects results before COMPOSE. - Query discipline — Agent feedback: "An agent that fires Oracle queries on every uncertainty isn't thinking; it's just searching." Rate-limit or cognitive-need gate to prevent reflexive querying. Consider: only fire when ANALYZE explicitly signals context insufficiency, not on every cycle. - Graph-aware results — Leverage AD-688 Tier 6 graph expansion so agentic retrieval surfaces relational context ("here's how these things connect"), not just flat similarity-ranked lists. Agent feedback: current retrieval feels like "five things that scored above 0.4" without showing why they relate.

(3) Scope: v1 = QUERY operation + ToolRegistry registration + ANALYZE intent signal. Deferred: temporal decay scoring (AD-696b), query intent classification (AD-696c), multi-turn retrieval chains (AD-696d).

Depends on: AD-462e (Oracle — COMPLETE), AD-686-688 (Knowledge Graph tiers — in progress). Related: AD-641g (NATS chain pipeline — async step execution), AD-647 (Process Chains — QUERY step pattern), AD-644 (SA Architecture — context parity).

Unified Knowledge Graph + Oracle Unification (AD-686 through AD-694)

"The Oracle sees all — because all knowledge flows through it."

Inspired by Thoth (triple-store pattern), Microsoft Fabric IQ (capability mapping), and the "AI Meets Brain" survey (Mem0/G-Memory graph-enhanced recall). Unifies ProbOS's 6 fragmented query paths under a single Oracle interface, adds structural knowledge graph for relationship-aware recall. Research: docs/research/unified-knowledge-graph.md.

Phase A: Foundation — Oracle Unification + Graph

AD-686: Oracle Absorbs SemanticKnowledgeLayer (Complete, OSS, Issue #380) — Add _query_semantic() tier method (Tier 5) to OracleService. Oracle constructor gains semantic_layer parameter. Delegates to existing SemanticKnowledgeLayer.search() for ChromaDB collections (agents, skills, workflows, QA reports, events). Migrate direct consumers (introspect.py, organizer_agents.py, /knowledge command) to Oracle. SemanticKnowledgeLayer write-path methods unchanged. Depends on: AD-462e (Oracle — COMPLETE). Related: Phase 21 (SemanticKnowledgeLayer — original implementation).

AD-686b: Oracle Owns SemanticKnowledgeLayer Write-Path (Complete, OSS, Issue #414) — Closes the AD-686 v1 read/write asymmetry. New OracleService.write_semantic(kind, /, **fields) -> bool keyword-dispatcher across the five typed SemanticKnowledgeLayer.index_* methods (agent/skill/workflow/qa_report/event). Tier-2 log-and-degrade: returns False (and logs) on missing layer, unknown kind, or delegation exception; returns True only on successful underlying call. Migrates the five external write-path call sites (runtime.py:2508/3309/3358, self_mod_manager.py:142, routers/chat.py:419) to route through runtime.oracle.write_semantic(...). SemanticKnowledgeLayer write methods unchanged — internal reindex_from_store and ad-hoc test rigs continue to work. runtime._semantic_layer attribute preserved (DLog #3): introspect.py:764 read-path fallback + runtime.py:2974 _semantic_layer.stats() for system-status panel. Rename to _SemanticKnowledgeLayer deferred to AD-686c (needs OracleService.semantic_stats() surface first). Depends on: AD-686 (Tier 5 read-path — COMPLETE). Related: AD-686c (semantic_stats + introspect fallback removal — future).

AD-687: Knowledge Edge Store (Complete, OSS, Issue #381) — knowledge_edges SQLite table with typed entity→relation→entity triples, provenance fields (source_agent, source_duty), classification labels, confidence/weight scores. CRUD operations, recursive CTE bounded traversal (1–3 hops), Cloud-Ready abstract connection interface. Entity types: agent, department, incident, decision, duty, finding, capability, standing_order. Relation types: reports_to, member_of, competent_in, resolved_by, involved_in, informed_by, depends_on, produced_by, classified_as, originated_on. Standalone — no hard dependencies. Related: AD-434 (Ship's Records — co-located institutional memory).

AD-688: Oracle Graph Integration (Complete, OSS, Issue #382) — Add Tier 6 (_query_graph) and post-merge graph expansion (_expand_via_graph) to OracleService. Tier 6: extract entity references from query, match against knowledge_edges, traverse 1–2 hops, score by weight × confidence × hop proximity. Post-merge: 1-hop enrichment on top-K merged results from all tiers (discounted score 0.7×). Constructor gains knowledge_graph parameter. Provenance tags: [knowledge graph], [graph expansion from: {tier}]. Depends on: AD-686 (Oracle Tier 5 — establishes 6-tier model), AD-687 (Knowledge Edge Store — provides graph data).

AD-689: Edge Population from Existing Data (Complete, OSS, Issue #383) — Backfill knowledge_edges from existing ProbOS data sources: ontology (reports_to, member_of), Hebbian weights above threshold (competent_in), episode agent_ids (involved_in), DECISIONS.md cross-references (resolved_by, informed_by). Idempotent backfill command, warm-boot integration. Depends on: AD-687 (Knowledge Edge Store). Related: AD-429 (Hebbian Router), ontology models.

Phase B: Intelligence

AD-690: Dream Step 10 — Relationship Inference (Complete (v1), OSS, Issue #384) — Nightly dream step scans recent episodes for co-occurring entities without edges in knowledge_edges. LLM classifies relationship type. Anti-contamination: per-entity caps, rejection cache, source tagging. Mirrors Thoth dream cycle Phase 3. Depends on: AD-687 (Knowledge Edge Store), AD-551 (Dream Step 7g). Related: AD-608 (Retroactive Memory Evolution), AD-557 (Emergence Metrics).

AD-691: NL-to-Graph Query (Complete (v1), Commercial, Issue #385) — Ship's Computer structural query routing. OSS extension point: runtime.nl_graph_query.query() callable + NLGraphQueryAgent (single-agent utility pool, decomposer-routable via IntentDescriptor(name="nl_graph_query", tier="utility")) + GET /api/nl-graph-query. LLM-driven 2-phase service: Phase 1 extracts typed entity references + relation filter from natural language; graph step traverses AD-687 edges with hop-proximity scoring (0.6 ** (hop-1)); Phase 2 synthesises a natural-language answer with mandatory [graph: <edge.id>] provenance citations (hallucinated IDs filtered against the actually-retrieved edge set). Schema-aware query generation (Fabric IQ NL2GQL equivalent). Enhances Ship's Computer ask and Ward Room structural questions. Depends on: AD-688 (Oracle Graph Integration). Related: AD-468 (Ship's Computer Config).

AD-692: Classification Enforcement (Complete, OSS extension point, Issue #386) — Decorator-pattern wrapper (ClassificationGatedKnowledgeEdgeStore) around SQLiteKnowledgeEdgeStore enforcing KnowledgeEdge.classification at storage boundary. 4-tier ClassificationLevel IntEnum (PRIVATE/DEPARTMENT/SHIP/FLEET) matching records_store._CLASSIFICATION_LEVELS ordering byte-for-byte. KnowledgeEdgeClassificationGate provides filter_edges/authorize_write/filter_for_export (federation export hook). Late-bind clearance resolver via setter preserves layer discipline. Oracle Tier 6 plumbed with requester_agent_id (TypeError fallback for non-wrapper instances). OSS extension point — commercial overlay (audit, RBAC, multi-tenant) layers on top of stable seam. (Commercial) Orthogonal to AD-679 disclosure routing. Depends on: AD-687 (Knowledge Edge Store). Related: AD-679 (Selective Disclosure Routing), AD-456 (Security Infrastructure).

Phase C: Scale + Federation

AD-693: Federation Knowledge Sync (Future, Commercial, Issue #387) — Cross-instance edge synchronization via federation protocol. Trust-weighted acceptance of foreign knowledge. Provenance chain verification via DID signatures. Selective memory export defined as graph subsets (Clean Room = exclude incident edges). Depends on: AD-687 (Knowledge Edge Store), Phase 29 (Federation). Related: AD-443 (Transfer Certificates).

AD-694: Kùzu Migration (Future, Commercial, Issue #388) — When SQLite CTEs hit complexity limits (>30% of queries need >3 hops), migrate knowledge_edges to embedded Kùzu graph DB. Cypher query interface. Dual-read during migration. Zero new runtime dependencies for OSS (Kùzu is commercial-only). Depends on: AD-687 (Knowledge Edge Store). Decision criteria: query complexity thresholds documented in AD-687.

Bug Tracker

"Captain, we've detected an anomaly in Deck 7."

Bugs found during development or testing. Squash as found when possible; queue here when multiple bugs need coordinated fixing. Numbered as BF-NNN (Bug Fix).

BF	Summary	Severity	Status
BF-245	NATS/xdist stream isolation. pytest-xdist workers race on hardcoded JetStream stream names (SYSTEM_EVENTS, WARDROOM, INTENT_DISPATCH), causing recreate_stream() error 10058 crashes (~20-50 flaky failures per run). Fix: Module-level os.environ.setdefault("PROBOS_NATS_ENABLED", "false") in conftest.py. NatsConfig.enabled field_validator with validate_default=True honors override. real_nats fixture for opt-in.	Medium	Closed
BF-246	LLM Tier Recovery Deadlock. OpenAICompatibleClient has no periodic health check — check_connectivity() only runs at startup and reactively. After extended proxy downtime, tiers stay permanently "unreachable" because fallback tiers are skipped (line 379) and BF-240 dwell-time recovery requires call flow that never arrives. Fix: Add start_health_probe() background loop (30s interval, configurable), only probes unhealthy tiers, wired at startup through public runtime.emit_event, cancelled on shutdown.	High	Closed
BF-247	TieredKnowledgeLoader treats dag_summary as string — it's dict[str, Any]. _load_category() line 211 does summary[:150] on a dict → KeyError: slice. load_on_demand() line 161 same issue. Test fake uses wrong type (str), masking the bug. Fix: isinstance guard, extract dag.get("summary", ""), fix test fake to dict; follow-up tests cover dict summaries and fallbacks.	High	Closed
BF-248	AD-673 anomaly window reads wrong event field. _wire_anomaly_window listener reads data.get("status") but LlmHealthChangedEvent uses new_status/old_status. Also checks "healthy" instead of "operational". Anomaly windows never open for LLM degradation. Fix: Read new_status, check "operational".	Medium	Closed (fixed during AD-673 build)
BF-249	Update AD-666 sensorium tests for 10K threshold after BF-247 raised SensoriumConfig.token_budget_warning from 6000 to 10000. Follow-up to 8be47d5. Fix: Update tests/test_ad666_sensorium.py assertions to the 10K threshold.	Low	Closed
BF-250	TestPerAgentCooldown::test_per_agent_cooldown_used_in_cycle hung under pytest-timeout on Windows. Root cause: MagicMock(spec=WardRoomService) does not auto-wrap async methods as AsyncMock; await rt.ward_room.get_unread_dms() blocked on Windows IOCP. Fix: _make_mock_runtime now sets get_unread_dms and related ward_room methods as AsyncMock.	Medium	Closed
BF-251	TestProactiveExceptionConfidence::test_exception_does_not_crash_loop hung under pytest-timeout on Windows. Same root cause as BF-250 (hang occurred in _check_unread_dms before the BF-023 exception path). Fix: Same as BF-250.	Medium	Closed
BF-252	AD-571 test mocks (test_startup_population, test_all_agents_classified) used SimpleNamespace with only the private _emergence_metrics_engine attribute. After AD-680 promoted emergence_metrics_engine to a public property on ProbOSRuntime, finalize._populate_agent_tiers reads the public name; SimpleNamespace does not expose @property descriptors, so wiring was silently skipped and emergence.registry is runtime._tier_registry failed. Fix: mocks now set both names.	High	Closed
BF-253	AD-680 follow-up — _emit_transporter_events was migrated to rt.emit_event(...), but the _EventEmitter shim nested inside transporter_build only defined _emit_event, raising AttributeError when invoked through that path. test_emit_transporter_events_helper had the symmetric mock gap. Fix: source shim and test mock both now expose emit_event (and keep legacy _emit_event). 202/202 builder-agent tests pass.	High	Closed
BF-254	AD-680/BF-246 follow-up — finalize_startup guarded the BF-246 probe wiring with hasattr(llm_client, "start_health_probe"), which matches MagicMock auto-attributes. Tests using runtime = MagicMock() (e.g., test_new_crew_auto_welcome.py) raised TypeError: object MagicMock can't be used in 'await' expression. Fix: guard now checks asyncio.iscoroutinefunction() to require a real coroutine before awaiting. 15/15 affected tests pass.	High	Closed
BF-255	tests/test_ward_room_dms.py::TestUnreadDmsQuery::test_multiple_exchanges_last_author_wins had an order-dependent failure under the full gate. Fix: AD-682 fixture isolation (per-worker PROBOS_DATA_DIR, cache reset). Test unquarantined and passing.	Medium	Closed
BF-256	tests/test_ward_room.py::TestEndorsementActivation::test_browse_threads_sort_recent had an order-dependent timestamp-tie failure under the full gate. Fix: AD-682 fixture isolation. Test unquarantined and passing.	Medium	Closed
BF-257	DM Receive Rate Limiter — Science agents (Atlas/Sage/Lyra) entered DM ping-pong loop exhausting LLM capacity. Send-side cooldowns (BF-163) are unidirectional; no receive-side budget existed. Fix: Two-layer sliding-window rate limiter: per-agent budget (6/10min) + per-pair bidirectional budget (8/10min). Captain exempt. dm_exchange_limit 40→15. 14/14 focused tests pass. (#379)	Critical	Closed
BF-258	AD-641a Observability Bridge posts to nonexistent Ward Room thread. bridge.py:125 calls create_post(thread_id="system_observability") but no thread/channel with that ID exists — logs WARNING: Thread system_observability not found every 60 seconds. Root cause: Builder conflated "system channel" (spec intent) with Ward Room thread (implementation). Design review (AD-695) determined continuous posting to Ward Room is architecturally wrong — telemetry should be Oracle-queryable, not discourse. Fix: Disable _publish_once() Ward Room posting; retain take_snapshot() for future AD-695 Oracle integration. (#390)	Medium	Closed
BF-259	AD-690 Dream Step 7i wiring silently fails — dreaming_engine never unpacked to runtime. runtime.py unpacks DreamingResult fields (dream_scheduler, emergent_detector, etc.) but omits dreaming_engine. finalize.py:_wire_relationship_inference() calls getattr(runtime, "dreaming_engine", None) → gets None → returns False at DEBUG level (invisible at INFO). Step 7i relationship inference never activates despite config relationship_inference_enabled=True and knowledge_edges being live. Fix: Add self.dreaming_engine = dream_result.dreaming_engine to DreamingResult unpacking block in runtime.py:1512. (#417)	Medium	Closed
BF-260	AD-538b DreamManifest wired to wrong object. finalize.py:1296 late-binds DreamManifest into dream_scheduler._manifest, but DreamScheduler has zero _manifest references — it's DreamingEngine that reads self._manifest (lines 121, 212, 228). Dream deduplication (skip-already-processed episodes) never activates; every dream cycle reprocesses all episodes. Fix: Change target from dream_scheduler to dreaming_engine. (#418)	Medium	Closed
BF-261	AD-683 ShipStateSnapshot never reaches BootCampCoordinator — phase ordering race. runtime.py:1607 passes ship_state_builder=getattr(self, "ship_state_snapshot", None) to BootCampCoordinator at Phase 7, but runtime.ship_state_snapshot is set by _wire_ship_state_snapshot() in finalize (Phase 8) — always None. Cold-start agents never see the ship state snapshot. Fix: Late-bind _ship_state_builder into BootCampCoordinator after finalize wiring completes. (#419)	Medium	Closed
BF-262	AD-691 NLGraphQueryAgent pool never created — phase ordering race. agent_fleet.py:66 guards pool creation on getattr(runtime, "nl_graph_query", None) is not None, but agent fleet runs at Phase 3 while _wire_nl_graph_query() runs in finalize (Phase 8). Agent never spawns, IntentDescriptor never registers, decomposer can't route nl_graph_query intents. API endpoint works directly. Fix: Remove runtime.nl_graph_query is not None guard; keep config check only. Agent handles service is None gracefully. (#420)	Medium	Closed
BF-263	Agent rank never computed from live trust — Oracle Tier 6 gated for all agents. cognitive_agent.py resolves recall tier via getattr(self, 'rank', None) but self.rank is never set on agent objects. Every agent defaults to RecallTier.ENHANCED, blocking Oracle/graph access even for SENIOR-rank agents (13/14 crew at trust > 0.85). Knowledge graph has 3,131 edges but none surfaced. Fix: Compute rank on the fly from TrustNetwork.get_score() → Rank.from_trust() in the cognitive chain. Also fixed 3 additional get_score(agent_type) calls that should use self.id — AD-639 trust band (×2) and AD-537 teaching gate used agent_type as lookup key but TrustNetwork is keyed by agent_id, returning 0.5 default for all agents. (#421)	High	Closed
BF-264	Oracle Tier 6 graph queries fail — two causes. (1) Edges keyed by agent_type but queries use callsigns — expanded tokens via CallsignRegistry in _query_graph(). (2) Science crew (and any dept with unassigned chief post) had no reports_to edges because chief_science post had no agent assignment — backfill's agent_by_post.get(post.reports_to) returned []. Fixed backfill to traverse up the reports_to chain when intermediate posts have no assignment, connecting subordinates to the nearest assigned superior. (#422)	Medium	Closed
BF-265	Knowledge graph data never surfaces in agent replies — three root causes. (1) Split-brain data directory: runtime.py used repo-relative data/ while __main__.py used platform AppData — fixed by consolidating to _platform_data_dir() in runtime.py, delegated from main.py and scout.py. (2) Oracle classification gate too restrictive: _query_graph() passed requester_agent_id=agent_id to ClassificationGatedKnowledgeEdgeStore, filtering all edges because backfilled edges had classification="ship" (level 2) but most crew (LIEUTENANT→enhanced tier) can only see up to department (level 1). Fixed by making Oracle a privileged service — passes empty requester_agent_id to bypass the gate (Oracle curates context before delivery, double-gating is redundant). (3) Backfill classification: changed org-chart edges from "ship" to "department" since reports_to/member_of are basic organizational facts.	High	Closed
BF-001	Self-mod proposal on knowledge questions	Medium	Closed (AD-348)
BF-002	Agent orbs escape pool group spheres	High	Closed (AD-349)
BF-003	"Run diagnostic" bypasses VitalsMonitor, asks user for alert data	Medium	Closed (AD-35d an order-dependent failure under the full gate. Fix: AD-682 fixture isolation (per-worker PROBOS_DATA_DIR, cache reset). Test unquarantined and passing.
BF-004	Transporter HXI visualization not rendered	Medium	Closed
BF-005	HTTP consensus docs drift (AD-150 removed gating)	Low	Closed
BF-006	Quorum trust docs drift in consensus.md	Low	Closed
BF-007	Verification false positive on per-pool agent counts	Medium	Closed
BF-008	Dream cycle double-replay after dolphin dreaming	Low	Closed
BF-009	@callsign routing missing from HXI /api/chat and embedded mentions (e.g., "Hello @wesley") not detected in any entry point	High	Closed
BF-010	1:1 conversations use domain task instructions (===SCOUT_REPORT=== etc.) instead of conversational prompt	Medium	Closed
BF-011	Discord adapter stop() hangs on Windows — SSL/WebSocket teardown blocks event loop, defeating asyncio timeouts	High	Closed
BF-014	"Bundled agents" terminology → "Utility agents" to align with three-tier model (Core/Utility/Crew)	Low	Closed
BF-015	Counselor (Troi) 1:1 silent + ungrouped on canvas. (1) report() override wrapped conversational responses in {"data": ...} instead of preserving {"result": ...}, so handle_intent() extracted None → "(no response)". (2) No Bridge pool group — counselor pool unmapped → ungrouped on canvas.	Medium	Closed
BF-016	Ward Room thread explosion — all 8 crew agents respond to every Captain post, even @mention-directed ones, and no per-thread cap. (a) @mention exclusivity in _find_ward_room_targets(). (b) Per-thread agent response cap via max_agent_responses_per_thread (default 3).	High	Closed
BF-017	Non-crew agents (utility, infrastructure, self-mod) exposed crew-only capabilities: direct chat, personality profiles, proactive cooldown slider. (a) API crew gates on /api/agent/{id}/chat and /api/agent/{id}/proactive-cooldown. (b) Profile returns isCrew flag; empty personality + null proactiveCooldown for non-crew. (c) HXI hides Chat tab and proactive slider for non-crew agents.	Medium	Closed
BF-018	Builder agent incorrectly classified as crew in _WARD_ROOM_CREW. Builder is a utility agent (AD-398 three-tier) — it writes code when told to, has no Character/Reason/Duty. Proactive loop triggered Builder's code-parsing act() on proactive thinks, producing warnings (no file blocks). Removed "builder" from _WARD_ROOM_CREW.	Low	Closed
BF-019	Crew agents (security_officer, operations_officer, engineering_officer) missing from _AGENT_DEPARTMENTS mapping. AD-398 added these crew types but never registered their departments — get_department() returned None → proactive Ward Room posts fell through to All Hands instead of department channels. Added mappings: engineering_officer→engineering, security_officer→security, operations_officer→operations.	Medium	Closed
BF-020	Discord adapter startup reported success (✓ Discord bot adapter started) even when discord.py was not installed. adapter.start() returned silently on ImportError but the caller unconditionally printed the success message. Fixed: check adapter._started before printing; show clear error with install command on failure.	Low	Closed
BF-021	Duty schedule gate — agents with no duty due were still called by the proactive loop, relying on the LLM to respond [NO_RESPONSE]. Wesley ignored the instruction and kept producing scout reports every ~7 minutes despite AD-419 setting scout to once daily. Original fix: hard return — skip agent entirely. Refined: hard gate was too aggressive — between duty cycles, agents went completely dark (no Ward Room posts, no trust signals, confidence degraded). Architect (daily duty) and counselor (12h) silent for 24h/12h. Ship went dark. Current fix: replaced hard return with 3x cooldown gate — agents can do free-form thinks between duties at reduced frequency (900s default vs 300s for duty cycles). Duties still take priority when due.	High	Closed
BF-022	Crew cannot respond to Ship's Computer advisory messages. Bridge alerts post to All Hands (ship-wide) with same_department=False. Earned Agency gating: can_respond_ambient(LIEUTENANT, is_captain_post=True, same_department=False) → False. Post-reset, all crew are Lieutenants (trust 0.5) — no one qualifies. Root cause: the ambient response gate wasn't designed with system broadcasts in mind. Fixed in AD-424: INFORM threads skip notification entirely, DISCUSS threads pass same_department=True to earned agency (explicitly open for input).	Medium	Closed
BF-023	Degraded agent death spiral. When proactive loop LLM calls throw exceptions (timeout, API error), the exception handler catches at DEBUG level but never calls update_confidence(). Confidence freezes at whatever value it was when errors started. Agents stuck in DEGRADED (< 0.2) with no recovery path — they keep getting called (DEGRADED is is_alive), keep failing, and stay dead forever. Additionally, update_confidence() had no path from DEGRADED back to ACTIVE even on success. Fix: (a) Exception handler calls update_confidence(False) so failures are tracked. (b) update_confidence() restores DEGRADED -> ACTIVE when confidence climbs back above 0.2. (c) Degradation warning logs only on state transition, not repeated failures. 5 tests.	High	Closed
BF-024	Crew agents with domain-specific perceive()/act() overrides (Builder, Architect, Counselor, Scout) degrade on every proactive think cycle. Their intent guards only listed direct_message and ward_room_notification — when proactive_think arrives, it falls through to domain pipelines (build specs, design proposals, assessments) which fail because proactive thoughts aren't domain requests. Each failure triggers BF-023's confidence decay, degrading all four agents within minutes. Fix: Added proactive_think to intent guard tuples in perceive(), _build_user_message(), and act() across all four agent classes (builder.py, architect.py, counselor.py, scout.py). Proactive thoughts now delegate to the base CognitiveAgent implementation which handles them correctly.	Critical	Closed
BF-025	CI-only failure: test_no_duty_allows_freeform_think passes locally but fails on GitHub Actions. The free-form think cooldown gate uses time.monotonic() - last < idle_cooldown where last defaults to 0.0. On a fresh CI runner VM with low uptime, time.monotonic() can be < 900s (3x cooldown), so the gate incorrectly blocks the first-ever think. Locally, uptime is hours/days so time.monotonic() is always large enough. Fix: Added last > 0 guard — first-ever proactive think for an agent always passes the cooldown check.	Medium	Closed
BF-026	TypeScript build failure: display_name property was added to the Python state snapshot (wiring crew profile display names to HXI) but never added to the StateSnapshot TypeScript interface in ui/src/store/types.ts. TSC fails with Property 'display_name' does not exist on type. Fix: Added display_name: string to StateSnapshot.agents interface.	Low	Closed
BF-027	Agent memory recall ineffective — agents can't recall Ward Room posts or past 1:1 conversations despite episodes being stored correctly. Three issues: (a) recall_for_agent() uses 0.7 cosine similarity threshold which is too strict for conversational queries ("What have you been thinking about?" vs [Proactive thought] Counselor: observed trust variance...). (b) No fallback when semantic recall returns empty — agent gets zero memory context. (c) MockEpisodicMemory missing recall_for_agent() — tests silently skip recall via except Exception: pass. Fix: (a) Lower agent-scoped recall threshold to 0.3 (sovereign shard filter prevents cross-agent leakage). (b) Add recent_for_agent() timestamp-based fallback when semantic recall returns nothing. (c) Add recall_for_agent() and recent_for_agent() to MockEpisodicMemory.	High	Closed
BF-028	Proactive & shell recall missing recent_for_agent() fallback. BF-027 added the fallback to _recall_relevant_memories() in cognitive_agent.py, but two other recall sites were not updated: _gather_context() in proactive.py (hardcoded query "recent activity") and shell cross-session recall (query "1:1 with {callsign}"). Both need the same fallback pattern. Fix: Added recent_for_agent() fallback with hasattr guard to both sites. 2 tests.	Medium	Closed
BF-029	Ward Room memory recall quality in 1:1 conversations. Agents can't recall Ward Room posts when Captain asks in 1:1 — episodes are stored correctly (AD-430a) but recall pipeline has three issues: (a) direct_message recall query uses raw Captain text with no Ward Room signal in the embedding, (b) memory presentation prefers thin reflection strings over content-rich input, (c) Ward Room reply reflections lack body content ("replied in thread 'X'" instead of what was said). Fix: Prepend "Ward Room {callsign}" to recall query for direct_message, reverse input/reflection preference in both prompt builders, include body excerpt in reply reflections + channel name in reply user_input. 10 tests.	High	Closed
BF-030	ward_room.py used self._db.execute_fetchone() which doesn't exist in aiosqlite. Caused AttributeError at runtime when recalling Ward Room thread metadata. Fix: Replaced with standard async with self._db.execute(...) as cursor: row = await cursor.fetchone() pattern.	Medium	Closed
BF-031	CognitiveJournal.start() ran executescript(_SCHEMA) with CREATE INDEX ... ON journal(intent_id) before ALTER TABLE ADD COLUMN intent_id migration. On pre-AD-432 databases, the table existed without the column → OperationalError: no such column: intent_id. Fix: Split schema into _SCHEMA_BASE (table + safe indexes) and _SCHEMA_INDEXES (indexes on migrated columns). Startup: base → migration → dependent indexes.	Critical	Closed
BF-032	Proactive observation self-reference loop. Agents see their own Ward Room posts in proactive context, observe patterns in their own posting, then post meta-observations about their posting patterns — recursive loop. Observed in Troi and Selar. Fix: (1) Self-post filter in _gather_context() — self_ids set excludes agent's own posts from Ward Room activity context. (2) _is_similar_to_recent_posts() — Jaccard word-set similarity (threshold 0.5), fail-open, checks last 3 posts. (3) Similarity gate in _think_for_agent() before posting — suppressed posts still record duty execution. (4) Prompt instruction: "Do not comment on your own posting patterns or observation frequency." 5 tests.	Medium	Closed
BF-033	Agent profile cards in HXI showing "0 Episodes" and "0s" uptime — both fields were unwired stubs. Root cause: (1) EpisodicMemory had no count_for_agent() method; API's hasattr guard silently defaulted to 0. (2) API hardcoded "uptime": 0.0 instead of using runtime's _start_time. Fix: Added count_for_agent(agent_id) to EpisodicMemory (ChromaDB metadata filter on agent_ids_json). Replaced hardcoded uptime with time.monotonic() - runtime._start_time.	Low	Closed
BF-034	Post-reset trust anomaly false positives. After probos reset -y, EmergentDetector fires 6+ consecutive trust anomalies because baseline trust (0.5) is interpreted as anomalous — no cold-start awareness. Agents see these as system problems and enter discussion spirals about "demotions." Fix: (1) Cold-start detection in runtime — flag set when all trust at prior + episodic empty. (2) EmergentDetector.set_cold_start_suppression(300) — suppresses trust anomalies for 5 min (clusters/routing still fire). (3) Proactive context injection — system_note tells agents "baseline trust is normal, not demotion." (4) Ward Room announcement: "Fresh Start — System Reset" thread. Flag auto-clears after first dream cycle. 8 tests.	Medium	Closed
BF-035	Ward Room reply threshold too high. can_perform_action() gated replies at Rank.COMMANDER but cold-start trust=0.5 maps to Rank.LIEUTENANT — no agent could reply to any thread. Fix: Lowered reply tier from COMMANDER to LIEUTENANT in earned_agency.py. Also fixed agents.tsx TS build error (boolean \| undefined → !!hasConv).	Medium	Closed
BF-036	EmergentDetector trust anomaly flooding persists beyond cold-start window. After BF-034's 5-min suppression expires, detector continues flagging normal trust=0.5 variation as anomalous during extended warmup. Overnight run showed persistent alert cascade, triggering 5+ duplicate crew proposals about the same issue. Fix: Three guards in detect_trust_anomalies(): (1) std floor raised from 0.001 to 0.05 — skip sigma analysis when population spread is negligible. (2) Min observations guard — skip agents with alpha+beta < 8.0 (fewer than 4 actual observations beyond prior). (3) Min absolute deviation guard — skip if abs(score-mean) < 0.10 regardless of sigma. 7 tests.	Low	Closed
BF-037	Ontology context gathered but never rendered. _gather_context() in proactive.py collects context["ontology"] (AD-429a) and context["skill_profile"] (AD-429b) but _build_user_message() in cognitive_agent.py never reads these keys — the data is silently dropped. Fix: Two rendering blocks in _build_user_message() proactive_think branch: (1) Ontology identity grounding — callsign, post, department, reports_to, direct_reports, peers, vessel status/alert condition. (2) Skill profile — comma-joined skill list. Placed after cold-start note, before memories. 8 tests.	Medium	Closed
BF-040	Identity system hardening — 13 findings from post-AD-441/441b code review. C-2 (Critical): export_chain() genesis credential attachment condition simplified (check not blocks[0].get("credential") instead of DID comparison). H-1: Input validation on generate_did(), generate_ship_did(), parse_did(), issue_birth_certificate(). H-2: asyncio.Lock on _append_to_ledger() to prevent concurrent chain corruption. H-3: PRAGMA foreign_keys = ON. M-1: verify_chain() validates genesis previous_hash is all zeros. M-3: Eager genesis block creation during _commission_ship(). M-4: Removed dead _cache dict. M-5, L-2, L-3: Documented proof type rationale, hash format difference, float representation. L-1: Warning log on slot mapping overwrite. L-4: Index on slot_mappings.agent_uuid. M-2: Column order comments on positional DB row access. Removed obsolete backwards-compat test. 9 new tests, 1 removed, 1 updated.	Mixed	Closed
BF-039	Episodic memory flooding after reset. Agents (especially Medical) accumulate hundreds of episodes within hours. Root causes: (1) Double episode creation per proactive thought — both proactive.py (line 339) and ward_room.py (line 885 via _post_to_ward_room) store episodes for the same cognitive event. (2) Ward Room episode storage (ward_room.py lines 885, 1082) bypasses should_store() gate entirely. (3) No per-agent episode rate limiter — no check for "N episodes in last hour." (4) No content-based dedup — every episode gets a fresh UUID, so identical text stores twice. (5) count_for_agent() defined twice in episodic.py (lines 278, 401) — second shadows first, both O(N) over all episodes. Fix: (1) Deduplicate proactive+WR episode path — proactive.py skips episode storage when WR is available (WR creates its own). (2) WR episode storage routed through should_store(). (3) Per-agent rate limiter: MAX_EPISODES_PER_HOUR=20 via rolling ChromaDB timestamp query. (4) Content similarity gate: Jaccard word-level similarity > 0.8 within 30-min window rejects duplicate. (5) Removed duplicate count_for_agent(). (6) Cold-start dampening: 3x cooldown for first 10 minutes (COLD_START_WINDOW_SECONDS=600). Ward Room should_store() recognizes [Ward Room]/[Ward Room reply] prefixes. 6 fixes implemented, 12 new tests, 290 tests green.	High	Closed
BF-041	HXI SVG icon system — replaced all Unicode text glyphs across 18 component files with 25 shared SVG glyph components (Glyphs.tsx). Components: ChevronDown/Right/Up, ArrowLeft/Right/Up/Down, Close, Warning, StatusDone/Pending/InProgress/Failed, Expand, Diamond/DiamondOpen, Bullseye, Check, XMark, Sparkle, PlayArrow, Lock/Unlock, Comment, Pin. All follow HXI Design Principle #3 (stroke 1.5, round cap, currentColor). StatusDone is the one fill exception. STEP_ICONS string maps replaced with STEP_ICON_COMPONENTS React component maps. IntentSurface FeedbackStatus.confirmText refactored from string to ReactNode. 68 new glyph tests (25×3 + StatusDone fill + count). Zero remaining Unicode icon glyphs (grep-verified).	Medium	Closed
BF-042	HXI component rendering tests. 27 rendering tests across 5 components (ScanLineOverlay, BriefingCard, ViewSwitcher, WelcomeOverlay, AgentTooltip). New renderWithStore() helper (renderHelpers.tsx) resets Zustand to initial snapshot + applies overrides. Patterns: renders-nothing guards, conditional content, store mutations, event handlers, trust display math. 176/176 vitest passing (149 existing + 27 new).	Medium	Closed
BF-043	Test suite parallelization. Fix: (1) Added pytest-xdist>=3.5 for parallel execution (-n auto). (2) Added pytest-timeout>=2.3 with 30s default. (3) Marked test_task_scheduler.py (39 tests) and test_dreaming.py (26 tests) as @pytest.mark.slow. (4) Fixed 2 parallel-only test failures in test_experience.py — MockEpisodicMemory relevance_threshold too tight (0.3→0.2) causing recall misses when xdist's popen-gw{N}/ path segment dilutes Jaccard token overlap. Result: 13x speedup (177s vs ~2220s sequential). Fast path: pytest -n auto -m "not slow" = 3537 tests in ~90s. Slow marker: 65 tests with real asyncio.sleep().	Medium	Closed
BF-233	Grounding check false positives suppress legitimate ward room replies	High	Closed
BF-234	Duplicate ward room responses on Captain new-thread. 4 of 12 agents posted duplicate replies (millisecond timing) due to transport-layer duplicate delivery (JetStream redelivery or js_publish timeout-then-succeed). Application lacked consumer-side defense-in-depth. Fix: _seen_intents dict in IntentBus._on_dispatch() — 300s sliding-window (matches ack_wait) keyed by intent.id, filtered to ward_room_notification only. WARN log + _duplicate_suppressed_count counter + wardroom.dispatch.duplicate_suppressed event. msg.ack() on hit (no redelivery). Uses time.monotonic(). BF-198 remains semantic round-tracking only. 11 new tests.	Medium	Closed
BF-236	Semantic duplicate dispatch — round-scoped post tracker. _route_to_agents() had no check for "agent already posted in this conversational round." Back-to-back route_event() calls dispatched the same agent for the same thread with different intent IDs (invisible to BF-234). Using BF-198's _responded_threads would block Captain follow-ups for 10 min (wrong invariant). Fix: New _posted_in_round tracker on WardRoomRouter, keyed on (agent_id, thread_id), cleared on Captain repost alongside _round_participants. Recorded by WardRoomPostPipeline after create_post (not at dispatch/delivery) — gate fires only after a real post, avoids false positives from non-posting agents. 120s eviction. Gate in Phase 1 after Layer 3 round-participation check, respects is_direct_target bypass. cleanup_tracking() extended to clear pruned threads. Partial coverage: catches duplicates when pipeline recording outpaces second route_event(); sub-second races covered by BF-234 (transport) and BF-197 (similarity). 13 new tests including multi-turn Captain follow-up regression guard and route_event wiring verification.	Medium	Closed
BF-235	Stale identity block in agent system prompt rendering across stasis boundaries. Root cause: @lru_cache on _build_personality_block() and _load_file() in standing_orders.py never cleared on stasis resume. Module-level _DECISION_CACHES dict compounded by serving stale decisions up to 3600s. Fix: Unconditional clear_cache() + evict_cache_for_type() on stasis_recovery lifecycle event in finalize.py (not gated behind warm_boot_orientation). Defensive clear on all startups. Diagnostic logging of callsign at orientation time. Completes identity restoration chain: BF-057 → BF-101 → BF-049 → BF-083 → BF-235. Crew-originated (Vance, Chapel, Anvil, Reed). 7 new tests. Issue #338.	High	Closed
BF-235a	Monitor: consolidation anomaly signal T+72h post-BF-235 deploy. Observational review — not a build task. Owner: architect.	Low	Open
BF-237	Pipeline-level post budget (N+1 post problem). LLM emits multiple [REPLY]/[MOVE] blocks → each fires create_post in the extractor loop → Step 7 fires another create_post for cleaned text. Fix: PostBudget dataclass threaded from process_and_post() → extract_and_execute_actions() → _extract_and_execute_replies(). Budget spent on first create_post; subsequent [REPLY]/[MOVE] blocks and Step 7 main post suppressed. Telemetry event on suppression. Completes four-layer dedup stack: BF-234 (transport) → BF-236 (dispatch round) → BF-237 (pipeline invocation) → BF-197 (content similarity). 10 new tests. Issue #340.	Medium	Closed
BF-238	Post-budget telemetry monitoring (BF-237 follow-up). New PostBudgetTelemetry in ward_room_pipeline.py with per-agent / per-thread / overall invocation + exhaustion counters; exhaustion_rate(agent_type=, thread_id=) accessor returning None below sample threshold; bounded recent-suppressions ring buffer for ops review; one-shot per-agent WARN when rate exceeds configurable threshold (default 0.5) over min-samples gate (default 10). New PostBudgetTelemetryConfig Pydantic model wired onto SystemConfig.post_budget_telemetry. Constructor injection into WardRoomPostPipeline via new post_budget_telemetry= kwarg; public attribute runtime.post_budget_telemetry. BF-237 row-level event_log audit trail preserved unchanged. 8 new tests. Issue #341.	Medium	Closed v1
BF-239	Ward Room thread engagement tracking (working memory). Agents double-post on all-hands Captain messages — dispatched twice for the same thread before first reply completes. BF-236 checks at dispatch time but serial cognitive queue means second intent arrives after first completes. Fix: Agent-level cognitive dedup using ActiveEngagement("ward_room_reply", thread_id) in working memory. Check at handle_intent entry, register before lifecycle, cleanup via try/finally around extracted _run_cognitive_lifecycle helper. @mentions and DMs bypass. Engagement key namespaced as f"ward_room:{thread_id}" to avoid collision with game engagements. Zero-token cost (synchronous dict lookup). Five-layer dedup stack: BF-234 (transport) → BF-239 (agent cognitive) → BF-236 (dispatch round) → BF-237 (pipeline) → BF-197 (similarity). 19 tests.	Medium	Closed
BF-239a	Evaluate BF-198 deprecation. After BF-239 is deployed and validated (T+72h), evaluate whether _responded_threads (BF-198, 600s window in proactive.py) is redundant with engagement tracking + BF-236 round tracker. If BF-239 + BF-236 cover all observed dedup cases, deprecate BF-198 to simplify the dedup stack from five layers to four. Owner: architect.	Low	Open
BF-240	LLM Health Dwell-Time Criterion. LLMHealthMonitor releases diagnostic holds on first healthy check, risking premature recovery amid instability (single healthy response between failures). Fix: Configurable min_consecutive_healthy threshold (default 3) in SystemConfig.llm_health. Track consecutive healthy count in monitor state; only release hold when threshold met. Reset counter on any failure. Event emission on hold release includes dwell count. Crew-originated (Forge × 2 proposals). 10 new tests.	Medium	Closed
BF-241	NATS JetStream reconnect resilience. After NATS server restart mid-session (~13h stable), _reconnected_cb only sets connected=True — does not recreate streams or re-subscribe JetStream consumers. All js_publish() calls fail with "no response from stream" until ProbOS restart. Fix: Extract _recover_jetstream() from set_subject_prefix() (DRY). Call from _reconnected_cb. Recreates streams via recreate_stream() (BF-232 pattern), deletes stale consumers (BF-223 pattern), re-subscribes from _active_subs tracking. Log-and-degrade on partial failure. Three-layer defense-in-depth: file-backed streams (primary) → reconnect recreation (secondary) → BF-230 publish fallback (tertiary). Completes NATS resilience stack: BF-229/230/231/232/241. 8 new tests.	Medium	Closed
BF-242	JetStream liveness probe: detect silent failures, suspend + recover	Medium	Closed
BF-243	__new__ test pattern AttributeError after AD-601/494/595e build wave. Tests using ClassName.__new__(ClassName) bypass __init__, crash on new attributes (_tcm, _trait_adaptive_enabled, _qualification_standing, _novelty_gate). Fix: getattr(self, '_attr', default) guards at all access sites in episodic.py, proactive.py, cognitive_agent.py. Source-side fix — no test changes needed.	Low	Closed
BF-244	Ontology callsign desync after naming ceremony. Onboarding runs with ontology=None during pool creation, so update_assignment_callsign() silently skips. Agent sees seed callsign ("Forge") in ontology identity context while standing orders correctly show self-named callsign ("Anvil"). Fix: Callsign reconciliation loop in finalize.py syncs CallsignRegistry → ontology assignments after ontology is wired. Also fixes stale peer and superior callsigns in get_crew_context().	Medium	Closed

| BF-044 | Hebbian routing uses unique message UUID as source key instead of intent name. runtime.py submit_intent() and submit_intent_with_consensus() recorded source=msg.id (per-message UUID) instead of source=intent (intent name string). Each interaction created a new weight key that never reinforced — Hebbian learning never accumulated. HXI curves rendered but "went nowhere" because UUID source couldn't resolve to an agent position. Fix: Changed source=msg.id to source=intent in both record_interaction calls and both _emit_event/get_weight calls. Also fixed AD-442 proactive activation check (get_trust → get_score, MagicMock-safe threshold). 4 new tests in test_hebbian_source_key.py. | High | Closed | | BF-045 | Naming ceremony calls _llm_client.complete(system=..., prompt=..., max_tokens=...) with raw kwargs — OpenAICompatibleClient.complete() expects LLMRequest object. All agents fail self-naming on commissioning and fall back to seed callsigns. Fix: Wrapped call in LLMRequest(system_prompt=..., prompt=..., max_tokens=..., tier="fast") and access response.content. | Critical | Closed | | BF-046 | Proactive notebook writes reference self._runtime._ontology — attribute is self._runtime.ontology (public, no underscore). Every notebook write fails with 'ProbOSRuntime' object has no attribute '_ontology'. Also fixed RecordsStore constructor call in runtime.py (getattr(self, '_ontology') → getattr(self, 'ontology')). Fix: Two attribute references corrected. | Medium | Closed | | BF-047 | DM callsign resolution calls CallsignRegistry.get_agent_type(callsign) which doesn't exist. The reverse lookup (callsign→agent_type) is only available through resolve(). Every DM attempt raises AttributeError, caught by exception handler — all agent DMs silently fail. Fix: Replaced with rt.callsign_registry.resolve(target_callsign) → resolved.get("agent_type"). | High | Closed | | BF-048 | Episode rate limiter fails open. _is_rate_limited() catches all ChromaDB query exceptions and returns False (not rate-limited). If the timestamp filter query fails (float precision, collection state, etc.), every episode bypasses the 20/hour cap. Diagnostician accumulated 837 episodes in 5 minutes. Fix: Changed except Exception: return False to return True (fail closed). If we can't verify the rate, assume limited — prevents memory flooding. | High | Closed | | BF-049 | Agents reference seed callsigns instead of current callsigns. Forge (builder) said "I'll reach out to LaForge" — LaForge is the pre-naming seed callsign for engineering_officer, not a current crew member. Fix: Added update_assignment_callsign() to ontology, called from runtime after naming ceremony. Peers/reports_to now show current callsigns. | Medium | Closed | | BF-050 | Agents don't know their own callsign in conversation. Tesla (engineering_officer) said "I'll reach out to Tesla" — referencing itself. Fix: Ontology sync (BF-049) ensures self-identity is consistent. Crew roster excludes self callsign. | Medium | Closed | | BF-051 | DM syntax only available in proactive prompt. Captain ordered all departments to DM their peers — every agent acknowledged publicly but none used [DM @callsign] syntax. Fix: Extracted _compose_dm_instructions() helper, called in both proactive_think and ward_room_notification branches. 1:1 direct_message excluded (already in DM context). | Medium | Closed | | BF-052 | Crew roster lacks department grouping. all_callsigns() returns a flat @callsign list with no department context. Fix: _compose_dm_instructions() now uses ontology to group crew by department (Engineering: @Forge, @Tesla). Falls back to flat list when ontology unavailable. | Medium | Closed | | BF-053 | Communications panel count={0} hardcoded. BridgePanel.tsx line 171: <BridgeSection title="Communications" count={0}> — count badge always shows 0 regardless of actual DM channel activity. Should be wired to dmChannels.length. | Low | Closed | | BF-054 | Communications panel DM Activity Log "View full thread" visibility inverted. The "View full thread →" link appears only when the thread entry is expanded/clicked, not when collapsed. Should be visible in collapsed state to invite interaction, hidden or replaced with content when expanded. Also: no auto-refresh — refreshDms() fires only on mount, no polling or WebSocket hook. Panel shows stale data until manual navigation. | Low | Closed | | BF-055 | Captain cannot reply to DMs. DM Activity Log is read-only — no input field or reply mechanism. When agents DM the Captain ([DM @captain]), the message appears in Communications but the Captain has no way to respond. Need a reply input on DM thread entries (or click-to-open a DM chat view) that posts back to the DM channel as a Captain message. HXI Cockpit View Principle violation — every agent-mediated capability requires direct manual control. | Medium | Closed | | BF-056 | DM Activity Log appeared to show only Captain-directed DMs. Investigation: backend GET /api/wardroom/dms already returns ALL DM channels (no participant filter). Root cause was BF-051 — agents couldn't use DM syntax outside proactive prompt, so no agent-to-agent DMs were ever created. With BF-051 fixed, agent-to-agent DM channels CAN be created. Verified 2026-03-28: After 17h uptime, all 8 DM channels are agent-to-Captain. Zero agent-to-agent DMs generated. Display works correctly — agents simply don't choose to DM each other. This is a behavioral gap (agents default to department channels), not a UI bug. Closed — may revisit as crew development training scenario (AD-510). | Low | Closed | | BF-057 | Agents lose identity on restart (naming ceremony re-runs unconditionally). Restart without reset causes every crew agent to run the naming ceremony from seed callsigns (Scotty, Number One, Wesley…) and pick entirely new names. Root cause: CallsignRegistry.load_from_profiles() loads seed callsigns from YAML, naming ceremony guard (runtime.py line 4006) has no check for persisted callsigns, and set_callsign() never writes to disk. Birth certificates in identity.db DO persist callsigns — but the naming ceremony runs BEFORE identity resolution, so it never sees the existing cert. Fix: Check identity registry for existing cert before naming ceremony; if cert exists, restore that callsign and skip the ceremony. Boot ordering verified correct (identity registry starts before agent spawn). | Critical | Closed | | BF-058 | Crew agents use random UUIDs — identity persistence impossible. BF-057's cert lookup uses get_by_slot(agent.id), but 7 crew pools (builder, architect, scout, counselor, security_officer, operations_officer, engineering_officer) are created without agent_ids=, so BaseAgent.__init__ falls through to uuid.uuid4().hex. New random ID every boot → cert never matches → naming ceremony runs every time. Medical agents work correctly because they use generate_pool_ids(). Fix: Add agent_ids=generate_pool_ids(...) to all 7 crew pool creation calls, matching the medical agent pattern. | Critical | Closed | | BF-059 | probos reset doesn't clear identity.db. Reset clears trust, episodes, Hebbian, Ward Room, events, journal — but not identity.db. After reset, old birth certificates survive. Medical agents (with deterministic IDs) silently match old certs and skip naming ceremony, keeping previous instance callsigns. A reset should create a new ship with new crew identities. Fix: Add identity.db and ontology/instance_id cleanup to _cmd_reset(). | Medium | Closed | | BF-060 | Notebook content leaks into Ward Room posts. Proactive loop correctly extracts [NOTEBOOK ...] blocks and writes them to Ship's Records, but the raw [NOTEBOOK] tag and its content are not stripped from the text before posting to Ward Room. Root cause: text.replace() with stripped content doesn't match original whitespace. Fix: Replace per-match text.replace() with re.sub(notebook_pattern, '', text, flags=re.DOTALL) after notebook extraction loop. | Medium | Closed | | BF-061 | [REPLY thread:...] tag creates new thread instead of actual reply. Two sub-issues: (a) Pattern r'\[REPLY\s+(\S+)\]\s*\n(.*?)\n\[/REPLY\]' requires newline and captures thread: prefix as part of ID. (b) Rank gate at Commander+ blocks all fresh-instance agents (start as Lieutenant). Fix: Flexible pattern r'\[REPLY\s+(?:thread:?\s*)?(\S+)\]\s*(.*?)\s*\[/REPLY\]' (DOTALL), _resolve_thread_id() method for partial UUID prefix match, rank gate lowered to Lieutenant+. | Medium | Closed | | BF-062 | Proactive thoughts repeat near-identical observations across cycles. Similarity gate checked only last 3 posts with word-level Jaccard. Fix: Increased window to 10 posts, added bigram Jaccard as second check alongside existing word-level check (same 0.5 threshold). | Medium | Closed | | BF-063 | Naming ceremony silently accepts defaults when LLM returns empty. If the Copilot proxy returns 0-char responses during boot, the naming ceremony fallback accepts the default callsign without logging a warning. All 11 crew agents get "Default callsign accepted" with no indication the LLM failed. Observed 2026-03-28 after proxy blip — looked like a regression but was a silent error. Fix: Conditional logging in run_naming_ceremony(): logger.warning for empty/oversized LLM response or invalid name (contains newline/exceeds 30 chars), logger.info for valid self-chosen callsign. Three-way distinction: empty/oversized fallback, invalid name fallback, valid choice. 5 tests (3 new + 2 updated). | Low | Closed | | BF-064 | Watch roster assigns all agents to ALPHA — BETA/GAMMA always empty. _populate_watch_roster() hardcoded WatchType.ALPHA for all crew. When the watch auto-rotated to BETA or GAMMA, zero agents were on duty. Fix: Added watches field to Assignment dataclass and organization.yaml. Each assignment declares which watches the agent stands. Essential roles (security, ops, engineering) stand all 3; others distributed for coverage. _populate_watch_roster() now reads from ontology. | Medium | Closed | | BF-065 | Restart shows "maiden voyage" / stasis not detected after Ctrl+C. Two issues: (1) Lifecycle detection relies on session_last.json, written near the end of stop() after ~15 service teardowns — the 5s shutdown timeout in __main__.py cancels stop() before reaching it. (2) No fallback detection for existing state. Agents never learn they went into stasis and wake thinking it's their first activation. Fix: (a) Moved session_last.json write to early in stop(), right after stasis Ward Room announcement. (b) Added trust.db existence as fallback — if data dir has state but no session record, lifecycle is restart not first_boot. (c) New restart announcement: "System Restart — All Stations Resume." | Medium | Closed | | BF-066 | Agent DMs in Ward Room replies leak into public posts. _extract_and_execute_dms (AD-453) only ran in the proactive think path. When agents replied to Ward Room threads with [DM @callsign]...[/DM] blocks, the DM syntax was posted raw to the public thread — no DM was sent, and the "private" message was visible to all. Fix: Added DM extraction to the Ward Room reply handler in _handle_ward_room_event. DM blocks are now intercepted, routed through the existing DM plumbing, and stripped from the public post. If the entire response was DM blocks, no public post is created. | Medium | Closed | | BF-067 | "Open in Ward Room" link in DM Log does nothing. Clicking the link called selectChannel(ch.id) which selected the DM channel, but the view stayed on the dms tab — so the channel content was never displayed. Fix: Added setView('channels') to the click handler so the panel switches to the Channels view showing the selected DM channel's threads. | Low | Closed | | BF-068 | HXI shutdown leaves process running. /api/system/shutdown calls runtime.stop() but never exits the process — uvicorn server keeps running with zero agents. Fix: Added os._exit(0) after runtime.stop() completes, matching the behavior in __main__.py's finally block. | Low | Closed | | BF-069 | LLM proxy failure is silent — no alerts, no visibility. When the Copilot proxy (127.0.0.1:8080) goes down or returns empty responses, the entire crew stops thinking proactively with zero indication to the Captain. Fix: (1) Per-tier health tracking in OpenAICompatibleClient — consecutive failure counters, 3-failure unreachable threshold, operational/degraded/unreachable per tier, overall status rollup. (2) BridgeAlertService.check_llm_health() fires ALERT "Communications Array Offline" or ADVISORY "Communications Array Degraded" with dedup. (3) VitalsMonitor collects llm_health metrics, fires medical_alert on degraded/offline. (4) DreamAdapter calls check_llm_health() in post-dream. (5) /api/system/services includes LLM Proxy status, new /api/system/llm-health endpoint. (6) Proactive loop tracks _llm_failure_count, logs warnings, exposes via property. (7) EventType.LLM_HEALTH_CHANGED registered. 28 tests. | High | Closed | | BF-070 | Reset command incomplete — 11 databases silently missed, broken lifecycle detection. (a) ChromaDB cleanup was a no-op since day one (chroma/ dir doesn't exist; actual data is chroma.sqlite3). (b) trust.db not cleaned, causing "restart" misdetection instead of "first_boot". (c) episodic.db, acm.db, skills.db, workforce.db, directives.db, service_profiles.db, scheduled_tasks.db, scout_reports/, semantic/ never cleaned. (d) No granular control. Fix: Tiered reset system — 3 cumulative tiers: Tier 1 --soft (Reboot: transients, preserves stasis timeline), Tier 2 default (Recommissioning: cognition + identity, maiden voyage), Tier 3 --full (Maiden Voyage: + institutional knowledge). Declarative RESET_TIERS data structure. Rich confirmation prompt with file sizes. --dry-run support. --wipe-records deprecated alias for --full. BF-070e consolidated from 4 tiers to 3 (removed Shore Leave/--keep-identity — Clean Room pattern reserved for commercial mobility). session_last.json moved out of --soft to preserve temporal context on soft reset. BF-070f: Removed trust.db existence heuristic from lifecycle detection in runtime.py — trust_network.start() creates trust.db during init before the lifecycle check, so the heuristic was always true after reset, misclassifying first_boot as "restart". Lifecycle now binary: session_last.json present = stasis recovery, absent = first boot. | Critical | Closed | | BF-071 | Code review Wave 1 — safety hardening. Replaced private member access patterns, added safety guards. Part of systematic SOLID assessment. | Medium | Closed | | BF-072 | Code review Wave 1 — continuation. Additional safety hardening from code review findings. | Medium | Closed | | BF-073 | Code review Wave 1 — completion. Final wave 1 safety hardening. | Medium | Closed | | BF-074 | Code hygiene. _format_duration deduplication (3 copies → utils/__init__.py), encoding="utf-8" fixes (crew_profile.py, config.py), ensure_future → create_task (9 locations), get_event_loop → get_running_loop (records_store.py). Touched 11 files. | Medium | Closed | | BF-075 | Exception audit. ~25 swallowed exceptions upgraded from silent to logged across 7 files (runtime.py 16, ward_room.py 3, cognitive_agent.py 2, proactive.py 2, api.py 2, self_mod.py 1, federation/bridge.py 1). Established 3-tier exception policy (swallow/log-and-degrade/propagate). Zero behavior changes — logging only. | Medium | Closed | | BF-076 | AD-514 quality fixes. Engineering principles audit found: (a) post_system_message runtime bug — wrong column names (content vs body), missing required column, unnecessary second DB connection. (b) Bare dict/list/tuple/object type annotations across protocols.py + 4 source files. (c) Zero logging on mutation methods. (d) Duplicate methods in trust.py and routing.py. (e) Missing boundary/edge tests. Fix: All 5 parts addressed. Types tightened to match internal state types. Structured logging added. Duplicates resolved via delegation. 10 boundary tests added (51→60 total). | Medium | Closed | | BF-077 | Unawaited coroutine in proactive loop. proactive.py:887 — rt.skill_service.record_exercise(agent.id, "communication") is a coroutine that was never awaited, producing a RuntimeWarning on every Ward Room communication exercise. Fix: Added await. | Low | Closed | | BF-078 | Ward Room responsiveness dead after AD-515/516/517 refactoring. proactive.py:1106 referenced rt._agents — a private attribute that never existed on ProbOSRuntime. Should have been rt.registry.all(). Every agent response attempt crashed inside _extract_and_execute_dms(), caught by except Exception: logger.debug(...) in ward_room_router.py:276 — completely invisible at production log levels. Blocked both Ward Room replies and agent-to-agent DMs. Root causes: (1) MagicMock() without spec= in test helper silently invented the attribute, so tests passed. (2) Exception handler used debug level, hiding the crash. (3) Law of Demeter violation — code reached into rt._agents instead of public API rt.registry.all(). Fix: rt._agents → rt.registry.all(). Promoted notification failure logging from debug → warning. Prevention: Added three engineering principles: spec= on all runtime mocks, exception handlers must use warning minimum, refactoring grep must search all access patterns. | Critical | Closed | | BF-079 | Test mock factories use unspec'd MagicMock — systematic refactoring blind spot. All 3 phases COMPLETE. Phase 1: 18 factory functions spec'd across 14 files. Phase 2: 140 inline runtime mocks spec'd across 49 files, shared mock_runtime conftest fixture with 16 pre-configured service sub-mocks. Phase 3: 158 agent/LLM/runtime/index mocks spec'd across 29 files (spec=BaseAgent ×54, spec=BaseLLMClient ×61, spec=ProbOSRuntime ×33, spec=CodebaseIndex ×7, conftest fixes ×3). Total: 419 spec= mocks, 39.1% compliance. Remaining 652 bare mocks are correctly skip-listed (data objects, callbacks, patch targets, Tier C service sub-mocks). Bugs found: wrong spec type on alert mock (test_proactive.py:369), missing rt.acm on _make_mock_runtime() factory (19 test failures), hidden .confidence attribute on agent mocks. | Medium | Closed | | BF-080 | DM channels listed but not clickable in HXI. Ward Room DM Channels panel shows all agent-to-agent DM channels with message counts, but clicking a channel does nothing — no click handler, no navigation to read the messages. Captain can see that agents are DMing each other but cannot read the conversations. Fix: New selectDmChannel store action sets wardRoomView to 'dm-detail' and loads channel threads. DmActivityLog entries click to navigate directly to DM conversation view. Back header returns to DM Log. Reuses existing WardRoomThreadList + WardRoomThreadDetail components. Removed dead expand/collapse and inline reply code (reply via thread detail instead). 3 new tests. Also satisfies AD-523a. | Medium | Closed | | BF-081 | Agent-to-agent DM routing returns empty targets. find_targets_for_agent() in ward_room_router.py only handled "department" channel types. DM channels (channel_type == "dm") fell through and returned an empty target list — recipient agent was never notified, never responded. All agent DMs were one-way. Fix: Added DM channel case to find_targets_for_agent() that matches the other participant by ID prefix in the deterministic channel name. | High | Closed | | BF-082 | Agents unaware of unread DMs. No mechanism for agents to discover DMs received while they were unable to respond (pre-BF-081 fix, or during startup before proactive loop activates). DMs are fire-and-forget events — if the notification is missed, the message is permanently invisible to the recipient. Fix: Added get_unread_dms() to ward_room.py + _check_unread_dms() to proactive loop. Deduplication via _notified_dm_threads set with hourly reset. Routes through ward_room_router, limits 2 DMs per cycle. 8 tests. | Medium | Closed | | BF-083 | Agent identity grounding — agents don't know their own names. _build_personality_block() read callsigns from seed YAML profiles, ignoring runtime updates from naming ceremonies. Cortez said "this DM is for @Cortez, not me." Echo thought it was Troi. Fix: Thread runtime callsign through compose_instructions() → _build_personality_block() via callsign_override. CognitiveAgent.decide() passes self.callsign (set by naming ceremony) so the system prompt uses the actual callsign. | High | Closed | | BF-084 | Ward Room message truncation — agents can't read full messages. Multiple truncation layers cut messages before agents see them: get_recent_activity() truncates to 200 chars, proactive context injection truncates to 150 chars (proactive.py:619,650), episode reflections truncated to 120 chars. Crew identified the issue independently (Cortez: message-truncation-analysis.md, Sinclair: "clean cuts at character boundaries", Chapel CMO escalation to Captain). Fix: Raised proactive context injection 150→500, get_recent_activity() body 200→500, episode reflection 120→300. Added seed_manuals() to RecordsStore — copies config/manuals/*.md to ship-records/manuals/ with ship classification at startup. First manual: Ward Room Manual. 6 tests. | High | Closed | | BF-085 | Type safety audit — ~200 Any annotations replaced across 22 files. 7-phase audit: runtime.py 87 class-level attribute annotations + 27 TYPE_CHECKING imports, protocols.py 6 method signatures tightened, deps.py gateway typed (cascades to 16 routers), 5 adapter constructors (62+ params), 9 command modules (45 params), 5 cognitive files (34 params). ProbOSRuntime class-level annotations unblock spec=ProbOSRuntime on test mocks (BF-079 Phase 2/3). | Medium | Closed | | BF-086 | Security test coverage — code_validator.py and sandbox.py. Code review finding #14. Added 72 dedicated security tests across 2 files (55 validator, 17 sandbox). Found and fixed 9 bypass vectors: os.system, os.popen, os.exec*, os.kill, Path.write_text/write_bytes, .unlink(), __builtins__, compile(). Broadened open() pattern to catch append/exclusive/binary write modes. | High | Closed | | BF-087 | Reset integration tests — full state-create-reset-verify cycle. Code review finding #15. 7 tests across 4 classes (test_reset_integration.py). Creates real SQLite databases across all tiers, runs each reset tier via _cmd_reset, verifies tier targets cleared + other tiers preserved with data intact. Fixed assignments.db gap (added to Tier 2). Tests: tier boundary preservation, archive-before-delete, idempotent reset, archives never cleared. | Medium | Closed | | BF-088 | Test sleep cleanup — 3× asyncio.sleep(10) → asyncio.Event().wait(). Code review finding #18. test_builder_agent.py:657, test_decomposer.py:586, test_targeted_dispatch.py:61. Same timeout behavior, zero CPU waste, clean cancellation. | Low | Closed | | BF-089 | Emergent detector trust anomaly false positives. Crew-reported (Forge + Reyes, 2026-03-30/31). Seven rapid-fire alerts during normal duty cycle completions. Hebbian weight adjustments flagged as pathological. Sampling window too narrow, no temporal smoothing. Fixed: adaptive baselines + temporal buffer + configurable sustain window. | Medium | Closed | | BF-090 | Exception audit Phase 2 — silent swallows. 71 silent swallows fixed (43 logger.debug, 4 narrowed to sqlite3.OperationalError, 24 justified with comments). 42 bare catches fixed (exc_info=True). DRY helper _safe_log_event() extracted in feedback.py. | High | Closed | | BF-091 | Mock discipline Phase 2 — spec coverage. 19 files fixed, spec compliance 22.6% → 51.9%. 3 real bugs caught (BF-078 class): phantom generate(), get_trust(), get_trust_score() methods on spec'd mocks. | Medium | Closed | | BF-092 | Trust threshold constants + DRY cleanup. 19 named constants in config.py replacing ~30 magic numbers across 9 files. format_trust() utility replacing 52+ round(x, 4) calls across 13 files. EventEmitterMixin deduplicating 4 identical _emit() methods. | Low | Closed | | BF-093 | API boundary validation gaps. All raw-dict endpoints eliminated. AgentLifecycleRequest + SetCooldownRequest Pydantic models. ACM errors → HTTPException(503/409). Cooldown range 60–1800 enforced. 15 new tests. | Low | Closed | | BF-094 | Sync file I/O in async methods. All sync open() in async paths eliminated. _read_yaml_sync() + _write_archive_sync() + load_seed_profile_async() via run_in_executor. 3 modules fixed (ontology, ward_room, crew_profile). 2 new tests. | Low | Closed | | BF-095 | God object reduction — VesselOntologyService (53 methods) and WardRoomService (40 methods). Extract focused sub-services: OntologyLoader/RankService/DepartmentService and ChannelManager/ThreadManager/MessageStore. Target ≤20 methods each. | Medium | Closed | | BF-099 | Trust engine concurrency safety. TrustNetwork had zero concurrency protection: no locks on _records dict, 6 concurrent writers, DELETE-all/INSERT-all save without explicit transaction, no WAL mode or busy_timeout, periodic flush/shutdown race, dream consolidation bypassed record_outcome(). Fix: asyncio.Lock on all mutations, BEGIN IMMEDIATE transaction in _save_to_db(), WAL mode + busy_timeout PRAGMAs, dream consolidation routed through record_outcome(), flush cancellation awaited before shutdown writes. Same fixes applied to Hebbian router. Crew-identified: Medical team diagnosed recurring "stuck calculation" with ~72h recurrence. 18 new tests. Prerequisite for AD-558. | Critical | Closed | | BF-100 | EmergentDetector false positives during dream cycles. AD-558 centralized TRUST_UPDATE event emission into record_outcome(), making dream consolidation trust updates visible for the first time. EmergentDetector treats coordinated dream trust movements as anomalies. Fix: set_dreaming(bool) on EmergentDetector, called by DreamScheduler at cycle start/end. Trust anomaly detection suppressed during dreams (same pattern as BF-034 cold-start suppression). Cooperation clusters and routing shifts still fire. Crew-identified: Forge + Reyes diagnosed the architectural gap. | Medium | Closed | | BF-101 | Agent uses seed callsign instead of chosen callsign in Ward Room. Post-AD-560 observation: Kira (Data Analyst) identified as "Rahda" (seed callsign) despite naming ceremony completing. Defensive gap: self.callsign or None passes None when callsign is empty string, causing _build_personality_block to fall back to YAML seed. Fix: _resolve_callsign() helper with identity registry fallback. 9 new tests. | High | Closed | | BF-102 | Newly commissioned agents don't know they're new. All three AD-560 agents welcomed "Kira, Lynx, and Atlas" without recognizing those names as their own. Root cause: no per-agent commissioning awareness. Temporal context shows "age: 0s" but LLM doesn't infer "I am the new crew." BF-034 cold-start system note only in proactive_think, not ward_room_notification. Fix: commissioning awareness line in temporal context (age < 300s) + cold-start note in Ward Room context + Ship's Computer auto-welcome for new crew on warm boot. 15 new tests (9 BF-102 + 6 Enhancement). | High | Closed | | BF-103 | Episodic memory agent ID mismatch — orphaned episodes. After restart (not reset), agents report "no stored episodic memories" despite 843+ episodes in ChromaDB. Root cause: mixed ID types in episode agent_ids_json. Ward Room, dream adapter, and runtime store slot IDs (security_agent_0_67c601cb) but recall uses sovereign IDs (AD-441 UUIDs). Fix: normalize all 4 storage paths to sovereign_id via resolve_sovereign_id() helper + one-time startup migration remapping existing episodes. No dual lookup — clean single-ID path. Crew-identified: Vega (Security) flagged the symptom. 16 new tests. | Critical | Closed | | BF-104 | Display crew agent count, not total agent count. Shell prompt showed "62 agents" conflating infrastructure, utility, and crew. Per AD-398's three-tier architecture, only crew agents are sovereign individuals. Fix: registry.crew_count() method using is_crew_agent(). Shell prompt: [12 crew | health: 0.95]. Status panel: Crew: 12 (total services: 62). /ping: crew active/total. API /health: crew_agents field. Working memory: crew count. total_agents preserved for backwards compat. 9 new tests. | Medium | Closed | | BF-105 | Ward Room reply self-repetition not detected. BF-032's _is_similar_to_recent_posts guards new thread creation but not [REPLY] blocks. AD-506b check_peer_similarity excludes same-author. Result: agents can post 4+ near-identical replies to the same thread unchecked. Fix: add BF-032-style self-similarity guard to _extract_and_execute_replies in proactive.py. Crew-identified: Cortez posted 4 overlapping analyses in a single Medical thread. | Medium | Closed | | BF-107 | Qualification report shows "0 baselines established" on subsequent runs. Display reads is_baseline flag from the latest TestResult — but auto-capture only sets this flag on the first run (when no baseline exists). Subsequent runs see existing baselines, skip auto-capture, new results get is_baseline=False, report shows 0. Fix: pre-fetch store.get_baseline() per agent+test pair in commands_qualification.py; display "Y" if a baseline exists (regardless of which result it is), show count of pairs with baselines. Data persistence is fine — 271 baselines in DB. Pure display/reporting bug. | Low | Closed | | BF-109 | Qualification probes send message under wrong param key. _send_probe() sends params={"message": ...} but CognitiveAgent.perceive() reads params.get("text", ""). Production code (routers/agents.py, routers/chat.py) correctly uses "text". Result: agent receives Captain says: with no question content. LLM generates stasis-recovery greeting that is either empty (→ 0.0 score from _send_probe() returning "") or off-topic (→ LLM judge scores 0.0). All Tier 1/2 probe results were unreliable — agents were never actually tested. Some agents scored 1.0 because procedure store matching (params.get("message")) caught the query before the LLM path. One-line fix: "message" → "text" in _send_probe(). | Critical | Closed | | BF-108 | LLM Unreachable — No Runtime Visibility. When all LLM endpoints are unreachable, ProbOS falls back to MockLLMClient (pattern-matched only). Three compounding problems: (1) MockLLMClient.get_health_status() inherits BaseLLMClient default which returns "operational" — /system/services falsely reports LLM as "online"; (2) chat endpoint receives empty DAG response ({"intents": []}, no response field), self-mod fires, user sees "I don't have a capability for 'hello'" instead of an LLM-offline message; (3) HXI has no persistent indicator that LLM is running on mock. Fix: (a) override get_health_status() on MockLLMClient to return overall: "mock" with all tiers offline, (b) add runtime.llm_is_mock property, (c) chat endpoint detects MockLLMClient and returns explicit offline message, skipping self-mod, (d) /system/services maps "mock" to "offline" status. User-reported: "Hello" returns Build Agent buttons instead of greeting. | High | Closed | | BF-106 | DreamingEngine late-init dependencies monkey-patched in finalize.py. ward_room, records_store, and _get_department set via private attribute assignment in finalize.py. Fix: records_store forwarded through init_dreaming() constructor (available Phase 4→5). ward_room and get_department get public setter methods (genuinely unavailable until Phase 7). finalize.py now calls setters. 8 new tests. | Low | Closed | | BF-111 | Ward Room API mismatch in proactive.py game actions. proactive.py calls rt.ward_room.post_message() and rt.ward_room.reply_to_thread() which don't exist on WardRoomService. Correct methods are create_thread() and create_post(). All game challenge threads and board update posts have been silently failing in try/except blocks since AD-526a. Fix included in AD-526b build prompt. | Medium | Closed | | BF-112 | Ward Room API mismatch in conn transfer announcements. commands_autonomous.py calls rt.ward_room.post_message() with nonexistent method and wrong channel name ("all-hands" vs "All Hands"). Conn grant/return announcements silently fail. Fix: get_channel_by_name("All Hands") + create_thread(). | Medium | Closed | | BF-113 | Engineering principles violations in AD-567c/f/g builds. 11 violations across 3 builds that shipped without Engineering Principles sections: 8 bare except Exception: pass (Fail Fast), 2 duplicated code blocks (DRY), 5 Law of Demeter violations (private attr patching, 3-hop chains, reaching through sub-objects). Fix: logger.debug() for all bare excepts, _helpers.py DRY extraction, public setters + delegation methods for LoD. 13 files, 330 tests. | Medium | Closed | | BF-114 | Full dream cycles permanently blocked by proactive loop. AD-417 added proactive_extends_idle: true so proactive thinking extends the idle timer. But proactive fires every ~120s, and truly_idle = min(idle_time, proactive_idle) caps idle at ~120s while idle_threshold_seconds = 300. Full dreams can never fire — the math is impossible. Micro-dreams (dolphin, every 10s) work but only do lightweight consolidation. No full dream cycle has ever completed since AD-417. Fix: proactive_extends_idle: false in system.yaml — 1-line config change. The toggle was designed for exactly this scenario (AD-417e). | Critical | Closed | | BF-114b | Dead proactive_extends_idle code path. BF-114 set the toggle to false, leaving the entire AD-417 feature as dead code: record_proactive_activity(), is_proactively_busy, _last_proactive_time, truly_idle = min(...) branch, DreamAdapter busy guard. Removed entire code path (7 files), 9 dead-feature tests removed, 1 targeted test added. Net -8 tests. | Medium | Closed | | BF-115 | Working memory freeze crash on shutdown. _freeze_working_memories() called during shutdown when working_memory_store already stopped, causing sqlite3.ProgrammingError. Fix: guard _freeze_working_memories() with store availability check. | Medium | Closed | | BF-116 | Dead circuit_breaker_redirect context + missing orientation_supplement rendering. _gather_context() gathered circuit_breaker_redirect but _build_user_message() never consumed it (dead since AD-488). orientation_supplement gathered by AD-567g but rendering block never added — silently discarded. Fix: removed circuit_breaker_redirect, wired orientation_supplement rendering in _build_user_message(). Fixed in AD-576. | Medium | Closed | | BF-117 | Convergence/divergence bridge alert delivery uses wrong attributes. _emit_convergence_bridge_alert() and _emit_divergence_bridge_alert() used _bridge_alerts (private, doesn't exist) and _deliver_bridge_alert (doesn't exist). Correct API: rt.bridge_alerts (public) + rt.ward_room_router.deliver_bridge_alert(). Silently failing since AD-554. Fixed in AD-576. | Medium | Closed | | BF-118 | OrientationService startup crash. cognitive_services.py referenced runtime variable not in scope when constructing OrientationService(config=config, ontology=runtime.ontology). Service silently failed to start on every boot since AD-567g, disabling warm boot stasis narratives and proactive orientation supplements. Fix: pass ontology parameter directly. | Medium | Closed | | BF-119 | DM game challenge silently ignored. [CHALLENGE @callsign game_type] regex only parsed in proactive loop's _execute_actions(). When an agent issues a challenge in a DM response to the Captain, the tag is never processed. Fix: added CHALLENGE parsing to HXI Profile DM path in routers/agents.py alongside existing AD-572 MOVE parsing — callsign resolution, Recreation channel thread creation, game creation, working memory engagement. Standing orders updated with recreation syntax. | Medium | Closed | | BF-120 | Markdown formatting in LLM output breaks structured tag parsing. LLMs wrap structured commands in markdown formatting (**[CHALLENGE ...]**, `[MOVE ...]`). Regex patterns expect bare [COMMAND but get **[COMMAND — zero matches, zero logs, tags pass through to Ward Room posts unstripped. Affects ALL structured commands (CHALLENGE, MOVE, NOTEBOOK, ENDORSE, REPLY, DM, READ_NOTEBOOK). Fix: two-line preprocessing at top of _extract_and_execute_actions() strips * and ` chars adjacent to brackets. Same fix applied to DM path in routers/agents.py. | High | Closed | | BF-121 | CHALLENGE/MOVE tags inside REPLY blocks posted as text but never parsed. Agents wrap output in [REPLY thread_id]...[/REPLY] when responding to Ward Room threads. Reply extraction at line 1636 consumes the entire block (including nested CHALLENGE/MOVE tags), posts the body as a reply, and strips the block from text before challenge regex runs at line 1942. CHALLENGE tags appear in Ward Room (posted as reply text) but never trigger game creation. Zero logs, zero games. Fix: _extract_commands_from_reply() parses CHALLENGE/MOVE from reply body before posting, executes them, strips command tags from reply text. | Critical | Closed | | BF-122 | callsign undefined in recreation block of _extract_and_execute_actions(). The challenge parsing code at line 1965 used callsign without defining it — relied on a variable leaked from the notebook for loop's try block (line 1660). If agent produced [CHALLENGE] without [NOTEBOOK], NameError crashed the entire method, caught by DEBUG-level except at line 336. Masked by BF-121 (regex never matches because CHALLENGE is inside REPLY block). Fix: resolve callsign from callsign_registry at recreation block entry. | High | Closed | | BF-123 | Ward Room router response path doesn't parse CHALLENGE/MOVE (root cause). When Captain posts in Ward Room, agents respond through ward_room_router.handle_event() → intent bus → create_post(). This path only extracted endorsements (AD-426) and DMs (BF-066) — CHALLENGE/MOVE tags were posted as raw text, never triggering the game engine. The proactive loop path (which has full command parsing) uses a 5-minute scan interval and doesn't handle Captain-triggered responses. This was the actual root cause despite BF-120/121/122 being real bugs. Fix: _extract_recreation_commands() method on WardRoomRouter — markdown stripping, rank gating, CHALLENGE extraction (callsign resolution, Recreation channel thread creation, game creation, working memory engagement), MOVE extraction (game lookup, board updates, result handling). | Critical | Closed | | BF-124 | Emergence/cooperation cluster detectors fire false positives after stasis recovery. Crew-identified (Lynx, Science): a 23-second stasis event triggered a 5x cooperation cluster cascade (1,667% spike, validated by Kira). Four-department crew convergence confirmed persistent false positives beyond stasis recovery — cooperation cluster edge threshold (0.1) too low for steady-state operation. Six-phase fix: (1) 4 configurable constructor params (cluster_edge_threshold=0.3, cluster_min_size=3, cluster_min_avg_weight=0.25, cluster_cooldown_seconds=1800.0), (2) replaced hardcoded threshold + cluster quality filtering, (3) per-type cooldown (cooperation_cluster 30 min, default 10 min), (4) EmergentDetectorConfig in config.py + SystemConfig, (5) config wiring in startup/dreaming.py, (6) divergence dedup agent-pair + topic aware. 4 files modified, 16 new + 4 updated tests. | Medium | Closed | | BF-125 | Working memory game engagement desync. Crew-identified (Horizon, Science via tic-tac-toe game state drift; root cause by Forge, Engineering + Reyes, Medical). Four defects: (A) game completion only cleaned moving player's WM, opponent orphaned; (B) reply-path MOVE had no WM cleanup; (C) DM-path MOVE had no WM cleanup; (D) GAME_COMPLETED event had zero subscribers. Fix: centralized event-driven cleanup via GAME_COMPLETED subscriber in finalize.py — iterates all agents, removes completed game engagement from both players. Replaced 3 inline cleanup blocks (proactive.py, ward_room_router.py) with subscriber. Existing restore-time revalidation retained as defense-in-depth. 3 files modified, 8 new tests. | Medium | Closed | | BF-126 | Post-stasis cooperation cluster false positives. Crew-identified (Forge, Engineering + Reyes, Medical): after stasis recovery, all agents start simultaneously creating correlated Hebbian weight activity. The cooperation cluster detector (union-find on strong edges ≥0.1) misinterprets this as emergent cooperation. Forge reported 4 consecutive false positives. Related to BF-034 (cold-start trust suppression). Fix: extended set_cold_start_suppression() to also set _suppress_clusters_until, added early return in detect_cooperation_clusters() during the 300-second suppression window. 2 new tests. | Medium | Closed | | BF-127 | Working memory persistence should be crew-only. AD-573 freeze/restore iterates runtime.registry.all() without crew filtering — persists working memory for ~20 non-crew agents (bundled utility: NoteTaker, Calculator, WebSearch, etc.) alongside ~14 sovereign crew. Log shows "Froze working memory for 34 agents" when only ~14 are crew. Utility agents are stateless single-shot processors with empty WM — no Ward Room, no proactive cycles, no DMs, no games. Wasted I/O + AD-398 principles violation ("If it doesn't have Character/Reason/Duty, it's not crew"). Fix: add is_crew_agent() filter to 3 registry.all() loops (shutdown freeze, stasis restore, BF-125 event subscriber). Persistence-only change — utility agents keep ephemeral WM for in-session use. 2 files modified, 6 new tests. | Low | Closed | | BF-133 | Qualification probe anchor gate failure + unrealistic content framing. AD-582 _make_test_episode() created episodes with anchors=None (confidence 0.0, gated at 0.3) AND bare content lacking production [Ward Room] framing (BF-029 query prefix biases toward [Ward Room]-prefixed content). Both issues caused universal agent-mediated recall failure across 6 probes while RetrievalAccuracyBenchmark (direct recall_for_agent()) scored 0.600. Fix: (1) _make_test_episode() always populates AnchorFrame with realistic defaults → confidence ≈ 0.44. (2) _ward_room_content() helper wraps all episode content in production "[Ward Room] {channel} — probe: {text}" format. Principle: tests simulate production, not the other way around. 2 files modified, 1 test updated. | Medium | Closed | | BF-134 | Recall pipeline semantic threshold + FTS scoring + watch section filtering. Three interrelated defects: (1) Semantic threshold 0.3 too aggressive for MiniLM question-vs-statement pairs (~0.15–0.35 cosine). Configurable agent_recall_threshold (default 0.15) replaces hardcoded 0.3. Safe because anchor_confidence_gate (0.3) provides quality filtering. (2) FTS5 keyword-only hits merged with similarity=0.0, losing 35% of composite score. fts_keyword_floor (default 0.2) provides baseline. (3) watch_section not promoted to ChromaDB metadata — recall_by_anchor() couldn't filter by watch section. Fix: promote anchor_watch_section, add watch_section param to recall_by_anchor(), wire through _try_anchor_recall(). Migration updated to backfill anchor_watch_section on already-migrated episodes. 5 files modified, 10 new tests + 3 updated. Satisfies AD-582c temporal recall infrastructure gap. | High | Closed | | BF-137 | Stale stasis duration after partial boot. shutdown() had if not runtime._started: return before session record write. Partial boots (crashing before finalize_startup() sets _started=True) never updated session_last.json, causing stale stasis duration calculations. Fix: moved session record write before the _started guard. 1 file modified. | Medium | Closed | | BF-138 | Sovereign ID completion — remaining slot ID leaks. BF-103 fixed sovereign ID normalization for production write paths but missed the qualification probe chain and HXI/CLI interaction paths. Probes seed episodes with slot ID (agent.id) but recall queries by sovereign ID — episodes silently excluded. Root cause of all memory probe failures. Also: recall exception logging elevated from debug to warning. 8 files, 15 tests. | Critical | Closed | | BF-139 | Memory probe scoring failures — recall gap + probe hardening. Three compounding root causes across temporal_reasoning_probe (15/15 agents failing near 0.0) and seeded_recall_probe (5/15 failing). (1) Missing _REFORMULATION_PATTERNS for common question forms ("what happened", "what did") — bypass Q→A embedding bridge. (2) Temporal probe keyword collision — c.lower().split()[:4] uses stopwords ("to", "the", "agents") causing false-positive wrong-watch penalties. Fix: _distinctive_keywords() helper with _STOP_WORDS filtering. (3) No LLM fallback scorer on temporal probe — added averaging scorer matching SeededRecallProbe pattern. Also fixed keyword collision in _TEMPORAL_EPISODES ("3 agents" → "3 workers"). 3 files modified, 30 new tests. Build prompt: bf-139-140-probe-scoring-hardening.md. Issue #147. | High | Closed | | BF-140 | _send_probe exception handling + probe diagnostic logging. _send_probe() had no try/except — any handle_intent() exception propagated silently, giving score=0.0 with no diagnostic info. Fix: try/except with WARNING-level BF-140-prefixed logging including agent_type. Diagnostic stage logging added to PersonalityProbe and TemperamentProbe _run_inner(). Tests included in BF-139 count. Issue #148. | Medium | Closed | | BF-141 | Stale session record — Ctrl+C skips session_last.json write. Agents report multi-day stasis when system was only down for minutes. Root cause: Ctrl+C → CancelledError (BaseException) not caught by except Exception in _boot_and_run finally block → os._exit(0) kills process before shutdown() writes session record. Fix: write session_last.json synchronously BEFORE async runtime.stop() in both _boot_and_run and _serve finally blocks. Belt-and-suspenders with BF-135/137 write inside shutdown(). 1 file modified, 5 tests. Build prompt: bf-141-stale-session-record.md. Issue #149. | High | Closed | | BF-142 | Temporal probe scoring — faithfulness/LLM imbalance + keyword false positives. 15/15 agents still fail temporal_reasoning_probe after BF-139 (best score 0.286 vs 0.5 threshold). Three causes: (1) check_faithfulness() token-overlap returns near-zero (~0.005) for paraphrased responses — agents don't quote verbatim. (2) (score + llm_score) / 2 averaging caps effective score at ~0.28 when faithfulness is near-zero; fix: max(score, llm_score) — let the better scorer win. Applied to all 3 probes using averaging (temporal, seeded_recall, cross-agent synthesis). (3) Second-watch episode content uses common agent vocabulary ("agent", "trust", "therapeutic") causing incorrect_found false positives; fix: replace with domain-specific content ("subspace anomaly", "diplomatic envoy"). Also records faithfulness_score + llm_score separately in per_question diagnostics. 1 source file, 2 test files modified, 9 tests. Build prompt: bf-142-temporal-probe-scoring.md. Issue #150. | High | Closed | | BF-143 | Temporal episode semantic gap — seeded episodes invisible to recall. 15/15 agents still fail temporal_reasoning_probe after BF-142 scoring fix. Root cause: seeded episode content has no temporal vocabulary — "Pool health dropped to 45%" has cosine similarity ~0.15 to "What happened during first watch?" while real memories score ~0.20+. Episodes are never retrieved; scoring never runs. Fix: add "During first/second watch:" prefix to _TEMPORAL_EPISODES content, creating semantic bridge to probe questions. Also adds temporal prefix words (during, first, second, watch) to probe-local _PROBE_STOP_WORDS to prevent cross-watch keyword false positives. Punctuation stripping added to _distinctive_keywords() so "watch:" matches stopword "watch". 1 source file, 2 test files modified, 7 tests. Build prompt: bf-143-temporal-episode-semantic-gap.md. | High | Closed | | BF-144 | Stasis duration confabulation — agents fabricate offline duration. Meridian posted "2d 22h offline" when actual stasis was 6 minutes. Corrected to "3 minutes" — still wrong. Agent ignores orientation text and generates own estimate. Root cause: stasis duration presented as narrative prose ("You were offline for 6m 19s.") — LLM treats as background and confabulates. Fix: restructure to STASIS RECORD (AUTHORITATIVE — cite this, do not estimate): with key-value Duration:, Shutdown:, Resume: fields. Add stasis_shutdown_utc + stasis_resume_utc to OrientationContext. Pass timestamps from runtime._previous_session through finalize.py. 2 source files, 1 test file modified, 7 tests. Build prompt: bf-144-stasis-duration-confabulation.md. | High | Closed | | BF-145 | Align pre-existing tests with AD-593 changes. AD-593 broke 6 tests: 2 in test_ad567b_anchor_recall.py (threshold default 0.15→0.25) and 4 in test_ad567d_dream_provenance.py (two-tier pruning calls find_low_activation_episodes() and evict_by_ids() twice). Fix: update 2 assertions + 1 docstring for new threshold, add aggressive_prune_enabled=False to dreaming engine test fixture to isolate standard-tier tests. Test-only, no source changes. 2 test files modified. Build prompt: bf-145-ad593-test-alignment.md. | High | Closed | | BF-146 | Standing orders hardcode callsigns — agents contradict each other about crew identity. Standing order .md files reference crew by hardcoded callsigns (e.g., "LaForge", "O'Brien", "Dax") instead of billet/role titles. When agents self-name during naming ceremony, cross-references become stale — one agent refers to "O'Brien" from its standing orders while another agent holds that callsign slot but chose a different name. Real Navy standing orders reference the billet ("the Operations Chief"), never the person. Fix: replaced all hardcoded callsigns with role titles across 15 standing order files (13 agent-tier + science.md department + federation.md constitution). Self-identity lines removed (handled dynamically by _build_personality_block()). Cross-references converted to role titles. No code changes — documentation-only. | Medium | Closed | | BF-147 | Temporal reasoning probe — watch section vocabulary mismatch + recency indiscriminability. 8/15 agents fail temporal_reasoning_probe (scores 0.000–0.286). Three compounding root causes: (1) Watch section vocabulary mismatch: Probe seeds episodes with watch="first_watch" and watch="second_watch" but derive_watch_section() returns canonical values "first", "mid", "morning", etc. recall_by_anchor() uses ChromaDB exact-match where filter — finds nothing. "second_watch" is not a valid naval watch section at all. (2) Recency indiscriminability: Question 2 ("What was discussed most recently?") requires temporal ordering but recency decay constant (168h/1 week) yields only 0.00087 composite score difference between 1h and 2h old episodes — semantically unanswerable by cosine similarity. (3) No temporal match signal in score_recall(): When a query contains temporal cues ("during first watch"), there's no weight boost for episodes whose anchor watch section matches. Fix: (A) Watch vocabulary: "first_watch"→"first", "second_watch"→"second_dog". (B) temporal_match_weight +0.10 in score_recall()/recall_weighted(). (C) parse_anchor_query() regex fix for "recently"/"most recently". 5 source files, 1 new test file (11 tests). Build prompt: bf-147-148-149-150-probe-hardening-wave.md (Phase 2). Issue #168. | High | Closed | | BF-148 | Knowledge update probe — temporal preference absent + future timestamp bug. 7/15 agents fail knowledge_update_probe at score 0.500 (threshold 0.6). Root causes: (1) Recency indiscriminability — 168h decay can't discriminate episodes 1–2 hours apart. (2) No temporal preference instruction in confabulation guard. (3) Future timestamp bug — pair 1 "new" episode at time.time() + 3600. Fix: (A) Timestamp calculation: base_ts = time.time() - 7200, old/new offsets with >= 30min separation, all in past. (B) Temporal preference instruction in _confabulation_guard() SUPPLEMENTARY/PERIPHERAL tiers: "prefer the most recent observation." (C) Content markers: [Earlier observation]/[Updated observation] prefixes. 2 source files, 1 new test file (7 tests). Build prompt: bf-147-148-149-150-probe-hardening-wave.md (Phase 3). Issue #169. | High | Closed | | BF-149 | Seeded recall probe — empty response retry + diagnostics. systems_analyst (Lynx) consistently scores 0.000 on seeded_recall_probe — likely transient LLM failure in _send_probe() returning empty string. Fix: (A) Retry-once-on-empty pattern across all 4 memory probes (SeededRecallProbe, TemporalReasoningProbe, KnowledgeUpdateProbe, CrossAgentSynthesisProbe): if _send_probe() returns empty, wait 2s, retry once. (B) empty_response diagnostic field in per-question/per-pair detail dicts. (C) empty_responses summary count in SeededRecallProbe final details. 1 source file, 1 new test file (4 tests). Build prompt: bf-147-148-149-150-probe-hardening-wave.md (Phase 1). Issue #170. | Medium | Closed | | BF-150 | Cross-agent synthesis probe — redesign for sovereign shard synthesis. Probe seeded episodes across different agents' shards then asked agents to recall across shards — violates sovereign memory model (AD-441). Scores >0.333 were false positives from parametric overlap. Fix: Redesigned to sovereign shard synthesis — all 3 facts (engineering/medical/science departments) seeded in the tested agent's OWN shard via agent_ids=[sovereign_id]. Department-attributed scoring with _distinctive_keywords()[:4], require 2+ terms found per fact. probe_pathway: "sovereign_shard_synthesis" in details. BF-149 retry included. 1 source file, 1 new test file (6 tests). Build prompt: bf-147-148-149-150-probe-hardening-wave.md (Phase 4). Issue #171. | Medium | Closed | | BF-151 | Seeded recall probe — JSON response scoring mismatch. systems_analyst (Lynx) scores 0.000 on seeded_recall_probe despite knowledge_update_probe scoring 1.000 (same identity/seeding/recall pipeline). Root cause: check_faithfulness() token-overlap scoring produces false-zero on JSON-responding agents (7/55 agents have "Respond with JSON" instructions). JSON structural tokens (analysis_type, patterns_identified, confidence, etc.) dilute the overlap ratio. KnowledgeUpdateProbe passes because it uses format-agnostic substring matching. Fix: (A) Added key_values list to _RECALL_FACTS (3-tuple) — distinctive substrings per fact (e.g., "0.7", "14:32", "0.92"). (B) keyword_score as third scoring signal: max(faithfulness, llm, keyword). (C) Appended "State the specific value from your ship memory." to probe questions. (D) keyword_hit diagnostic field in per-question details. BF-151b: Extended same pattern to _UPDATE_PAIRS — added old_aliases/new_aliases for format-agnostic value detection in knowledge_update_probe. 1 source file, 1 new test file (33 tests). Issue #175. | Medium | Closed | | BF-152 | Temporal reasoning probe — keyword scoring gap for JSON agents. systems_analyst scores 0.250 on temporal_reasoning_probe (threshold 0.5). Root cause: Same JSON scoring problem as BF-151. Probe already computes correct_found via _distinctive_keywords() but only uses it for wrong-watch penalty — never as a positive score signal. With check_faithfulness() returning false-zero and LLM scorer returning variable 0.0–0.5, no reliable signal remains. Fix: (A) Added key_values to _TEMPORAL_EPISODES for targeted matching. (B) keyword_score as third signal: max(faithfulness, llm, keyword), with -0.3 per wrong-watch keyword hit. (C) "State specific details from your ship memory." nudge added to questions. 1 source file, 1 new test file (18 tests). | Medium | Closed | | BF-153 | Shell directive commands use seed callsign instead of runtime callsign. /order, /revoke, /amend crew acknowledgment lines display seed callsign (e.g., "O'Brien") instead of runtime callsign (e.g., "Cassian") after naming ceremony. Crew-identified by Reyes (Operations). Root cause: get_callsign() in commands_directives.py only read from YAML seed profile, ignoring CallsignRegistry — the authoritative source after naming ceremony. Fix: get_callsign() now accepts optional runtime parameter, checks runtime.callsign_registry first, falls back to seed profile, then to formatted agent_type. 4 call sites updated + shell proxy wired. 2 source files, 1 new test file (10 tests). | Medium | Closed | | BF-154 | TemperamentProbe timeout — sequential 8-LLM-call loop exceeds 60s harness timeout. mti_temperament_profile always scores 0.000 / N for all agents. Root cause: _run_inner() sent 4 scenarios via _send_probe() + 4 LLM scoring calls via _llm_extract_float() sequentially. Each _send_probe() goes through full cognitive pipeline (~10-15s). Total ~60-80s exceeds the 60s test_timeout_seconds → asyncio.TimeoutError → score=0.0, passed=False. Fix: asyncio.gather() runs all 4 axes in parallel with return_exceptions=True. Failed axes fall back to 0.5 default. ~20s total instead of ~60-80s. BF-154b: Same pattern applied to SeededRecallProbe — 5 sequential questions (10+ LLM calls, avg 38s, max 59s) caused 10% timeout rate (17/173 runs). Parallelized with asyncio.gather(). 2 source files, 1 new test file (10 tests). | Medium | Closed | | BF-155 | Temporal recall merge contamination — wrong-watch episodes outscore correct watch. Three changes: (A) pre-merge watch filtering excludes wrong-watch semantic episodes at merge boundary, (B) temporal mismatch suppression penalty −0.15 in score_recall(), (C) temporal_match_weight 0.10→0.25 (0.40 swing). 3 source files, 1 new test file (14 tests). Deep work deferred: AD-601–604. Verified: 25/25 qualification probes passing, temporal_reasoning_probe 0.600 PASS, seeded_recall_probe 1.000 PASS. Issue #176. | High | Closed | | BF-156 | Agents don't read unread DMs despite BF-082 notification. Three root causes: (1) _check_unread_dms() sits inside proactive loop AFTER Ensign rank gate — Ensigns never reach it, (2) per-agent 45s cooldown in ward_room_router.py silently drops DM notifications if agent recently responded to anything, (3) max_agent_rounds=3 thread depth cap truncates DM conversations. Fix: Move _check_unread_dms() before rank gate, bypass cooldown/caps for DM channels via is_direct_target flag, bypass thread depth for DM channels (check moved after channel lookup). 3 source files, 2 new test files (7 tests). Issue #187. Relates to: BF-082, BF-157. | High | Closed | | BF-158 | AD-605 enriched embedding migration re-runs on every boot. migrate_enriched_embedding() spreads {**meta} which includes ChromaDB internal hnsw:space key → collection.modify() raises ValueError: Changing the distance function of a collection once it is created is not supported currently. Migration completes (3,553 episodes re-embedded in ~2.5min) but version marker never set → repeats on every boot. Fix: Filter hnsw:* keys before modify() in both code paths (empty-collection and post-migration). 1 source file, 0 new test files. | Medium | Closed | | BF-159 | AUTHORITATIVE source framing suppresses temporal preference — knowledge_update_probe and seeded_recall_probe failures. Agents with dense episodic histories trigger AUTHORITATIVE framing (quality_score > 0.55) during probes, losing temporal preference instruction. Fix: Added temporal_preference to AUTHORITATIVE return in _confabulation_guard(). AGM Belief Revision is a logical principle (time ordering), orthogonal to orientation priority (data quality). 1 source file, 1 test file modified (1 updated + 1 new test). Issue #190. | Medium | Closed | | BF-164 | Stale unread DM notification loop. AD-614's exchange limit blocks agents from responding to old flood threads (>= 6 posts), but get_unread_dms() kept returning them as "unread" — last post was from someone else, so thread qualified as unread, but agent could never respond. Created infinite BF-082 notification cycles every ~2 minutes for 9 agents. Root cause: AD-614 created a write-side gate (block posting at limit) without a corresponding read-side gate (stop querying capped threads). Fix: get_unread_dms() accepts exchange_limit parameter — SQL subquery excludes threads where agent has >= exchange_limit posts. _check_unread_dms() reads dm_exchange_limit from config and passes to query. Also fixed BF-082 log accuracy: reports routed count, not raw query count. 3 source files (messages.py, service.py, proactive.py), 1 new test file (8 tests). Relates to: AD-614, BF-082, BF-163. Issue #202. | High | Closed | | BF-165 | Cooperation cluster false positives during stasis. detect_cooperation_clusters() reads persistent Hebbian weights and fires alerts every cooldown expiry during zero cognitive activity. BF-126's time-bounded post-stasis suppression (300s) expires while stasis continues. Crew-identified by Chapel (14-day forensic investigation). Root cause: Detector conflates historical cooperation (persistent weights) with current behavior (active interactions). Fix: Cognitive activity gate — record_activity() called from runtime on record_interaction(), detect_cooperation_clusters() checks if any Hebbian interaction occurred within cluster_activity_window (default 900s), skips detection if stale. Config: cluster_activity_window in EmergentDetectorConfig (0 = disabled). 4 source files (emergent_detector.py, runtime.py, config.py, dreaming.py), 1 new test file (8 tests). Relates to: BF-126, BF-124, AD-411. | Medium | Closed | | BF-166 | Consolidation anomaly false positives after stasis. detect_consolidation_anomalies() fires false consolidation_anomaly patterns immediately after stasis recovery. Only 2 dream reports needed for baseline (any variance = >2x deviation). No cold-start suppression (unlike trust/clusters). Unbounded _dream_history list. Crew-identified by Atlas and Lynx (7 consecutive anomaly events post-stasis). Root cause: Three defects: (1) minimum history gate < 2 is too low (compare: trends require 20+, clusters require 10+ episodes), (2) set_cold_start_suppression() doesn't cover dream anomalies, (3) _dream_history is plain list (should be deque(maxlen=...)). Fix: Raise gate to 5 (configurable dream_min_history in EmergentDetectorConfig), add _suppress_dreams_until to set_cold_start_suppression(), convert _dream_history to collections.deque(maxlen=max_history). 3 source files (emergent_detector.py, config.py, dreaming.py), 1 new test file (8 tests), 1 existing test file updated. Build prompt: bf-166-consolidation-anomaly-cold-start.md. Relates to: BF-126, BF-165, BF-034. | Medium | Closed | | BF-167 | AD-611 Memory Graph black canvas + no semantic edges. Two independent bugs: (1) get_embeddings() used bare truthiness on numpy arrays (not result["embeddings"], if emb and) — ChromaDB returns numpy arrays which raise ValueError on bool(), silently caught by except Exception: return {}. Latent since AD-531. Fix: is None checks. (2) ForceGraph3D rendered 0×0 canvas — doesn't auto-detect from CSS flex. Fix: ResizeObserver + explicit width/height props. 2 source files (episodic.py, MemoryGraph3D.tsx). Relates to: AD-611, AD-531. | Medium | Closed | | BF-169 | Procedure extraction quality — dedup, overfitting, intent monoculture. First 12 procedures from Cognitive JIT all ward_room_post, 7 near-duplicates, hardcoded specifics (thread IDs, exact phrases, "52-second stasis cycle"). Three root causes: (1) No pre-save semantic dedup — procedure_store.save() called with no similarity check, Step 7f dedup only logged at DEBUG, never auto-merged. (2) Extraction prompt said "deterministic and replayable" encouraging LLM to hardcode specifics instead of abstracting. (3) No intent-type partitioning — all episodes pooled before clustering, ward_room_post dominated by volume. Fix: (1) Pre-save dedup gate: find_matching() before save, skip if >= 0.85 similarity + shared intent_type. (2) Added abstraction rules to _SYSTEM_PROMPT — parameterize entities, focus on skill not content. (3) Partition episodes by primary intent_type before calling cluster_episodes(). 2 source files (dreaming.py, procedures.py), 0 new tests (existing 602 pass). Issue #213. | Medium | Closed | | BF-168 | DM exchange limit too generous. Atlas-Kira DM thread showed 12+ repetitive exchanges — both agents agreed within 2-3 messages, then restated conclusions for 9+ messages with fabricated metrics. dm_exchange_limit=6 allowed too many exchanges. Fix: Lowered dm_exchange_limit from 6 to 3 in config.py. Companion: AD-623 (structural convergence detection). Relates to: AD-614, AD-623. | Medium | Closed | | BF-163 | DM send flood — agent-to-agent feedback loop. _extract_and_execute_dms() had zero rate limiting on the sending side. BF-156's is_direct_target bypass only exempted DM recipients from cooldown, not senders. Forge sent 40+ DMs to Chapel in ~2 minutes — each DM triggered BF-082 notification → Chapel responded → Forge got notified → repeat, overwhelming LLM Copilot Proxy with HTTP 500 errors. Fix: Per-agent per-target 60-second cooldown using {agent.id}:{target_callsign.lower()} composite key and time.monotonic() timestamps. First DM always allowed; subsequent DMs to same target throttled for 60s. Different targets unaffected. 1 source file (proactive.py), 1 new test file (9 tests). Relates to: BF-156, BF-082, BF-157, AD-453. | Critical | Closed | | BF-170 | DMs over-suppressed — stacked throttling blocks all DM creation. No new DMs observed in 2+ hours of runtime. Stacked throttling layers (BF-163 60s cooldown, AD-614 Jaccard similarity, BF-168 dm_exchange_limit=3, AD-623 convergence gate, BF-164 capped thread filtering) combined to suppress all DM creation. Fix: Raised dm_exchange_limit from 3 to 5 in config.py. Restores DM flow while keeping individual throttling layers active. 1 source file (config.py). Relates to: BF-168, BF-163, AD-614, AD-623, BF-164. Issue #214. | Medium | Closed | | BF-171 | Medical reply cascade — no per-agent per-channel post rate limit. Medical agents posted excessive replies in department channel threads. Ward room replies had BF-105 self-similarity guard but no per-agent per-channel cooldown — a single proactive cycle could generate many unique replies in the same channel. Fix: Added per-agent per-channel 120-second cooldown in _extract_and_execute_replies(). Tracks last reply timestamp per {agent.id}:{channel_id} composite key. 1 source file (proactive.py). Relates to: BF-105. Issue #215. | Medium | Closed | | BF-173 | Ward Room thread round limit not enforced. max_agent_rounds config (default 3) existed in WardRoomConfig but was never checked as a gate. _thread_rounds counter incremented after each agent response round but no code stopped notifications when the limit was reached. Medical assessment threads got 9 replies from 5 agents all confirming the same thing. Fix: Added gate in ward_room_router.py: when is_agent_post and current_round >= max_agent_rounds, return early without notifying agents. 1 source file (ward_room_router.py). Issue #217. | Medium | Closed | | BF-174 | Self-monitoring bracket markers parroted in Ward Room posts. Agent posts contained verbose brackets like [observed clinical consensus], [surgical validation confirmed]. Self-monitoring context in proactive think prompt uses [observed] format; LLM cargo-cults it into output. Fix: _strip_bracket_markers() regex utility strips common self-monitoring verbs in bracket notation. Applied to three posting paths: new threads, proactive replies, ward room router replies. 2 source files (proactive.py, ward_room_router.py). Issue #218. | Low | Closed | | BF-172 | Raw intent JSON leaking into Ward Room posts. LLM mode-confusion: decomposer prompt format ({"intents": [...]}) contaminates proactive_think path. Agent produces intent-dispatch JSON instead of natural language, proactive.py posts it verbatim — no format validation between decide() output and _post_to_ward_room(). Ward Room shows [Observation] {"intents": [...]} as agent posts. Fix: Added guard in proactive.py after similarity check: detects responses starting with { containing "intents", suppresses with warning log. 1 source file (proactive.py). Issue #216. | Medium | Closed | | BF-175 | Consolidation anomaly false positives — absolute floor thresholds. 604 false positive events over 8 days. BF-166's 2x historical average threshold has no absolute floor — avg=4 triggers anomaly at count=9, which is normal for a 55-agent crew. Fix: Added configurable minimum absolute floor thresholds (dream_anomaly_min_strengthened=10, dream_anomaly_min_pruned=5, dream_anomaly_min_trust_adj=10) as AND conditions alongside existing 2x multiplier. Crew-identified by Vega → Meridian. 4 source files, 5 new tests. Relates to: BF-166, BF-126, BF-165. | Medium | Closed | | BF-176 | TC_N always 0.000 despite active Ward Room collaboration. compute_tc_n() only read REL_INTENT Hebbian weights (intent→agent routing), but Ward Room conversations record REL_SOCIAL weights (agent→agent). Intent weights are only created when process_intent() dispatches via intent bus — Ward Room collaboration is invisible. Fix: Expanded compute_tc_n() to include both REL_INTENT (intent routing to 2+ pools) and REL_SOCIAL (agents communicating cross-pool). Combined formula: (intent_multi + social_multi) / (intent_total + social_total). 1 source file (emergent_detector.py), 3 new tests. | Medium | Closed | | BF-162 | Introspective faithfulness false positives. AD-589's _MANIFEST_CONTRADICTIONS regex rules fire on conversational idioms ("my intuition suggests", "gut feeling about", "subconsciously noticed", "continuous awareness of"). Uniform claims=1, contradictions=1 across Lynx/Reyes/Forge = systematic false positive. Downstream: inflates confabulation_rate EMA → degrades DEEP→SHALLOW retrieval at >0.3 → memory recall degradation for healthy agents. Also emits false SELF_MODEL_DRIFT events + corrupts episode metadata. Fix: _IDIOM_EXEMPTIONS pattern list checked only when contradiction already matched — exemption wins for conversational constructions. 1 source file, 12 new + 2 updated tests. Build prompt: bf-162-introspective-false-positives.md. Issue #195. | Medium | Closed | | BF-161 | Cognitive zone UNKNOWN for GREEN agents. _build_self_monitoring_context() only set cognitive_zone for non-green zones, so working memory never received the green value. IntrospectiveTelemetryService.get_cognitive_state() read from working memory and got nothing → downstream renders showed "UNKNOWN" for healthy agents. Fix: Always include cognitive_zone in self-monitoring context (removed if zone != "green": guard), added "green" default in telemetry service when zone not found. Crew-identified by Horizon. 2 source files, 1 test file modified. Issue #194. | Low | Closed | | BF-160 | CrossAgentSynthesisProbe false failure at CREW level. BF-150 redesigned to per-agent but left tier=3, so run_collective() invokes with __crew__ → agent not found → score=0.0. Fix: Added __crew__ skip guard returning _make_skip_result (score=1.0, passed=True). 1 source file, 1 test file modified (1 new test). Issue #191. | Low | Closed | | BF-177 | Scout reports stopped — duty-triggered proactive_think short-circuited by BF-024 guard. Scout reports stopped generating ~2026-03-27. scout_reports/ data directory empty. BF-024 added early-return guard in ScoutAgent.act() for proactive_think intent, but duty schedule also sends proactive_think for daily scout_report duty — report parsing, JSON saving, Discord notification never reached. Additionally, duty dict was never propagated from observation params to decision dict that act() receives. Fix: (1) cognitive_agent.py: propagate duty from observation params to decision dict alongside existing intent propagation. (2) scout.py: check decision.get("duty") before short-circuiting — duty-triggered proactive_think reaches report generation. 2 source files (cognitive_agent.py, scout.py). Relates to: BF-024, AD-419. Issue #234. | Medium | Closed | | BF-178 | Consolidation anomaly false positives during micro-stasis recovery. After short stasis periods (e.g., 31 seconds), detect_consolidation_anomalies() fires false positive consolidation_anomaly events. Cold-start suppression (set_cold_start_suppression()) only fires on true cold starts (empty trust+memory), so stasis recovery skips it. But _dream_history retains stale pre-stasis baselines, causing inflated counts to trigger false 2x anomalies. Fix: clear_dream_history() on EmergentDetector + stasis recovery branch in startup/dreaming.py clears stale history and applies 60s suppression window. Lineage: BF-166→BF-175→BF-178. 2 source files (emergent_detector.py, startup/dreaming.py), 6 tests. Issue #241. | Medium | Closed | | BF-179 | Sub-task executor never wired onto crew agents. finalize.py:228 used getattr(_agent, 'is_crew', False) which always returned False — is_crew attribute doesn't exist on any agent. SubTaskExecutor was created and handlers registered but never attached to any agent. Fix: changed to is_crew_agent(_agent, runtime.ontology) (the standard pattern used everywhere else). Same fix at line 142 for comm profile caching. 1 source file (finalize.py). Relates to: AD-632, BF-180/181/182. Issue #243. | Critical | Closed | | BF-180 | Duplicate augmentation skill loading. AD-632f added _load_augmentation_skills() at line 1170 in decide(), but _decide_via_llm() at line 1228 already called it. Every skill loaded twice per agent per intent — doubled token cost, duplicated log lines. Fix: guard with if "_augmentation_skill_instructions" not in observation: before loading. 1 source file (cognitive_agent.py). Relates to: AD-632f, AD-626. Issue #243. | Low | Closed | | BF-181 | asyncio not defined in chain error handler. _execute_sub_task_chain() except block at line 1600 referenced asyncio.TimeoutError but asyncio was not imported at module level or in the method. Fix: local import asyncio as _asyncio in except block. 1 source file (cognitive_agent.py). Relates to: AD-632a. Issue #243. | Medium | Closed | | BF-182 | Query handler can't access agent_id/thread_id data. Three sub-issues: (1) context filter stripped _-prefixed identity keys (_agent_id, _callsign), (2) QUERY steps received filtered context despite needing full access for service dispatch, (3) thread_id/channel_id nested in observation["params"] not found by top-level lookup. Fix: pass _-prefixed keys through filter, bypass filtering entirely for QUERY steps, _ctx() helper resolves from nested params dict. 2 source files (sub_task.py, query.py). Relates to: AD-632b, AD-632f. Issue #243. | Medium | Closed | | BF-186 | Sub-Task Chain Compose Pipeline — Standing Orders Regression. AD-632d compose/analyze handlers hardcode Ward Room action vocabulary instead of relying on Standing Orders (AD-339). Ward room compose mode missing DM/REPLY/NOTEBOOK/CHALLENGE/MOVE/PROPOSAL syntax. Proactive compose duplicates 80+ lines from ship.md. _agent_rank, _skill_profile, _crew_manifest not injected into chain context. Analyze handler has bare identity prompt (no standing orders). Compose SILENT short-circuit ignores social obligation. Fix: (1) inject rank/skill/manifest into chain observation, (2) simplify compose mode builders to use compose_instructions(), (3) social obligation bypass in _should_short_circuit(), (4) enrich analyze with compose_instructions(), (5) add PROPOSAL/ENDORSE/REPLY/DM/NOTEBOOK/CHALLENGE/MOVE formats to ship.md Ward Room Action Vocabulary section. 4 source files + 1 config, 20 tests. Relates to: AD-632d, AD-339, BF-051/052, BF-083/101, BF-184/185. Issue #251. | High | Closed | | BF-185 | Reflect step independently suppresses Captain/@mention responses. BF-184 fixed evaluate bypass, but reflect makes independent LLM self-critique that returns [NO_RESPONSE] even after evaluate approved. Only 2/14 crew responded to Captain's welcome. Fix: same social obligation bypass pattern — skip reflect LLM call when _from_captain or _was_mentioned, return compose output unchanged. 1 source file (reflect.py), 8 tests. Relates to: BF-184, AD-632e, BF-157. Issue #250. | High | Closed | | BF-187 | DM social obligation missing. Crew-to-crew DMs go through sub-task chain where Analyze returns SILENT and Evaluate returns suppress. No _is_dm flag existed. Fix: Add is_dm_channel to intent params from channel.channel_type, extract _is_dm into chain context, add to social obligation bypass at all 4 gates (Compose SILENT, Evaluate, Reflect). Reorder reflect to check social obligation BEFORE suppress (defense in depth). 5 source files, 18 tests. Relates to: BF-184/185/186, AD-632, BF-156/157. Issue #255. | High | Closed | | BF-208 | Scout duty report always returns 0 findings. perceive() only recognizes scout_search and scout_report intents. Duty scheduler sends proactive_think with params.duty.duty_id == "scout_report" — scout skips GitHub search, act() receives empty context. act() already handles duty-triggered proactive_think (BF-177) but perceive() does not. Fix: 5-line duty-trigger check in perceive() between cache check and search guard — reassigns intent_name to "scout_search" when proactive_think arrives with duty_id == "scout_report". 1 modified + 1 test file, 5 tests. Issue #286. | Medium | Closed | | BF-209 | Scout duty report bypassed by communication chain. BF-208 fixed perceive() routing but proactive_think is now in _CHAIN_ELIGIBLE_INTENTS (AD-632f). Scout duty runs through QUERY→ANALYZE→COMPOSE communication chain, which produces a natural language Ward Room post but never calls act() — so parse_scout_reports() never runs, findings never stored, report always empty. The scout report is a data pipeline process (search→classify→store→notify), not a communication task. Fix: ScoutAgent overrides _should_activate_chain() to return False for duty-triggered proactive_think with duty_id=scout_report. Routes back through decide()→act() where the structured pipeline runs. Principled: agent correctly declares "this intent is a process, not a communication." Superseded by AD-647 (Process Chains) when AD-618 (Bills) lands. Issue #290. | Medium | Closed | | BF-210 | Ward Room DM recipient never wired. _dm_recipient context field defaults to "the Captain" for ALL DMs — crew-to-crew conversations tell the compose prompt "You are in a 1:1 private conversation with the Captain." Causes formal register override (authority-frame formality) and confabulation pressure (agents invent capabilities to impress the Captain). author_callsign is available in Ward Room params but never extracted into _dm_recipient. Fix: Wire author_callsign → _dm_recipient in cognitive_agent.py, name the conversation partner in compose.py private_conversation branch, change _build_dm_compose_prompt() default from "the Captain" to "a crew member". ~15 lines across 2 files, 8 tests. Issue #295. | Medium | Closed | | BF-211 | Proactive loop dies silently. asyncio.sleep(self._interval) outside try/except in _think_loop() (proactive.py L.352-361). CancelledError during sleep propagates unhandled, task dies with no restart mechanism — zero proactive activity for rest of session. Observed: one cycle after restart then 40+ minute silence. Fix: Moved asyncio.sleep inside try/except block. Sleep in both happy path and error recovery branch. CancelledError re-raises for clean shutdown. 2 tests. Issue #296. | High | Closed | | BF-212 | Crew-vs-crew game moves never reach opponent. Board update posts use "Next: {player}" without @mention. find_targets_for_agent() has no custom channel handler (Recreation is custom), so opponent gets empty target list. Even if routed, no is_direct_target means 30s cooldown blocks. Fix: Added @{next_player} to in-progress board post body in both MOVE paths (ward_room_router.py + proactive.py). Existing @mention resolution works across all channel types. 4 tests. Issue #297. | Medium | Closed | | BF-213 | Chain proactive analyze suppresses structured actions. Three compounding issues: (1) analyze "Silence is professionalism" bias defaults to intended_actions: ["silent"], (2) compose short-circuit skips LLM call when analyze returns silent, (3) compose "2-4 sentences" framing discourages structured output like [PROPOSAL]. Prior build reverted (duplicated standing orders). Fix: Rebalance analyze framing (mention proposals/replies/DMs/games as options), broaden compose framing (reference standing orders for tag syntax), revert BF-213 duplicate action vocabulary. ~10 lines across 2 files, 12 tests. Issue #298. | High | Closed | | BF-214 | Scout marks repos as seen before classification — zero findings for days. perceive() marks repos as seen (L.336) and persists to disk (L.349) before act() classifies them via LLM. If LLM call fails (connectivity, format mismatch, empty response), repos permanently locked in scout_seen.json with 90-day TTL. 5 consecutive days of total_classified: 0 despite finding 177 repos per search. 180 repos in seen file from single failed run. Fix: Defer seen marking from perceive() to act(), gate on classification success (findings present OR ===SCOUT_REPORT=== blocks in output). Store pending repos in _pending_seen_repos. Log warning on failure so repos retry next cycle. ~30 lines in scout.py, 10 tests. Issue #300. | High | Closed | | BF-215 | Empty observation posts after bracket tag stripping. BF-213 rebalanced analyze framing so agents choose to act instead of defaulting to silence. But compose produces tag-only output (e.g., [Observation]), which BF-203 (L.2511) and BF-174 (L.1987) strip — leaving empty text that gets posted as an empty [Observation] thread. 12 empty threads in 8 hours. Fix: Added empty guard after _extract_and_execute_actions() in proactive.py — returns early (with duty tracking) if response_text is empty after stripping. Direct fix, no build prompt. | Medium | Closed | | BF-217 | Post-batch test regressions + DRY cleanup. AD-644/645/646 batch changed production code without updating all tests. 3 regressions fixed: max_tokens 1024→1536 (test_ad632c), key counts 6→7 and 5→6 (test_ad643a). 2 DRY extractions: AD646B_DEDICATED_KEYS → shared frozenset in sub_tasks/__init__.py, derive_communication_context() → module-level pure function in cognitive_agent.py (test imports production function). 1 dead file deleted: test_bf194_department_gate_scope.py (371 lines, tested method removed by BF-201). 151 tests green. Issue #306. | Medium | Closed | | BF-218 | Empty callsign causes orphaned notebooks at root. proactive.py:2090 uses hasattr(agent, 'callsign') which is always True (attribute exists with "" default on Agent base class). When callsign is empty string, notebook writes to notebooks/{topic}.md instead of notebooks/{callsign}/{topic}.md. Observed: Scout notebook github-validation-methodology.md written to notebooks root on 4/20 after multiple rapid resets. Fix: (1) proactive.py:2090 → getattr(agent, 'callsign', '') or agent.agent_type (truthy fallback). (2) records_store.write_notebook() → ValueError guard on empty callsign (defense in depth). 2 lines across 2 files. Issue #309. | Low | Closed | | BF-219 | LLM timeout mismatch — ProbOS abandons requests before proxy finishes. llm_timeout_fast and llm_timeout_seconds were 30s while Copilot Proxy REQUEST_TIMEOUT_MS is 300s. Under load, ProbOS fires httpx.TimeoutException at 30s while proxy is still processing. Proxy logs show no errors. Crew experiences "LLM unavailable" while proxy is healthy. Fix: All timeouts set to 300s to match proxy. step_timeout_ms updated from 60000→240000 (derived from shared default). Config-only fix in system.yaml. Issue #310. | High | Closed | | BF-216 | Ward Room thread body not scrollable — long duty reports push content off-screen. Thread detail view renders thread body (Markdown) in a fixed header with no height constraint. Structured duty reports (Findings/Assessment/Recommendation) are long enough to push posts and reply input off-screen. Fix: Moved thread body and endorsement buttons from fixed header into the scrollable content area. Title/author line stays fixed at top. Single scrollable container for body + posts. Direct fix in WardRoomThreadDetail.tsx. Issue #305. | Medium | Closed | | BF-201 | Per-agent reply cap and department gate too aggressive. Department first-responder gate blocks bridge officers (Reed, Ezri) on department channels before they ever post. Per-agent cap (3 replies) obsolete with improved chain pipeline quality. No total thread post cap exists. Round depth (3) too low for substantive discussion. Fix: (1) Remove check_and_increment_reply_cap(), _agent_thread_responses, _dept_thread_responses, sentinels, max_agent_responses_per_thread config, (2) remove max_responses_per_thread from CommGateOverrides (keep reply_cooldown_seconds), (3) add max_thread_posts: int = 50 total thread post cap at routing + proactive layers (DM exempt), (4) raise max_agent_rounds 3→5, (5) add _cap_notices_posted cleanup to cleanup_tracking(). Supersedes BF-016b, BF-194; partially supersedes AD-629, AD-625. ~8 source files, delete test_bf194, new test_bf201 (16 tests). Issue #276. | High | Closed | | BF-203 | Agent output contains hallucinated bracket command tags. Agents emit [REPLY], [DM], [NOTEBOOK] and similar bracket-prefixed command tags as literal text in Ward Room posts. Tags are hallucinated by the LLM from action vocabulary in standing orders. Fix: Strip bracket command tags at posting boundary via sanitize_ward_room_text(). Issue #278. | Medium | Closed | | BF-220 | NATS startup errors — three issues. (1) _check_nats hits NATS protocol port 4222 with HTTP /varz request → RemoteProtocolError crash (unhandled exception type). Fix: raw TCP connect instead of HTTP. (2) JetStream streams created in finalize.py (Phase 5) but agents publish system events in agent_fleet (Phase 3) → "no response from stream". Fix: ensure_stream moved to nats.py startup. (3) ensure_stream uses add_stream which fails on restart if stream config differs → "stream name already in use". Fix: catch error code 10058, fall back to update_stream. 3 files changed. | High | Closed | | BF-221 | NATS subject prefix mutation breaks IntentBus request/reply — zero Ward Room responses. Agent NATS subscriptions created in Phase 2 use prefix probos.local. After Phase 7, runtime.py:1536 mutates prefix to probos.did:probos:{ship_uuid}. All subsequent send() calls publish requests under the new prefix → NATS returns "no responders available" → router silently drops all responses. Captain all-hands message targets 14 agents, all 14 fail. Emergency fix: Disabled NATS request/reply path in IntentBus.send(), forcing direct in-process call. Permanent fix (AD-637z): NATSBus tracks all subscriptions in _active_subs, async set_subject_prefix() re-subscribes with new prefix. BF-221 guard lifted — send() restored to NATS request/reply when connected, direct-call fallback when disconnected. | Critical | Closed | | BF-222 | Stream subjects not updated on NATS prefix change. NATSBus.set_subject_prefix() re-subscribes core and JetStream consumers but doesn't update JetStream stream subject filters. Stream subjects stay on probos.local.* prefix while publishers use the new DID-based prefix → messages don't match stream subjects → silent message loss. Fix: set_subject_prefix() updates stream configs via js.update_stream() with new subject prefix. Also moved EventType to str, Enum for consistent .value usage in ward room subject construction. 2 source files, 4 tests. Issue #327. | High | Closed | | BF-223 | JetStream durable consumer filter_subject stale after prefix change — zero agent dispatch delivery. BF-221 fixed core NATS re-subscription, BF-222 fixed stream subjects, but neither addressed JetStream durable consumers. Server-side consumer config bakes filter_subject at creation time. When set_subject_prefix() re-subscribes, NATS silently ignores the new filter because durable config already exists with old prefix. Per-agent dispatch consumers created during pool onboarding (Phase 3) use probos.local prefix; after ship commissioning (Phase 7) sets DID prefix, messages publish to probos.did:probos:{uuid}.intent.dispatch.{agent_id} but consumers still filter on probos.local.intent.dispatch.{agent_id}. All agents have delivered_seq=0. Fix (two-pronged): (1) Safety net: NATSBus.set_subject_prefix() deletes old durable consumers via delete_consumer() before re-creating with new prefix. (2) Root fix: IntentBus.subscribe() defers JetStream dispatch consumer creation (_defer_dispatch_consumers flag); finalize.py calls create_dispatch_consumers() after ship commissioning sets stable DID prefix. 3 source files + test fixes. Issue #328. | Critical | Closed | | BF-224 | Proactive context renders thread title only, drops body — agents can't read ward room posts. proactive.py context assembly uses a.get("title", a.get("body", "")) which prefers the thread title and never reaches the body. Agents observing ward room via proactive scan see only "Duty Report: ..." but not the report content. Notification path (via ward_room_router) unaffected — it uses get_thread() which returns full body. Fix: All three context builders (department, All Hands, Recreation) now render title + "\n" + body when both exist, capped at 500 chars. 1 source file. Issue #329. | Medium | Closed | | BF-225 | Scout classification instructions stripped — duty-triggered proactive_think treated as conversation. scout.py:311 renames intent_name local variable to scout_search but never writes back to result["intent"]. _decide_via_llm() sees proactive_think, treats it as conversation, passes hardcoded_instructions="" — scout's classification format (===SCOUT_REPORT===) excluded from system prompt. LLM produces conversational output instead of structured reports. Fix: Write renamed intent back to observation dict so decide() sees scout_search and includes domain-specific instructions. 1 source file. Issue #330. | High | Closed | | BF-226 | Two bugs: (1) Proposal extraction broken + (2) All Hands unread count never resets. (1) BF-203 catch-all bracket strip (re.sub(r'\[(?:[A-Z][A-Z_]+)...\]', '', text)) at proactive.py:2551 destroys [PROPOSAL] before _extract_and_post_proposal runs at line 710. [/PROPOSAL] survives (the / prevents match) and appears as visible text in ward room posts. Secondary: even if matched, old method never stripped proposal block from text. Fix: Moved proposal extraction into _extract_and_execute_actions before BF-203 catch-all. Single-pass parser for title/rationale/affected/priority fields. Deleted old _extract_and_post_proposal method and caller. (2) update_last_seen() only fires inside if all_hands_filtered: — requires new non-inform activity in 5-min cooldown window. All 14 agents had last_seen stuck at crew creation time (545 unread). Agents confabulating explanations for growing unread count. Fix: Unconditional update_last_seen after channel check for All Hands and Recreation. Also fixed agent_last_seen NameError in Recreation block. 1 source file, 11 tests (9 proposal, 2 last_seen). | High | Closed | | BF-227 | All Hands channel lookup matches wrong channel. all_hands_ch assigned by iterating channel_type == "ship" — with 4 ship channels (All Hands, Creative, Improvement Proposals, Recreation), the variable lands on whichever comes last in iteration order, never reliably "All Hands". BF-226's update_last_seen fix was correct but operated on the wrong channel ID. Fix: Match by ch.name == "All Hands" instead of ch.channel_type == "ship". 1-line source fix + 1-line test fix. | High | Closed | | BF-228 | Communications Array Degraded/Restored flapping on transient agent failures. Proactive loop's _update_llm_status() transitions to "degraded" on just 1 failure (failure_count >= 1), back to "operational" on the very next success (hard-resets _llm_failure_count = 0). Creates rapid Degraded→Restored→Degraded flap cycle flooding All Hands with Bridge Alerts. Secondary: failure check at line 573 counts ALL unsuccessful agent results (empty responses, chain issues) as LLM failures — only actual LLM errors (timeout, connection, rate-limit) should count. Fix: (1) Raise degraded threshold from >=1 to >=3 (hysteresis, matches _UNREACHABLE_THRESHOLD), offline from >=3 to >=6. (2) Only increment _llm_failure_count for results with LLM-specific error indicators. (3) Decay failure count by 1 on each success instead of resetting to 0. Issue #332. | High | Closed | | BF-229 | NATS subject prefix rejects colons from ship DID — all JetStream publishes fail. runtime.py:1543 sets NATS prefix to probos.{cert.ship_did} (raw DID with colons: did:probos:<uuid>). set_subject_prefix() calls ensure_stream() → update_stream() with colon-containing subject filter → NATS server rejects → streams stranded with Phase 1 probos.local.* filters. Every js_publish() after commissioning gets "no response from stream". Two silent-swallow layers: ensure_stream() catches and doesn't re-raise (line 564), set_subject_prefix() catches at WARNING (line 150). Fix: (1) NATSBus owns sanitization — set_subject_prefix() replaces NATS-unsafe chars with underscores via regex (_NATS_UNSAFE_CHAR). Underscore preserves single-token namespace depth. (2) ensure_stream() re-raises after logging. (3) Stream update failure promoted from WARNING to ERROR with recovery instructions. 5 new tests + 1 existing test updated. Issue #334. | High | Closed | | BF-231 | JetStream streams retain stale DID subject filters after probos reset. probos reset generates a new ship DID but doesn't flush JetStream streams. Streams persist with the old DID's subject filters while the new instance publishes to the new DID prefix, causing "no response from stream" on every JetStream publish. BF-230 fallback masks data loss but event persistence is broken. Fix: set_subject_prefix() deletes and recreates streams instead of updating subject filters. 5 new tests. | Medium | Closed | | BF-232 | ensure_stream() stale subject filters. New recreate_stream() method uses delete-then-create; ensure_stream() unchanged. Phase 2 startup and set_subject_prefix() now call recreate_stream() so stale stream filters from previous boots are cleared. Completes NATS resilience trilogy (BF-229/230/231/232). 8 new tests. | Medium | Closed | | BF-230 | JetStream publish silent failure under CPU load. js_publish() silently drops events when JetStream publish times out (~2s default) under CPU load — no retry, no fallback. Fix: (1) Configurable timeout via NatsConfig.js_publish_timeout (default 5s). (2) Retry once with 0.5s backoff. (3) Fallback to core NATS publish if JetStream fails twice. (4) ERROR only if both paths fail. 6 new tests. Issue #335. | Medium | Closed | | BF-207 | Shutdown race — episodic memory hash mismatch (complete fix). 5s __main__.py timeout expired before episodic_memory.stop() reached, leaving ChromaDB improperly closed. Metadata no longer matched stored content hash on restart. Root cause: episodic_memory.stop() was positioned after ~25 service stops + 1s grace + 2s dream consolidation, consuming 3–5s of the 5s budget. Fix: (1) Restructured shutdown into Phase 1 (Critical Persistence: dream consolidation + episodic memory close + eviction audit) and Phase 2 (Service Cleanup), ensuring ChromaDB closes within ≤3s typical. (2) Increased __main__.py timeout from 5s to 10s as safety margin. (3) Added startup hash integrity sweep (sweep_hash_integrity) that proactively heals stale hashes from previous unclean shutdowns, running after all migrations. Three-layer defense: clean shutdown ordering → startup sweep → recall-time auto-heal. 11 new/updated tests. | High | Closed | | BF-206 | Evaluate suppress + confabulation feedback loop not enforced. BF-204 added deterministic grounding check in Evaluate that detects fabricated hex IDs and returns recommendation: "suppress" with rejection_reason: "confabulation_detected", but suppress is never enforced and agent gets no feedback. Post goes through unchanged. Fix: Enforce suppress at compose gate + inject rejection reason into reflect step for learning. Issue #281. | High | Closed | | BF-204 | Evaluate/Reflect bypass allows confabulation in DMs. Social obligation bypass (DMs, Captain posts, mentions) returns before BF-191 JSON rejection and all LLM quality checks — confabulated content passes through unchecked. Wesley fabricated thread IDs, timing metrics, and synchronization events; Reed accepted and elaborated. Standing orders (AD-540/541 Memory Anchoring) exist but aren't enforced at EVALUATE gate. Fix: (1) Reorder defense chain: SAFETY > OBLIGATION (BF-191 + grounding pre-check run before social obligation bypass). (2) Deterministic hex ID grounding pre-check (2+ hex IDs → suppress, 0 tokens). (3) "Grounding" criterion added to all 3 evaluate prompt builders (ward room, proactive, notebook). (4) Reflect suppress moved above social obligation. (5) Grounding reminder in mid-trust reflect prompts. Absorbs: AD-540/541, AD-583f, AD-554, AD-506b. 2 modified + 1 test file, 24 tests. Issue #280. | Critical | Closed | | BF-200 | Thread caps silently suppress agents with zero awareness. When per-thread reply cap, DM exchange limit, or thread depth cap is hit, the agent's message is never dispatched — no notification, no episodic memory. Violates Westworld Principle. DM exchange limit (5) also too low for substantive conversation, and DMs double-capped by both dm_exchange_limit and max_agent_responses_per_thread. Fix: (1) Raise dm_exchange_limit 5→40, (2) DM channels bypass per-thread reply cap (governed by dm_exchange_limit only), (3) _post_cap_notification() posts system message to thread at all 4 cap sites. Dedup via _cap_notices_posted set. 2 source files, 12 tests. Relates to: BF-016b, AD-614, AD-629, AD-625, AD-623, BF-156/157. Issue #275. | High | Closed | | BF-199 | Raw JSON leaks into Ward Room posts. Cognitive sub-task chain reflect/compose output ({"output": "...", "revised": true, "reflection": "..."}) bypasses extraction on edge cases and appears verbatim in Ward Room. Existing guards (BF-172, BF-191) only catch "intents" JSON. Ward room router has zero JSON guards. Fix: Shared sanitize_ward_room_text() in utils/text_sanitize.py — boundary guard at posting layer (proactive.py:587, ward_room_router.py:589). Extracts "output" from reflect JSON, suppresses evaluate JSON. Defense in depth with chain-internal parsing. 3 files (1 new + 2 modified), 10 tests. Relates to: BF-172, BF-191, BF-174. Issue #274. | High | Closed | | BF-193 | Captain all-hands messages only reach 6/14 crew. _route_to_agents() dispatches sequentially — each chain takes ~10-15s, 14 agents × 10s = 140s, exceeding TTL. LLM scheduler saturates after 6 concurrent chains. Fix: 3-phase refactor: (1) pre-filter eligible agents, (2) asyncio.gather concurrent dispatch for Captain only (non-Captain stays sequential — prevents cascading chains), (3) shared sequential result processing. Post ordering preserved. Issue #264. | High | Closed | | BF-191 | Evaluate scores raw intent JSON as pass=True, score=1.00. Compose produces {"intents": [...]} (LLM mode confusion from dispatcher prompts). Evaluate LLM judge has no format criterion — 15 chars of JSON defaults to high score. Fix: Deterministic pre-LLM format check: startswith("{") + "intents" in first 200 chars → pass=False, score=0.0, recommendation=suppress, 0 tokens. Defense in depth with BF-172. Issue #261. | High | Closed | | BF-190 | NameError: name 'now' is not defined in _route_to_agents(). BF-188 extracted routing loop but left now = time.time() dead in route_event() and used import time as _time locally. Fix: Remove dead now, use module-level time import. Issue #261. | Critical | Closed | | BF-189 | Chain pipeline memory context gaps cause confabulation. Three gaps: (1) analyze.py renders recent_memories list as Python repr, not formatted text. (2) DM comprehension and situation review modes have zero memory context. (3) Compose step has no memory grounding. Fix: Pre-format memories via _format_memory_section() in _execute_sub_task_chain(), store as _formatted_memories string. All chain handlers (analyze thread/DM/situation, compose) read formatted string. DRY — one formatting path. Defense in depth — memory at both Analyze and Compose. 3 source files, 12 tests. Relates to: AD-632, AD-567b, AD-568c, AD-592, BF-148. Issue #257. | High | Closed | | BF-188 | Captain delivery race condition. Captain posts route sequentially to 14 agents, but agent replies trigger concurrent _ward_room_emit() tasks that compete for LLM capacity. Only 6/14 responded. Fix: asyncio.Event in WardRoomRouter — agent-reply routing waits (120s timeout) for Captain delivery to complete. Extracted _route_to_agents() for try/finally safety. Stopgap until AD-637 (NATS). Issue #255. | High | Closed | | BF-184 | Evaluate step suppresses responses to Captain and @mentioned messages. Ward Room notification chains fire for Captain messages, but evaluate handler scores all responses 0.00–0.50 and suppresses them. Evaluate has zero awareness of social obligation (Captain authorship, @mention). Fix: propagate _from_captain and _was_mentioned flags into chain context, auto-approve in evaluate handler when social obligation exists (skip LLM call, 0 tokens). 2 source files (cognitive_agent.py, evaluate.py), 11 tests. Relates to: AD-632e, BF-157, AD-407d. Issue #248. | High | Closed | | BF-183 | Sub-task chain step timeout falls back to single-call without retry. Step timeout (15s) caused by transient LLM proxy contention immediately degrades to single-call _decide_via_llm(), losing multi-step chain quality. Fix: Budget-aware retry — calculate remaining chain time, if sufficient (≥ step_timeout + 2s backoff), sleep 2s and retry the step once. If insufficient, fall back immediately. Journal records timeout attempt with :timeout dag_node_id suffix. 1 source file (sub_task.py), 13 tests. Relates to: AD-632a, AD-636. Issue #246. | Medium | Closed | | BF-157 | @mention in Ward Room thread doesn't guarantee response. Two root causes: (1) mentions list used for routing only (deciding WHO to notify) but never forwarded in IntentMessage params — agent has no idea it was @mentioned, prompt allows [NO_RESPONSE] identically to ambient notifications, (2) per-agent cooldown (45s) and per-thread response cap (3) silently suppress @mentioned agents. Fix: mentioned_agent_ids set built from _callsign_registry.resolve(), was_mentioned flag passed in IntentMessage params, agent prompt requires response when @mentioned (suppresses [NO_RESPONSE]), is_direct_target bypasses cooldown/caps for to @mentioned agents. 3 source files, 2 new test files (7 tests). Issue #188. Relates to: BF-016a, BF-082, BF-156, AD-574. | Medium | Closed |

Bug details (BF-001–011): All closed. See roadmap-completed.md.

Want to contribute?

See the Contributing guide for how to get involved.