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

Degraded modes and fail-safe

Table of contents

1. Failure taxonomy 2. Mode state machine 3. Detection and hysteresis 4. Safe outcomes 5. Recovery 6. Testing degraded paths

Failure taxonomy

Map each to detected by, debounce, mode transition, logged code.

Mode state machine

Example modes (rename per program):

INIT → STANDBY → ARMED → AUTONOMOUS ⇄ ASSISTED
                    ↓         ↓
                 DEGRADED ←──┘
                    ↓
              SAFE_HOLD / RTL / LAND / ABORT

Rules:

• Single writer for mode authority (avoid races between planner and UI)
• Explicit transitions only; no silent skip of DEGRADED
• Entry actions (e.g., clear integrators, announce to operator)

Detection and hysteresis

Publish health bitmap or structured diagnostics for HITL displays.

Safe outcomes

Fail-safe defaults should be conservative when uncertainty is high—prefer smaller ODD over aggressive continuation.

Recovery

Log recovery attempts and reasons for denial.

Testing degraded paths

• Inject faults in SIL/HIL per scenario ID
• Verify no geofence violation during degradation
• Measure time in each mode on field logs
• Regression: any change to detection thresholds reruns fault suite

Coordinate with embedded-real-time-software-engineer on watchdog and control-software-developer on actuator interlocks where platforms overlap.

Deployment, logging, and audit

Table of contents

1. Edge deployment 2. Configuration and OTA 3. Autonomy decision logging 4. Audit and reconstruction 5. Privacy and retention 6. Incident handoff

Edge deployment

Align image versions with model hash, rules version, and map/geofence version in manifest.

Configuration and OTA

OTA plan: staged rollout, rollback image, canary vehicles, compatibility matrix between stack components.

Autonomy decision logging

Minimum structured fields per control cycle or planner tick (adjust rate):

Use append-only storage on vehicle; offload post-mission with integrity check (hash chain optional).

Audit and reconstruction

Build a replay toolchain that feeds logged inputs through offline stack for diff (same versions pinned).

Privacy and retention

• Avoid logging unnecessary PII or imagery beyond program policy
• Define retention TTL per environment (lab vs operational)
• Redact or crop sensors in exports when sharing outside program

Incident handoff

Package for investigators:

1. Config manifest (all versions) 2. Autonomy trace + raw sensor bag (if authorized) 3. Scenario ID if test; ODD statement if ops 4. Known software issues / open defects

Route security incidents on comms/compromise to cybersecurity peers; model safety policy breaches to ai-risk-governance / safeguards as appropriate.

Do not include export-controlled performance parameters or customer-identifying metadata in generic skill outputs.

Perception–planning–control stack

Table of contents

1. Pipeline overview 2. Perception and fusion 3. Planning and behavior 4. Control and actuation interface 5. Learned vs symbolic split 6. Middleware patterns 7. Timing and interfaces

Pipeline overview

Typical sense-to-act chain (names vary by program):

Sensors → calibration/sync → perception → world model → planner/behavior → trajectory/setpoints → control → actuators
                ↑_____________________ safety / rules monitor _____________________↑

Assign owner, rate (Hz), max latency (ms), and failure output per block.

Perception and fusion

Avoid over-specifying vendor SDKs; define interface contracts (message fields, frames, timestamps).

Planning and behavior

Document mode graph: manual, assisted, autonomous, emergency, mission abort.

Control and actuation interface

• Planner outputs: waypoints, splines, velocity commands, or low-level setpoints—match actuator controller expectations
• Respect rate limits, saturation, and interlocks from control/embedded peers
• Never bypass hardware estops or mechanical limits in software design docs

Learned vs symbolic split

Golden rule: learned components propose; safety layer disposes (allow/deny/clamp/abort).

Middleware patterns

ROS2-style concepts at high level (implementation-agnostic):

Name critical topics (commands, mode, abort) vs best-effort (debug).

Timing and interfaces

Measure on hardware-in-the-loop or instrumented field rigs—not desktop-only profiling for release claims.

Safety, human oversight, and rules

Table of contents

1. Operational design domain 2. Constraint rules 3. Human-on-the-loop 4. Mission abort and escalation 5. Enforcement architecture 6. Coordination with AI safety

Operational design domain

Define where autonomy may run:

Exit ODD → automatic degrade, hold, or RTL (return-to-launch) per program policy.

Constraint rules

Each rule needs: ID, inputs, predicate, action (deny, clamp, abort), priority, log event.

Human-on-the-loop

Capture latency from operator action to effect; train on injected faults in sim.

Mission abort and enforcement

Abort paths must be tested in sim and field with recorded traces.

Enforcement architecture

Prefer multiple layers:

1. Planner constraints — soft costs, replanning 2. Safety monitor — independent check on proposed command (symbolic) 3. Control limits — saturations, rate limiters 4. Hardware — estop, mechanical limits (outside software skill scope but referenced)

Safety monitor should run at control rate or faster than planner commits irreversible actions.

Coordination with AI safety

Do not conflate operational rules with LLM content policies—different stacks, may coexist on same platform.

Simulation, testing, and validation

Table of contents

1. Test pyramid 2. SIL and HIL concepts 3. Scenario design 4. Metrics and gates 5. Sim-to-real 6. Field testing

Test pyramid

Autonomy releases should not skip layers without documented risk acceptance.

SIL and HIL concepts

Distinguish functional HIL (autonomy integration) from security HIL (hardware-in-the-loop-security-tester).

Scenario design

Structure scenarios with IDs:

Cover: nominal mission, edge ODD, single-fault, common double-faults, operator abort, rules trip.

Metrics and gates

Pre-register pass/fail before running campaigns; version the scenario suite.

Sim-to-real

Document gaps explicitly:

Require field scenarios for any behavior not bounded by sim evidence.

Field testing

Never use production customer environments for unapproved autonomy experiments.

Tactical AI autonomy scope

Table of contents

1. Role boundary 2. Constraint capture 3. Platform classes 4. Compute and deployment envelope 5. What good looks like

Role boundary

Constraint capture

Document before design:

Platform classes

Keep customer-specific payloads and classified CONOPS out of generic skill outputs.

Compute and deployment envelope

What good looks like

• One-page autonomy boundary diagram with rates, owners, and safety enforcement points
• Explicit assumptions list (GPS, comms, human availability) tied to degraded modes
• Release criteria linked to scenario IDs, not ad hoc demo flights alone
• Peer review hooks to embedded (timing), control (actuation limits), and AI safety (rules)