Industry_Day_Q&A_Final_16Sep19.pdf

Flyleaf BAA F8750-19-S-7013 Industry Day 05 Sep 2019

Question and Answer Period

The following questions were submitted in writing during the Multi-Domain Command & Control Execution Management and Workflows – “Flyleaf” Broad Agency Announcement Industry Day held at the Griffiss Institute in Rome, NY on 05 Sep 2019. The Flyleaf government team provided the answers below orally on that day. Follow-up questions were not entertained.

Q1: Will data developed in recent and future Flyleaf efforts be shared with other program performers? How?

A1: Results from Flyleaf Program efforts and activity, including data sets and lessons learned, will be made available to performers through traditional government-furnished data arrangements or through a planned publicly-accessible website.

Q2: Is the extended Pacifica data in the form of AF information artifacts, e.g., OPLAN, MIDB, ATOs, etc? If not, what form is it in?

A2: Yes. Existing and extended Pacifica data to be used under Flyleaf is consistent with existing operations center artifacts, including OPLANs, ATOs, AODs, etc. Formats include XML and CSV files representing the area of responsibility (AOR).

Q3: Are there any required ontologies that must be used? Can we use our own proprietary ontologies?

A3: Applicable ontologies include the Air Traffic Management and DARPA Hallmark ontologies. Use of proprietary ontologies is discouraged.

Q4: Do you intend to ask offerors to work at Rome Labs? (since you have lab space built for developers) Or, is the lab space for Rome Labs organic developers?

A4: AFRL is open to hosting contractor personnel on-site, though this is not a requirement.

Q5: Have you worked with Kessel Run for how to onboard your work in applications and algorithms, can you share this path?

A5: The relationship between the Flyleaf program and Kessel Run is still being developed.

Applications successfully hosted and assessed using Flyleaf will be considered for submission to Kesssel Run.

Q6: Do you intend to utilize Test-Driven Development (TDD) where you build code that passes the pre-built test and only enough code to make the pre-built test pass?

A6: We are not opposed to TDD-based approaches, but see it as more appropriate at the scenario/integration level than at the unit-level of development.

Q7: Will AFRL handle network/internet issues that arise from the Universal Command and Control Interface (UCI) being Distribution ‘D’?

A7: Flyleaf expects to support UCI messaging format and recognizes the Distribution “D” concerns with this approach. Any non-DoD offerors will need to use an alternate message format, e.g., Cursor-on-Target (CoT), Distributed Interactive Simulation (DIS); for communicating scenario information.

Q8: What barriers to entry are expected to onboard a Flyleaf capability to Shadow OC?

(nothing… CTF… in between)

A8: Onboarding capabilities to ShadowOC will likely require a CTF. A CTF is not required for hosting of software at AFRL/RI, and limited capability to test non-CTF software is expected to be an option during exercises.

Q9: Will the current UCI spec be used verbatim? Or extended?

A9: There is no requirement to stay within the confines of the current UCI standard.

Extensions and modifications to UCI can be considered and constructed as necessary to support proposed work.

Q10: Are there any existing metrics/docs that can be used as a baseline?

A10: No metrics or baseline performance documents have been identified or are required for use in the Flyleaf program. Measurement of technology performance should be an integral part of any proposal.

Q11: Beyond expressed need for test harness/framework, can you expand at all on lessons learned with the existing in-house team that can be used to prioritize parts of the approach that respondees should/shouldn’t focus on? (i.e., don’t want to waste your time responding with capabilities/tools you’re already satisfied with).

A11: AFRL is interested in responses to all technical areas outlined in the BAA synopsis. No particular test harness/framework has been identified or required.

Q12: How will duty position SMEs from the 805th be made available to performers for workflow modeling?

A12: Limited access to SMEs through the 805th TS may be available before and during exercises, but cannot be guaranteed. Offerors should not rely on them for successful completion of proposed work.

Q13: Will the government provide access to Red Flag data?

A13: AFRL has access to Red Flag data at the Secret level and can vouch for contractor access and need-to-know on a case-by case basis. Success of proposed efforts should not be solely dependent on government-furnished data.

Q14: Can you reconcile comment that this is not a DevOps program with the microservices/experiment steps?

A14: The Flyleaf program is not structured to be an Applications Factory. However, the program acknowledges that software – micro-services – will need to be written to bridge gaps between applications, capabilities, and data. We expect this software to be developed in an iterative fashion concurrent with operation of the Flyleaf software within AFRL and in conjunction with exercises with the 805th TS.

Q15: What is the relation between this proposed testbed build and other testbed or tech stacks in the CTC? (e.g. StreamlinedML)

A15: It is envisioned that the Flyleaf infrastructure will be utilized by other AFRL/RI programs and technology. The long-term vision is for C2 applications from these programs to be exercised and tested using Flyleaf, as well as contribute to Flyleaf capabilities, e.g., machine learning technology.

Q16: Is there a best practice guide for developing/using unclassified scenarios that enable operators to analogize to SECRET pain points?

A16: No such guide exists at this time.

Q17: This is a complex program. Who/how do you integrate the “pieces” that an offeror provides into the bigger solution? And phase these into your experiment timeline?

A17: The Flyleaf government team has primary responsibility for ensuring completion of the complete suite of capabilities. Offerors should be prepared to work with AFRL or a third-party integrator to achieve this.

Q18: To what extent is AFRL bearing the burden for coordinating cross-performer efforts, sprint cadence, dependencies, etc?

A18: The AFRL government team will be responsible for coordinating cross-team interaction at the program level.

Q19: Are we leveraging anything from the OADCGS Program? Lessons Learned?

A19: The Flyleaf team has incorporated lessons learned under the OADCGS program in formulating the BAA, and will continue to leverage OADCGS technical advances as the Flyleaf program moves forward.

Q20: What companies are currently working on Flyleaf?

A20: Outside of a few studies in progress, there have been no new contracts awarded to date under Flyleaf.

Q21: Could you elaborate on what’s stated in the BAA regarding planned number of awards within the $24M budget? How this relates to the Technical Areas?

A21: As per the BAA synopsis, awards are anticipated to be between $300K and $1M, and for no longer than 24 months; larger efforts are possible, all within a program ceiling of $24.9M. Final distribution of funding across the technical areas is dependent on proposals received.

Q22: Is there any value placed on a digital engineering approach to systems engineering for collaborative development?

A22: All proposed work will be evaluated on its merits. No one development approach is desired or favored.

Q23: Will a video be shared around the demonstration? Is AFSIM the standard ModSim on Flyleaf? Mentioned DIS, is HLA also supported?

A23: No video of current software is available for release or distribution. Although we have used AFSIM as the ModSim in some of our experiments to date, it is not required to be used. Nor is development restricted to DIS, HLA is a viable option.

Q24: Is the Flyleaf team looking to leverage the work being done at Catalyst Campus, as well as the on-going AFWERX MDO Challenge.

A24: There are no plans at this time to collaborate with the Catalyst Campus team. We are aware of the MDO Challenge results and are nurturing a relationship with AFWERX to host selected MDO Challenge applications in the Flyleaf environment.

Q25: A daily suggest cadence was mentioned, as was a monthly cadence for exercises. Can you elaborate a bit more on the expected cadence?

A25: Within AFRL we anticipate a development cadence involving a daily scenario-execution cycle. Interaction with an Operations Center is expected to have more of a monthly cadence. Actual scenario duration and cadences is indeterminate and will likely vary over the course of the program.

Q26: Does AFRL have a proposed implementation schedule of major activities by fiscal year, beyond materials presented thus far?

A26: The results of the daily development cadence within AFRL and exercise cycles outside of AFRL will determine the schedule and expectation of future activities.

Q27: Will all of the briefs be available?

A27: Copies of the briefings will be available Distribution ‘D’ to DoD Contractors upon request to the BAA Manager, Mr. Dale Richards, (dale.richards@us.af.mil).

Q28: Since the industry day was pushed out, will the due date for whitepapers be as well?

A28: Delays in publishing the BAA in FedBizOps forced a delay in the Industry Day date. The recommended submission date for white papers was also extended accordingly, to 19 Sep 2019.

mailto:dale.richards@us.af.mil