Phase 1 of 6
Scoping & Autonomy Level / SWaP
Define the platform class, autonomy level, perception-action latency envelope, SWaP (size / weight / power) ceiling, and operating-environment assumptions that will govern every subsequent architectural decision.
0/11
Phase Progress
Required Recommended Optional Open-Source Proprietary Trinidy
Platform Class & Mission Surface
Identify autonomous platform classes in scope
Why This Matters
Platform class sets the physics. Small UAS under 2kg operate on milliwatt SWaP budgets and sub-20ms perception loops; an MQ-9-class Group 5 platform has orders of magnitude more compute but must still hold a sub-100ms loop under SATCOM-degraded conditions. A single stack rarely spans small-UAS and Group 5 without material subsystem divergence — the most common architectural failure is designing the stack against one class and retrofitting the others.
Note prompts — click to add
+ Which classes share enough compute envelope to justify a single inference stack vs. dedicated builds?+ Have we inventoried every platform class we field today plus what is in the next two POR milestones?+ Who owns per-class latency attribution so we can measure autonomy impact platform-by-platform?
Required
Select every platform class the autonomy stack must support — per-class latency and SWaP envelopes vary by an order of magnitude.
Select all that apply
Small UAS, < 2kg (Skydio X10D class)
Group 3 SUAS (Shield AI V-BAT, Anduril Altius / Bolt)
Group 5 UAS (General Atomics MQ-9 / Mojave, Northrop MQ-4C Triton)
Collaborative Combat Aircraft (Anduril Fury, GA Gambit, Kratos XQ-58A Valkyrie)
UGV / robotic combat vehicle
Unmanned Surface Vessel (Saildrone, Saronic)
Unmanned Undersea Vehicle (Anduril Dive-LD)
Heterogeneous swarm (> 3 platforms, mixed domains)
required
✓ saved
Define perception-action loop latency budget
Why This Matters
At 10 m/s (typical UGV speed), a 50ms perception-action latency means the vehicle has already moved 50cm before acting on the last sensor reading. The budget is set by the physics of platform speed and stopping distance, not by engineering preference — and once set, every millisecond spent on network egress is a millisecond unavailable for perception, planning, or safety arbitration. Budgets must be chosen first and architecture chosen to fit them.
Note prompts — click to add
+ What is our measured p99 perception-action latency today, and where is the dominant jitter source?+ Have we stress-tested at 2x sensor burst rate to locate the latency cliff before a real mission finds it?+ What is our fallback behavior when the loop overruns, and does it meet the safety case?
Required
Select the P99 perception-action latency budget the autonomy stack must hold under degraded conditions.
Single choice
Sub-20ms (small UAS, < 2kg)
Sub-30ms (Group 3 SUAS)
Sub-50ms (UGV, swarm per-agent)
Sub-100ms (Group 5 UAS, USV)
Tiered by platform (mixed budgets)
requirededgetrinidy
TrinidyAny cloud-routed link consumes 30–150ms of round-trip before a single inference runs — exceeding the entire loop budget for sub-50ms platforms. NEXUS OS runs the full perception-plan-act chain on-platform with deterministic scheduling so p99 is bounded even under burst sensor load.
✓ saved
Select DoDD 3000.09 autonomy classification
Why This Matters
DoD Directive 3000.09, reissued Jan 25, 2023, imposes specific review and approval paths on lethal autonomous weapons systems. Semi-autonomous and autonomous systems that select and engage targets without human action require senior-leader review (USD(R&E), USD(P), VCJCS) before formal development and again before fielding. Non-weapon autonomous systems (autonomous navigation, ISR collection, logistics) do not carry the same engagement-approval requirement, but still inherit DoD AI Ethics Principles and LOAC obligations.
Note prompts — click to add
+ Has the program submitted the 3000.09 senior-leader review package, or does it fall outside the weapons-engagement scope?+ Who is the designated program lead for 3000.09 compliance artifacts and test-evaluation coordination?+ Has the January 2023 reissuance been re-mapped against the program's prior 2012 3000.09 position?
Required
Classify the system against DoD Directive 3000.09 (Jan 25, 2023) autonomy categories — this drives the senior-leader review path.
Single choice
Human-operated (no autonomy in weapon engagement decisions)
Semi-autonomous weapon system (human selects targets)
Human-supervised autonomous (human-on-the-loop, can intervene)
Autonomous weapon system (selects and engages without human action)
Non-weapon autonomous (ISR, logistics, nav only — outside 3000.09 engagement scope)
required
✓ saved
Define autonomy level per mission phase
Required
Autonomy level is rarely uniform across a mission — specify per-phase.
Select all that apply
Launch / takeoff — operator-in-loop
Transit — human-on-loop, autonomous nav
Ingress to objective — autonomous, degraded comms tolerated
ISR collection — autonomous with operator review of tracks
Engagement / effects — human-in-loop required
Egress / RTB — autonomous
Recovery / landing — operator-in-loop
required
✓ saved
Define SWaP ceiling for the autonomy compute stack
Why This Matters
SWaP is the hard constraint that kills more autonomy programs than accuracy does. Model architectures that hit target accuracy at server-class power budgets routinely miss by 5–10x at embedded envelopes, and the gap is not closed by quantization alone. SWaP must be budgeted before model selection — not discovered after training. The Skydio X10D, Anduril Bolt, and Shield AI V-BAT all ship specifically because their autonomy stacks were designed to the SWaP envelope, not retrofitted into it.
Note prompts — click to add
+ What is the sustained (not peak) power budget available to autonomy compute on each platform?+ Have we modeled thermal behavior at sustained inference load in the target operating envelope?+ Is our model selection driven by SWaP or by accuracy benchmarks from non-embedded contexts?
Required
Select the size / weight / power envelope available to the autonomy compute on the target platform.
Single choice
< 15W, < 100g (small UAS embedded — Jetson Orin Nano class)
15–60W (Group 3 SUAS — Jetson Orin AGX / discrete GPU)
60–300W (UGV / USV — workstation-class)
> 300W (Group 5 UAS / mission bay — server-class)
Mixed — different envelope per platform class
requirededge
✓ saved
Specify operating environment and degraded-comms assumptions
Why This Matters
Replicator and the DoD Joint Warfighting Concept both assume comms-degraded and GPS-denied operation as the baseline, not the exception. A stack whose safety case only holds with continuous link and GPS is not a fielded autonomous system — it is a remotely piloted system. Environmental scope must be stated explicitly so perception training data, SLAM fallback, and degraded-mode behaviors can be validated against it.
Note prompts — click to add
+ Does our perception training set include adverse weather and night operation at representative volume?+ What is our navigation fallback when GPS is denied — VIO, SLAM, terrain-relative?+ How does the autonomy stack behave on a 60-second comms blackout, and is that behavior tested?
Required
Select every environmental condition the stack must hold its safety case under.
Select all that apply
GPS-denied / GPS-spoofed
Comms-degraded / intermittent link
Full comms blackout (EMCON or jammed)
Contested EMS (electromagnetic spectrum)
Day / clear weather baseline
Night / low-light
Adverse weather (rain, fog, dust, maritime spray)
Urban / cluttered terrain
Maritime (sea-state dependent)
Subterranean / GPS-unavailable by structure
required
✓ saved
Confirm deployment topology
Required
Select the physical/logical deployment target for the autonomy inference stack.
Single choice
On-platform embedded compute (full autonomy, no off-board dependency)
On-platform + tactical edge node (SOF team kit / vehicle)
MOB-edge inference (forward base, disconnected from CONUS)
Hybrid: on-platform safety-critical + MOB for heavier reasoning
CONUS cloud with on-platform fallback (not valid for EMCON)
requirededgetrinidy
TrinidyFor on-platform autonomy with air-gap operation under comms denial, cloud inference is physically incompatible. NEXUS OS is the on-platform inference substrate — embedded GPU, FPGA, and CPU targets on the same deployment fabric, with local Foundry for model management at the MOB.
✓ saved
Define swarm coordination scope
Why This Matters
DARPA OFFSET's final field experiment at Fort Campbell in 2021 demonstrated 300+ combined physical and virtual autonomous agents operating simultaneously in urban terrain — this remains the largest coordinated swarm experiment DoD has publicly validated. Swarm scale changes the architecture: a pair can run on a centralized controller; a 300-agent swarm requires mesh coordination with no central dependency because any central node is a single point of failure and a communications magnet.
Note prompts — click to add
+ Is our coordination architecture centralized, decentralized, or mesh — and does it survive 30% platform loss?+ Have we validated our coordination algorithm at the target scale, or extrapolated from smaller experiments?+ What is the comms bandwidth per agent required by our coordination protocol, and does it fit the EMS plan?
Required
Select the multi-agent coordination requirements.
Single choice
Single-platform only — no coordination
2–3 platform coordination (pair / small element)
4–30 platforms (tactical element, Replicator Tranche 1 scale)
30–300 platforms (DARPA OFFSET FX-6 demonstrated scale)
> 300 platforms (beyond DoD-demonstrated baseline)
recommended
✓ saved
Program Alignment
Map program to active DoD autonomy efforts
Recommended
Confirm which funded program the autonomy stack aligns to.
Select all that apply
Replicator Tranche 1 (est. $500M+ FY24, announced Aug 2023)
Replicator Tranche 2 (counter-UAS focus)
CCA Program Phase 1 (Anduril + General Atomics selected, April 2024)
F-35 Block 4 modernization
Army RCV (Robotic Combat Vehicle)
Pentagon Swarm Voice Control Prize
SOCOM / service-specific autonomy POR
DARPA / service S&T (pre-POR)
recommended
✓ saved
Confirm ITAR / EAR export control posture
Why This Matters
Autonomy software that directs weapons employment or enables military-critical capabilities generally falls under USML Category XI (military electronics) or Category VIII (aircraft) on the U.S. Munitions List, making it ITAR-controlled. ITAR restricts who can touch source, training data, and model weights — misclassifying early leads to painful contractor and cloud-vendor rework. The classification must be made before vendor selection, not after.
Note prompts — click to add
+ Has State DDTC commodity jurisdiction been confirmed for the autonomy software package?+ Are all development contractors, subcontractors, and cloud vendors ITAR-cleared?+ Have we segregated ITAR training data from non-ITAR development environments?
Required
Autonomy stacks for fielded weapon systems almost always carry ITAR scope — confirm before partner selection.
Single choice
ITAR-controlled (USML Cat VIII / XI / XII applies)
EAR 600-series dual-use
EAR 9x515 (spacecraft) — relevant if on-orbit
Foreign Military Sales variant planned
Not yet classified
required
✓ saved
Identify ground-vehicle / airworthiness safety standard
Recommended
Applicable functional-safety standard for the platform class.
Single choice
ISO 26262 (ground vehicles — automotive functional safety)
STANAG 4671 (NATO UAS airworthiness)
MIL-HDBK-516C (military airworthiness)
ASTM F3269 (run-time assurance for UAS)
None formally adopted — program-specific safety case
optional
✓ saved