Protected Anti-Jam Tactical SATCOM Enterprise Mission Management (PATSEMM) Sources Sought Request for Information (RFI)

Section I: PTES Description & Background

The Protected Tactical Enterprise Service (PTES) is the ground system designed to provide anti-jam (AJ) wideband Satellite Communications (SATCOM) capability utilizing the Protected Tactical Waveform (PTW) for the Protected Anti-Jam Tactical SATCOM (PATS) Family of Systems. PTES consists of a Mission Management System (MMS), a Key Management System (KMS), and Joint Hubs (JHs) to enable transponded PTW via WGS, Protected Tactical Satellite – Global (PTS-G) and commercial satellites, and processed PTW in space via Protected Tactical Satellite – Prototype (PTS-P) satellites. The user equipment consists of existing wideband terminals with upgraded PTW modems. PTW modems for user terminals include the Air Force-Army Anti-Jam Modem (A3M) and the Navy Wideband Anti-Jam Modem System (WAMS). The user terminal segment, not included in this acquisition, may utilize the low-cost PTW modem upgrades enabled by the A3M and WAMS programs.  

Requirements for PTW mission management have evolved and grown since the inception of the PTES Program, to include the requirements for other programs of record and management of PTW SATCOM over commercial satellite constellations. Additionally, the Government desires to implement a more rapid and flexible approach to delivering PTW mission management capabilities to meet urgent operational needs, in alignment with Agile and Software Pathway Program principles.

This RFI specifically requests information related to development and fielding efforts as outlined within this document. Responses to this RFI will be considered as Market Research in accordance with FAR Part 10 to inform the Government’s procurement strategy. The Government may or may not compete or award this requirement. Additional market research may or may not be conducted. Responses from small businesses and small disadvantaged businesses are highly encouraged. The anticipated NAICS code for this acquisition is 517810 and the size standard is $40,000,000.

Section II: RFI Objective

While PTW over WGS (PTWoW) provides an initial operational baseline, the Government emphasizes that this RFI seeks information from industry regarding the acquisition and integration of additional mission planning and mission management services beyond PTWoW alone, applicable across the broader PATS Family of Systems. Responses should address scalability, extensibility, and applicability to multiple satellite system implementations.

The Government encourages responses from vendors capable of rapidly addressing the full scope of mission planning and mission operations functions, as well as from vendors proposing solutions that address one or more discrete subsections of the scope described in Section III. Respondents should clearly identify which specific subsections of Section III their response addresses and describe any assumptions regarding external services, integrations, or complementary capabilities provided by other vendors or the Government. The Government anticipates that capability‑based responses may be combined in future acquisition strategies to assemble a complete mission management solution.

Section III: RFI Scope: PATSEMM

This new approach is the Protected Anti-Jam Tactical SATCOM (PATS) Enterprise Mission Management, or PATSEMM.  PATSEMM scope includes mission planning, mission operations, mission product generation, and systems integration functions required to support operational PTW satellite communications missions. The PATS Family of Systems currently includes PTW over WGS (PTWoW), Protected Tactical Satellite - Global (PTS-G), Protected Tactical Satellite - Prototype (PTS-P), Enhanced Protected Tactical Satellite Prototype (Enhanced PTS-P), and PTW over Commercial (PTWoC). The Government seeks information from industry regarding capabilities to rapidly develop and provide mission planning and mission management services in support of the PATS Family of Systems architecture, spanning both classified Secret Internet Protocol Router Network  (SIPR) and Non-classified Internet Protocol Router Network (NIPR) environments.

III.1 Mission Planning (SIPR)

• Mission planning workflows, including mission request ingest, analytics, and mission product generation.
• Mission request supportability analysis (benign/contested), including feasibility impacts from payload/terminal/JH constraints and threat/interference data, supportability against other users such as non-PTW, blocked bandwidth for users.
• SATCOM resource determination across constellations (e.g., power/bandwidth) to support independent and/or aggregated solutions.
• SATCOM resource scheduling/allocation and management for current and future mission requests.
• Mission-request and approval workflows PATS Mission Request (PMR), Pre-Satellite Access Request (SAR), Satellite Access Authorization (SAA) and post‑solution mission plan generation (PMP).
• Operator mission planning user experience, including map-based views and guided workflows to reduce workload and data entry errors.
• Implementing planning-side interfaces, including the MMS to EM&C interface (documented in the MMS to EM&C ICD).
• Creating and maintaining the MM Planning to MM Ops ICD and the MMS to EM&C ICD and testing the interfaces to external systems
• Capturing and publishing required metadata for planning outputs (e.g., provenance/lineage, markings/handling, and descriptors needed for enterprise discovery).
• Operating within a Government‑defined security accreditation boundary, including scenarios where mission planning capabilities are integrated with, layered atop, or partially replaced from existing Government‑provided functionality

III.2  Mission Operations (SIPR)

• Building and integrating MMS Operations functions: packaging/publishing, dissemination paths, and enterprise-service integration.
• Execution of approved PATS Mission plans (PMPs)
• C2 (or Government-directed control interfaces) for PTW ground elements (e.g., JHs/JHVs) and dynamic operations across satellite constellations and orbits (e.g., GEO to MEO satellite handover).
• Generation of configuration files, mission service plans, and key mission packages
• Support for mission replanning and updates
• Preparation of mission products for cross‑domain transfer
• Creating and maintaining the MMS to KMS ICD and the MMS to KLIF ICD

III.3 Cross-Domain Data Preparation

• Prepare mission products for bidirectional transfer across Government‑provided Cross Domain Solutions (CDS)
• Ensure data formatting, labeling, and compliance with cross‑domain requirements
• Operate within Government‑approved CDS workflows without direct CDS ownership or operation

Vendors shall not assume responsibility for CDS accreditation, operation, or sustainment.

III.4 Mission Operations (NIPR)

• Receipt and processing of cross‑domain mission products
• Generation and distribution of configuration files and mission artifacts for downstream systems
• Coordination with Government‑ or contractor‑operated network and host systems

Mission operations on NIPR shall coordinate with, but not exercise operational control of, external network management, host, or payload execution systems.

III.5 Interfaces and Integration

• Mission command and control systems
• Enterprise mission management platforms
• Network management and configuration systems
• Government‑defined ICDs across security domains

The Government retains authority over interface definition and approval; vendors are expected to implement against Government‑provided or Government‑approved ICDs with minimal disruption to fielded interfaces.

III.6 Transition and Operational Cutover

• Build upon existing mission management capabilities
• Knowledge transfer and operational cutover
• Risk identification and mitigation during transition

Section IV: Execution Assumptions and Government Constraints

The following ground rules and assumptions apply to the PATSEMM effort:

• The Government intends to be intimately involved in the incremental definition and prioritization of capabilities for this effort (i.e. product owner), and as such, requires the ability to rapidly pivot vendor development activities (within a few days) in response to operational priorities, not solely software development cycles.
• The Government is seeking solutions that will minimize impacts to existing interface control documents.
• The Government may provide software development and production environments at IL4-IL6, as required. Use of the Government environments is not a requirement.
  • Should a vendor choose to NOT use the Government environments, then Government access to non-Government development libraries and production/test environments is a requirement. Additionally, non-Government software environments must be proven to decrease the risk to the Government. Government access includes auditability sufficient to support cybersecurity assessments, mission assurance, and continuity of operations.
• Vendors can propose to build on top of the existing PTES mission management capability, start anew, integrate/modify existing commercial or Government solutions, or propose any other solution that best addresses Government requirements, constraints and objectives. The Government strongly recommends vendors leverage existing elements of the PTES System such as the Cross Domain Solution. An ICD will be provided to enable this use.

Section V: RFI Questions and Prompts

1. What do you propose to address the items listed in Sections II to IV? Please identify which specific subsections of Section III your solution will address. Include process workflow, automation points, document/requirement assumptions.
2. How does your proposed solution support future PATS capabilities (e.g., additional satellites, waveforms, or transport paths) without re‑architecting core mission management workflows?
3. What experience does your company have with software tools that perform:
   • Payload management (with high TRLs)
   • Optimization techniques
   • At high availability
   • Integration with crypto and real hardware
4. How does your solution support rapid incremental capability insertion with Government oversight?
5. What are the top three mission‑impacting risks in transitioning mission planning and operations from an incumbent provider, and how have you mitigated similar risks in operationally fielded systems?
6. For non-commercial solutions, assume that a minimum of Government Purpose Rights will be required for all aspects of the delivered solution, including source code.
7. Do you have any concerns with integrating your solution into a DoW (Department of War) DevSecOps environment for your development (e.g., Kobayashi Maru (KM))?  The DoW options come with CI/CD tools, access to both cloud development and production environments, cyber security processes and porting between IL4-6.
8. Do you have COTS or proprietary solutions that already can be applied to some or all of these mission planning requirements? Describe these products and how they can be applied in detail.  Which components would you propose as contractor‑owned vs government‑owned?
   • If you are proposing a COTS solution, please describe your knowledge and understanding of the DoW Cybersecurity Risk Management Construct (CSRMC) and its core principles.
   • Are there any concerns with Government Purpose Rights (GPR) being applied to your COTS solution? (Please address source code)
