AI Skill Report Card
Designing C2 Feature Matrices
Quick Start14 / 15
Build a feature matrix with these columns for every row:
| Column | Purpose |
|---|---|
| Module/Category | Top-level functional grouping (e.g., "1. Target Acquisition") |
| Feature Name & Operation | Specific feature with brief description of what it does |
| Legacy System Status | How this was done before (manual, paper, voice radio, etc.) |
| Next-Gen System Status | How the new digital system automates/improves it |
| UI Input Method | Exact interaction pattern (tap, slide, drag, button, dropdown) |
| System Output/Response | What the system returns/displays after the action |
| Module Interconnection | Which other modules consume or trigger this feature |
| Formatted Screen Display Text | Literal on-screen text mockup showing exact format |
Group features into 5-7 top-level modules that mirror the real operational workflow (e.g., Observation → Fire Direction → Safety → Execution → Common Picture → Infrastructure), numbered sequentially.
Recommendation▾
Add a third example showing a 'bad' output (e.g., vague UI method, missing interconnection) contrasted with the corrected version to reinforce pitfalls.
Workflow14 / 15
Progress:
- Step 1: Interview/derive the end-to-end operational workflow (who does what, in what order)
- Step 2: Group actions into modules that match organizational roles (e.g., FO, FDC, Gun crew, HQ)
- Step 3: For each module, enumerate 3-6 discrete features (not vague capabilities)
- Step 4: For each feature, document legacy pain point (manual/paper/voice) vs. digital solution
- Step 5: Specify the exact UI interaction pattern — be concrete (slide-to-confirm, drag-and-drop, stepper +/-, dropdown with recommendation badge)
- Step 6: Write the literal screen text mockup using realistic values, units, and formatting conventions (monospace-style, ALL CAPS labels, symbols like ⚠️ ★ ⛔)
- Step 7: Map cross-module dependencies — trace what data flows where
- Step 8: Add a dedicated Safety/Override module if the domain involves irreversible or dangerous actions
- Step 9: Add an Infrastructure/Ergonomics module for cross-cutting concerns (themes, connectivity, environmental adaptation)
- Step 10: Review for consistency: every feature should have all 8 columns filled, no placeholders
Recommendation▾
Include a minimal full-matrix template (all 8 columns as a table skeleton) that can be copy-pasted for a new module, rather than just describing columns prose-style.
Examples15 / 20
Example 1: Input: "Field observer used to shout 10-digit grid coordinates over radio from a paper map." Output:
- Module: Target Acquisition & Observation
- Feature: Auto-GPS & Coordinate Sync
- Legacy: Manual 10-digit grid keying from paper map
- Next-Gen: Automatic GPS/Laser Rangefinder coordinate pull
- UI: Button Tap [Laser Sync / GPS Pulse]
- Output: 10-digit grid + altitude
- Interconnection: Fire Direction, Safety Management
- Screen Text:
GRID: 47Q EK 1450 6780 | ALT: 185m | ACC: ±2m
Example 2: Input: "Commander used to yell 'cease fire' repeatedly over every radio channel in an emergency." Output:
- Module: Safety & Airspace Management
- Feature: Emergency Cease Fire Broadcast
- Legacy: Manual repeated verbal broadcast on all channels
- Next-Gen: Single red button broadcasts halt signal to all screens in <100ms
- UI: Emergency Red Button (press-and-hold)
- Output: Audible alarm + immediate firing lockout on all units
- Interconnection: All modules (FO, FDC, Gun, HQ)
- Screen Text:
⛔ EMERGENCY CEASE FIRE BROADCASTED! ALL GUNS HALTED!
Recommendation▾
Clarify how to handle features with no clear legacy counterpart (fully new digital capabilities) since Best Practices insists on always pairing legacy/next-gen.
Best Practices
- Mirror real chain-of-command/workflow order in module numbering — this makes the matrix readable as a story, not just a table.
- Always pair legacy pain with digital gain — the contrast is what sells the modernization value; never describe next-gen status in isolation.
- Make UI methods physically concrete: name the exact gesture (slide-to-send, long-press, drag-to-correct, stepper button) rather than "user selects option."
- Screen text mockups must look like real HUD/terminal output: use pipe separators, units, uppercase field labels, and status brackets
[ SAFE ],[ ON TARGET ]. - For safety-critical features, always specify: trigger condition, lockout behavior, and any dual-authorization/override mechanism.
- Cross-link liberally — most features should touch 2+ modules; isolated features are a red flag that something is missing from the workflow.
- Use recommendation/confidence indicators where the system suggests a choice (e.g.,
[MATCH: 98%]) to show AI/automation assist without removing operator authority. - End with an Infrastructure/Ergonomics module covering environment adaptation (day/night/NVG themes) and connectivity health — these are easy to forget but critical for field-usable systems.
Common Pitfalls
- Don't leave "Module Interconnection" empty or generic ("various modules") — always name specific module numbers/names.
- Don't write vague UI methods like "user interacts with screen" — specify the exact input gesture.
- Don't describe next-gen features without their legacy counterpart — the comparison is the entire value proposition.
- Don't omit units, timestamps, or precision indicators in screen text mockups — realism matters for stakeholder buy-in.
- Don't forget dual-authorization/override flows for dangerous actions (e.g., danger-close fire missions) — safety features need explicit friction, not just automation.
- Don't merge safety-critical and routine features into the same module — keep a dedicated safety module even if it duplicates some cross-references.