Tactical AI Autonomy Developer

Tactical AI & Autonomy Developer

When to Use

• Integrate perception, planning, and control on edge compute with end-to-end latency and safety budgets
• Choose behavior representation—behavior trees, state machines, hybrid symbolic + learned policies
• Define human-on-the-loop workflows—monitoring, intervention, escalation, and handoff semantics
• Specify operational constraints—geofences, no-strike / keep-out rules, mission abort, ROE hooks
• Design sensor fusion and world-model interfaces—time sync, calibration, uncertainty propagation
• Plan simulation and field validation—SIL/HIL concepts, scenario suites, regression gates
• Engineer degraded modes—sensor loss, comms loss, compute derating, fail-safe and hold patterns
• Implement autonomy audit logging—decision traces, rule firings, model versions, override events
• Coordinate middleware—ROS2-style pub/sub, services, lifecycle nodes at pattern level (not distro pick)
• Align with embedded, control, and AI safety peers on interfaces and acceptance criteria

When NOT to Use

• General LLM/RAG products, chat agents, or cloud inference features → ai-engineer
• LLM jailbreak / app red team engagements and ROE → ai-redteam
• Safeguard gateway serving, GPU routing, moderation infra SLOs → ml-infrastructure-engineer-safeguards
• AI governance, risk tiers, model cards, compliance mapping only → ai-risk-governance
• Bare-metal MCU firmware, ISR/RTOS, drivers without autonomy stack → embedded-real-time-software-engineer (unless autonomy runs on that edge target)
• Plant PLC/DCS, historian, OT scan cycles, Modbus/DNP3 plant logic → control-software-developer
• HIL security bench, bus fault injection, authorized exploitation on rigs → hardware-in-the-loop-security-tester
• Adversarial ML robustness (evasion/poison on models in lab) → ai-adversarial-robustness-engineer
• Export-controlled weapon design detail or customer-specific classified architectures → legal / program office; keep outputs generic

Related skills

Core Workflows

1. Scope and platform constraints

Capture mission class, latency chain, safety intent, compute envelope, and test environments before stack design.

See references/tactical_ai_autonomy_scope.md.

2. Perception–planning–control stack

Partition pipelines, interfaces, timing, and responsibility between learned and symbolic components.

See references/perception_planning_control_stack.md.

3. Safety, rules, and human oversight

Define geofencing, constraint rules, HITL escalation, and abort semantics with traceable enforcement points.

See references/safety_human_oversight_and_rules.md.

4. Simulation and validation

Build scenario matrices, sim-to-real gaps, metrics, and release gates from SIL through limited field trials.

See references/simulation_testing_and_validation.md.

5. Degraded modes and fail-safe

Specify detection, transitions, and safe outcomes for sensor, comms, and compute failures.

See references/degraded_modes_and_fail_safe.md.

6. Deployment, logging, and audit

Plan edge deployment, OTA boundaries, structured autonomy logs, and post-incident reconstruction.

See references/deployment_logging_and_audit.md.

Outputs

• Autonomy architecture brief — PPC boundaries, rates, compute map, middleware topology
• Behavior spec — states/modes, BT or policy outline, preconditions and timeouts
• Safety rules pack — geofences, constraints, abort triggers, enforcement layer mapping
• HITL playbook — roles, UI cues, override logging, escalation paths
• Validation plan — scenarios, metrics, pass/fail gates, sim vs field phases
• Degraded-mode matrix — triggers, transitions, safe states, recovery rules
• Audit schema — fields per decision cycle, retention, correlation IDs

Principles

• Safety before capability — prove constraint enforcement and abort paths before expanding autonomy
• Traceable decisions — every safety-critical branch logs rule ID, inputs hash, and outcome
• Deterministic fallbacks — symbolic safe modes when learned components are uncertain or unavailable
• Measured latency — budget per stage; no stack design without end-to-end timing evidence
• Sim ≠ field — document sim assumptions; require field scenarios for release-critical behaviors
• Generic documentation — UAS/autonomous systems terms only; no named customers or controlled technical dumps