9. Do you participate in existing contracts that can be leveraged by the Government, for example General Services Administration (GSA), Space Enterprise Consortium (SpEC), Other Transaction Authority (OTA), other Best-In-Class (BIC) contracts that may cover the scope of this RFI? If so, provide contract details and a government POC.
10. Briefly describe the Human Engineering approach accompanying the identified capability or solution (if applicable) and/or the organization’s experience designing user-friendly graphical user interfaces.
11. Please provide examples of relevant prior programs or operational deployments.
12. Assumptions as well as cost and schedule Rough Order of Magnitude (ROM) estimates shall accompany each response.

Section VI: Industry Day, Response Format, Submittal Instructions, and Questions

The Government intends to host an industry day at a future date that will provide a demonstration of the mission planning capability achieved to date.  One-on-one meetings will be offered for the purpose of allowing interested vendors to clarify scope and discuss alternative options. 

Response Format – Responses shall be submitted as a white paper in PDF or Microsoft Word for Office 2007 or later compatible format, supplemented with Microsoft Word, Excel, PowerPoint, PDF, or JPG attachments as necessary. Responses shall be prepared so that when printed, they meet the following requirements: 8.5x11 inch paper, single-spaced typed lines, 1-inch margins, 12-point Times New Roman font. Tables may use 10-point font. Pictures are not allowed. Illustrations such as tables, flowcharts, organizational charts, process charts or other similar informational charts may be used. Respondents are responsible for ensuring the legibility of all tables, charts, etc., and should assume that when their response is printed or copied, it will be done in black and white. The Government will not accept company literature or marketing materials in response to this notice. Responses that do not materially address the content of this RFI, to include those that only make inquiries or which provide generic capability statements, will be disregarded.

Respondents may also submit an “optional White Paper” (no more than 5 pages in length) describing how your company’s products and technical expertise can produce and deliver the capabilities specified in this RFI.

Response Classification – All material provided in response to this notice shall be UNCLASSIFIED, non-confidential, and non-proprietary to the maximum extent practicable. Firms providing confidential/proprietary information shall separately and clearly identify and mark all confidential/proprietary information. The Government will take all necessary steps to protect/safeguard any confidential/proprietary information not clearly marked.

Submittal Due Date – Responses are due by 12:00 PM (Pacific Time) on 10 July 2026.

Submittal POCs – Unclassified responses shall be submitted electronically to the points of contact listed below:

1. Scott Lucas, Contracting Officer, at scott.lucas.1@spaceforce.mil
2. Heather Ayres, Contract Specialist, at heather.ayres@spaceforce.mil
3. William Chan, Contract Specialist, at william.chan.5@spaceforce.mil

All inquiries associated with this request must be submitted in writing to the Contracting Officer with a courtesy copy to the Contract Specialists identified above.

Section VII: Disclaimers

THIS IS A REQUEST FOR INFORMATION ONLY. This notice is issued solely for information and planning purposes. It does not constitute a solicitation (Request for Proposal or Request for Quotations) or a promise to issue a solicitation in the future. This notice does not commit the Government to contract for any supply or service whatsoever. Furthermore, the Government is not, at this time, seeking proposals. Respondents are advised that the Government will not pay for any information or administrative costs incurred in response to this notice. The Government will not assume liability for costs incurred by any attendee for travel expenses or marketing efforts. All costs associated with responding to this notice will be solely at the responding party's expense.

Proprietary information, if any, should be kept to a minimum and shall be clearly marked. Please be advised that all submissions become Government property and will not be returned. In order to review RFI response, proprietary information may be given to Federally Funded Research and Development Center (FFRDC) and/or Advisory and Assistance Services (A&AS) contractors working for the Government. Non-government support contractors and their subcontractors may be involved in the review of any responses submitted. Please advise the listed government points of contact in advance of response submission if you do not wish for your submission to be reviewed by non-government support contractors and their subcontractors.

Section VIII: Enclosures

Enclosure 1 –  TRDs and ICDs

• Respondents must request Enclosure 1 documents in writing to the Contracting Officer and Contract Specialists listed above. The Government will then verify the requesting organization's security/facility clearance details and if they are capable of receiving the requested documents.

Enclosure 2 - MIL-STD-188-164C (for public release)

Enclosure 3.a. – DODI 8510.01 (for public release)

Enclosure 3.b. – NIST SP 800-53 rev 5 (for public release)

Enclosure 3.c. - CNSSI No 1253 (for public release)