Accelint Persona Review

Persona-Based Design Review

Evaluate Figma designs from the perspective of specific operator personas. Generic UX advice ("make it more intuitive") misses insights that emerge from the persona's documented profile - their responsibilities, pain points, systems they monitor, and operational context.

Workflow

1. Load Persona Profile

Start by loading the persona index to find available personas:

Read references/personas/_index.md

Then load the specific persona requested by the user:

Read references/personas/{persona-id}.md

Do NOT load multiple persona files - only load the one requested by the user.

Do NOT load evaluation-examples.md yet - wait until Step 4.

If the persona doesn't exist, list available options from the index and ask the user to choose.

2. Gather Design Context

Figma URL provided: Use appropriate Figma MCP tool to fetch the design (e.g., mcp__figma-desktop__get_design_context with extracted node ID from URL pattern node-id=1-2 → 1:2).

No URL (default): Use Figma MCP desktop to get current file/selection. If nothing selected, prompt user to select a frame or component.

Figma MCP unavailable: Ask user to provide a screenshot of the design. Analyze the screenshot using visual inspection, but note that without full design context (component properties, layout constraints, interaction states), the review will be limited to visual elements only.

3. Search Supporting Documentation

Use Outline MCP to find relevant context. Since Outline requires workspace selection, use this pattern:

ListMcpResourcesTool(server: "outline")

Search for documents covering:

• UI standards/guidelines for this operator role
• Previous design reviews or feedback
• System requirements or specifications
• Training materials or user guides

Prioritize documents mentioning the persona's role, responsibilities, or systems they interact with.

Outline MCP unavailable: Proceed with the review based solely on the persona profile and design context. Note in your review that supporting documentation wasn't available, and recommend areas where organizational standards should be consulted.

4. Analyze & Critique

Load evaluation examples to calibrate your approach:

Read references/evaluation-examples.md

Use the evaluation framework below, but adapt structure to findings - don't force insights into rigid sections.

Evaluation Framework

Cognitive Load Assessment

• Information density: Can they process all displayed data given their experience level and work tempo?
• Visual hierarchy: Does critical info for their role stand out immediately?
• Mental models: Does the interface match systems they already use (documented in "Sees")?

Communication Pattern Alignment

• "Says & Does" support: Does the UI facilitate their typical actions and communications?
• Workflow integration: How well does this fit documented workflows?
• Error prevention: Does it prevent mistakes aligned with their documented pain points?

Pain Point Mitigation

• Direct pain relief: Which documented pain points does this design address?
• Inadvertent pain creation: Does this introduce new friction or complexity?
• System consolidation: If they juggle multiple systems, does this reduce context switching?

Context Awareness

• Experience calibration: Is complexity appropriate for their rank/experience (e.g., E4 vs E7)?
• Responsibility alignment: Does the design support their specific responsibilities?
• Schedule considerations: Can they use this effectively given their work schedule/tempo?

System Visibility

• "Sees" coverage: Are the systems they monitor visible/accessible (e.g., BCS-F, RS-4, ERSA)?
• Integration gaps: What critical systems are missing?
• Redundancy: Is there unnecessary duplication of information they see elsewhere?

Communication Support

• "Hears" integration: Does the design support their communication channels (e.g., Surveillance Net)?
• Information relay: Can they easily relay information as documented in "Says & Does"?
• Notification design: Are alerts/notifications appropriate for their attention budget?

Output Structure

Provide critique in this general format (adapt as needed):

## Persona Review: [Persona Name]

### Design Summary
[1-2 sentence summary of what you reviewed]

### Critical Findings
[2-3 most important insights specific to this persona]

### Detailed Evaluation

**Cognitive Load**: [Assessment with specific examples from persona profile]

**Communication Patterns**: [How well it supports their "Says & Does"]

**Pain Point Mitigation**: [Which pain points addressed/created]

**Context Awareness**: [Appropriate for their experience/responsibilities]

**System Visibility**: [Coverage of their "Sees" systems]

**Communication Support**: [Integration with their "Hears" channels]

### Recommendations
[Prioritized list of actionable improvements, grounded in persona profile]

### Supporting References
[Links to relevant Outline docs found during research]

This is an example structure, not a rigid template. Adapt based on:

• Depth of findings in specific areas
• Completeness of persona profile
• Design scope (component vs. full dashboard)

The critical elements are: 1. Clear connection to persona's documented profile 2. Specific, actionable recommendations 3. Prioritization based on operational impact 4. Evidence from supporting docs (when available)

