BAA # 03-30
|
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 persons 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 users orientation and movements. Biomedical sensors capture the users physical state.
LifeLog also captures the users 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 persons 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 users 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 users 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 offerors LifeLog system will accomplish this process of
tracing the threads and telling the story of the users
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 LifeLogs
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 efforts 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 Governments
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
proposers 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 <PMs 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 reviewers
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.
"To Achieve World
Government it is necessary to remove from the minds of men their individualism,
their loyalty to family traditions and national identification" Brock Chisholm - Director of the World Health Organization
"A society whose citizens refuse to see and investigate the facts, who refuse to
believe that their government and their media will routinely lie to them and fabricate a
reality contrary to verifiable facts, is a society that chooses and deserves the Police
State Dictatorship it's going to
get." Ian Williams Goddard
The fact is that "political correctness" is all about creating uniformity. Individualism is one of the biggest obstacles in the way of the New World Order. They want a public that is predictable and conditioned to do as it's told without asking questions.
"The two enemies of the people are criminals and government, so let us tie the second down with the chains of the Constitution so the second will not become the legalized version of the first." Thomas Jefferson