Industry Questions on ARES DRAFT Solution Solicitation.xlsx
XLSX spreadsheet 63 KB Posted
- Solicitation number
- Not on record
About this file
This document is an industry Q&A file for the Aerospace Readiness Enterprise System (ARES) prototype solicitation, providing detailed responses to 242 technical and procedural questions from potential vendors. The opportunity involves developing a prototype scheduling and training management system for the U.S. Air Force, to be hosted exclusively within the Operations Enterprise Architecture (OpsEA) Salesforce platform at Impact Level 4 (IL4), with a roadmap to transition to IL6.
Key requirements include developing the prototype within 90 days, integrating with systems like ARTEMIS and Envision, supporting pilot training scheduling, and meeting strict technical requirements such as DevSecOps compliance, intrusion detection system integration, and mobile/disconnected operations capabilities. The government will select 2-4 offeror teams for the prototype phase, providing $500,000 per team, with developers required to complete specific Salesforce certifications and training before gaining sandbox access. The prototype is intended to eventually replace legacy systems like PEX and G/TIMS, leveraging modern technologies including potential AI and machine learning capabilities to create an enterprise solution for training and standardization across multiple Air Force commands.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| ARES Update to Industry_10DEC2025.pdf | ||
| ARES Notional Schedule Update to Industry.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Questions with Answers
| ID | Question | Answer |
| 1 | Different parts of your draft solicitation hint at competing/conflicting acquisition strategies. At a high level, are you looking for vendors to: |
a. Provide Salesforce-certified reseller engineering services to build ARES entirely in Salesforce using no/low-code features/data, depending entirely on OpsEA features, roadmap and availability at different security levels, or:
| b. Build a working ARES prototype based on best of breed vendor innovations, that also can run on the Salesforce runtime platform but may also diverge where needed to fulfill requirements | The Government is interested in both (a) and (b) approaches for vendors to use. The approach the vendor chooses should be explicitly addressed in their whitepaper submission to the Final Solution Solicitation. To specify on Part (b), divergance is limited based on OpsEA capabilities. | |
| 2 | What development capabilities and ARES features are provided by / required to be used through OpsEA? |
a. Is the CI/CD pipeline runner / observability / security tools in Threshold #4 provided by OpsEA, or is vendor required to propose that solution?
b. What portion of the IDS capability in Threshold #5 is provided by OpsEA?
c. How does OpsEA provide the identity source and a method for authentication for Threshold #6/7/8? Is this different than the ICAM and Zero Trust strategy in use by ABMS and C3BM?
d. What existing Salesforce data/applications developed by HAF/A3 in OpsEA are contractor solutions required to use?
e. Is contractor solution required to use Salesforce mobile apps or other proprietary solutions? ARES must be developed within the USAF-standard Salesforce platform under the Operations Enterprise Architecture (OpsEA) framework. Development occurs in SDK-governed environments using the Sherpa-guided intake, RFC process (ERD, Flow Catalog, Data Dictionary), and follows the Flosum-based CI/CD release cycle. Capabilities include secure data collection, automation via declarative Flows, dashboards, reporting, and API integrations through COE-approved mechanisms.
a. OpsEA standardizes on Flosum for CI/CD and release management. Use Flosum pipelines for packaging, promotion (Dev→QA→CIT→UAT→Prod), traceability, and rollback. Observability/security monitoring are COE‑managed; vendors should align to these and must not introduce alternate runners without approval. Static code scanning via Checkmarx is required in the release process.
b. Threshold #5 requires integration with enterprise Intrusion Detection System (IDS) and vulnerability management capabilities. OpsEA and the Sherpas provide the standard Salesforce platform-level monitoring and security controls; the prototype must expose application-level logs, events, and configurations to integrate with those controls. In addition, all security telemetry must comply with ATO CSSP-mandated continuous monitoring requirements. Event and audit data produced by the prototype must support ingestion by the Cybersecurity Service Provider (CSSP) for defensive cyber operations. This integration ensures full visibility of OpsEA-hosted applications within CSSP event monitoring and incident response ecosystem.
c. OpsEA provides identity with Okta and SailPoint (SSO + identity lifecycle). ARES must integrate with this enterprise ICAM and implement role‑based access with permission sets, permission set groups, and least privilege.
d. Reuse standard Salesforce objects and Sherpa‑managed shared metadata where applicable. The Sherpa team identifies reusable models during intake/design to reduce duplication and enforce consistency. Any deviations require Sherpa review.
e. Mobile access is supported but not mandated as a threshold. Use of Salesforce mobile is optional and determined by mission need; if used, it must comply with SDK/Sherpa policies and IL4 data handling.
| 3 | Does the requirement to use OpsEA include extending the prototype to enterprise Air Force and Joint/Allied use cases listed under “Extensibility & Scalability”? | Yes, but not for the prototype deliverable. However, offerors should incorporate into their strategy the necessary capabilites to meet these requirements within the production roadmap. |
| 4 | Does OpsEA/Salesforce support IL-6, multi-level security and partner environments, DDIL operations where the salesforce cloud is not available, and other technical requirements requested in the solicitation? Details on these OpsEA capabilities or roadmap to achieve them would be critical to proposing a technical solution that meets the threshold requirements and operates on OpsEA. | OpsEA/Salesforce is forecasted to have IL6 functionality in 12-18 months from now. |
| 5 | Does the ARES proposal and prototype design need to use or match the PEO C3BM DAF Battle Network design? For example, does the proposed solution need to use ABMS DI Network services, security tools, SD-WAN, etc to be considered able to integrate with the DAF Battle Network? | The use of existing DAF BATTLE NETWORK technologies are not thresholds or objectives for the prototype however they may be brought forward within the production roadmap once the prototype is scaled. |
| 6 | The solicitation notes the ARES contractor team will only be evaluated on their solution’s potential to extend to more complex use cases (partners, Joint, DDIL) after conclusion of the prototype period through several whitepapers. Does this mean ARES proposals won’t be evaluated on their ability to extend to these future use cases? | All artifacts submitted in accordance with Instructions to Offerors will be evaluated by the Government. |
| 7 | For future IL4, IL6, and Joint/Partner scaling, does HAF/A3 or PEO C3BM plan to impose a preferred security architecture, such as using Cross Domain Solutions or operating at a single security level (S/REL)? This architectural decision will have significant impacts on complexity, scaling, and cost of the prototype to meet those requirements. | The Offeror's architecture provided in the prototype should demonstrate the capability to scale to meet potential coalition and classified use cases. |
| 8 | The whitepaper requirement refers to DDIL and mobile access together. What is the definition of DDIL use case(s) for ARES - is this just about mobile devices in airplane mode? Each use case below implies a different network topology |
a. Mobile access for a single crew to ARES application to enter data on EFB that doesnt have Wifi or connection to OpsEA cloud (while on the apron, airplane mode, catching up after hours)
b. Continued (hours/days) scheduling/training/evaluation with many aircrew/jets/training sessions at a squadron experiencing intermittent or denied comms
c. Continued Scheduling and sortie generation at hub (safe haven base, many aircraft) and spoke (small chalks of aircraft/airmen) ACE bases amidst intermittent or denied comms
| d. Continued Scheduling and sortie generation between AF, joint and allied units at one or more units across a theater, each experiencing intermittent or denied comms | The Government is not proposing to restrict industries capabilities as it relates to DDIL during the prototype phase. The Government is interested in what capabilities are available within the OpsEA environment. Based on industry response the Government will evaluate the capabilities and refine the DDIL requirement further during the production phase. Mobile devices as defined by the Government include laptops, tablets, and smart phones. | ||
| 9 | Threshold #10 “Capability to schedule up to 160 sorties per day with a goal of accelerating the DAF’s pilot training pipeline” - what is the context of 160 sorties per day, is this a single training squadron? Is 160 unreachable today due solely to G/TIMS and PEX software limitations, or are there flying/training resource constraints you are asking industry to solve? | Presently, 160 sorties are achievable today, for a single training squadron, and to achieve G/TIMS parity this is considered a minimum (threshold) requirement. | |
| 10 | Can the government provide a development instance of OpsEA/Salesforce for the contractor to use offline to speed development, or is all test/development required to be performed on the HAF/A3 hosted platform? | Offerors invited to the prototype phase, will be granted access to the OpsEA/Salesforce sandbox. | |
| 11 | Will access/credentials/environments on the OpsEA platform be provided to the contractor on day 1? | Credentials/environments are provisioned after knowledge verification: certification (Admin, App Builder, etc.) or completion of the SDK Trailmix, plus Flosum training as needed. Sherpa approved access; UAT/Prod are Sherpa‑controlled. | |
| 12 | Will schema / access to Envision/ARTEMIS data be provided to the contractor on day 1? | The ARTEMIS data dictionary and ENVISION OSDK will be provided as part of the Bidder's Library. | |
| 13 | Will the government provide ARES user roles and permissions, or do you want the contractor to research and propose those? | The Government provides role definitions; the contractor implements them with SDK‑compliant permission sets, sharing rules, and least‑privilege enforcement. Profiles are not customized; COE approval is required for any exceptions. | |
| 14 | What government SMEs and OpsEA support resources will be available to the contractor to ask questions, remove blockers, and access required A3 data? | The Government will provide technical support, to include OpsEA SMEs and users during the prototyping phase. | |
| 15 | In the ARES architecture, as defined in the draft, what is the role of Salesforce? Is it intended to act as a primary workflow or operational interface layer? Simlarly, is it intended to serve as the system of record for mission, training, or user records/metadata? | OpsEA is the DAF-owned enclave within Salesforce. Further, ARES will be the System of Record residing within the OpsEA enclave on the Salesforce platform. | |
| 16 | To what extent is Salesforce expected to integrate with the ARES backend data platform (e.g., ingest/export, real-time synchronization, or event-driven updates)? | A prototypes ability to integrate with Envision will be evaluated as an objective criteria. | |
| 17 | Will the Salesforce instance be hosted inside a DoD/GovCloud enclave (IL4/IL5)? If so, what access and/or system-to-system interface mechanisms exist (or are planed) to cross ATO/security boundaries? | OpsEA runs in Salesforce Government Cloud Plus (IL4, FedRAMP High). Cross‑ATO or boundary interfaces must use Sherpa‑approved integration mechanisms (e.g., Named Credentials, Connected Apps) and follow security reviews documented in the RFC. | |
| 18 | Was wondering how/if government shutdown impacts your timeline for execution? | The Government shutdown has negatively impacted the ARES acquisition timeline. An updated acquisition timeline was made available to Industry on 2 December 2025 via SAM.gov. | |
| 19 | Was wondering if there are any updates to solicitation timeline given feedback from the field on the draft? Due to the short period between proposed solicitation and submission we want to be well ahead of the game, and your timeline falls right in the middle of Military Flight Training Conference in San Antonio where our key staff will be heavily engaged. | The Government shutdown has negatively impacted the ARES acquisition timeline. An updated acquisition timeline was made available to Industry on 2 December 2025 via SAM.gov. | |
| 20 | Was wondering if you have any expanded guidance on how the The Offeror’s Teaming Structure element would be evaluated in a proposal, i.e. what attributes bring the most value to the government in this section? | The teaming structure will be evaluated on an offeror's ability to meet at least one of the requirements set forth in 10 U.S.C. 4022. | |
| 21 | Further, would submissions that reflect a solo-company response that covers all elements of the Threshold Requirements and a clear plan to meet all Objective Criteria be rejected? | No, so long as the offeror meets at least one of the requirements set forth in 10 U.S.C. 4022. However, based on extensive market research, the Government does not believe any single offeror can successfully meet all of the Government's ARES requirements. | |
| 22 | Was wondering if there is expanded guidance on Threshold Requirement #1 in terms of hosting and developing within the Operations Enterprise Architecture (OpsEA) platform? I want to ensure I fully understand all elements associated with compliance with this requirement. | Any successful proposal shall demonstrate the capability for the ARES application to be developed and hosted within the OpsEA/Salesforce platform. | |
| 23 | Further, how is Threshold Requirement #1 juxtaposed against the minimum requirements for working within the OpsEA Salesforce development sandbox? |
| Given the specified minimum requirements necessary to access the Salesforce sandbox, understanding expectations on the difference between hosting and exclusive development within Salesforce (front end and back end) versus front end compatibility with Salesforce is important for us to understand prototype solution architecture. Furthermore, understanding the driving factors behind the Salesforce requirement help our understanding of both the prototype and the production solutions. | Hybrid architectures are only allowed in situations where OpsEA capabilties are unable to meet the ARES requirements with Sherpa endorsement. All core logic should run on-platform. External microservices may only be used with Sherpa approval, ATO documentation, and strict integration controls; otherwise compute‑intensive tasks must be implemented with Apex/Flows/Platform Events. Additional information can be found in question #142. | ||
| 24 | The government states “All significant participants in the transaction, other than the Federal Government, are small businesses (including small businesses participating in a program described under section 9 of the Small Business Act (15 U.S.C. § 638)) or non-traditional defense contractors” Please clarify if this means that only small businesses will be considered as primes. If this is not the case, kindly provide clarification in the document or answers to questions. | This acquisition is not specifically set aside for small business. This is only one of the four factors associated with 10 U.S.C. 4022. Prime offerors will be evaluated to determine whether they meet at least one of the criteria called out in this code. | |
| 25 | As part of the Threshold Requirements ID# 1 the Government is requesting the prototype be hosted and developed on the OpsEA platform. Will the Government provide Industry access to this environment as part of the prototyping requirement? This will level the playing field since any company with existing access to the OpsEA platform has a distinct advantage. | Yes, the Government will provide the process to access the OpsEA/Salesforce environment to offerors who have met the training requirements necessary for acces to the sandbox for development of their respective prototypes. This will be done concurrently for all offerors participating in the prototype phase. | |
| 26 | The Government is requesting the prototype shall be built at the IL4 level. If the prototype we are currently using is a production application that is already approved and runs in an IL4 environment, is that sufficient? Or does the prototype have to be built on the OpsEA platform at the IL4 level? | The prototype shall be developled and deployed within the OpsEA/Salesforce IL4 enclave. | |
| 27 | Can the Government please expand on the requirements and/or provide an example of what is required for the Intrusion Detection System (IDS)? Should this IDS be software based and built into the prototype or is the IDS handled by the network (OpsEA platform) and monitoring network traffic? | Threshold #5 requires integration with enterprise Intrusion Detection System (IDS) and vulnerability management capabilities. OpsEA and the Sherpas provide the standard Salesforce platform-level monitoring and security controls; the prototype must expose application-level logs, events, and configurations to integrate with those controls. In addition, all security telemetry must comply with ATO CSSP-mandated continuous monitoring requirements. Event and audit data produced by the prototype must support ingestion by the Cybersecurity Service Provider (CSSP) for defensive cyber operations. This integration ensures full visibility of OpsEA-hosted applications within CSSP event monitoring and incident response ecosystem. | |
| 28 | For submission on this opportunity, is it required to have a nontraditional defense contractor or no-profit research institute serve as the prime for this effort? | No, so long as the prime offeror meets at least one of the requirements set forth in 10 U.S.C. 4022. | |
| 29 | For submission on this opportunity, can we submit a team that has a nontraditional defense contractor or no-profit research institute serve as the sub to a significant extent? | Yes. The Government will not dictate a particular teaming structure. However, an offeror's submission must show compliance with 10 U.S.C 4022. | |
| 30 | Can the Government please expand on the "significant extent" the nontraditional defense contractor or no-profit research institute must perform. Does the "significant extent" have to be a minimum of 20%, 30%, or more than 50%? A percentage that represents the "significant extent" would remove any ambiguity. | Significant extent is not determined by a specific percentage. Each offeror utilizing this rational for acceptance into the prototype phase will be required to annotate the extent to which the non-traditional defense contractor is participating in the prototype and the significance of their respective contribution to the overall final deliverable. The Agreements Officer will make the final determination on this evaluation criteria. | |
| 31 | Is there a security clearance requirement for this effort? If so, is the clearance required by only the prime or by the prime and subcontractors? | For the prototype there will be no DD254 as the prototype will be built at the IL4 level. However, for the production agreement a DD 254 will be issued at the SECRET level to the prime. The prime will flow this requirement down to any team members as necessary. | |
| 32 | The "Minimum Qualifications for developers for working within the OpsEA Salesforce development sandbox" list multiple knowledge validation and training items. Will the Government make these available to Industry prior to the solicitation release? As it currently stands, this requirement seems to favor companies and individuals that are currently working in the OpsEA Salesforce development sandbox. Recommend the Government relax this requirement to allow for new competitors and companies to submit solutions. | No, it is the responsibility of the offeror and their respective team members to have these certifications in place to participate in this acquisition. These requirements for certifications will be outlined within the OpsEA SDK which will provided in the Draft Bidder's Library and/or Final Solicitation to all Industry at one time. | |
| 33 | The Government states, "Upon receipt and evaluation of solution proposals from offerors the Government will select between two (2) and four (4) offeror teams for the OTP. The prototyping phase will last approximately three (3) months and will include minimal funding from the Government (~$500K for each prototype) and multiple check-in points to determine progress". Does the ~$500K for each prototype refer to a single payment of ~$500K for delivery of one prototype over a 3 month timeframe or can the offeror deliver more than one prototype for multiple ~$500K payments. For example, can the offeror submit 2 prototypes over the 3 months for a total of ~$1M in payments? | The Government will pay offeror teams $500K for their single prototype delivery. Additional prototype deliveries by the same offeror team will not result in additional $500K payments. | |
| 34 | Row intentionally left blank. | Row intentionally left blank. | |
| 35 | Would the Government please consider allowing font smaller than 10-point in images? | No. | |
| 36 | Can you please provide more details on the “Operations Enterprise Architecture (OpsEA) platform”? |
a. Our software is provided as a pre-STIG’d, hardened container suitable to be deployed to any OCI-compliant (Open Container Initiative) runtime. This allows our software to run in any cloud, private data center, and at the edge. Does the OpsEA platform provide a Kubernetes or other container runtime capability?
b. What is the underlying data management component of the OpsEA platform?
c. What operational services are available on the platform? OpsEA is the USAF‑standard Salesforce platform governed by the SDK and Sherpa process: IL4 hosting, Sherpa gating, Flosum CI/CD, security scans, and release governance. It provides a managed path from intake to production for A3 mission apps.
a. All components must run natively within Salesforce per SDK policy; external compute requires Sherpa approval.
b. Data within OpsEA is managed using standard Salesforce platform capabilities, including shared metadata models, governed data dictionaries, entity-relationship diagrams (ERDs), and version-controlled changes managed through Flosum. All integrations and schema modifications must follow Sherpa-approved patterns and undergo design review. In addition, OpsEA data is federated through an integration with Envision, the centralized Air Force data hub for all Salesforce environments, enabling enterprise-wide visibility, analytics, and data sharing across A3 and other mission applications.
c. Operational services include Sherpa intake and help desk support, Sherpa architecture review, Flosum release orchestration, Checkmarx scanning, and platform health/optimizer practices. Data ingestion may use Envision or other Sherpa-approved import tools. In addition, all standard Salesforce operational services are available within OpsEA, provided they are FedRAMP-authorized and approved by the Sherpas for use within the IL4 environment.
37 How can an organization bringing an innovative, new technology to the fight learn more about existing systems like Puckboard and Patriot Excalibur (PEX), along with others like G/TIMS?
a. Can you lease point us to recorded demonstrations, or individuals who can show the existing capabilities?
b. How can we review the architecture of the underlying technologies which power these solutions? a) The Government will not provide information that could influence prototypes based on legacy scheduling systems. However, user experience artifacts/resources will be provided in the Bidder's Library to aid in domain understanding.
b) The Government will not provide architectural diagrams for legacy systems as they will not pertain to this acquisition.
| 38 | Can you please provide details of the mechanisms planned for integrating with broader DAF BATTLE NETWORK? | ||
| a. If this is still in the planning/design phases, portions of our solution can help simplify and accelerate this. Which individuals can you connect with to help with these aspects? | It is too early in the acquisition phase to consider this question. Further, the DAF BATTLE NETWORK is still defining requirements for integration of various C2 systems. | ||
| 39 | To encourage and enable participation from non-traditional partners, will the government please consider waiving the facility clearance requirement for non-tranditional partners? | There is not a facility clearance level requirement for the prototype phase. A DD 254 will be issued for the production phase which will require a SECRET facility clearance. Further, it is not accurate to assume that all non-traditional offerors are without a facility clearance. | |
| 40 | Will the government please confirm that a Table of Contents page does not count towards the 10-page limit? | Cover pages, acronym lists, and tables of content will not count against the overall page count. | |
| 41 | Will the government please provide what specific company information should be provided on the cover page? | Company name, CAGE code, POC, and contact information. | |
| 42 | The DDIL plan requires stating how long the system can operate disconnected before resync. Is there a minimum threshold of days the Government expects? | The Government is not proposing to restrict industries capabilities as it relates to DDIL during the prototype phase. The Government is interested in what capabilities are available within the OpsEA environment. Based on industry response the Government will evaluate the capabilities and refine the DDIL requirement further during the production phase. | |
| 43 | Section 1.0 of the Prototype Requirements states that “The prototype shall be completed and available for inspection and use no later than 90 calendar days after contract award.” Can the Government clarify whether the 90-day performance period begins at the date of contract award, or upon the contractor’s receipt of access to the OpsEA Salesforce development environment (sandbox)? Since environment access requires Government approval and developer certifications, starting the clock at award may compress the actual development window significantly. | The 90 day performance period will begin once the awardee has access to the OpsEA/Salesforce development environment. | |
| 44 | The Prototype Requirements (Extensibility & Scalability) direct contractors to deliver a roadmap (NTE 3 pages) outlining the plan to transition from IL-4 to IL-6, including milestones and time required for this transition. Since the system must be hosted on the OpsEA Salesforce platform, and Salesforce is responsible for obtaining IL-6 authorization/capabilities, can the Government clarify what level of detail or assumptions contractors are expected to provide? Specifically, should the roadmap focus only on contractor-controlled activities (e.g., data segregation, configuration, integration steps) rather than Salesforce-controlled IL-6 certification timelines that are outside of contractor influence? | The roadmap should focus on the offeror's workstreams to achieve IL6 compliance. Specifically, the Government is interested in evaluating your understanding of the process to acheive certification and what steps you will take when developing within the IL4 partition to reduce rework when migrating to the IL6 environment. | |
| 45 | FOSS Microservices Integration with OpsEA: | ||
| Given that threshold requirement #1 mandates OpsEA Salesforce platform, can offerors propose a hybrid architecture that leverages existing Free and Open Source Software (FOSS) based microservices built on technologies like Node.js, Python, MongoDB, and PostgreSQL as external services integrated with the OpsEA platform? Or must ALL application logic, including data processing and computational services, reside within Salesforce and use Salesforce offerings? This is particularly relevant for compute-intensive operations like OCR processing, AI scheduling optimization, and real-time conflict resolution that are traditionally better suited to containerized microservices. | Hybrid architectures are only allowed in situations where OpsEA capabilties are unable to meet the ARES requirements with Sherpa endorsement. All core logic should run on-platform. External microservices may only be used with Sherpa approval, ATO documentation, and strict integration controls; otherwise compute‑intensive tasks must be implemented with Apex/Flows/Platform Events. | ||
| 46 | Salesforce Service Limitations at IL-6: | ||
| What specific Salesforce services/features are currently confirmed as NOT available at IL-6? This is critical for ensuring compliance with threshold requirement #3. | To be determined by federal agencies when IL6 achieved. | ||
| 47 | Legacy System Data Migration: | ||
| Will the Government provide access to existing PEX/Puckboard/G-TIMS data formats and migration tools, or is data migration out of scope for the prototype phase? | Data migration is out of scope for the prototype phase. | ||
| 48 | ARTEMIS/MILPDS API Documentation: | ||
| Will the Government provide API documentation, sandbox access, or interface specifications for ARTEMIS and MILPDS systems during the prototype phase? What authentication mechanisms are required for these integrations? | API documentation for Salesforce platform is publicly available through Salesforce and Government Cloud resources. Sandbox access will be provided following successful completion of SDK knowledge validation and Sherpa intake approval. The OPS EA team does not own or administer the MILPDS system; integration with MILPDS will rely on existing approved interfaces and data services managed by the owning authority. Standard Salesforce authentication mechanisms, including Named Credentials, Connected Apps, and OAuth 2.0, will be used for all authorized system integrations. | ||
| 49 | OpsEA SDK and Sandbox Access Timeline: | ||
| When will offerors receive access to the OpsEA platform SDK and sandbox environment for development? Is this access contingent on staff completing all validation requirements first, or can provisional access be granted while certifications are in progress? | The OpsEA SDK will be provided within the Bidder's Library with the final solicitation. Offerors will be provided access to the development sandbox upon agreement award or soon thereafter and that is when the delivery clock will begin. Access cannot be provided until all training certifications have been completed and verified by the Government. | ||
| 50 | IDS Integration Requirements: | ||
| For threshold requirement #5, what specific IDS systems must be integrated, and are there preferred vendors or Government-furnished IDS solutions available on the OpsEA platform? | Threshold #5 requires integration with enterprise Intrusion Detection System (IDS) and vulnerability management capabilities. OpsEA and the COE provide the standard Salesforce platform-level monitoring and security controls; the prototype must expose application-level logs, events, and configurations to integrate with those controls. In addition, all security telemetry must comply with ATO CSSP-mandated continuous monitoring requirements. Event and audit data produced by the prototype must support ingestion by the Cybersecurity Service Provider (CSSP) for defensive cyber operations. This integration ensures full visibility of OpsEA-hosted applications within CSSP event monitoring and incident response ecosystem. | ||
| 51 | IL-4 ATO Timeline and Provisional Approval: | ||
| What is the expected timeline for IL-4 ATO approval, and will provisional ATOs be accepted for prototype demonstration purposes? | The OpsEA platform has already achieved IL4 accreditation and ATO. A CTF will be required for the prototype delivery and requirements will be documented in the final solution solicitation. | ||
| 52 | DDIL Operational Scenarios: |
Can the Government provide specific use cases or operational scenarios for DDIL (Denied, Degraded, Intermittent, Limited) operations to better scope the offline capability requirements? Specifically:
- Expected duration of disconnected operations
- Data volume during disconnected periods
| - Priority functions that must remain available offline | The Government is not proposing to restrict industries capabilities as it relates to DDIL during the prototype phase. The Government is interested in what capabilities are available within the OpsEA environment. Based on industry response the Government will evaluate the capabilities and refine the DDIL requirement further during the production phase. | |
| 53 | Objective Requirements Prioritization: | |
| Of the 67 objective requirements, can the Government indicate the top 10-15 highest priority items that would most influence the prototype evaluation scoring? | No, it is at the discretion of each offeror to present their respective best solutions for evaluation by the Government. | |
| 54 | Performance Testing Environment: |
For the 160 sorties/day requirement (Objective #10), will the Government provide:
- Representative test data and scenarios?
- Expected user concurrency levels?
| - Performance benchmarks from current systems? Or should offerors generate synthetic data for demonstration? | The Government will provide representative data for evaluation of the prototype. We will also provide access to users and SMEs during development of the prototype to facilitate accuracy and efficacy of the final deliverable. The expected user concurrency levels will be further refined during the prototype phase. Regarding the performance benchamrk, this information will be provided in the Bidder's Library. The verbiage of "Industry Standards" will be removed from the Final Solicitation. | |
| 55 | Existing Capability Risk Reduction Credit: | |
| If an offeror has existing, production-proven scheduling and training management systems with similar capabilities (currently deployed but not on OpsEA), how will this be evaluated in terms of "lowest risk and greatest capability"? Will demonstrated migration paths from existing systems be considered favorably? | No, demonstrated migration paths will not be viewed favorably. Offerors are required to conduct development and deployment activitie for the ARES application within the OpsEA enclave. | |
| 56 | Prototype Fidelity Expectations: | |
| Should the 90-day prototype demonstrate full production-ready capabilities for all 13 threshold requirements, or is proof-of-concept implementation acceptable for certain features, with detailed roadmaps for production completion? | While not necessary to achieve total MVCR capabilities with the prototype, all identified threshold criteria shall meet the stated definition of a single MVP as outlined within the Instruction to Offerors. Proofs of concepts do not meet the MVP definition as provided by the Government. | |
| 57 | Evaluation Scope for Multi-Squadron Operations: | |
| Will the prototype evaluation include only single squadron operations at AETC UPT, or should the prototype demonstrate multi-squadron coordination and resource sharing capabilities? | The Government is not restricting offeror's proposals to one squadron. However, this will be a future requirement to be incorporated in the production phase as defined by the need for scalability. | |
| 58 | Path to Production Contract: |
Is there an anticipated path from prototype OT agreement to production contract? If so:
- What are the expected transition criteria?
- Will successful prototype performers receive preferential consideration?
| - What is the anticipated timeline for production contract award? | Yes, the Government contemplates awarding one (1) production agreement from the prototype phase. Only vendors who have been awarded a prototype agreement will be considered for a production agreement. Given the Government shutdown the timeline for award of a production agreement will be delayed. However, the Government will provide a revised acquisition milestone schedule with the final solicitation. As for transition criteria, the Government will evaluate each prototype submittal and data deliverables and determine which offering provides the lowest risk and greatest value to the Government based on the stated requirements. Moreover, pursuant to 10 U.S.C. 4022 only a vendor who successfully delivers a prototype will be eligible for a production award. | |
| 59 | DevSecOps Pipeline Specifications: | |
| For threshold requirement #4, are there specific DevSecOps tools or platforms mandated for use on OpsEA, or can offerors propose their own CI/CD pipeline that meets auditability and ATO compliance requirements? | Yes, there are specific DevSecOps platforms mandated for use on OpsEa and this information will be provided within the Bidder's Library. | |
| 60 | Mobile Platform Support: | |
| For Objective #1 (mobile device access/EFB), are there specific mobile platforms (iOS/Android) or EFB systems that must be supported, or is web-based responsive design sufficient? | While not necessary for the prototype phase, given the Government's DDIL requirement a strategy that employs a web-based approach will not be accepted by the Government. | |
| 61 | Real-time Collaboration Requirements: |
Several objectives imply real-time updates and notifications. Are WebSocket connections permitted through the OpsEA platform for real-time features, or must all updates use polling/REST APIs?
| • | Will 'real-time' time or 'near-real-time' time data updates be required? | ||
| • | If so, what services are within OpsEA that we can use to meet this requirement? | ||
| • | In the event there are no OpsEA services to support ‘real-time' or 'near real time’ communications, will Polling services with 300ms-500ms be considered acceptable tollerations? | For the Prototype Phase, data publishing to Envision should occur no less than twice a day. Notifications should occur in near real-time. Referencing polling, the Government is not going to dictate acceptable tolerances at this time. The Government is interested in evaluating industry capabilities in this area. | |
| 62 | Will mock data be provided for the OpsEA Salesforce sandbox? If so, what types of data will be provided? | Some sample data will be provided by the Government. This will be provided to successful offerors selected to enter the prototyping phase. | |
| 63 | What acquisition path will Kessel Run follow as an outcome of the prototype phase? | The Government contemplates award of a single production other transaction agreement as a result from the prototype other transaction. Reference Government response to question #58. | |
| 64 | What rollout strategy for enterprise-wide adoption will Kessel Run/USAF employ after AETC is onboarded? | The Government is not going to discuss this topic in this forum. | |
| 65 | In what sequence will other MAJCOMs and other internal clients implement the proposed system? | The Government is not going to discuss this topic in this forum. | |
| 66 | What is the timeline for rolling out the proposed system to other MAJCOMs and other internal clients? | The Government is not going to discuss this topic in this forum. | |
| 67 | Following the 90-day implementation period, what is the timeline for the evaluation of prototypes? | Current schedule indicates 60 days to award of the production agreement. However, the Government will work to reduce this timeline to the greatest extent possible. | |
| 68 | Following the 90-day implementation period, will Kessel Run move forward with only one vendor? Will that vendor(s) only be selected from the pool of shortlisted vendors that completed the prototype? | The Government contemplates award of a single production other transaction agreement as a result of the prototype other transaction. Yes, any agreement awarded by the Government will only be to an offeror who has participated in the prototype phase. | |
| 69 | If sub-contractors are unable to perform as expected, will the prime contractor have the opportunity to make changes to, or augment, their team to perform the required services? | Yes. The Government will not restrict a offeror's structuring as long as it remains compliant with 10 U.S.C. 4022 through the duration of the Agreement(s). | |
| 70 | We understand the usage of instant messaging/group chats by USAF. Can Kessel Run expand on the required workflow for this integration? Will this integration be evaluated by a select group of people from AETC? | The Government will provide user experience data in the Bidder's Library. Offerors are encouraged to review this data and provide thier recommended solutions for consideration. | |
| 71 | Kessel Run has requested the following integrations: Envision (ARTEMIS); Mapping Programs (Google Maps); Instant Messaging/group chat (Mattermost, Slack); Other systems or databases to gather necessary information for asset assessment/onboarding; Data Link for personal data from external systems (MILPDS); IDS. Please share the format in which the data feeds for each integration will be provided. | ARTEMIS information will be provided by the Government within the Bidder's Library. Formats for integration with other applications will be at the discretion of the offeror. | |
| 72 | Has Kessel Run/USAF had success with or a level of familiarity with a particular IDS in the past? | The IDS will be provided through OpsEA. Historical use by Kessel Run is not applicable at this juncture. | |
| 73 | Kessel Run has outlined the need for the system to ensure compliance “with regulations and standards throughout the assessment and onboarding process” in line item 38 of the Prototype Requirements document. Can Kessel Run share a document outlining those regulations and standards? | Yes, the Government will provide this information within the Bidder's Library. | |
| 74 | Kessel Run has outlined the need for the system to monitor and track “training progress to ensure compliance with regulatory and organizational requirements” in line item 41 of the Prototype Requirements document. Can Kessel Run share a document outlining those regulatory and organizational requirements? | Yes, the Government will provide this information within the Bidder's Library. | |
| 75 | Kessel Run has outlined the need for the system to “Build pre/post event processes to meet requirements in AFIs” in line item 52 of the Prototype Requirements document. Can Kessel Run share a document outlining the requirements in AFIs? | Yes, the Government will provide this information within the Bidder's Library. | |
| 76 | Kessel Run has outlined the need for the system to automate “risk calculation, customizable at the unit level and based on factors defined by AFIs” in line item 53 of the Prototype Requirements document. Can Kessel Run share a document that lists the risk factors defined by AFIs? | Yes, the Government will provide this information within the Bidder's Library. | |
| 77 | Kessel Run has outlined the need for the system to conduct “comparative analysis to benchmark training performance against industry standards or organizational benchmark” in line item 49 of the Prototype Requirements document. Can Kessel Run share the list of organizational benchmarks it will use for this comparative analysis? What industry standards is Kessel Run referring to? Has Kessel Run conducted research into industry standards? If so, what industry standards are preferred? | This information will be provided in the Bidder's Library. The verbiage of "Industry Standards" will be removed from the Final Solicitation. | |
| 78 | What needs to be included in the Minimum Viability Capability Requirement (MVCR)? For how many MAJCOMs will the MVCR be required? | The intent is for the MVCR criteria to be identified and negotiated prior to the prodution OTA based on need and funding. MAJCOM deployment will be determined at a later date. | |
| 79 | Does the Salesforce OpsEA platform have multi-tenant capability with RBAC permissions to enable teams to scope permissions and protect intellectual property? | Yes. Multi‑tenancy is supported with strict RBAC via permission sets, sharing rules, private OWDs, and least‑privilege access. IP and data partitioning is enforced through Sherpa‑approved models. | |
| 80 | What is the shape and format of the Envision (ARTEMIS) data? Can you provide some examples? | The ARTEMIS Data Dictionary will be provided in the Bidder's Library. | |
| 81 | What authentication mechanism does Envision require? To integrate with Envision (or any other second/third party), our application will need to authenticate with the other service. To estimate effort, we would like to know the architectural requirements of the external service(s). Further, the scope of data authorization will also impact the requirements. Will all users of the application be authorized to view all data from the Envision service? If not, will Envision enforce authorization or would that need to be enforced by our application. | The Government will work with successful offeror's to remove Information Assurance adminstrative blockers. It is an offeror's responsibility to develop an effective integration utilizing the OSDK developed and published by the Envision team. The Envision OSDK will provided as part of the Bidder's Library. | |
| 82 | What is the scope for recommended conflict resolutions? Is the application able to recommend changing other student schedules? | The Government is interested in evaluating what industry solutions exist for conflict resolution. As for the second part of the question, the Government's response is, yes. | |
| 83 | Section 3.0, ID #15 states “Supports AI-enhanced scheduling that creates events and assigns individuals based on priorities.” Are the priorities known and static? Do you have any examples? For example, a unit may want to prioritize sorties with a takeoff time before 1500, or they may prioritize certain event types over others. Have stakeholders and SME’s performed this analysis to identify and rank these priorities or is this work that needs to be accomplished? | The Government will further define this requirement prior to the Production phased dependent on the AI being used by the offerors. | |
| 84 | Do you have specific industry standards in mind? Can you share some examples of organizational benchmarks? | This information will be provided in the Bidder's Library. The verbiage of "Industry Standards" will be removed from the Final Solicitation. | |
| 85 | What is the approximate time commitment for completing Salesforce Sandbox access requirements? | The Government requires offerors to have completed the requisit training/certifications prior to gaining access to the OpsEA/Salesforce sandbox. |
The training is self-paced so individual times may vary.
| 86 | Besides CMMC, what standard applies to software related to scheduling and training management? ISO 20000-1 pertains to a service management system and does not seem relevant in this case. What affordances are you making for small businesses who cannot acquire an external audit, such as for CMMC Level 2 for the purposes of certification prior to the proposal due date? What does the Salesforce OpsEA platform provide in terms of pipeline gates for static code analysis? | The Government's requirement is for, at a minimum, the prime have an industry standard quality management system. The request from the Government was for the offeror to provide copies of quaility system certifications for review not evaluation. ISO 9001-15 is also an applicable quality system that would be accepted by the Government. ISO 20000-1 is relevant for the production phase of the program. |
| 87 | Does the ARES prototype environment require direct development within the existing OpsEA (Salesforce) sandbox, or will hybrid integration (Salesforce + Azure IL4 APIs) be acceptable for the initial 90-day prototype phase? | Hybrid architectures are only allowed in situations where OpsEA capabilties are unable to meet the ARES requirements with Sherpa endorsement. All core logic should run on-platform. External microservices may only be used with Sherpa approval, ATO documentation, and strict integration controls; otherwise compute‑intensive tasks must be implemented with Apex/Flows/Platform Events. |
| 88 | Can the government confirm whether FedRAMP Moderate (IL4) authorization inherited through Azure Government or Salesforce GovCloud will meet ARES prototype security requirements, or should we plan for additional IL6 enclave provisioning during prototype execution? | The requirement for the prototype phase is for the application to be operational within the OpsEA/Salesforce IL4 partition. The IL6 requirement will be developed within the production roadmap. However, a migration strategy to IL6 shall be incorporated into the offeror's prototype submission for evaluation by the Government. |
| 89 | We currently host our TRL 9 application at Impact Level 5 in operational use at 70+ squadrons under the US Air Force. Considering that this is not a new start, can we take our existing product hosted on SecondFront Systems and deploy that within Salesforce’s boundaries without refactoring our existing codebase? | The Government is unable to answer this question. |
| 90 | Some algorithms we use require mathematical solvers that are unobtainable within the OpsEA ecosystem. Building any kind of automated solution within the OpsEA ecosystem becomes prohibitively difficult without these solvers. Are there options within the OpsEA platform to facilitate the use of such tools? | External solver libraries are not allowed off‑platform unless packaged as an approved managed component. Otherwise implement algorithms in Apex/Flows, or seek Sherpa approval for any external compute. |
| 91 | We are working on adding AI modules to our platform to create GenAI-based thinking partners to aid pilots, schedulers and squadron leaders manage operations from strategic planning to day of execution. Such models have to be finetuned for optimal performance. How would OpsEA accommodate deploying mature models that exist outside of the Salesforce ecosystem? | GenAI/AI modules must run within IL4 or integrate through Sherpa‑approved endpoints. Off‑platform models/inference require Security Risk Review, and data controls. |
| 92 | Can part of the application be deployed on Heroku and still be considered as being hosted and developed on OpsEA? | No. Heroku or other PaaS components are outside the IL4 enclave and require separate accreditation. The prototype must be hosted and developed on OpsEA Salesforce. |
| 93 | Does the OpsEA platform accommodate the usage of custom-built applications deployed through the AppExchange? | Yes, if Sherpa‑approved. Managed packages from the AppExchange may be installed following Security Risk Review and documentation in the RFC |
| 94 | Products like Heroku, AppExchange and Mulesoft are considered as “external connections”, but are interoperable. Will they inherit the Fedramp status of OpsEA? | Heroku and MuleSoft do not inherit OpsEA’s FedRAMP by default. AppExchange packages are evaluated individually; only Sherpa‑approved components operate under the platform’s compliance boundary. |
| 95 | Does the OpsEA platform equate to Salesforce’s Gov Cloud? Can you share any details on the OpsEA platform architecture? | Yes. OpsEA is hosted on Salesforce Government Cloud Plus (IL4/FedRAMP High) with USAF‑specific SDK governance, Sherpa intake and operations. |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .