The ADL Initiative contracts with external vendors and academic institutions to perform some research and development tasks.
The ADL Initiative uses a Broad Agency Announcement (BAA) contracting mechanism to solicit and award external R&D contracts. The U.S. Government uses BAAs to award contracts for basic and applied research and advanced technology development (so called, budget activities 6.1, 6.2, and 6.3). The ADL Initiative primarily uses our BAA to contract for Advanced Technology Development (budget activity 6.3).
Our official BAA solicitation is posted on FedBizOpps. It lists general areas of interest. Each year, we also identify more refined research targets, which are listed on this page (below).
Initial submissions received by 30 Sep 2019 will be considered for the first tranche of FY20 funding.
Businesses and academic institutions may submit project ideas for consideration. The official FedBizOpps link includes full participation details, and a summary is provided below for convenience (the primary reference is the FedBizOpps guidance).
Offerors are encouraged to carefully review the BAA, and to ask for clarification and assistance as required. The Small Business Administration also offers a number of Contracting Assistance Programs for Federal contracts.
You can start at any point in this process, but we recommend you first submit a quad-chart. Quad-charts let you pitch ideas quickly, and if we believe the idea has merit, fits our mission, and can be potentially funded then we'll request a more detailed white paper. You can use this template for your quad charts: Quad Chart Template.
If the ADL Initiative is interested in your quad-chart submissions, then the Government may request a corresponding White paper. These are due within 30 days of request. You're encouraged to contact the ADL Initiative to discuss project ideas prior to White paper submission. Offerors may use their own format for the white paper but are encouraged to consider Heilmeier's Catechism as part of their organizing structure.
After white paper review, offerors may be asked to submit a formal proposal. Proposal guidelines are provided in the BAA. These should include detailed technical and management plans, pricing data, execution timelines, and a proposed statement of work. After receiving a formal request for proposals, offerors have 30 days to submit. Once a proposal is requested, open discussions with ADL Initiative personnel are no longer permitted other than with explicit Contracting Officer involvement and oversight. Offerors should be notified of the award decision within 4-6 months of Proposal submission.
Submitted products are reviewed by technical/scientific personnel who are knowledgeable within the subject matter to determine if the product is consistent with the intent of the BAA and is of interest to the government. Quad Charts will primarily be considered on the scientific/technical merit and the importance to agency programs. White papers will be reviewed on the scientific/technical merit, the importance to agency programs, and the proposed price. Proposals are evaluated on the criteria presented in the BAA: scientific and technical innovation and benefits to the ADL Initiative; scientific and technical approach; management, and cost / benefit.
Products having insufficient scientific/technical merit, insufficient relevance to the ADL Initiative mission, or those in areas for which funds are not expected to be available, may not advance further in the process. In instances where the proposed cost increases substantially from earlier ROM estimates, the offeror should provide clarification for the price increase; inadequately explained deviations between the white paper and proposal ROMs will negatively impact the proposal's evaluation.
The purpose of this BAA is to solicit industry participation in the furtherance of the Distributed Learning modernization and policy mission of the ADL Initiative. Towards that end, the ADL has stood up an overarching Research and Development Science and Technology (S&T) strategy known as the "Total Learning Architecture" (TLA).
The TLA seeks to decouple learning organizations from reliance on a Learning Management System (LMS) centric IT infrastructure, and instead, use a loose federation of web-based services and data sources that communicate human performance information via standardized data contracts. The activities of learning and evidence of human performance of interest to the TLA, and to achieving a "lifelong learning" path for federal personnel, include traditional web-based content, classroom experiences, simulations, and even on the job training and work experiences. These experiences provide data of "learning activities" within an overall "learning ecosystem."
Problem Statement: To support a learner-centric continuum of lifelong learning, individual profiles and performance records must be (safely and ethically) portable across time, system, and institutional boundaries. This capability does not yet exist, and current data standards and specifications are not yet harmonized to support this vision.
Outcomes: This project should build upon prior efforts and be designed to interoperate with Total Learning Architecture specifications. This project will define an initial set of requirements and associated specifications for an enterprise-wide universal learner record system, which (as described in the Talent Development Toolkit report) is envisioned as an aggregation of learner data from federated sources. The requirements and specifications should consider, for instance:
This project will culminate in an operational prototype (i.e., reference implementation model) of the universal learner records system, including a demonstration of its publish/subscribe services and the methods it employs for managing privacy, cybersecurity, identity verification/authentication, and validation (trust) of data. Note, while the documentation should address a DoD-wide federated solution, the prototype can be demonstrated at the local (enclave or federation) level.
For more information, see the Universal Learner Record paper.
Problem Statement: The Experience Application Programming Interface (xAPI) specifies how data from learning activities are captured, stored, and retrieved. A Learning Record Store (LRS) is the implementation of the server-side requirements of the xAPI specification. To support the enterprise-wide adoption of xAPI across the Department of Defense (DoD), LRS solutions need to be accredited to run on DoD networks.
Outcomes: This effort will demonstrate an accredited LRS collecting xAPI data from two or more sources across an unclassified DoD network and then exchanging data between them; this reference implementation will provide a baseline of cybersecurity management approaches for other DoD organizations. The ADL Initiative will provide a partner organization for the prototype testing, but offerors may suggest other testing venues. To perform this operational trial, the project will require successful completion of DoD accreditation processes, and the performers are expected to deliver all associated documentation, including supplementary guidance to aid DoD stakeholders in completing similar cybersecurity accreditation processes. This documentation package must also conform with all necessary Security Technical Implementation Guides (STIGs). The ultimate goal is to support the development of xAPI as an approved transport protocol and to evaluate whether a type-accreditation or other enterprise-level approval for all of DoD is viable. As part of this process, performers should advise the ADL Initiative on best practices for cybersecurity accreditation of other xAPI-enabled systems and provide recommendations to make future xAPI system accreditation processes more cost and time efficient. Recommended revisions to the xAPI specification or its supplementary implementation guidance are encouraged as needed.
For more information, see the Accredited LRS information paper.
Problem Statement: The cmi5 specification was created to replicate SCORM functionality, with the intention of replacing SCORM as the de-facto format of online courses and traditional computer-based training. However, the Department of Defense (DoD) requires a minimally viable cmi5-player reference implementation and a software conformance test suite for cmi5-based content to enable its transition into operational use.
Outcomes: This project will design, develop, test, and ultimately deliver a free and open-source cmi5 content player that serves as reference implementation for DoD stakeholders. The project will also deliver a cmi5 Conformance Test Suite that validates cmi5 content packages against the latest specification.
For more information, see the cmi5 Player and Test Suite paper.
Problem Statement: Privacy is a central concern in the Information Age, and data-privacy considerations affect many aspects of learning and development (e.g., training and education systems, career planning, learner profiles, skills assessments). Given that data-rich systems can provide added-value to learning and development, as well as workforce planning, how should system owners maximize the utility of data while also treating personal information responsibly?
Outcomes: This research builds on the ADL Initiative's Total Learning Architecture (TLA) and learner privacy research, and it relates to the FY20 Universal Learner Records research topic. This project will first validate the prior research recommendations against existing policy and best practices. Then it will produce requirements and specifications for an iteration of a Privacy API that can function within the TLA. The specifications and other design documentation should address all standard component-types within a learning ecosystem (e.g., edge systems, such as learning management systems, and central systems, such as universal learner records). These documents should also consider how data are handled at different organizational levels (e.g., immediate data within a given learning instance, data aggregated across several months at a school, career-spanning data aggregated at the enterprise level, etc.), and they should inform questions such as: Where should different kinds of data reside, who owns what data, how should different portions of a dataset be used or shared, and how should federated applications negotiate for data access and reuse? Next, the project will deliver a reference implementation of the Privacy API, integrated into existing tools, learning activities, and/or other TLA components in a sandbox environment. (Note, other government engineers or contracted performers may be asked to implement the Privacy API based upon its documentation.) Finally, the developers will test and demonstrate the prototype, including tests of its functional and nonfunctional requirements (e.g., user experience).
For more information, see the Learner Data Privacy paper.