ATAK Plugin for SHIELD/ATLAS — Design Memo

Author: Dr. Terry Flood, Integrated Services and Solutions LLC Date: 2026-05-04 Status: Decision memo — recommendation made, decision not yet taken Audience: Internal (ISS LLC) and any reviewer asking "where does the warfighter touch ATLAS?"

1. Question

Should ATLAS ship an ATAK plugin (UI inside ATAK) in addition to its current posture as a CoT producer (data into the TAK bus)?

This question became live on 2026-05-04 when the TAK Product Center GitHub presence (github.com/TAK-Product-Center) was confirmed as the canonical source of truth for ATAK-CIV, TAK Server CIV, WinTAK-CIV, and the official Plugin SDK — all Apache 2.0, no DoD sponsorship required to build against.

2. Three architectures on the table

Architecture A — CoT producer only (current state)

• ATLAS server emits CoT messages onto the TAK bus
• ATAK shows tracks as map pins; warfighter sees results, cannot interact
• Touch surface: read-only, map-side
• Build cost: zero additional (already shipping)
• Maintenance cost: existing kill-chain bridge agent
• What the warfighter cannot do: query an agent ad hoc; accept/reject a Decide-lane recommendation; pull DIME/PMESII synthesis on a tapped entity; request a re-collect on a lost track

Architecture B — Pure ATAK plugin

• ATLAS UI lives entirely inside ATAK as a plugin
• Plugin calls ATLAS REST API directly from the device (over tactical network or beacon)
• Touch surface: full bidirectional, in-ATAK
• Build cost: second codebase (Android Java / Kotlin), Plugin SDK learning curve, ATAK plugin packaging and signing pipeline, second test surface
• Maintenance cost: material — every ATLAS API change risks plugin compatibility; ATAK version upgrades occasionally break plugins
• Risk: if the plugin lags ATAK upgrades, the warfighter sees a broken plugin and blames ATLAS

Architecture C — Hybrid (CoT producer + narrow ATAK plugin)

• CoT producer remains the primary integration (Architecture A unchanged)
• A thin ATAK plugin is added as a secondary surface — a sidebar/dropdown that:
  1. Shows the provenance trail for any CoT track ATLAS emitted (citation chain, source reliability, LLM provider/model used)
  2. Offers three buttons per track: "re-collect", "why this assessment?", "escalate to operator review"
  3. That's it. No general chat, no agent picker, no settings panel.
• Plugin is intentionally narrow — its only job is to make the existing CoT pins inspectable and actionable
• Touch surface: read CoT (Architecture A) + targeted bidirectional on demand
• Build cost: moderate — one Android engineer × ~6 weeks for v1, then ~1 week per quarter for ATAK-version maintenance
• Maintenance cost: bounded by the narrow scope; the plugin doesn't try to be ATLAS, it tries to be a magnifying glass on ATLAS-emitted CoT

Architecture D — SitX Bridge Adapter (added 2026-05-04 on BAH guidance)

Surfaced after Booz Allen Hamilton (via Greg, 2026-05-04) pointed ISS LLC at Booz Allen Sit(x)® — a commercial TAK federation product (boozallen.com/expertise/products/sitx-situational-awareness-in-real-time.html). The headline feature for ATLAS is Bridge Adapters, quoted from the Sit(x) product page: "Third-party integrations can send and receive data to TAK without having to develop a TAK plugin application."

• ATLAS publishes its tracks and agent outputs as a Sit(x) bridge-adapter producer against the published bridge-adapter API
• Sit(x) federation layer (running in AWS GovCloud) ingests and delivers into ATAK / WinTAK / iTAK / web Dashboard automatically — including across organizational and affiliation boundaries
• Touch surface: ATLAS data appears in TAK clients without ATLAS writing any Android, iOS, or Windows client code
• Build cost: ~2 weeks of API integration work, server-side, in our existing Node/TS codebase — no Android dev, no plugin packaging, no APK signing pipeline, no per-version ATAK churn to track
• Maintenance cost: low. Bridge-adapter API stability is BAH's commitment. ATAK / WinTAK / iTAK version churn is BAH's problem, not ours.
• Strategic cost: ATLAS data flows through a BAH commercial platform. BAH owns the end-user relationship; ATLAS is a data provider in their stack. Commercial terms required.
• Status of commercial relationship as of 2026-05-04: BAH has indicated partnership interest (Greg-mediated outreach to ISS LLC). Specific commercial terms TBD.

3. Why Architecture D wins as v1, Hybrid (C) wins as v2

