The embryonic LifeLog program would dump everything an individual does into a giant database: every e-mail sent or received, every picture taken, every Web page surfed, every phone call made, every TV show watched, every magazine read.
All of this -- and more -- would combine with information gleaned from a variety of sources: a GPS transmitter to keep tabs on where that person went, audio-visual sensors to capture what he or she sees or says, and biomedical monitors to keep track of the individual's health.
This gigantic amalgamation of personal information could then be used to "trace the 'threads' of an individual's life," to see exactly how a relationship or events developed, according to a briefing from the Defense Advanced Projects Research Agency, LifeLog's sponsor.
The specific Proposer Information Pamphlet from DARPA is listed below as a reference, because the solicitation period ended many years ago and it is no longer easily indexed on the web. If DARPA is still claiming copyright in this solicitation and wants me to remove, then please send me an email requesting removal.
BAA # 03-30
LifeLog
Proposer Information Pamphlet
| LifeLog SOL BAA 03-30 | POC: Dr. Doug Gage, DARPA/IPTO Proposals Due: Initial Closing: Monday, June 23, 2003 Final Closing: Friday, May 7, 2004 E-Mail: baa03-30@darpa.mil FAX: (703) 741-7804 WEB: http://www.darpa.mil/ipto/Solicitations/index.html |
ADMINISTRATIVE NOTE:
NEW REQUIREMENTS/PROCEDURES
The Defense Advanced Research Projects Agency (DARPA) often selects its research efforts through the Broad Agency Announcement (BAA) process. The BAA will be posted directly to FedBizOpps.gov, the single government point-of-entry (GPE) for Federal government procurement opportunities over $25,000. The following information is for those wishing to respond to the Broad Agency Announcement.
The Information Processing Technology Office (IPTO) of the Defense Advanced Research Projects Agency (DARPA) is soliciting proposals to develop an ontology-based (sub)system that captures, stores, and makes accessible the flow of one person’s experience in and interactions with the world in order to support a broad spectrum of associates/assistants and other system capabilities. The objective of this "LifeLog" concept is to be able to trace the "threads" of an individual's life in terms of events, states, and relationships.
Functionally, the LifeLog (sub)system consists of three components: data capture and storage, representation and abstraction, and data access and user interface. LifeLog accepts as input a number of raw physical and transactional data streams. Through inference and reasoning, LifeLog generates multiple layers of representation at increasing levels of abstraction. The input data streams are abstracted into sequences of events and states, which are aggregated into threads and episodes to produce a timeline that constitutes an "episodic memory" for the individual. Patterns of events in the timeline support the identification of routines, relationships, and habits. Preferences, plans, goals, and other markers of intentionality are at the highest level.
LifeLog is interested in three major data categories: physical data, transactional data, and context or media data. “Anywhere/anytime” capture of physical data might be provided by hardware worn by the LifeLog user. Visual, aural, and possibly even haptic sensors capture what the user sees, hears, and feels. GPS, digital compass, and inertial sensors capture the user’s orientation and movements. Biomedical sensors capture the user’s physical state. LifeLog also captures the user’s computer-based interactions and transactions throughout the day from email, calendar, instant messaging, web-based transactions, as well as other common computer applications, and stores the data (or, in some cases, pointers to the data) in appropriate formats. Voice transactions can be captured through recording of telephone calls and voice mail, with the called and calling numbers as metadata. FAX and hardcopy written material (such as postal mail) can be scanned. Finally, LifeLog also captures (or at least captures pointers to) the tremendous amounts of context data the user is exposed to every day from diverse media sources, including broadcast television and radio, hardcopy newspapers, magazines, books and other documents, and softcopy electronic books, web sites, and database access.
LifeLog can be used as a stand-alone system to serve as a powerful automated multimedia diary and scrapbook. By using a search engine interface, the user can easily retrieve a specific thread of past transactions, or recall an experience from a few seconds ago or from many years earlier in as much detail as is desired, including imagery, audio, or video replay of the event. In addition to operating in this stand-alone mode, LifeLog can also serve as a subsystem to support a wide variety of other applications, including personal, medical, financial, and other types of assistants, and various teaching and training tools. As increasing numbers of people acquire LifeLogs, collaborative tasks could be facilitated by the interaction of LifeLogs, and properly anonymized access to LifeLog data might support medical research and the early detection of an emerging epidemic. Application of the LifeLog abstraction structure in a synthesizing mode will eventually allow synthetic game characters and humanoid robots to lead more "realistic" lives. However, the initial LifeLog development is tightly focused on the stand-alone system capabilities, and does not include the broader class of assistive, training, and other applications that may ultimately be supported.
LifeLog technology will support the long-term IPTO vision of a new class of truly "cognitive" systems that can reason in a variety of ways, using substantial amounts of appropriately represented knowledge; can learn from experiences so that their performance improves as they accumulate knowledge and experience; can explain their actions and can accept direction; can be aware of their own behavior and reflect on their own capabilities; and can respond in a robust manner to surprises.
TASK AREAS
This solicitation seeks proposals to develop and demonstrate LifeLog system-level capabilities as described in the following tasks:
Task 1. Representation and Abstraction via Reasoning and Inference
The research focus of the LifeLog program is the appropriate placement of transactional and physical data within an appropriate framework of representations and abstractions to make accessible both the flow of the user's physical experiences in the world and the stream of his or her interactions with other entities in the world. For transactional data, this process of representation and abstraction might begin with the association of metadata with each data item (e.g., the header information in an email or the information on the envelope of a physical letter). Physical data streams generally have to be parsed into meaningful “chunks,” such as “saccadic” scenes of video, motion segments in GPS or inertial data, or segments of one person’s speech in audio, and these chunks have to be labeled. The key challenge of LifeLog is to make sense of this ongoing sequence of multi-modal transactions and labeled chunks of physical data, by sorting it into discrete “events” and “states” (whose transitions are marked by events) and “threads” (consisting of sequences of events and states) and “episodes” (with beginnings and ends), and to do this automatically and recursively until an extended episode can be identified and labeled as, for example, “I took the 08:30 a.m. flight from Washington's Reagan National Airport to Boston's Logan Airport.” The representational path from the raw physical sensor inputs to this high-level description includes concepts of walking, standing, and riding, being indoors and outdoors, being “at home,” taking a taxi, and going through airport security. The task can be made considerably easier because LifeLog can also process a “going to Boston” entry in the calendar program, email from the airline telling that the flight is on time, and a phone call ordering the taxi, and can correlate GPS readings to a COTS street map. Beyond the generation of the user’s individual timeline or history, represented as a structure of labeled threads and episodes, LifeLog will be able to find meaningful patterns in the timeline, to infer the user’s routines, habits, and relationships with other people, organizations, places, and objects, and to exploit these patterns to ease its task.
The proposal should describe in detail exactly how the offeror’s LifeLog system will accomplish this process of “tracing the threads” and “telling the story” of the user’s experience. State how physical sensory inputs will be parsed and classified (labeled). Define the metadata to be used for each type of input data. Describe how the representation hierarchy is to be constructed, and how classification of events, states, etc., will be performed. Explicitly address the extraction of patterns such as routines, habits, and relationships. Present an approach for assessing the contribution of each data source proposed to LifeLog system-level performance. Provide a comparison of the relative importance of human knowledge engineering and machine learning components both during system development and when deployed. Discuss the tools to be provided to the user to support the visualization and manual generation and editing of the representational hierarchy.
Task 2: Data Capture and Storage Subsystem
LifeLog must acquire data to capture both the user's physical experiences in the world and his or her interactions with other entities in the world. The specific types and fidelity of data to be captured should be driven by the needs implied by the offeror's approach to Task 1. Physical data is captured by various physical sensors and is stored as multiple data streams in appropriate formats at appropriate resolutions. Transactional data is extracted principally from a number of computer applications. Detectors, recognizers, analysis tools, and heuristics are used to “distill” the data, associating metadata, flagging keywords, and otherwise preparing the data for further categorization in terms of representations at various levels of abstraction. Data capture capability must be adequate to support the development of LifeLog, but should not involve new development of sensors.
The proposal should identify the sources and modalities of physical, transactional, and context/media data to be captured, and also the specific sensors and deployment (e.g., wearable) means to be used for gathering physical data, and the methods to be used to acquire transactional and context/media data. The proposal should identify the data storage components to be employed and provide an estimate of the volume of data of each type to be stored per unit time. Selection rationale for components, including critical specifications and estimated costs, should be presented. LifeLog system integration should be specifically addressed, together with power and endurance issues. Offerors must also address human subject approval, data privacy and security, copyright, and legal considerations that would affect the LifeLog development process. Leverage of existing hardware and software is highly encouraged, and LifeLog should interface to commonly used computer applications.
Task 3. Data Access and User Interface Subsystem
The initial LifeLog prototype implementation must provide a functional Application Programming Interface (API), as well as a stand-alone user data access capability which is envisioned to be a search-engine style interface allowing functions (e.g., less than, greater than, Booleans) of the various metadata parameters. Offerors should propose additional features to enhance the user interface (e.g., timeline displays) and to augment the API to support use by additional applications. The developmental interface should also provide a query capability to enable the user to learn why the system behaved as it did. In addition, the interface should provide intervention tools to enable the user to manually create metadata, assign classifications, and edit the abstraction hierarchy. The capabilities of the proposed access scheme should be described in terms of the flexibility of access queries to be supported (of primary concern) and expected performance, such as response time. Leveraging of existing software is encouraged, since the user interface is not a principal subject of research for LifeLog.
Task 4: Experimentation and Performance Assessment
The successful development of LifeLog will require extensive experimentation to provide both the system and its developers with enough “experience” to be representative of use in the real world. The first LifeLog users will clearly be the developer team itself, and, once a critical initial threshold of capability has been achieved, the results of this use should be documented as longitudinal studies. Operating conditions should not be controlled, and a broad spectrum of both physical and transactional data should be captured over weeks of continuous real-world use. The proposal should address performance assessment over these longitudinal studies, and address the metrics of completeness of the ontology and correctness of the LifeLog’s classification decisions. The LifeLog program also includes a “Challenge Problem” in the form of a system demonstration while taking a trip to Washington D.C. Travel combines physical activity (movement via a variety of conveyances) and a diversity of transactions (email, calendar, financial, itinerary, etc.) over the course of a trip. The Travel Challenge consists of an uncontrolled trip from the user's home to Washington, plus controlled trials involving travel over a government-prescribed course within the D.C. area, each trial lasting less than one day. Each proposer is encouraged to have at least three (3) LifeLog users participate in the Travel Challenge. Proposals should include plans for participation in these experiments, specifically including a plan for measuring the performance of the LifeLog system in terms of correctness and completeness. The performance metric for correctness of system decisions addresses 1) What fraction of events are correctly detected and properly classified in the abstraction hierarchy?; and 2) How capable is the system of learning to improve its detection and classification performance? The performance metric for completeness of the ontology considers 1) What fraction of events require additions to the set of existing representations?; and 2) How capable is the system of learning to add and use new representations? The results of the Travel Challenge will be a major determinant of the scope and course of future LifeLog development, including the exercise of proposed options. Offerors should also propose other challenge activities in addition to the Travel Challenge to demonstrate and assess the richness of the LifeLog representation structure and complexity of the domain (task and environment). Additional metrics should also be proposed.
Task 5: Options for Advanced LifeLog Development
The base efforts solicited by this BAA address critical issues that must be tackled to demonstrate a basic LifeLog capability. However, many other equally critical and challenging issues must be addressed to realize a fully deployable LifeLog (sub)system. Therefore, the proposal may include one or more options to perform additional work addressing relevant technical questions, including but not limited to the following:
- How should the LifeLog system enforce security and privacy, given that different data sources may require different restrictions (i.e., classified, proprietary, privacy act) on each data element, and a given item of data may be acquired from more than one source?
- How should different people’s LifeLog systems interact with each other? For example, if each person’s LifeLog understands only his/her own speech perfectly, how should multiple LifeLogs share information so that each can acquire and store all parts of a conversation?
- How should LifeLog be implemented so that it can degrade gracefully in its access modes, storage resources, and capture capabilities?
- How can the domain of intentionality (plans and goals) above the level of timeline or history be more fully developed so that LifeLog can effectively support the broadest possible spectrum of assistive and training applications?
Proposed options should include a clear statement of the functionality and performance benefits envisioned, and should define metrics to support the assessment of these benefits.
PROGRAM SCOPE
This solicitation seeks proposals that address the development of system-level LifeLog capabilities and which fully address Tasks 1 through 4. A proposal that instead focuses on one or more specific individual technologies will be considered, but to be successful it must make a clearly convincing case that the effort would provide an extremely high payoff. Proposed efforts should cover a base 18-month period of performance and may include one or more options, whose period of performance should not exceed 24 months. The project schedule must include an initial kick-off meeting, an engineering design review 6 months after award to approve the architecture and implementation plan, a Principal Investigators' Meeting 9 months after award, and a final project review associated with the Travel Challenge, 16 months after award. Up to four awards are anticipated, and teaming is highly encouraged.
Proposed research should investigate innovative approaches and techniques that lead to or enable revolutionary advances in the state-of-the-art. Proposals are not limited to the specific strategies listed above, and alternative visions will be considered. However, proposals should be for research that substantially contributes towards the goals stated. Research should result in prototype hardware and/or software demonstrating integrated concepts and approaches. Specifically excluded is research that primarily results in evolutionary improvement to the existing state of practice or focuses on a specific system or solution. Integrated solution sets embodying significant technological advances are strongly encouraged over narrowly defined research endeavors. Proposals may involve other research groups or industrial cooperation and cost sharing. The establishment of LifeLog as an approved DARPA program is dependent upon the quality of the responses to this BAA.
SUBMISSION PROCESS
The Defense Advanced Research Projects Agency/Information Processing Technology Office (DARPA/IPTO) requires completion of a Broad Agency Announcement (BAA) Cover Sheet Submission for each Proposal, by accessing the URL below:
http://www.dyncorp-is.com/BAA/index.asp?BAAid=03-30
After finalizing the BAA Cover Sheet Submission, the proposer must print the BAA Confirmation Sheet that will automatically appear on the web page. Each proposer is responsible for printing the BAA Confirmation Sheet and attaching it to the "original" and each copy. The Confirmation Sheet should be the first page of the Proposal. If a proposer intends on submitting more than one Proposal, a unique UserId and password should be used in creating each BAA Cover Sheet. Failure to comply with these submission procedures may result in the submission not being evaluated.
PROPOSAL FORMAT
Proposers must submit an original and 3 copies of the full proposal and 2 electronic copies (i.e., 2 separate disks) of the full proposal (in PDF or Microsoft Word 2000 for IBM-compatible format on a 3.5-inch floppy disk, 100 MB Iomega Zip disk or cd). Mac-formatted disks will not be accepted. Each disk must be clearly labeled with BAA 03-30, proposer organization, proposal title (short title recommended) and “Copy
Restrictive notices notwithstanding, proposals may be handled for administrative purposes by support contractors. These support contractors are prohibited from competition in DARPA technical research and are bound by appropriate non-disclosure requirements. Input on technical aspects of the proposals may be solicited by DARPA from non-Government consultants /experts who are also bound by appropriate non-disclosure requirements. However, non-Government technical consultants/experts will not have access to proposals that are labeled by their offerors as “Government Only”. Use of non-government personnel is covered in FAR 37.203(d)
EVALUATION AND FUNDING PROCESSES
Proposals will not be evaluated against each other, since they are not submitted in accordance with a common work statement. DARPA's intent is to review proposals as soon as possible after they arrive; however, proposals may be reviewed periodically for administrative reasons. For evaluation purposes, a proposal is the document described in PROPOSAL FORMAT Section I and Section II (see below). Other supporting or background materials submitted with the proposal will be considered for the reviewer's convenience only and not considered as part of the proposal.
Evaluation of proposals will be accomplished through a scientific review of each proposal using the following criteria, which are listed in descending order of relative importance:
(1) Overall Scientific and Technical Merit: The overall scientific and technical merit must be clearly identifiable and compelling. The technical concept should be clearly defined, developed and defensibly innovative. Emphasis should be placed on the technical excellence of the development and experimentation approach.
(2) Innovative Technical Solution to the Problem: Proposed efforts should apply new or existing technology in an innovative way such as is advantageous to the objectives. The plan on how offeror intends to get developed technology artifacts and information to the user community should be considered. The offeror shall specify quantitative experimental methods and metrics by which the proposed technical effort’s progress shall be measured.
(3) Potential Contribution and Relevance to DARPA/IPTO Mission: The offeror must clearly address how the proposed effort will meet the goals of the undertaking and how the proposed effort contributes to significant advances to the DARPA/IPTO mission.
(4) Offeror's Capabilities and Related Experience: The qualifications, capabilities, and demonstrated achievements of the proposed principals and other key personnel for the primary and subcontractor organizations must be clearly shown.
(5) Plans and Capability to Accomplish Technology Transition: The offeror should provide a clear explanation of how the technologies to be developed will be transitioned to capabilities for military forces. Technology transition should be a major consideration in the design of experiments, particularly considering the potential for involving potential transition organizations in the experimentation process.
(6) Cost Realism: The overall estimated cost to accomplish the effort should be clearly shown as well as the substantiation of the costs for the technical complexity described. Evaluation will consider the value to Government of the research and the extent to which the proposed management plan will effectively allocate resources to achieve the capabilities proposed. Cost is considered a substantial evaluation criterion but is secondary to technical excellence.
The Government reserves the right to select for award all, some, or none of the proposals received. Proposals identified for funding may result in a contract, grant, cooperative agreement, or other transaction depending upon the nature of the work proposed, the required degree of interaction between parties, and other factors. If warranted, portions of resulting awards may be segregated into pre-priced options.
GENERAL INFORMATION
Proposals not meeting the format described in this pamphlet may not be reviewed. Proposals MUST NOT be submitted by fax or e-mail; any so sent will be disregarded. This notice, in conjunction with the BAA 03-30 FBO Announcement and all references, constitutes the total BAA. A Frequently Asked Questions (FAQ) list will be provided. The URL for the FAQ will be specified on the DARPA/IPTO BAA Solicitation page. No additional information is available, nor will a formal Request for Proposal (RFP) or other solicitation regarding this announcement be issued. Requests for same will be disregarded. All responsible sources capable of satisfying the Government's needs may submit a proposal that shall be considered by DARPA. Historically Black Colleges and Universities (HBCUs) and Minority Institutions (MIs) are encouraged to submit proposals and join others in submitting proposals. However, no portion of this BAA will be set aside for HBCU and MI participation due to the impracticality of reserving discrete or severable areas of this research for exclusive competition among these entities.
NEW REPORTING REQUIREMENTS/PROCEDURES: The Award Document for each proposal selected and funded will contain a mandatory requirement for submission of DARPA/IPTO Quarterly Status Reports and an Annual Project Summary Report. These reports, described below, will be electronically submitted by each awardee under this BAA via the DARPA/IPTO Technical – Financial Information Management System (T-FIMS).
The T-FIMS URL will be furnished by the government upon award. Detailed data requirements can be found in the Data Item Description (DID) DI-MISC-81612 available on the Government’s ASSIST database ( http://assist.daps.dla.mil/quicksearch/ ). Sample instructions that specify how information in the DID may be collected (content and frequency requirements) can be found in Appendix A. An outline of T-FIMS report requirements is as follows:
(a) Status Report: Due at least three (3) times per year – Jan, Apr, & Oct
1) Technical Report
a) Project General Information
b) Technical Approach
- Accomplishments
- Goals
- Significant changes / improvements
c) Deliverables
d) Transition Plan
e) Publications
f) Meetings and Presentations
g) Project Plans
h) Near term Objectives
2) Financial Report
3) Project Status / Schedule
(b) Project Summary (PSum): Due once each fiscal year in July
1) All Sections of the Status Report
2) QUAD Chart
a) Visual Graphic
b) Impact
c) New Technical Ideas
d) Schedule
PROPOSAL FORMAT
Proposals shall include the following sections, each starting on a new page (where a "page" is 8-1/2 by 11 inches with type not smaller than 12 point) and with text on one side only. The submission of other supporting materials along with the proposal is strongly discouraged. Sections I and II (excluding the submission cover sheet and section M) of the proposal shall not exceed 25 pages. Maximum page lengths for each section are shown in braces { } below.
Section I. Administrative
The BAA Confirmation Sheet {1 page} described above under “Submission Process” will include the following:
- BAA number;
- Technical topic area;
- Proposal title;
- Technical point of contact including: name, telephone number, electronic mail address, fax (if available) and mailing address;
- Administrative point of contact including: name, telephone number, electronic mail address, fax (if available) and mailing address;
- Summary of the costs of the proposed research, including total base cost, estimates of base cost in each year of the effort, estimates of itemized options in each year of the effort, and cost sharing if relevant;
- Contractor's type of business, selected from among the following categories: "WOMEN-OWNED LARGE BUSINESS," "OTHER LARGE BUSINESS," "SMALL DISADVANTAGED BUSINESS [Identify ethnic group from among the following: Asian-Indian American, Asian-Pacific American, Black American, Hispanic American, Native American, or Other]," "WOMEN-OWNED SMALL BUSINESS," "OTHER SMALL BUSINESS," "HBCU," "MI," "OTHER EDUCATIONAL," "OTHER NONPROFIT", or "FOREIGN CONCERN/ENTITY."
Section II. Detailed Proposal Information
This section provides the detailed discussion of the proposed work necessary to enable an in-depth review of the specific technical and managerial issues. Specific attention must be given to addressing both risk and payoff of the proposed work that make it desirable to DARPA.
[IMPORTANT NOTE: WITH THE EXCEPTION OF E, C THROUGH H HAVE BEEN REVISED.]
A. {1 Page} Innovative claims for the proposed research.
This page is the centerpiece of the proposal and should succinctly describe the unique proposed contribution.
B. {1 Page} Proposal Roadmap
The roadmap provides a top-level view of the content and structure of the proposal. It contains a synopsis (or "sound bite") for each of the nine areas defined below. It is important to make the synopses as explicit and informative as possible. The roadmap must also cross-reference the proposal page number(s) where each area is elaborated. The nine roadmap areas are:
1. Main goals of the proposed research (stated in terms of new, operational capabilities for assuring that critical information is available to key users).
2. Tangible benefits to end users (i.e., benefits of the capabilities afforded if the proposed technology is successful).
3. Critical technical barriers (i.e., technical limitations that have, in the past, prevented achieving the proposed results).
4. Main elements of the proposed approach.
5. Rationale that builds confidence that the proposed approach will overcome the technical barriers. ("We have a good team and good technology" is not a useful statement.)
6. Nature of expected results (unique/innovative/critical capabilities to result from this effort, and form in which they will be defined).
7. The risk if the work is not done.
8. Criteria for scientifically evaluating progress and capabilities on an annual basis.
9. Cost of the proposed effort for each performance year. C. {2 Pages} Research Objectives: D. Technical Approach: E. {3 Pages} Statement of Work (SOW) written in plain English, outlining the scope of the effort and citing specific tasks to be performed and specific contractor requirements. F. Schedule and Milestones: 1. {1 Page} Schedule Graphic. Provide a graphic representation of project schedule including detail down to the individual effort level. This should include but not be limited to, a multi-phase development plan, which demonstrates a clear understanding of the proposed research; and a plan for periodic and increasingly robust experiments over the project life that will show applicability to the overall program concept. Show all project milestones. Use absolute designations for all dates. 2. {2 Pages} Detailed Individual Effort Descriptions. Provide detailed task descriptions for each individual effort in schedule graphic. G. {2 Pages} Deliverables Description. List and provide detailed description for each proposed deliverable. Include in this section all proprietary claims to results, prototypes, or systems supporting and/or necessary for the use of the research, results, and/or prototype. If there are no proprietary claims, this should be stated. The offeror must submit a separate list of all technical data or computer software that will be furnished to the Government with other than unlimited rights (see DFARS 227.) Specify receiving organization and expected delivery date for each deliverable. H. {2 Pages} Technology Transition and Technology Transfer Targets and Plans. Discuss plans for technology transition and transfer. Identify specific military and commercial organizations for technology transition or transfer. Specify anticipated dates for transition or transfer. I. {2 Pages} Personnel and Qualifications. List of key personnel, concise summary of their qualifications, and discussion of proposer’s previous accomplishments and work in this or closely related research areas. Indicate the level of effort to be expended by each person during each contract year and other (current and proposed) major sources of support for them and/or commitments of their efforts. DARPA expects all key personnel associated with a proposal to make substantial time commitment to the proposed activity. J. {1 Page} Facilities. Description of the facilities that would be used for the proposed effort. If any portion of the research is predicated upon the use of Government Owned Resources of any type, the offeror shall specifically identify the property or other resource required, the date the property or resource is required, the duration of the requirement, the source from which the resource is required, if known, and the impact on the research if the resource cannot be provided. If no Government Furnished Property is required for conduct of the proposed research, the proposal shall so state. K. {1 Page} Experimentation and Integration Plans. Offerors shall describe how their results could be integrated with solutions that other contractors are currently developing or are likely to develop. In addition, offerors should identify experiments to test the hypotheses of their approaches and be willing to work with other contractors in order to develop joint experiments in a common testbed environment. Offerors should expect to participate in teams and workshops to provide specific technical background information to DARPA, attend semi-annual Principal Investigator (PI) meetings, and participate in numerous other coordination meetings via teleconference or Video Teleconference (VTC). Funding to support these various group experimentation efforts should be included in technology project bids. L. {2 Pages} Cost. Cost proposals shall provide a detailed cost breakdown of all direct costs, including cost by task, with breakdown into accounting categories (labor, material, travel, computer, subcontracting costs, labor and overhead rates, and equipment), for the entire contract and for each Government fiscal year (October 1 – September 30). Where the effort consists of multiple portions that could reasonably be partitioned for purposes of funding, these should be identified as contract options with separate cost estimates for each. M. Contractors requiring the purchase of information technology (IT) resources as Government Furnished Property (GFP) MUST attach to the submitted proposals the following information: 1. A letter on Corporate letterhead signed by a senior corporate official and addressed to 2. An explanation of the method of competitive acquisition or a sole source justification, as appropriate, for each IT resource item. 3. If the resource is leased, a lease purchase analysis clearly showing the reason for the lease decision. 4. The cost for each IT resource item. IMPORTANT NOTE: IF THE OFFEROR DOES NOT COMPLY WITH THE ABOVE STATED REQUIREMENTS, THE PROPOSAL WILL BE REJECTED.
Awards made under this BAA may be subject to the provisions of the Federal Acquisition Regulation (FAR) Subpart 9.5, Organizational Conflict of Interest. All offerors and proposed subcontractors must affirmatively state whether they are supporting any DARPA technical office(s) through an active contract or subcontract. All affirmations must state which office(s) the offeror supports, and identify the prime contract number. Affirmations should be furnished at the time of proposal submission. All facts relevant to the existence or potential existence of organizational conflicts of interest, as that term is defined in FAR 9.501, must be disclosed in Section II, I. of the proposal, organized by task and year. This disclosure shall include a description of the action the Contractor has taken, or proposes to take, to avoid, neutralize, or mitigate such conflict.
Section III. Additional Information
A bibliography of relevant technical papers and research notes (published and unpublished) that document the technical ideas, upon which the proposal is based, may be included in the proposal submission. Provide one set for the original full proposal and one set for each of the 4 full proposal hard copies. Please note: The materials provided in this section, and submitted with the proposal, will be considered for the reviewer’s convenience only and not considered as part of the proposal for evaluation purposes.
The administrative addresses for this BAA are:
Fax: 703-741-7804 Addressed to: DARPA/IPTO, BAA 03-30
Electronic Mail: baa03-30@darpa.mil
Electronic File Retrieval: http://www.darpa.mil/ipto/Solicitations/index.html
Mail to: DARPA/IPTO
ATTN: BAA 03-30
3701 N. Fairfax Drive
Arlington, VA 22203-1714
Appendix A - Sample Instructions for Application of DiD MI-DISC-81612 or Analog
REMARKS.
- REPORTING PERIOD TERMINOLOGY
- QUARTERLY REPORTING PERIODS:
- JUL-SEP: Covers PERFORMANCE FROM 1 July - 30 September
- OCT-DEC: Covers performance from 1 October - 31 December
- JAN-MAR
;: Covers performance from 1 January - 31 March - APR-JUN: Covers performance from 1 April - 30 June
- ELECTRONIC SUBMISSION. THE CONTRACTOR SHALL ACCESS THE DARPA EXTRANET REPORTING PAGE To BE FURNISHED AND ELECTRONICALLY SUBMIT ALL REQUIRED REPORTING INFORMATION ACCORDING TO ALL SPECIFICATIONS BELOW.
- Post-Award Initial Submission Requirement: Submit within 30 calendar days of award all data items in 1. Project Information.
- Minimal Initial Report: If award occurs within 30 calendar days of end of quarterly reporting period submit data items 2.10 Issues or Concerns and 3.2 Project Plans, only, in first report. Due date for MINIMAL first report is within 15 calendar days of end of quarterly reporting period that includes award date.
- GENERAL Quarterly SUBMISSION REQUIREMENTS
- FREQUENCY: BLOCK 10. INPUT FOUR (4) TIMES YEARLY, ONCE FOR EACH OF THE QUARTERLY REPORTING PERIODS CITED ABOVE, FOR DURATION OF CONTRACT.
- REPORTING PERIOD: BLOCK 11. REPORT ON PERFORMANCE DURING THE MOST RECENT QUARTERLY REPORTING PERIOD.
- DUE DATE: BLOCK 12 AND BLOCK 13. SUBMIT WITHIN FIFTEEN (15) CALENDAR DAYS AFTER THE END OF MOST RECENT QUARTERLY REPORTING PERIOD, BEGINNING 3030X, i.e.
- For Reporting PERIOD JUL-sep, due date is october 15
- For Reporting PERIOD OCT-dec, due date is january 15
- For Reporting PERIOD JAN-mar, due date is april 15
- For Reporting PERIOD APR-jun, due date is july 15
- QUARTERLY CONTENT REQUIREMENTS
- IF current submission is final submission for this cdrl item include all paragraphs of referenced data item description (did), else
- for THE apr-jun quarterly report, INCLUDE ALL PARAGRAPHS OF REFERENCED DID
For 3.2.1. Planned Activities, In addition to reporting planned activities for next quarter, include a top-level bullet list of planned activities for time period beginning 1 october of current year and ending 31 december of next year. - for all other quarterly reports, INCLUDE ALL PARAGRAPHS OF THE REFERENCED DID EXCEPT FOR DID PARAGRAPH 1.2 PROJECT DESCRIPTION (and all sub-elements of 1.2)
- GENERAL MONTHLY SUBMISSIoN REQUIREMENTS
o FREQUENCY: BLOCK 10. INPUT TWELVE (12) TIMES YEARLY FOR DURATION OF CONTRACT.
o REPORTING PERIOD: BLOCK 11. REPORT ON PERFORMANCE DURING Previous month.
o DUE DATE: BLOCK 12 AND BLOCK 13. SUBMIT WITHIN FIFTEEN (15) CALENDAR DAYS AFTER END OF previous month.
- Monthly CONTENT REQUIREMENTS
- For duration of contract, submit REFERENCED DID ITems
2.3 Incurred Expenses this Period and 2.4 Incurred Expenses to Date, as Lump Sum TOTAL Only.
- CONCURRENT SUBMISSIoN REQUIREMENTS
- FOR DURATION OF CONTRACT SUBMIT 2.5 iNVOICES THIS PERIOD AND 2.6 INVOICES TO DATE, AS INVOICES ARE SUBMITTED FOR PAYMENT. pERIOD IN 2.5 DENOTES TIME SINCE LAST SUBMISSION OF INVOICE(S).
- FORMAT
- GENERAL FORMAT INSTRUCTIONS: comply with ALL INstructions delineated on the DARPA extranet reporting page.
- SPECIAL FORMAT INSTRUCTIONS: SUBMIT 3.1.7, publications THIS PEriod, IN ADOBE ACROBAT (PDF) FILE FORMAT. SUBMIT
1.2.3.1, SCHEDULE GRAPHIC IN EITHER POWERPOINT (PPT), JPG, TIFF, or PDF FILE FORMAT. SUBMIT 1.2.6, QUAD-CHART, IN MICROSOFT POWERPOINT (PPT) FILE FORMAT.
- input of PROPRIETARY INFORMATION:
- PROPRIETARY INFORMATION MAY BE ENTERED ONLY FOR the FOLLOWING ITEMS and only IN THOSE AREAS DESIGNATED FOR SUCH INPUT ON THE darpa extranet REPORTING PAGE
- 1.2.2.1 DETAILED Description of Technical Approach
- 1.2.2.2 COMPARISON with CURRENT TECHNOLOGY
- 3.1.2 Technical Accomplishments this Period
- 3.2.1 Planned activities
- Classification: the entire report shall be unclassified.
- INCLUDE THIS R&D Project Summary ON THE FINAL DD FORM 250.
No comments:
Post a Comment