Summary

Build a pipeline that analyzes the cross-mission memory store to automatically detect recurring anti-patterns not yet codified in the standing orders library. Candidate standing orders are surfaced for human review, refined, and promoted to the live library. The standing orders become self-improving.

Motivation

Nelson's standing orders are its most distinctive architectural feature — a curated library of 16 named anti-patterns that the admiral checks at each decision point. But they are hand-written and static. With accumulated mission data (standing order violations, damage control invocations, outcome correlations), Nelson can identify anti-patterns empirically rather than relying solely on human intuition.

The Darwin Gödel Machine demonstrates that agent systems can self-improve by maintaining an archive of past variants and empirically evaluating mutations. Applied to standing orders, this means: observe patterns in mission data → hypothesize new standing orders → validate against historical missions → promote or discard.

Detailed Design

Anti-Pattern Detection Pipeline

python3 nelson-data.py detect-patterns \
  --min-missions 10 \
  --confidence-threshold 0.7

The pipeline:

1. Scans all mission-log.json files for recurring event patterns
2. Correlates patterns with mission outcomes (outcome-achieved in stand-down.json)
3. Identifies candidate anti-patterns: event sequences that correlate with negative outcomes
4. Scores each candidate by frequency, severity, and confidence
5. Outputs a structured report of candidate standing orders

Candidate Standing Order Format

{
  "candidate_id": "cso-001",
  "title": "Overloaded Flagship",
  "description": "Missions that assign more than 6 tasks to a flagship-class ship have a 40% lower success rate",
  "evidence": {
    "missions_analyzed": 25,
    "pattern_occurrences": 4,
    "negative_outcome_correlation": 0.85,
    "confidence": 0.78
  },
  "proposed_symptoms": [
    "Flagship ship assigned 6+ tasks",
    "Hull integrity drops to Amber within first 3 checkpoints"
  ],
  "proposed_remedy": "Split flagship workload across two ships. Maximum 4 tasks per flagship.",
  "status": "candidate"
}

Human Review Workflow

Candidates are stored in .nelson/memory/candidate-standing-orders.json and surfaced in the Mission Intelligence Brief:

CANDIDATE STANDING ORDERS (awaiting review):
1. "Overloaded Flagship" — 78% confidence from 25 missions
   Action: Review and promote/dismiss

The admiral surfaces these to the human operator. Promoted candidates become new standing order .md files and are added to the SKILL.md table.

Validation via Mission Replay

Before promoting a candidate, optionally validate it by replaying historical missions (issue #13) with the candidate order active:

python3 nelson-data.py validate-standing-order \
  --candidate cso-001 \
  --replay-missions 5

If the candidate order would have prevented the negative outcome in >70% of replayed missions, recommend promotion.

Standing Order Versioning

Add version tracking to standing orders:

• Each standing order gets a version and changelog
• Changes are tracked with the mission data that motivated them
• Historical versions preserved for audit

Rationale

• HMS Audacious rated this as Very High impact / Very High effort / Transformative
• HMS Daring identified cross-mission eval datasets (from Mastra) as prerequisite infrastructure
• HMS Astute identified the standing orders architecture as "brilliant" — self-improvement is the highest-leverage extension
• Darwin Gödel Machine and Hyperagents demonstrate that self-improving agent systems are achievable

Effort Estimate

XL

Impact

Transformative — a self-improving anti-pattern library derived from operational data is a completely novel capability

Dependencies

Requires: Cross-mission memory store (#8), OTel span emission (#3)
Benefits from: Mission replay (#13) for candidate validation