Architecture D as v1, three reasons:

1. Time-to-warfighter collapses from ~8 weeks to ~2 weeks. Bridge-adapter integration is a server-side API contract, not a second codebase. We can demo SitX-mediated CoT delivery to a vendor in two weeks of focused work, not eight.
2. Maintenance burden is bounded by BAH's product-stability commitment. We don't track ATAK-CIV version churn, we don't sign APKs, we don't maintain a second build pipeline.
3. It de-risks the "warfighter touch" question without committing to native plugin work. If a PMO asks "how does the warfighter interact with ATLAS?", the answer becomes "via SitX, which is fielded and operational across multiple branches." That's a stronger answer than "via a plugin we plan to build."

Architecture C (hybrid w/ narrow plugin) as v2, three reasons:

1. SitX coverage gaps may emerge. Some PMOs do not deploy SitX. For those, Architecture A (CoT producer) remains the floor and Architecture C (narrow plugin) is the upgrade path.
2. A native plugin gives us a non-BAH-mediated path if commercial terms with BAH stall or change. We do not want our entire fielded-warfighter touch to depend on one commercial partner.
3. The narrow plugin still honors "no new GUI for the warfighter" and still answers the touch question — just without BAH in the middle.

The original Architecture C rationale (honors no-new-GUI, bounds maintenance liability, credible answer to touch question) all still applies. Architecture D simply makes it the v2 commitment rather than the v1 commitment.

4. Cost and timeline

Aggregate v1: ~8 weeks elapsed, ~2 person-months. ROM cost $40K–$60K depending on contractor rate.

5. Risks and how we'd handle each

6. Recommendation

v1: Take Architecture D (SitX bridge adapter). Engage BAH on commercial terms via the Greg-mediated channel that surfaced this option on 2026-05-04. Once terms are framed, allocate ~2 weeks of server-side work to publish ATLAS as a Sit(x) bridge-adapter producer. Demo target: vendor-to-vendor live demo where ATLAS-emitted tracks appear on a SitX-federated ATAK device within seconds.

v2: Take Architecture C (hybrid CoT + narrow plugin) on signal from a non-SitX-deploying PMO. Authorize Discovery phase (2 weeks, ~$10K contractor) when the first warm PMO conversation surfaces that does not run on SitX. Do not pre-build before that signal lands.

Floor (Architecture A) is already shipped: ATLAS as a CoT producer against TAK Server CIV (Apache 2.0, github.com/TAK-Product-Center) works today, demoed at /demo-stack. This is our fallback regardless of how D and C develop.

What we ship in code before the BAH terms close: nothing committing us to either D or C. We document the architectures in the public posture (this memo + /transition SitX row), and we make sure our /demo-stack recipe stands up TAK Server CIV cleanly so any vendor demo can start from a baseline they can verify themselves.

7. Decision needed from

Dr. Terry Flood. Trigger condition: first warm PMO conversation that includes the question "how does the warfighter interact with ATLAS?"

Appendix A — What "ATAK plugin" actually means technically

ATAK plugins are Android components packaged as APKs that ATAK loads at runtime. The Plugin SDK (github.com/TAK-Product-Center) provides the lifecycle hooks, map-overlay APIs, dropdown receiver pattern, and event bus. A plugin can:

• Add icons / dropdowns to the ATAK toolbar
• Receive taps on map entities (including CoT tracks ATLAS emitted)
• Make HTTP calls (subject to ATAK's network policy)
• Render its own panels using ATAK's UI primitives

What we'd build is a dropdown receiver registered on CoT tracks emitted with the SHIELD/ATLAS source UID. When the warfighter taps such a track, the dropdown shows three buttons. That is the entire UI footprint.

Appendix B — Why not WinTAK or iTAK first

Note on availability — both ATAK-CIV and iTAK are freely available on Google Play and the Apple App Store respectively, published by the TAK Product Center. Availability is not the constraint; plugin extensibility is.

• WinTAK is desktop, lower operational priority, smaller fielded user base relative to ATAK. Plugin SDK exists but is less mature.
• iTAK (iOS) — freely installable from the App Store, but the plugin model on iOS is materially more restricted than ATAK's. iOS sandboxing limits the dropdown-receiver pattern this memo's design depends on. Not a v1 target for plugin work; iTAK is fine as a consumer of ATLAS-emitted CoT today.
• ATAK is the right v1 plugin surface: Android, largest fielded base, most mature plugin model, civilian build openly distributable, supports the dropdown-receiver pattern this design uses.