DRAFT_ARES Instruction to Offerors.pdf

Kessel Run Flight Operations (Flight Ops)

Aerospace Readiness Enterprise System (ARES)

Entry to Prototype Phase – Instruction to Offerors

INSTRUCTION TO OFFERORS:

For consideration to enter the ARES prototyping phase, Offerors will be required to provide a written response, not to exceed ten (10) pages for evaluation by the Government; a cover page that includes company information will not be included in the ten (10) page limit. The written response should be provided in Portable Document Format (PDF) to the Agreements Officer, Ms. Lauren Cheslofska, lauren.cheslofska@us.af.mil, the Contract Specialists, Ms. Shamieka Gilmore-Williams, smamieka.gilmore-williams@us.af.mil, and Capt Leonardo Dominguez, Leonardo.dominguez.1@us.af.mil.

Written responses should be formatted using New Times Roman font no smaller than 12-point. Margins should be one (1) inch both sides and top and text should be single spaced. Fold out pages will be counted as two (2) pages. Text in tables and graphics should be no smaller than 10-point. The due date for written responses shall be provided to the individuals identified in this document on, or before, the due date/time published in this release.

Reponses should include the following information for evaluation by the Government.

1. Offerors compliance with 10 U.S.C. § 4022, Authority of the Department of Defense to carry out certain prototype projects

2. Offeror’s teaming structure

3. Offeror’s proposed prototype solution

4. Offeror’s Quality Management System and/or IT Management System

5. Offeror’s compliance with minimum qualifications for working within the OpsEA Salesforce development sandbox

Offeror submittals will be evaluated IAW with the methodology outlined in this document. Submittals greater than ten (10) pages will be considered non-responsive and the Government will eliminate that Offeror from further consideration. Offerors are encouraged to focus the content of their white papers on their respective technical approach to meeting the prototype threshold requirements however, all requirements in this document are to be addressed within the Offeror’s submittal.

THRESHOLD REQUIREMENTS:

ID # Type Description 1 Technical The prototype shall be hosted and developed on the Operations Enterprise Architecture (OpsEA) platform. Proposals that do not incorporate this requirement will be determined non-responsive.

mailto:lauren.cheslofska@us.af.mil mailto:smamieka.gilmore-williams@us.af.mil mailto:smamieka.gilmore-williams@us.af.mil mailto:Leonardo.dominguez.1@us.af.mil

2 Technical The prototype shall be built at the IL-4 level.

3 Technical The prototype shall not use any cloud services or components not forecast to be available at the IL-6 level.

4 Technical The prototype shall offer auditability, reporting, and platform ATO compliance as part of a CI/CD, DevSecOps hardened pipeline.

5 Technical The prototype shall integrate an Intrusion Detection System (IDS) and cyber security vulnerability to conform to OpsEA platform requirements.

6 Accessibility The prototype shall be designed for access control, to include defined user roles with associated permissions.

7 Accessibility The prototype shall enable systems/data access to be determined by user role.

8 Accessibility The prototype shall provide the ability for authorized users to assign or remove roles and permissions.

9 Syllabus

Management The prototype shall support building and managing formal training syllabi.

10 Scheduling The prototype shall support the following event scheduling capabilities: Assigning an individual to a location/resource to accomplish an event.

11 Scheduling The prototype shall support verifying individual and resource availability and configuration.

12 Scheduling The prototype shall support allowing the ability to create, copy, and edit event details in calendar view.

13 Scheduling The prototype shall enable the capability to build, administer, and track routine qualification.

EVALUATION CRITERIA:

Offeror’s written proposals will be evaluated on compliance with this document. Specifically, Offerors are required, at a minimum, to provide information supporting the following:

Compliance with 10 U.S.C. § 4022: Offerors shall provide their rationale for compliance with this requirement to be evaluated by the Agreements Officer. Offerors shall claim compliance in at least one area of the requirement for consideration to participate in the prototype phase. Final determination will be made by the Agreements Officer.