Evaluation Principles

Be specific to the persona: Generic UX advice helps no one. Ground every observation in the persona's documented profile (Profile, About, Hears, Sees, Says & Does, Pain Points).

Prioritize operational impact: A minor UI inconsistency that breaks muscle memory for a high-tempo operator matters more than major visual polish issues. Consider the stakes of their work.

Assume domain expertise: These operators are experts in their field. Don't suggest "simplifications" that remove necessary complexity they need to do their jobs.

Consider the full context: Review their entire profile - insights often emerge from connections between sections. A pain point in one area may relate to systems they monitor or communication channels they use.

Connect across profile sections: The most valuable insights synthesize multiple parts of the persona profile (e.g., a pain point + systems they see + actions they take = integrated solution opportunity).

NEVER Do When Reviewing

• NEVER give generic UX advice like "make it more intuitive" or "improve the user experience" - these could apply to any interface. Ground every observation in the persona's specific profile.
• NEVER suggest simplifications that remove necessary complexity - these operators are domain experts. Complexity that serves their documented responsibilities is valuable.
• NEVER ignore operational context - a minor UI inconsistency that breaks muscle memory matters more than major visual polish issues for high-tempo operators.
• NEVER treat all personas as the same - an E4 AST review should differ from an O4 MCC review for the same interface.
• NEVER skip loading the persona profile - generic reviews without persona context miss the entire value of this skill.

References

• Persona profiles: references/personas/{persona-id}.md
• Persona index: references/personas/_index.md
• Evaluation examples: references/evaluation-examples.md

Load these on-demand to minimize context usage.

Persona-Based Design Review

Evaluate Figma designs from the perspective of specific operator personas, surfacing UX insights that generic reviews miss.

Usage

# Review current Figma selection
/persona-review air-surveillance-tech

# Review specific Figma URL
/persona-review weapons-director https://figma.com/design/...?node-id=1-2

What It Does

1. Loads the operator persona profile (responsibilities, pain points, systems, workflows) 2. Fetches the Figma design (URL or desktop selection) 3. Searches Outline docs for relevant guidelines and standards 4. Provides structured critique covering:

• Cognitive load assessment
• Communication pattern alignment
• Pain point mitigation
• Context awareness (rank, experience, schedule)
• System visibility
• Communication support

Available Personas

Surveillance Roles:

• air-surveillance-tech - Air Surveillance Technician (E4-E7)
• surveillance-tech - Surveillance Technician (E1-E6)

Weapons Roles:

• weapons-director - Weapons Director (O1-O3)
• senior-director - Senior Director (O3-O4)
• air-weapons-officer - Air Weapons Officer (O1-O2)

Command Roles:

• mission-crew-commander - Mission Crew Commander (O4-O5)

Adding New Personas

Create a new file in references/personas/{persona-id}.md following this structure:

# [Persona Name]

**Persona ID**: `persona-identifier`

**Profile:**
- **Age:**
- **Rank:**
- **Schedule:**
- **Position:**
- **Responsibility:**

**About them:**
[Bullet points: role, certifications, responsibilities]

**Hears:**
[Communication channels they monitor]

**Sees:**
[Systems and interfaces they interact with]

**Says & Does:**
[Typical actions and communications]

**Pain Points:**
[Known frustrations and challenges]

Then update references/personas/_index.md to include the new persona.

Requirements

• Figma MCP: For accessing designs (desktop or URL)
• Outline MCP: For searching supporting documentation

Evaluation Examples

Examples of effective vs. ineffective persona-based design reviews.

What Makes a Good Persona Review

✅ Specific to Persona Profile

Good:

The manual track validation workflow creates friction for ASTs who are already juggling 7+ systems (documented pain point). The current design requires them to context-switch between BCS-F, RS-4, and ERSA before making a valid/not-valid determination. Consider consolidating validation inputs into a single view, prioritized by the AST's decision criteria: radar signature clarity, weather pattern correlation, and ERSA visual confirmation.

Why: Directly references persona's documented pain points and systems (Sees), proposes solution aligned with their workflow.

Bad:

This interface could be more intuitive. Users need easier access to validation tools.

Why: Generic advice that could apply to anyone. Doesn't reference persona profile or operational context.

---

✅ Prioritize Operational Impact

Good:

The alert notification design will interrupt the WD during fighter communications (critical "Hears" channel). For high-tempo scrambles, breaking concentration on Fighter Comms to acknowledge a system alert could delay relay of time-critical intercept vectors (documented "Says & Does"). Recommend: defer non-critical alerts until communication lull, or use peripheral visual indicators that don't demand immediate attention.

Why: Understands the stakes - interrupting fighter comms has real operational consequences. Grounds recommendation in persona's documented workflow.

Bad:

The notification colors don't follow our style guide. Let's make them more consistent.

Why: Visual polish over operational effectiveness. Misses the persona's actual need.

---

✅ Respect Domain Expertise

Good:

The simplified threat assessment UI removes details about presumed target locations and alternate intercept vectors - information WDs use for COA generation (documented "Says & Does"). While the streamlined view reduces visual clutter, it eliminates data WDs need for manual mission planning (documented pain point: "Manual COA generation"). Consider: keep detailed view as default, offer simplified view as optional toggle.

Why: Recognizes that "simplification" can remove necessary complexity. Validates operator's expertise.

Bad:

This screen shows too much information at once. Let's hide the advanced details to make it simpler for operators.

Why: Assumes operators are overwhelmed by complexity they actually need. Patronizing approach that would remove critical data.

---

✅ Connect Across Profile Sections

Good:

The base status overlay mutation system addresses WD's documented pain point ("Manually updates base status with overlay mutations"), but the design doesn't account for the fact that they also monitor Radio Mx Board (documented "Sees") and coordinate over DEN ("Hears"). When base status changes, they need to relay T.A.s over DEN ("Says & Does"). Consider: auto-populate DEN relay template when base status changes, prepopulating with relevant details from the mutation.

Why: Synthesizes insights from Pain Points + Sees + Hears + Says & Does to propose integrated solution.

Bad:

This overlay feature is nice. It will make updating base status easier.

Why: Surface-level observation. Doesn't connect to broader workflow context.

---

What to Avoid

❌ Generic UX Advice

Don't say: "Make it more intuitive" / "Improve the user experience" / "Add better labels"

These apply to any interface. Ground every observation in the persona's specific profile.

❌ Assuming Simplification is Always Better

Don't say: "This is too complex, simplify it"

Operators are domain experts. Necessary complexity enables their work. Only flag complexity that doesn't serve their documented responsibilities.

❌ Ignoring Operational Context

Don't say: "Add a training tutorial for this feature"

Consider their schedule and work tempo. An E1 surveillance tech on a busy schedule doesn't have time for extensive tutorials. Design should align with their existing mental models from systems they already use.

❌ Treating All Personas the Same

Don't say: "Operators will find this confusing"

Different personas have different experience levels, responsibilities, and pain points. An E4 AST review should differ from an O4 MCC review for the same interface.

---

Output Format Flexibility

The skill provides an example output structure, but you can adapt it based on:

• Depth of findings: If cognitive load is the primary concern, expand that section and condense others
• Persona profile completeness: If supporting docs provide rich context, reference them heavily
• Design scope: A single component needs different structure than a full dashboard review

The critical elements are: 1. Clear connection to persona's documented profile 2. Specific, actionable recommendations 3. Prioritization based on operational impact 4. Evidence from supporting documentation (when available)

Don't force findings into sections where they don't naturally fit. Let the persona's actual needs drive the structure.

Available Personas

Load individual persona files on-demand using their persona ID.

Surveillance Roles

• `air-surveillance-tech` - Air Surveillance Technician (E4-E7)
• Validates tracks, manages sensor health, coordinates surveillance info
• Moderate schedule, 4+ years experience

• `surveillance-tech` - Surveillance Technician (E1-E6)
• First in killchain: detect, identify, maintain continuity
• Busy schedule, entry to 5 years experience

Weapons Roles

• `weapons-director` - Weapons Director (O1-O3)
• Control fighters, recommend tactical actions
• Busy schedule, 2+ years experience

• `senior-director` - Senior Director (O3-O4)
• Approve tactical actions and missions
• Busy schedule, 4+ years experience

• `air-weapons-officer` - Air Weapons Officer (O1-O2)
• Place alert base status orders, control COMSEC
• Moderate schedule, 2+ years experience

Command Roles

• `mission-crew-commander` - Mission Crew Commander (O4-O5)
• Approve tactical actions, manage crew
• Busy schedule, 6+ years experience

Loading Personas

Use the Read tool to load specific persona files:

Read references/personas/{persona-id}.md

Example:

Read references/personas/air-surveillance-tech.md

[Persona Name]

Persona ID: persona-identifier

Profile:

• Age: [Age range and years of experience]
• Rank: [Military rank range]
• Schedule: [Work schedule intensity: Busy/Moderate/Light]
• Position: [Role title and position in workflow]
• Responsibility: [Primary responsibilities, comma-separated]

About them:

• [Bullet point describing key responsibility or activity]
• [Bullet point describing key responsibility or activity]
• [Bullet point describing key responsibility or activity]
• [Add more as needed]

Hears:

• [Communication channel or network they monitor]
• [Communication channel or network they monitor]
• [Add more as needed]

Sees:

• [System, interface, or display they interact with]
• [System, interface, or display they interact with]
• [Add more as needed]

Says & Does:

• [Typical action or communication they perform]
• [Typical action or communication they perform]
• [Add more as needed]

Pain Points:

• [Known frustration, inefficiency, or challenge]
• [Known frustration, inefficiency, or challenge]
• [Add more as needed]

Air Surveillance Technician

Persona ID: air-surveillance-tech

Profile:

• Age: 23+ (~4+ years of experience)
• Rank: Staff Sergeant → Master Sergeant (E4-E7)
• Schedule: Moderate work schedule
• Position: Surveillance Filter to Killchain
• Responsibility: Validate Tracks/Weather, Manage Sensor Health, Manage Surveillance Section, Coord Surveillance info to Crew, E3 Coord/approval

About them:

• Responsible for Accurate Air Picture
• Validates "Tracks"
• Manages Sensor Health
• Coordinates w/ CFP (Comm Focal Point) for maintenance/sensor issues
• Certified ERSAOs (Enhanced Regional Situational Awareness Operator)
• Interpret Weather Data to best assess Track vs Weather validation
• Coordinate w/ Weapons Section for alternate frequencies for E-3s
• Pass pertinent surveillance information to crew
• RS-4 Operator (playback for validation)
• Reconstruction of TOI event(s)

Hears:

• Surveillance Net
• Crew Net
• CONR 1

Sees:

• BCS-F
• RS-4
• ERSA (Enhanced Regional Situational Awareness system)

Says & Does:

• Relays "Valid" "Not Valid" to ST regarding track validation
• Use of RS-4 for validation/weather patterns
• Use of ERSA for NCR validation (visual/EO/IR)

Pain Points:

• Manual decision of "valid" / "Not valid"
• Use of 7+ systems/sites to get the whole picture and enable decision making
• Phone calls to CFP for sensor status updates

Air Weapons Officer (AWO)

Persona ID: air-weapons-officer

Profile:

• Age: 22+ (~2+ years of experience)
• Rank: 1st Lieutenant → 2nd Lieutenant (O1-O2)
• Schedule: Moderate work schedule
• Position: Weapons Lead
• Responsibility: Place Alert base status orders, Monitor alert base status, Control Fighters, Recommend Tactical Actions and Missions to MCC, Control COMSEC required to authenticate Safe passage and Alert Base Status Changes (AKAC 1553, AKAL1553)

About them:

• Control fighters via radios
• Manage Radio Status
• Place T.A. calls to the bases
• Threat Assess
• Mission Plan
• Place guard calls
• Calculate intercept points, navigate fighters to quickest route
• Pass orders, engagements, instructions to fighters
• Pass instructions to TOIs (turn around, squawk IDENT, and contact FAA)
• Update AEISS card

Hears:

• Weapons Net
• Crew Net
• AICC
• Domestic Events Network (DEN)
• Auxiliary volume crew coord (Voice)
• Fighter Comms
• TOI Comm (Guard Calls)
• JADOC Net

Sees:

• BCS-F
• NIPR
• SIPR
• MVP (Comms Device)
• WindyTV
• Radio Mx Board/Overlay

Says & Does:

• Acknowledges crew calls for track point outs
• Measures track to nearest defended point/searches for presumed target
• Recommends Scramble route and actions to SD
• Relay orders to ACA bases (T.A.s) as well as to fighters when airborne
• Conveys air picture to fighters/assets
• Relays T.A.s over DEN
• Mission plans for scrambles and LRA etc/ and POTUS movements to determine response times and assets
• Make Guard calls to PTOIs/TOIs in restricted airspace or approaching
• Update AEISS cards w/ weapons section / base status/ timings of placed calls/ 9LA/B and flares/missiles expended etc

Pain Points:

• No automatic way to track radio outages (radios are both input as land points and mutated points)
• Needs vector assist
• Manual math for threat assessment and scrambles routes and vectors for intercept points
• Manual COA generation/recommendations
• Manually chats and updates AEISS what information could be auto imported/copied
• Manually updates base status with overlay mutations

Mission Crew Commander (MCC)

Persona ID: mission-crew-commander

Profile:

• Age: 26+ (~6+ years of experience)
• Rank: Major → Lt Colonel (O4-O5)
• Schedule: Busy work schedule
• Position: Crew Lead
• Responsibility: Approve Tactical Actions and Missions, Control Fighters, Manage Crew, Approve Alert base status orders, Approve Tactical Actions

About them:

• Approves Tactical Actions
• Approves Mission Plans
• Approves T.A. calls to the bases
• Threat Assess
• Approves guard calls
• Approves intercept points, navigate fighters to quickest route
• Approves orders, engagements, instructions to fighters
• Approves instructions to TOIs (turn around, squawk IDENT, and contact FAA)
• Update AEISS card

Hears:

• Weapons Net
• Crew Net
• AICC
• Domestic Events Network (DEN)
• Auxiliary volume crew coord (Voice)
• Fighter Comms
• TOI Comm (Guard Calls)
• JADOC Net

Sees:

• BCS-F
• NIPR
• SIPR
• MVP (Comms Device)
• WindyTV
• Radio Mx Board/Overlay

Says & Does:

• Acknowledges crew calls for track point outs
• Approves track to nearest defended point/searches for presumed target
• Approves Scramble route and actions
• Approves orders to ACA bases (T.A.s) as well as to fighters when airborne
• Approves air picture to fighters/assets
• Approves T.A.s over DEN
• Approves mission plans for scrambles and LRA etc/ and POTUS movements to determine response times and assets
• Approves Guard calls to PTOIs/TOIs in restricted airspace or approaching
• Update AEISS cards w/ weapons section / base status/ timings of placed calls/ 9LA/B and flares/missiles expended etc

Pain Points:

• No automatic way to track radio outages (radios are both input as land points and mutated points)
• Needs vector assist
• Manual math for threat assessment and scrambles routes and vectors for intercept points
• Manual COA generation/recommendations
• Manually chats and updates AEISS what information could be auto imported/copied
• Manually updates base status with overlay mutations

Senior Director (SD)

Persona ID: senior-director

Profile:

• Age: 24+ (~4+ years of experience)
• Rank: Captain → Major (O3-O4)
• Schedule: Busy work schedule
• Position: Weapons Lead
• Responsibility: Approve Tactical Actions and Missions, Control Fighters, Manage Weapons Section, Approve Alert base status orders, Approve Tactical Actions

About them:

• Approves Tactical Actions
• Approves Mission Plans
• Approves T.A. calls to the bases
• Threat Assess
• Approves guard calls
• Approves intercept points, navigate fighters to quickest route
• Approves orders, engagements, instructions to fighters
• Approves instructions to TOIs (turn around, squawk IDENT, and contact FAA)
• Update AEISS card

Hears:

• Weapons Net
• Crew Net
• AICC
• Domestic Events Network (DEN)
• Auxiliary volume crew coord (Voice)
• Fighter Comms
• TOI Comm (Guard Calls)
• JADOC Net

Sees:

• BCS-F
• NIPR
• SIPR
• MVP (Comms Device)
• WindyTV
• Radio Mx Board/Overlay

Says & Does:

• Acknowledges crew calls for track point outs
• Approves track to nearest defended point/searches for presumed target
• Approves Scramble route and actions
• Approves orders to ACA bases (T.A.s) as well as to fighters when airborne
• Approves air picture to fighters/assets
• Approves T.A.s over DEN
• Approves mission plans for scrambles and LRA etc/ and POTUS movements to determine response times and assets
• Approves Guard calls to PTOIs/TOIs in restricted airspace or approaching
• Update AEISS cards w/ weapons section / base status/ timings of placed calls/ 9LA/B and flares/missiles expended etc

Pain Points:

• No automatic way to track radio outages (radios are both input as land points and mutated points)
• Needs vector assist
• Manual math for threat assessment and scrambles routes and vectors for intercept points
• Manual COA generation/recommendations
• Manually chats and updates AEISS what information could be auto imported/copied
• Manually updates base status with overlay mutations

Surveillance Technician

