Section 1: Company Overview and Selected Approach

Integrated Services and Solutions LLC (ISS), operating as SecureAssure, is a Texas-based Veteran-Owned Small Business with SDVOSB certification in process through SBA VetCert. ISS meets the ownership and control eligibility posture for SDVOSB consideration under 38 USC 8127 and is prepared to provide VetCert/application documentation to the Contracting Officer upon request. ISS was founded by Dr. Terry Flood, CWO 131A, USA Ret., and is backed by a multi-echelon team of active and retired military targeting officers, fires planners, joint operations specialists, and senior technical consultants spanning brigade, corps, and joint echelons. Platform development, operational review, technical advisory, and integration validation functions are distributed across this team. There is no single point of failure. Dr. Flood is an Army Targeting Officer who operated AFATDS and JADOCS in the field, identified their architectural and operational limitations firsthand, and led the development of a modern replacement. ATLAS (Adaptive Tactical and Leadership Assistance System) is that replacement. ISS proposes it under Approach 1 — Commercially Mature Solution.

ATLAS is not a concept or prototype. It is a commercially operational platform with live API endpoints, a fires targeting state machine, bidirectional AFATDS integration, a multi-track kill chain orchestrator with human approval gates, and an embedded AI planning assistant — available for demonstration today at secureassure.app. The platform addresses every desired capability in Section 2.0 of this RFI with working, demonstrable software. ISS offers PM C2 Applications a low-overhead acquisition path via Other Transaction Authority consortium, SBIR Phase III sole-source, or small-business/direct award paths available while SDVOSB certification is pending final determination — substantially reducing procurement timeline and administrative burden compared to a major defense prime.

Section 2: Fires Targeting Architecture

ATLAS implements the complete fires chain from Call for Fire through Battle Damage Assessment: CFF → Visual PID → Weaponeering → CDE/NSL Check → Paired Target Lock → Export → Engage → BDA. Every step is a live, API-backed module. Eleven active API endpoints support mission generation, state transitions, adjustment submission, BDA recording, engagement retrieval, training scenario generation, and scenario evaluation.

Fire Mission Engine. The ATLAS fire mission generator produces simultaneous outputs in AFATDS (USMTF), VMF K05.1, Cursor on Target (CoT/XML), and GeoJSON. The engine computes MGRS coordinates from WGS84 using a full ellipsoidal projection model, performs danger-close calculations per FM 3-09, and manages a six-state fire mission machine: PENDING, APPROVED, IN_EFFECT, ROUNDS_COMPLETE, BDA_PENDING, COMPLETE. Adjustment records — ADD, DROP, LEFT, RIGHT — are tracked and associated with each mission record. This is the same state machine AFATDS manages, rebuilt on a modern platform.

Kill Chain Orchestration. ATLAS supports concurrent multi-track designation with independent state machines per track type (BLUE, RED, GRAY, WHITE, GREEN). A Priority Arbitration Service de-conflicts assets across concurrent kill chains using configurable rules, prevents fratricide, and logs all arbitration decisions with full audit trails. No asset can be double-committed without a logged conflict resolution event.

Fire Support Coordination and Targeting Workflow. ATLAS manages Fire Support Coordination Measures — CFL, FSCL, RFL, and NFA — as live data objects with activation and expiration times. Close Air Support 9-Line requests are generated and tracked through completion. Target lists — HPTL, AGM, TSS — are integrated into the Targeting Board battle rhythm, which includes the D3A (Decide, Detect, Deliver, Assess) meeting as a structured recurring event with defined agenda, attendees (FSO, S2, S3, ALO), and output products. ATLAS integrates the full Military Decision Making Process: OPORD and FRAGO wizard, Warning Order generation, synchronization matrix, Decision Support Matrix, wargaming engine, rehearsal planning, and TLP workflow. The fires support plan is a native OPORD output.

Section 3: Artificial Intelligence and Man-in-the-Loop Targeting

ATLAS includes ODIN (Operational Decision Intelligence Network), a doctrine-grounded AI planning assistant purpose-built for man-in-the-loop operation. ODIN is an advisor, not an autonomous actor.

