# 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

| Phase | Duration | Deliverable | Headcount |
|---|---|---|---|
| Discovery | 2 weeks | Plugin SDK familiarization, build pipeline, signing infrastructure | 1 Android dev (contracted is fine) |
| v1 build | 4 weeks | Three-button plugin against staging ATLAS API, signed APK, internal test on Pixel + on Samsung XCover Pro (the standard ATAK device) | 1 Android dev |
| Hardening | 2 weeks | Test against three ATAK-CIV versions, package as both plugin APK and TAK Server-distributable | 1 Android dev + 0.5 ATLAS engineer for API side |
| Ongoing | ~1 week per quarter | Track ATAK-CIV releases, fix breakages | 0.25 FTE Android |

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

## 5. Risks and how we'd handle each

| Risk | Mitigation |
|---|---|
| ATAK version churn breaks plugin | Narrow scope (three buttons) + signed-APK distribution per ATAK-CIV major version |
| Plugin requires DoD signing for fielded ATAK | Civilian build (ATAK-CIV) does not; mil-build distribution would route through the standard ATAK plugin distribution channel after PMO engagement |
| Plugin call to ATLAS API fails over tactical network | Plugin gracefully degrades to "data unavailable" — does not crash ATAK; warfighter still has the underlying CoT pin |
| Adoption is poor | The plugin's value is enabling provenance inspection for already-emitted CoT — even zero adoption costs us nothing in operational risk |

## 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.