Persona ID: surveillance-tech

Profile:

• Age: 18+ (Entry Position → ~4/5 years)
• Rank: Airman Basic → Technical Sergeant (E1-E6)
• Schedule: Busy work schedule
• Position: First in killchain
• Responsibility: Detect, Identify, Maintain continuity (F2T) Find Fix Track

About them:

• Identify radar patterns resembling that of aircraft
• Identify weather patterns of radar data
• Initiate "tracks" onto data sets resembling an aircraft (Pass to AST to validate)
• Identify "valid" tracks
• Primary DEN coordinator/"talker"
• Pass DEN info to the Crew
• Identify Potential TOIs (a/c close to breaking "rules" in NCR/TFR)
• Maintain continuity of TOIs/PTOIs (Hdg/Spd/Alt/M3 changes)
• Investigate for pertinent aircraft information
• Enforce ADIZ rules (M3/flt plan/etc)
• Coordinate for scheduled flying w/ Navy, Coast Guard, other agencies
• Update AEISS card

Hears:

• Surveillance Net
• Crew Net (Occasional)
• Phone Calls for Flight Coordination
• Domestic Events Network (DEN)
• E-3 Frequency (live fly TFR Voicetell) (Occasional)
• Auxiliary volume crew coordination (Voice)

Sees:

• BCS-F
• AMOSS (Air and Marines Operations Surveillance System)
• TSD
• NIPR (Unclass Internet)
• SIPR (Secret computer)
• ID Board
• MVP (Comms Device)
• Flight Aware
• Weather Patterns
• ADSB-Exchange
• AEISS

Says & Does:

• Requests Validation from AST on "possible" tracks via Surveillance Net
• Communicates w/ DEN via DEN phone/line
• Passes DEN info to Crew via Crew Net
• Coordinates w/ external agencies for flight coordination / NAVY ship locations
• Detects "tracks" & possible tracks
• Identifies A/C via use of AMOSS/TSD/Flight Aware/ ID Board / External Coord
• Fill out AEISS card w/ proper track information along w/ manifest etc

Pain Points:

• Differentiating weather from tracks
• Listening to multiple different nets/voices/lines
• Toggling between 8 different screens of information
• Unable to group data sets (plots) to create a track and associate to it / keeping tracks on data user establishes as part of the trail
• No system-inherent uses to aid in identification (agencies based on kinematics/location)
• No alerts/maintenance ability to be queued as to when kinematics change

Weapons Director (WD)

Persona ID: weapons-director

Profile:

• Age: 22+ (~2+ years of experience)
• Rank: 2nd Lieutenant → Captain (O1-O3)
• Schedule: Busy work schedule
• Position: Weapons Lead
• Responsibility: Control Fighters, Recommend Tactical Actions and Missions to SD, Manage Weapons Section

About them:

• Control fighters via radios
• Manage Radio Status
• Place T.A. calls to the bases
• Threat Assess
• Mission Plan
• Place guard calls
• Calculate intercept points, navigate fighters to quickest route
• Pass orders, engagements, instructions to fighters
• Pass instructions to TOIs (turn around, squawk IDENT, and contact FAA)
• Update AEISS card

Hears:

• Weapons Net
• Crew Net
• AICC
• Domestic Events Network (DEN)
• Auxiliary volume crew coord (Voice)
• Fighter Comms
• TOI Comm (Guard Calls)
• JADOC Net

Sees:

• BCS-F
• NIPR
• SIPR
• MVP (Comms Device)
• WindyTV
• Radio Mx Board/Overlay

Says & Does:

• Acknowledges crew calls for track point outs
• Measures track to nearest defended point/searches for presumed target
• Recommends Scramble route and actions to SD
• Relay orders to ACA bases (T.A.s) as well as to fighters when airborne
• Conveys air picture to fighters/assets
• Relays T.A.s over DEN
• Mission plans for scrambles and LRA etc/ and POTUS movements to determine response times and assets
• Make Guard calls to PTOIs/TOIs in restricted airspace or approaching
• Update AEISS cards w/ weapons section / base status/ timings of placed calls/ 9LA/B and flares/missiles expended etc

Pain Points:

• No automatic way to track radio outages (radios are both input as land points and mutated points)
• Needs vector assist
• Manual math for threat assessment and scrambles routes and vectors for intercept points
• Manual COA generation/recommendations
• Manually chats and updates AEISS what information could be auto imported/copied
• Manually updates base status with overlay mutations