Target Lifecycle and Approval Gates. The JTIC2S fcb-targets service models the target lifecycle as an explicit state machine — NOMINATE → IN_DEVELOPMENT → READY_FOR_EXECUTION → SENT_FOR_EXECUTION → SHOT → SPLASH → ROUNDS_COMPLETE → END_OF_MISSION → CONFIRMED_DESTROYED. ATLAS's kill chain mirrors this state machine one-for-one and emits a human-approval-required event before every transition advancing a designation toward execution. The READY_FOR_EXECUTION → SENT_FOR_EXECUTION boundary in JTIC2S maps to ATLAS's approval-required gate; no software path advances past that boundary without a recorded human authorization. The JTIC2S jtic2s-gateway enforces a complementary Zero-Trust authorization layer with role-based access (JTIC2S_READER, JTIC2S_USER, JTIC2S_ADMIN) and defaultDenyAll: enabled: true in production. ATLAS interoperates with the JTIC2S Keycloak (OIDC/OAuth2 JWT) realm on the same role taxonomy.

Confidence Framework and CDE Alignment. All ODIN outputs carry a three-tier confidence label enforced in code: [GREEN] (verified data or doctrine), [AMBER] (inference with named verification path), [RED] (ungrounded — human verification required before use). Four hard rules in the AI Audit Engine prevent the class of errors that would make a fires AI system a liability: NO_HALLUCINATED_COORDINATES, NO_FABRICATED_UNITS, NO_UNAUTHORIZED_ENGAGEMENTS, CDE_PRECISION. ATLAS's CDE_PRECISION rule maps directly to the JTIC2S FCBCollateralDamageEstimationResult evidence chain (analystName, assessment, ceDay/Night/Episodic, CBR/CHAMP/Navoceano hazard flags, level, metRoe, positiveId, source) so every AI-assisted CDE recommendation carries the same audit trail the JTIC2S data model already requires. Target significance classifications (HIGH_PAY_OFF_TARGET, JOINT_INTEGRATED_PRIORITY_TARGET, TIME_SENSITIVE_TARGET) flow through ATLAS HPT/JIPT/TST queues using JTIC2S's existing enums.

Deconfliction Integration. The JTIC2S geo-filtering service runs five named deconfliction rules — NoAndRestrictedFireAreaRule, NslRtlRule (No-Strike List / Restricted Target List), FriendlyUnitRule, TrackRule, AirspaceCMRule — against server-core friendly units, persistence MIDB target lists (status filter A,V,Z), and fcb-airspace ACO data, writing results to an fcbconflict_entity table capturing friendly-unit location, FSCM location, intersection point, ACM/ACO IDs, projected distance, and active time period. ATLAS consumes the JTIC2S deconfliction-entity-topic RabbitMQ message at the human-approval gate, presents the conflict evidence to the operator, and refuses to advance the state machine until each conflict is resolved or explicitly accepted.

Reasoning, Planning, and Intel. ODIN applies OODA, ASCOPE/PMESII-PT, DIME, and IPB to generate 2–3 Courses of Action with risk scoring, resource requirements, and timelines for comparative analysis. ATLAS integrates ODIN with the JTIC2S intelligence plane via the jtic2s-intel-reports service (POST /api/tps/intel/ingest for structured ingest) and the TCS → tcs-intel-reports → intel-report-update RabbitMQ chain, preserving JTIC2S provenance tagging (FiresTaskMetadata.dataSource: AXS_DEFAULT, AXS, AFATDS_68, MIDB, DDS, LINK_16, VMF, ISF_INTEL, JTIC2S) on every recommendation. Context-aware doctrine, checklists, and decision criteria surface at each step.

Section 4: Multi-Domain Data Integration and Coalition Interoperability

Program-Level Alignment. ATLAS attaches to JTIC2S as an adapter-layer consumer at seventeen named module boundaries, grounded in ISS's architecture review of the JTIC2S source distribution (Develop branch, 20 May 2026 snapshot) under the executed PM C2 Applications Software Distribution NDA. JTIC2S is the JADOCS-displacement component within the broader FIRES Converged Baseline (FCB) under the AFATDSM (AFATDS Modernization) program, deployed via the AXS (AFATDS Suite) common chassis. ATLAS integration aligns at the FCB level: ATLAS attaches at the JTIC2S microservice boundary (Spring Boot 3.5 / Spring Cloud 2025 / Java 17 on Iron Bank openjdk17-slim) and is conformant with the FCB DevSecOps pipeline pattern (CReATE GitLab at gitlab.create.army.mil, CDSO mirror at code.cdso.army.mil, git.mil sync, TRMC Artifactory image registry, SonarQube quality gate, OWASP Dependency-Check with NVD enforcement).