Offeror’s Teaming Structure: Offerors shall provide a matrix or table with their team composition identifying, at a minimum, company names, facility clearance level, and what portion of the prototype effort they would be contributing to.

Offeror’s Proposed Prototype Solution: Offeror’s shall provide a technical response to the Government’s threshold (minimum) requirements for a prototype deliverable which shall meet the Minimum Viable Product (MVP) definition. Responses should provide details of how their proposed solution meets each of the threshold requirements outlined in this document and whether these capabilities already exist within the base software solution or whether they would need to be developed.

Offerors should not assume the Government has any prior knowledge of the individual or collective capabilities of the Offeror’s products, or those of their respective team members.

NOTE: MVP Definition: An early, basic version of a product that meets the minimum necessary requirements for use but can be adapted and improved in the future, especially after customer feedback.

Offeror’s Quality System: Offerors shall identify what quality system(s) they employ for software development (e.g., ISO 9001, ISO 20000-1, CMMC). Offerors shall also identify what quality system(s) their team members utilize.

OpsEA Minimum Requirements: In order to participate in the prototype phase, Offerors shall demonstrate they have staff with the requisite minimum requirements to work within the OpsEA Salesforce sandbox. Offerors shall provide the names and job titles of those individuals who meet the minimum requirements to operate within the OpsEA Salesforce sandbox and what certifications/training they have successfully completed.

OT PROTOTYPE EVALUATION METHODOLOGY – PROTOTYPE ENTRY PHASE:

The following methodology will be utilized by the Government when evaluating written proposals from Offerors. The Government reserves the right to award more than one prototype agreement or none at all. Offeror’s proposal will be evaluated on the following elements and which proposal demonstrates the lowest risk and greatest capability to the Government. Cost/Price and past performance will not be evaluation factors for award of a prototype agreement.

OT Prototype Evaluation Methodology – Prototype Entry Phase Criteria Evaluation Methodology

1. There is at least one non-traditional defense contractor or non-profit research institution participating to a significant extent in the prototype project. The Government Agreements Officer will determine the definition of “significant extent” as it relates to this requirement and whether the offeror meets this standard. Pursuant to 10 U.S.C. § 3014, the term “non-traditional defense contractor,” with respect to a procurement or with respect to a transaction authorized under 10 U.S.C. § 4021 or 4022 means, any entity that is not currently performing and has not performed, for at least the one-year period preceding the solicitation of sources by the Department of Defense for the procurement or transaction, any contract or subcontract for the Department of Defense that is subject to full coverage under the cost accounting standards (CAS) prescribed pursuant to §1502 of title 41 and the regulations implementing such section.

2. 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, or

3. At least one third (1/3) of the total cost of the prototype project is to be paid out of funds provided by sources other than the Federal Government.

Each Offeror Team shall demonstrate, in writing as part of their white paper submittal, how they meet one or more of the requirements set forth in 10 U.S.C. § 4022. The Agreements Officer will evaluate the responses provided by each Offeror team and make a determination on whether one or more of the requirements have been met to participate in the prototype phase.

Offeror’s teaming structure Each Offeror Team shall submit, in writing as part of their white paper submittal, their proposed teaming structure for review and evaluation by the Government. Offerors shall identify the company name and facility clearance level of each team member and what aspect of the ARES prototype they will be supporting.

Offeror’s proposed prototype solution Each Offeror shall provide a written description of how they will meet the threshold requirements of the prototype phase. Each threshold requirement should be clearly identified within this written submittal with a short narrative on the approach that the Offeror's team intends to execute in order to meet these minimum requirements.

Quality Management System The Prime Offeror shall identify the quality system they have implemented for software development and deployment and how this quality system will be used to monitor development and delivery by team members to assure customer satisfaction and quality. A copy of the Offerors quality certification(s) shall be provided separately from white paper submittal. Copies of certificates will not count against the overall page count of the respective white paper responses.

