BAA
# 03-30
|
|
LifeLog |
POC: Dr. Doug Gage, DARPA/IPTO |
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:
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 <n> of 2”. The full
proposal (original and designated number of hard and electronic copies) must
be submitted in time to reach DARPA by 12:00 PM (ET) Monday, June 23, 2003, in
order to be considered during the initial evaluation phase. However, BAA 03-30, LifeLog will remain open
until 12:00 NOON (ET) Friday, May 7, 2004 Thus, proposals may be
submitted at any time from issuance of this BAA through Friday, May 7,
2004. While the proposals submitted after the Monday, June 23,
2003, deadline will be evaluated by the
Government, proposers should keep in mind that the likelihood of funding such
proposals is less than for those proposals submitted in connection with the
initial evaluation and award schedule.
DARPA will acknowledge receipt of submissions and assign
control numbers that should be used in all further correspondence regarding
proposals.
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:
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 <PM’s
Title & Name>, DARPA/IPTO, stating that you either can not or will
not provide the information technology (IT) resources necessary to conduct
the said research.
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.
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.