# flenn-drone-defense — STRATEGIC PLAN (G0 draft, 2026-07-06) — FLAGSHIP
Detect / identify / track incoming drones for perimeter DEFENSE, integrating DST-SLAM + FLENN,
parallelized across spatial subregions. "An improved defense perimeter for everyone." Approve G0 → G1.
Depends on: slam-dst-integration (substrate) and flenn-chess (FLENN method validation).

## The one-sentence bet
A defense-perimeter sensor system that (a) builds a fast, parallel 3D scene with DST-SLAM, (b)
identifies threats with a FLENN whose logic nodes encode auditable target-signature rules, and (c)
tracks them across spatially-partitioned subregions, can match or beat a conventional FLANN-SLAM +
CNN-detector pipeline on detection rate, false-alarm rate, track continuity, and latency — while being
INTERPRETABLE enough for human-in-the-loop rules of engagement.

## The integrated architecture (this is the answer to "SLAM-module-incorporating FLENN approaches")
Sensors (LIDAR / radar / EO-IR, possibly RF) → point clouds / detections
  │
  ▼  DST-key every return → per-subregion BWA archives            [slam-dst substrate]
DST-SLAM: denoise → ground/clutter removal → object association → voxel boxing → egomotion-stabilized
  3D scene + frame-to-frame object tracks (4D keys = object identity over time)
  │
  ▼  per detected object: voxel-shape + motion + (optional RF/EO) feature vector
FLENN DETECTOR / IDENTIFIER — classify object as {threat-drone, bird, balloon, clutter, friendly}.
  Logic nodes encode target-signature RULES, e.g.:
     small-cross-section AND fast AND non-ballistic-trajectory AND (RF-emitting OR rotor-signature)
     → threat;  bird-like-flap-motion AND biological-IR → not-threat.
  WHY FLENN here specifically: the classification is auditable — you can READ why an object was
  flagged (which rule fired), which is exactly what rules-of-engagement, after-action review, and
  human trust require. A black-box CNN can't offer that. This is FLENN's unique value in defense.
  │
  ▼  FLENN TRACKER / DATA-ASSOCIATOR — associate detections to tracks across frames (learned
     association function; SRNN + twist-and-bend as the bio-inspired multi-sensor spatial-fusion
     substrate feeding it — Tom's own representation).
  │
  ▼  PARALLEL over spatial subregions: airspace octant-partitioned by DST prefix; each octant runs
     its own detect+identify+track; cross-boundary handoff by key message (lockstep); CC-combine to
     the global threat picture. Scales with #sensors / volume.
  │
  ▼  Threat picture → human operator (identification, track, confidence, WHICH RULES FIRED).
     STOPS HERE. Detection/identification/tracking only. No engagement/effector logic in scope.

## Success metric + baseline
Against a conventional pipeline (FLANN-SLAM + a standard CNN/point-cloud detector + a Kalman/JPDA
tracker): detection probability, false-alarm rate (per hour), track continuity / ID-switch rate,
end-to-end latency (sensor→track), and throughput scaling with #subregions and #objects (swarm load).
FLENN-specific win condition: comparable detection/FA at MATCHED cost, PLUS auditable identifications
(every threat call traceable to fired rules) PLUS graceful low-data behavior (rules encode prior
knowledge → fewer labeled examples needed than a CNN). Kill/scope criteria stated per-metric at G4.

## Dataset — the HARD gate (G2), plan for it now
Real multi-sensor counter-UAS data is scarce, sensitive, and often classified/proprietary. Strategy:
1. **Synthetic first** — a simulator (e.g., AirSim/Gazebo/Isaac + point-cloud + radar models) generates
   drone-swarm scenarios with perfect labels: trajectories, classes, clutter. De-risks the whole
   pipeline before any real data. Most of G3/G4 runs on this.
2. **Public/open** — open drone-detection datasets (EO/IR, some radar), open LIDAR (KITTI-style) for
   the SLAM substrate, bird-vs-drone motion datasets for the identifier.
3. **Partner data (later, gated)** — real counter-UAS sensor logs only via a proper institutional
   partner under the legal/export controls below. Not an early dependency.

## Guardrails — this is DEFENSE / dual-use tech (READ before G1)
- **Scope is DEFENSE**: detection, identification, tracking of threats to a defended perimeter.
  Effectors/engagement/weapons are explicitly OUT of scope. Tom's framing: "an improved defense
  perimeter for everyone."
- **Legal / export control**: counter-UAS and target-tracking work can implicate ITAR / EAR
  (export-controlled), and some counter-UAS operation is legally restricted to authorized entities.
  G1 MUST include a compliance check (what may be published open vs. controlled; who may participate;
  can this be open-source at all). This gate is a Tom decision + likely counsel, NOT an engineering
  call. Nothing gets published or shared externally until it clears.
- **Ethics / dual-use**: identification errors have real-world stakes (a bird misclassified as a
  threat, or vice versa). Human-in-the-loop is mandatory in scope; the interpretability requirement
  is a safety feature, not a nicety.
- **Data provenance**: synthetic/open only until a vetted partner + legal clearance exist.
- **Autonomy boundary**: I (the AI) design/analyze; agents write sim + code; NO connection to real
  sensors, weapons, or live systems in this R&D — simulation and public data only, absent explicit
  Tom+legal authorization.

## Doorway sequence
- **G0** strategic plan (this) — approve scope, the defense-only boundary, and the metric set.
- **G1** architecture + COMPLIANCE — full system design (sensor model, DST-SLAM integration, FLENN
  identifier + rule set, tracker, parallel decomposition) AND the legal/export/ethics compliance
  memo. G1 does not pass without the compliance memo. Coordinate with George Mou (DST) + likely
  outside counsel (export).
- **G2** dataset — stand up the simulator + assemble open data; define scenarios (single intruder →
  swarm), labels, splits. Deliver: sim + a pilot scenario set.
- **G3** development — integrate DST-SLAM substrate + FLENN identifier + tracker + parallel octant
  processing; milestone-gated (SLAM scene → identifier on sim → tracker → parallel).
- **G4** initial testing — the metric battery vs. the conventional baseline, on sim + open data;
  the auditability demonstration; the scaling curves.
- **G5** results + refine-loop — iterate rules/features/architecture; OR, if strong, the gated
  conversation about a real-data partner + productization (which is its own major decision tree).

## Dependencies + sequencing (important)
This flagship should NOT start G3 before: slam-dst-integration reaches ~G3 (working DST-SLAM substrate)
AND flenn-chess reaches ~G4 (FLENN mechanism validated cheaply). Rationale: don't build the hardest,
highest-stakes system on two unvalidated components. G0/G1 (plan + design + compliance) can proceed in
parallel now; the build waits on its substrate. This ordering is itself a thing to approve.

## Why it matters
If it works, it's a genuinely better, cheaper, auditable perimeter defense — the DST speed makes
real-time large-volume tracking feasible on modest hardware, and FLENN's interpretability makes it
trustworthy for human decision-makers. Tom's stated aim: defense for everyone, not offense for some.