Minimum qualifications for developers for working within the OpsEA Salesforce development sandbox*

In order for Offerors’ developers to operate within the OpsEA Salesforce development sandbox certain criteria shall be met in advance. Specifically, team members performing work within the OpsEA Salesforce sandbox for development of the ARES prototype shall complete knowledge validation which may include one or more of the following activities.

Minimum Requirements for Developer Salesforce Sandbox Access:

Access to a development sandbox is gated by successful completion of knowledge validation and training, ensuring alignment with platform standards and compliance controls.

• SDK Knowledge Check via ExAM/Achieve

• All users must complete the SDK onboarding assessment delivered through the ExAM/Achieve platform. This includes:

− Multiple-choice and scenario-based knowledge checks

− Scoring thresholds to validate understanding of SDK procedures

− Badge issuance tied to completion and score thresholds

• The knowledge check covers topics such as:

− Flow Catalog structure − Data Dictionary requirements − Metadata naming conventions − Least privilege access design − Documentation for Request for Change (RFC)

• Salesforce Knowledge Verification (choose one path):

Option A: Salesforce Certification: Complete any one of the following:

− Salesforce Administration − Platform App Builder − Platform Developer I or II

Option B: Trailhead Path:

− Complete all modules in the SDK Intake User

Trailmix − Core Admin Foundations − Security & Compliance Superbadges − Sharing & Visibility − Flow Fundamentals & Optimization − Object Relationships and Validation Rules − Reporting & Dashboards

• Additional Requirements for Contractors and Privileged Users:

PROTOTYPE PHASE DATA DELIVERABLES:

During the prototyping phase, Contractor Teams shall provide written responses to the following deliverables for evaluation by the Government. No classified or proprietary information shall be included in these deliverables.

Prototype Phase Data Deliverables Title Frequency First Submission Format Elements

IL-4 to IL-6 Roadmap

One Time At time of prototype delivery

Offeror Format The Offeror shall provide a white paper, not to exceed 3-pages, outlining their proposed strategy for transitioning the ARES enterprise solution from IL-4 to IL-6. The roadmap shall demonstrate an understanding of the milestones and time required for this transition.

Data Segregation Plan

One Time At time of prototype delivery

Offeror Format The Offeror shall provide a white paper, not to exceed 5-pages, documenting their approach to data segregation to include: defined data categories, proposed segregation mechanisms, data flow diagrams, and access control policies. This Data Segregation Plan shall enable access control to protect Personal Identifiable Information (PII) as well as the capability to scale to support Joint and Allied use cases.

DDIL Plan One Time At time of prototype delivery

Offeror Format The Offeror shall provide a white paper, not to exceed 3-pages, outlining their proposed strategy

− Completion of Flosum Release Management training

− Adherence to sandbox hygiene and change control protocols

• Once these validations are complete and approve by the Sherpa team, sandbox provisioning will proceed.

for scaling to meeting Denied, Degraded, Intermittent, and Limited (DDIL) and mobile access; response must include number of days system can work disconnected and still successfully resync.

Release Documentation

One Time At time of prototype delivery

Offeror Format The Offeror shall provide release documentation for the submitted prototype. There is no page count restriction for this submittal.

QUESTIONS FROM INDUSTRY:

The Government will accept questions from industry regarding the ARES requirement. Questions are due by 1600 EST, Friday, 10 October 2025. Questions can be sent to the ARES Program Manager, 1st Lt Evan Pomfret, evan.pomfret.1@us.af.mil and the Deputy Integrated Product Team Lead, Mr. William Fondriest, william.fondriest@us.af.mil. Questions can be sent via email.

After the closing date, the Government will catalogue the questions from industry and prepare responses which will be published to industry shortly thereafter but before release of the final Solution Solicitation.

mailto:evan.pomfret.1@us.af.mil mailto:william.fondriest@us.af.mil