AFATDS 6.8 and C2IUL Interfaces. ATLAS's fires-format-adapters module attaches to JTIC2S's jtic2s-afatds68 service for bidirectional AFATDS 6.8 interop. ISS adopts the same named upstream parser libraries the JTIC2S build uses — c2iul-payloads-mtf-parser, c2iul-payloads-vmf-parser, c2iul-payloads-vmf-json-convertor-util, and the USMTF 2004 templates (c2iul-payloads-mtf-payloads-standards-usmtf-2004) — so message-format alignment is build-level, not interpretive. The JTIC2S extinterfaces-c2iul service (C2IUL VMF/MTF gateway with NATO classification V_1..V_6) is consumed by ATLAS through the gateway-routed REST surface. The extinterfaces-axs adapter on AXS Public API port 8141 provides ATLAS-to-AFATDS-Suite bidirectional access with mTLS via the axs public api keystore. The JTIC2S fcb-airspace service exposes ATO/ACO over RabbitMQ topics on the shared afatdsm-topic-exchange (mil.army.fires.extint.c2iul.airspacecontrolorder.in / airspacetaskingorder.in / ato-report-update / aco-report-update); ATLAS subscribes for airspace situational awareness during fires planning.

Link-16 and ActiveMQ LDM. ATLAS Link-16 surface (J3.2 air track, J3.5 surface track, J7.0 EW, J12.6 free-text) attaches to jtic2s-link16, which bridges the NTDM LDM (Local Data Manager) via ActiveMQ JMS at failover:(tcp://activemq:61616) topic Reaper.Public under OIDC client ldm-svc against Keycloak realm ntdm. Link-16 track reports flow through link16-track-report-update/delete (RabbitMQ → STOMP WebSocket → ATLAS COP) while deconfliction-entity-topic carries entity-level triggers to JTIC2S geo-filtering for upstream conflict evaluation. ATLAS retains organic ADS-B fusion on NIPRNET and feeds the fused track set into the JTIC2S Link-16 pipeline on SIPRNET.

NGC2 Dual Integration (Anduril Lattice + Palantir Foundry). JTIC2S's jtic2s-ngc2 service is a dual-integration headless adapter to Anduril Lattice (gRPC on port 3445; publishes own-unit entity, HPTL objects, TLWS objects, AXS execution units) and Palantir Foundry (ontology API at palantir.ngc2apps.army.mil with classification markings, mandatory markings, target-area-of-interest polygon definitions, named operation, HPTL publication). ATLAS's NGC2 adapter consumes the same lattice-axs-target (from fcb-targets), ngc2-tps-hptl (from TPS), and ngc2-tlws (from TLWS) RabbitMQ topics that jtic2s-ngc2 consumes, and publishes to lattice-tcs-intel-report for the TCS intel return path. ATLAS therefore participates in NGC2's Lattice and Foundry surfaces on parity with the JTIC2S reference integration.

DIEE and T3D, Intel and MIDB. ATLAS bridges to jtic2s-diee (Distributed Information Exchange Engine to sibling T3D at t3d-rest.t3d.svc.cluster.local) over jtic2s-diee-request-update and jtic2s-diee-result-update RabbitMQ topics, providing ATLAS users access to T3D Kafka streams (t3d-request-json / t3d-request-xml) and T3D message-relay XML↔JSON transformations. ATLAS consumes the JTIC2S TCS → tcs-intel-reports → intel-report-update intel chain and the server-extinterfaces-midb (Modernized Integrated Database, port 8083) target-list access with the A,V,Z status filter geo-filtering uses. The JTIC2S NATS JetStream coordination plane (JTIC2S_COORDINATION_STREAM, KV-bucket JTIC2S_PRESENCE, subject taxonomy jtic2s.{plane}.{domain}.{action}.{routing_mode}.{destination} with CQRS command/ack pairs) is the inter-node coordination surface ATLAS adopts on parity with JTIC2S nodes.

Coalition and NATO Interoperability. ATLAS's eight-STANAG ISA Compliance Adapter (STANAG 4586, 4609, 5516, 4676, 4559, 7023, 5500, and MIL-STD-2525D) interoperates with the thirteen coalition standards JTIC2S's data model declares via AlternateStandardCode: ADEM, AIS, LINK11, LINK16, LINK22, MIP2, MIP31, MATRA, NFFI13, NVG, VMF, ACCS, NATO. Hostility codes (NATO MIP-3.1: AFR, AHO, AIV, ANT, FAKER, FR, HO, IV, JOKER, NEUTRL, PENDNG, SUSPCT, UNK) and NATO confidentiality codes (V_1..V_6) flow unchanged between JTIC2S and ATLAS so coalition data exchange is identity-preserving. ATLAS additionally supports CoT/TAK (bidirectional), DCGS-MC, NGA geospatial, CDS cross-domain, STIX/TAXII 2.1, DAF Battle Network, and the GeoServer OGC WMS/WFS/WMTS surface the JTIC2S fcb-web Cesium 3D globe consumes.

Section 5: Architecture, DevSecOps, and NGC2 Alignment

Cloud-Native and DDIL Architecture. ATLAS is a microservices platform with a typed event bus (platformBus) — the same architectural pattern JTIC2S adopts with RabbitMQ as the primary AMQP bus (afatdsm-topic-exchange), Apache Kafka with Zookeeper for T3D data plane, ActiveMQ for Link-16 LDM, NATS JetStream for inter-node coordination, Apache NiFi for SMPS data pipelines, ZeroMQ XPUB/SUB for CPCE config-change notifications, and STOMP-over-WebSocket for UI real-time updates. ATLAS aligns at the architectural-pattern level, not by accident of similarity. ATLAS operates in full DDIL environments: zero external connectivity does not degrade fires targeting, planning, or situational awareness functions. Mission-critical data, target lists, and FSCM are available offline with synchronization on reconnect — ATLAS contributes DDIL capability to the FCB stack where JTIC2S's reference deployment assumes K8s-cluster persistent connectivity, extending operational resilience without requiring architectural change in JTIC2S itself.

FCB and NGC2 Alignment (Named). ATLAS aligns with the Fires Converged Baseline at five named integration points: (1) jtic2s-ngc2 for Lattice gRPC and Palantir Foundry ontology participation; (2) the CPCE configuration plane (mil.army.missioncommand.coev3.infrastructure.management.config-service, REST on :8443 per OpenAPI 3.0.3, Infinispan-backed, ZeroMQ XPUB on :23231 for change notifications) for FCB-conformant configuration consumption under the same hierarchical container=global/root=JTIC2S namespacing; (3) the AXS persistence layer (mil.army.fires.persistence:* artifact stack at version 6.0.4) for shared fires data model access; (4) the AXS server-core (mil.army.fires.servercore:* at version 9.0.0-SNAPSHOT) for shared system configuration; (5) the JTIC2S gateway (Spring Cloud Gateway with Resilience4j circuit breakers, audit publish/consume to Postgres audit_log, TokenRelay JWT propagation, full RBAC) for unified ingress. ATLAS consumes the JTIC2S jtic2s-data-model shared DTO library (mil.army.jtic2s.dm.model-dto/model-entity/entity-mappers) for typed adapter integration rather than schema-by-inference. NGC2 Optimized compliance reduces from a programmatic abstraction to concrete adapter work against named JTIC2S modules — Phase 1 engineering, not architectural redesign.

Agile Development Model. ISS develops ATLAS on a Program Increment model with 13-week PI cycles matching JTIC2S's Engineering Release cadence. Each PI delivers testable, deployable capability increments. Sprint reviews and demonstrations are conducted with operational users. ISS maintains a continuous integration and continuous deployment pipeline with automated testing, security scanning, and dependency management. Build gates enforce capability-claim-to-implementation congruence: no feature is declared in the platform without a working backend endpoint.

Cybersecurity and eMASS. ATLAS is currently enrolled in SIPR eMASS with an active RMF process underway. STIGs and Security Requirements Guides are applied systematically, with automated dependency management tied to the CI/CD pipeline. ISS is prepared to engage with the Government's ATO process on award and will provide full eMASS documentation and audit support. MBSE tooling — MagicDraw or Government-directed equivalent — will be adopted within Phase 1 to produce required DoDAF artifacts: AV-1, OV-3, OV-5b, and SV-6. ISS brings operational architecture knowledge from the practitioner level and will apply MBSE tooling to formalize it in the formats required for joint interoperability certification.

Embedded Training. ATLAS implements TRAINING mode as a native operational mode — the same platform used in operations is used for training. Exercise mode equals operations mode. ODIN's cognitive assistance function surfaces doctrinal guidance, checklists, and decision criteria at each step of execution, providing context-aware support at the point of need. ISS is prepared to provide on-site support to military units for incremental capability releases, with team members who have direct operational backgrounds in fires, targeting, and C2.

Section 6: Past Performance and Key Personnel

Origin and Practitioner Credibility. ATLAS was designed by its primary user. Dr. Terry Flood, CWO 131A, USA Ret., is an Army Targeting Officer who operated AFATDS and JADOCS in the field. The platform is not a defense contractor's interpretation of targeting doctrine — it is a targeting officer's direct implementation of it, built after operating the systems being replaced. No past performance statement is more credible for a JADOCS successor than a system built by a practitioner who ran JADOCS against real targets. The platform is live and publicly accessible at secureassure.app for independent technical verification.

Key Personnel.

DoD Security Experience. ISS has operated ATLAS on SIPRNET and maintains active SIPR eMASS enrollment. The team has hands-on experience with Army cyber procedures, RMF requirements, and DoD classification requirements. Platform design choices — dual-network architecture, confidence labeling on all AI outputs, CUI handling for planning products — reflect operational security experience.

Section 7: Technical Innovation, Data Rights, and Adaptability

Innovative Technologies. Three technologies differentiate ATLAS from legacy C2 platforms and from commercial AI wrappers:

ODIN AI Engine. ODIN is purpose-built for targeting and operational planning, not a general-purpose large language model. Hard-coded confidence tiers ([GREEN]/[AMBER]/[RED]) and four AI Audit Engine rules enforce responsible output at the code level. ODIN's reasoning is documented, traceable, and challengeable — consistent with responsible AI requirements for lethal decision support.

platformBus Data Fabric. The event bus connecting all 80+ platform modules is a typed, validated, persistent fabric providing schema validation, delivery guarantee, event history, and cross-domain routing. This is the same data fabric architecture required by NGC2. The adapter pattern applied to ten existing DoD systems means adding NGC2 common services or new AI models does not require touching the platform core.

DDIL Architecture. Offline-first design eliminates the single largest operational risk in forward-deployed C2: loss of capability when the network degrades. This is not a mitigation measure — it is the primary design posture.

Data Rights. ISS owns all ATLAS intellectual property. No open-source licenses encumber the proprietary core. ISS proposes Government Purpose Rights (GPR) for all deliverables produced under a JTIC2S contract per DFARS 252.227-7013/7014, preserving the Government's full operational rights while allowing ISS to continue commercial development. Proprietary background IP would be licensed to the Government under terms ensuring complete operational use for JTIC2S purposes.

Adaptability. The modular chassis is designed for multi-decade capability evolution. New capabilities, interfaces, and AI models are added as adapters without modifying the platform core. Ten DoD system integrations were added using this pattern without disrupting existing functionality. Adapting to future threats, new AI models, or emerging NGC2 services follows the same path.

Section 8: Cost, Schedule, Risk, and Contract Vehicles

Rough Order of Magnitude (ROM) — Non-Binding. ATLAS is a commercially developed, dual-use platform. Under FAR Part 12, the Government acquires commercial items at fair and reasonable market prices — not through cost-plus accounting. The ROM below reflects the commercial value of the platform plus Government-specific integration, compliance, and sustainment services. To contextualize this ROM: USASpending.gov data shows the Government currently obligates over $63M across more than 20 separate JADOCS sustainment contracts — all maintenance, zero new capability. Palantir's Maven Smart System, the closest AI-enabled targeting C2 analog, has received over $375M in awards. The BAE Systems Joint Targeting Toolbox sustains at $44M in support contracts alone. ISS's $28M five-year ROM delivers complete JADOCS displacement and a modern AI-enabled fires targeting platform — at approximately 44% of current JADOCS sustainment cost and 7% of the Maven Smart System investment. This is not a discount; it is the acquisition advantage of a commercially mature platform where development cost has already been absorbed.

ISS assesses the following milestones as achievable: Award + 90 days — NGC2 compliance activities complete, ATO documentation submitted, first unit demonstration complete at APG. Award + 6 months — Phase 1 complete, Government UAT passed. Award + 18 months — Phased JADOCS displacement underway across all targeting echelons. Award + 24 months — Full displacement operational; steady-state PI evolution begins. The $28M 5-year ROM represents acquisition of a fielded, commercially proven capability — not a development contract. Schedule risk is commensurately lower than a new-build program, as the primary technical risk (platform development) has already been retired.

Contract Vehicles. ISS is a small business and Veteran-Owned Small Business with SDVOSB certification in process through SBA VetCert. ISS meets the ownership and control eligibility posture for SDVOSB consideration under 38 USC 8127 and is prepared to provide VetCert/application documentation to the Contracting Officer upon request. Available vehicles include Other Transaction Authority consortium participation, SBIR Phase III sole-source bridge consistent with 15 USC 638(r), and small-business/direct award paths available while SDVOSB certification is pending final determination. ISS's small business status provides significant contracting flexibility and reduces overhead costs relative to large prime alternatives.

Risk Management. Integration risk is mitigated by ATLAS's proven adapter pattern — ten DoD system integrations exist, adding new ones is a validated engineering activity, not research. DDIL architecture eliminates network-dependency risk by design. The modular chassis prevents vendor lock-in: any component can be updated or replaced without disrupting the platform.

Organizational Continuity. ISS is not a single-person operation. ISS maintains two separate support structures and does not conflate them. The personnel named in Section 6 include serving/active-duty and retired operational reviewers and subject matter experts who provide fires, targeting, and joint-operations validation. Separately, ISS operates under formal teaming and memorandum-of-understanding instruments with a retired senior advisor bench (the grey-beard continuity bench) for cross-coverage, advisory depth, and continuity-of-performance support. Those instruments establish defined roles, cross-coverage responsibilities, and continuity obligations; they are not informal advisory relationships. In addition, ISS proposes source code escrow and a Government-readable architecture repository on award, ensuring the Government retains full operational continuity independent of any personnel change.

Source Code. ISS executed the PM C2 Applications Software Distribution NDA and received the JTIC2S Government Furnished Information distribution (Develop branch, 20 May 2026 snapshot — JTIC2S-Src_Develop_20May26.zip) via DoD SAFE on 12 June 2026 from Mr. Nicholas Imhoff. ISS completed a full architecture pass of the distribution under NDA, identifying seventeen jtic2s-* core modules plus the FCB family (fcb-airspace, fcb-targets, fcb-web, fcb-helm-charts), the T3D sibling application family, the SMPS Apache NiFi pipeline modules, the C5ISR ISF modules (EOB, TPS, TLWS, TCS), and the AXS shared chassis (server-core, persistence-server, extinterfaces-afatds68/c2iul/midb/dds/axs, CPCE config-service, Keycloak). All integration claims in Sections 3, 4, and 5 of this whitepaper are grounded in named JTIC2S modules, named interfaces, and named DoD interop targets observed in that distribution, with no reproduction of internal class identifiers, schema field names, or source code excerpts. ISS is prepared to provide reciprocal ATLAS source code access to PM C2 Applications for technical evaluation under the same Software Distribution NDA framework.

Summary

ISS offers PM C2 Applications a commercially operational, doctrinally grounded, immediately demonstrable replacement for JADOCS. ATLAS was designed by an Army Targeting Officer who operated the systems being replaced, built with a multi-decade architecture horizon, and proven across ten live DoD interfaces. Every JTIC2S desired capability in Section 2.0 is implemented, running, and available for demonstration. ISS respectfully requests consideration for a half-day onsite session at APG and is prepared to demonstrate the complete ATLAS fires targeting chain — CFF through BDA — live, unscripted, against a Government-provided scenario.

Point of Contact: Dr. Terry Flood, CWO 131A, USA Ret. | 254-319-8460 | Mr.Terryflood@gmail.com | CAGE 9VKK3 | UEI C7YDV3P8EHL7

UNCLASSIFIED. All submissions become Government property and will not be returned.