[From: http://www.darpa.mil/iso/ABC/BAA0007PIP.htm, cache 2000-10-06.]

=====================================================================
BAA 00-07 PROPOSER INFORMATION PAMPHLET
Agent Based Computing
=====================================================================

The information provided in this Proposer Information Pamphlet (PIP), in addition to that provided in the Commerce Business Daily (CBD) Announcement, BAA 00-07, constitutes a Broad Agency Announcement as contemplated in FAR 6.102 (d)(2)(i).

Technical POC: Dr. Jim Hendler, DARPA/ISO, jhendler@darpa.mil,
FAX: (703) 696-2203
Contractual POC: Ms. Algeria Tate, DARPA/CMO, atate@darpa.mil,
FAX: (703) 696-2208

SUMMARY OF IMPORTANT DATES
 

Events
Abstract Due Date
Proposal Due Date
BAA 00-07 Closes
Contract Award (Estimated)		 Date
29 November 1999  (Proposal abstracts are required)
7 February 2000
 7 February 2000
GFY 2000 3Q

The PIP is organized into the following major sections:

I.              Introduction
II.             Technical Overview
                 A. DAML
                 B. TASK
III.            Program Schedule
IV.            Deliverables
V.             Proposal Preparation
                 a) Technical proposal
                 b) Cost proposal
VI.            Evaluation Criteria
VII.          Technical and Administrative Information
VIII.         Other Important Administrative Information

I. INTRODUCTION

DARPA is soliciting research and development proposals for two of the three programs within the Agent-Based Computing thrust: Taskable Agent Software Kit (TASK) and DARPA Agent Markup Language Advanced (DAML).  Information on the third, the Control of Agent-Based Systems (CoABS) is currently reachable from DARPA’s web page (http://www.darpa.mil).  A contractor-supported website (http://coabs.globalinfotek.com) is also available.

The programs in the Agent-Based Computing (ABC) thrust are collectively focused on developing the technologies required to seed the next major evolution of the world-wide web – the ability for autonomously operating intelligent software programs (software agents) to perform distributed computing on the same worldwide scale that has been achieved in sharing information. DARPA is seeking to create an environment in which intelligent distributed computing can be made as easy and ubiquitous as data exchange has become.

While the technology developments made under these programs will also benefit commercial users, the primary end users of these efforts will be military.  In particular, the main focus of these efforts is on the development of capabilities that will dramatically improve U.S. and allied capabilities against asymmetric threats and the proliferation of non-nuclear weapons of mass destruction.  Additionally, these capabilities are expected to address the improvement of military command and control capabilities and of military intelligence efforts.  Of lower priority will be the application of these to military support functions such as supply and logistics or the use of e-commerce by the Department of Defense.

To accomplish these overarching objectives requires technology advancements in three areas.  (1) DARPA is developing the technology foundation that allows software agents to interoperate with other software agents and with other entities in cyberspace such as servers, databases, and sensors, etc.  This goal is being pursued as the major thrust of the Control of Agent-Based Systems (CoABS) program.  The CoABS program is ongoing and is not part of this solicitation.  (2) DARPA is seeking to develop technologies that enable software agents to identify, communicate with, and understand other software agents dynamically (i.e., on the fly at run time, not built in at development time) and to be able to process the informational content of a wide range of information sources.  This goal will be pursued as the major thrust of the DARPA Agent Markup Language (DAML) program.  (3) New scientific and engineering developments must be made to formally characterize the capabilities of agents and the environments in which they function.  An engineering approach, based on mathematically viable models, is needed to drive down the cost of building and using software.  This also involves developing tools that allow software agents to be considered and analyzed in a system context.  This goal will be pursued as the major thrust of the Taskable Agent Software Kit (TASK) program.

FUNDING SUMMARY:

The following summarizes by individual program the anticipated funding level and number of contract awards.

II. TECHNICAL OVERVIEW:

A. DAML: The program goal, to create the technologies so that software agents can dynamically identify, communicate and understand each other, will be based on the following research.  (1) Create an Agent Markup Language (DAML) built upon XML that allows users to provide machine-readable semantic annotations for specific communities of interest.  (2) Create tools that embed DAML markup on to web pages and other information sources in a manner that is transparent and beneficial to the users.   (3) Use these production tools to build up, instantiate, operate, and test sets of agent-based programs that markup and use DAML.  (4) Measure, via empirical experimentation, the productivity improvements provided by these tools.  (5) Apply these tools to third party agent development efforts and evolve DAML technologies towards large-scale use.  (6) Transition DAML to the commercial and military markets via partnerships with industrial and military (C2 and intelligence) activities.

A.1 DAML Technical Background

The modern information technology world is a dynamically changing environment with an exponentially increasing ability to create and publish data that rapidly swamps human abilities to process that data into information.  Agent-based computing can potentially help us to recognize complex patterns in this widely distributed, heterogeneous, uncertain information environment.  Unfortunately, this potential is hampered by the difficulty agents face in understanding and interacting with data that is either unprocessed or in natural languages.   The inability of agents to understand the conceptual concepts on a web page, their difficulty in handling the semantics inherent in the outputs of a program, and the complexity of fusing information concept from the outputs of sensors, to name but a few problems, truly keep the “agent revolution” from occurring.

One potential solution to this problem is for humans to, as it were, meet the computer half way.  By using tools to provide markup annotations attached to data sources, information can be made available to the agents in new and exciting ways.  Going far beyond XML, the goal of this program is to develop a language aimed at representing semantic relations in machine readable ways compatible with current and future Internet technologies.  Further, prototype tools will be developed to show the potential of such markups to provide revolutionary capabilities that will change the way humans interact with information.  Deployment of such tools to military and intelligence users, and showing the incredible dual use potential of such a technology, caps off the program’s goals.

To realize this solution, Internet markup languages must move beyond the implicit semantic agreements inherent in XML and community-specific controlled languages, and move towards making semantic entities and markup a primary goal. DARPA will lead the way with the development of the DARPA Agent Markup Language (DAML). DAML will be a semantic language that ties the information on a page to machine-readable semantics (ontology).  The language must allow for communities to extend simple ontologies for their own use, allowing the bottom-up design of meaning while allowing sharing of higher level concepts.  In addition, the language will provide mechanisms for the explicit representation of services, processes and business models, so as to allow non-explicit information (such as that encapsulated in programs or sensors) to be recognized.

DAML will provide a number of advantages over current markup approaches. It will allow semantic interoperability at the level we currently have syntactic interoperability in XML. Objects in the web can be marked (manually or automatically) to include descriptions of information they encode, descriptions of functions they provide, and/or descriptions of data they can produce.  This will allow web pages, databases, programs, models, and sensors all to be linked together by agents that use DAML to recognize the concepts they are looking for.  If successful, dynamic, run-time information fusion from diverse sources will become a reality.

A.2 DAML Technical Topics

DAML contracts are expected to be of two major types – component development contracts, which focus on the design, implementation, and/or evaluation of DAML tools, and integration contracts, aimed at bringing together these components and transitioning the results.  To achieve these ends, component contractors should propose research in one or more of the following tasks, with integrators considering primarily the last of these.

In addition, all DAML contractors will be expected to participate in two additional tasks – language development and source markup (section A.2.3).  All of these tasks are described below.  Please note that several areas that might be implied by a quick reading of the above tasks may not be considered responsive to the needs of this announcement.  To this end, all those considering submission should check the “caveats” section below (A.2.4).

A.2.1 Component Development Tasks

Component developers will be expected to design, deploy and evaluate approaches in any of the three following areas.

    A.2.1.1 DAML Ontology- and Markup-Tool Development

A semantic markup language must include some mechanism for explicit reference to ontological concepts that are represented in a machine-readable format.   This task will focus on building tools that allow users to embed DAML code on their web pages without needing to know language details (similar to the manner in which current web-page creation tools do not require a user to know HTML) or that allow webmasters and/or novice users to create, browse and/or use ontology pages.   Proposals should explain not only what the tool will do, but what the technical underpinnings are that are expected to make the tool successful, and how these will be tested.

    A.2.1.2  DAML –Agent Component Development

The pervasive availability of machine-readable markups on web sites and other information sources should enable a wide range of new capabilities for software agents.  DAML-agent components may be able to use these markups to enhance search, negotiation, problem solving, software-development, sensor tasking, and many other software-related tasks.  Proposers should describe what approach their tool will need, what sort of sources will need to be annotated, and how these annotations will be produced for demonstration and testing of the tools. Tools that use DAML to help enhance the semantic interoperability between heterogeneous systems or sources are also of interest.  Proposals should explain not only what the tool will do, but what the technical underpinnings are that are expected to make the tool successful, and how these will be tested.

    A.2.1.3 DAML Language/Tool evaluation

The evaluation of agent-components operating over a wide range of information sources annotated with machine readable code will offer new challenges.  Traditional information retrieval metrics, such as precision and recall, are likely to be insufficient for judging the effect of the enhancement of the highly interactive and capable tools to be developed.  Proposals focusing on the DAML language/tool evaluation  task should explain why the evaluation technique (experimental or otherwise) they propose would be useful for judging such work, and describe a research plan for testing DAML components.

A.2.2 Integration and Transition Tasks

Proposers interested in integration contracts for DAML should describe their approaches to integrating and fielding the components developed by component developers.

    A.2.2.1 Integration: Integration will focus on defining and coordinating the tools developed/evaluated by the performers of the other technical topic areas with as minimal a requirement for a homogeneous architecture as possible.  Integration will identify areas of overlapping or common concern, such as common elements of DAML ontology use, and will develop and coordinate approaches for satisfying them.  Integration will identify critical technologies needed to achieve a coherent DAML capability, and plan for their development, if necessary, and incorporation. Integration will need to manage technical risk with flexibility and innovation.  Integration must identify technical issues having the potential to delay development or increase costs and provide technical approaches for resolving them. Proposing organizations must be capable of providing support for developing and maintaining DAML testbeds, managing integrated experiments, and providing information as needed to enable DAML program contractors to produce compelling demonstrations of the utility of their technology.  This includes developing shared knowledge repositories and providing access to data sources.  Integration will include defining scenarios to exercise and stress the larger system capabilities integrated from separate technical components and defining metrics to measure their collective effectiveness.

Integration offerors should identify how they will coordinate the efforts to test the hypotheses of DAML approaches. As all participants should expect to be directed to travel and work with other members of the program in order to participate in semi-annual experiments, the use of the DARPA Technology Integration Center (TIC) should be considered as a primary planning opportunity.

With regard to support in the TIC, the DAML program integrator should plan to support a core lab facility.  Those proposing integration efforts will have to bid equipment and manpower to support the build up and maintenance of the program's core lab.  The programs will likely provide Government Furnished Space within the TIC, but those bidding integration efforts should provide an option for developing a core lab outside the TIC in case space is not available.

     A.2.2.2 Transition: The DAML Integration and Transition contractor will lead transition efforts, rationalizing component transitions to military, non-DoD Government, and commercial organizations, assisting the program management in defining commercial and military markets and working with industrial and military (C2 and intelligence) activities.  Of particular interest to DAML will be the development of tools to help military users prepare information briefings and to gather mission-critical data from a wide variety of sources.  The DAML Integration and Transition contractor will be expected to work with other organizations that are focused on deploying tools to operational military intelligence users, and to help identify, package, and transition components that can be useful prior to DAML completion.  To this end, the DAML Integration and Transition contractor must demonstrate an ability to provide personnel who can work on classified projects (at the secret level; familiarity with Intelink is a plus.)

A.2.3 Additional Responsibilities

As well as the deliverables specified below, all component and integration contractors will be expected to work on two additional tasks.  All participants will be expected to be involved in the design and evolution of the DARPA Agent Markup Language itself.  This activity will include participation in the design of the language, testing of language features, namely, the individual contractor’s projects, and helping to identify critical areas of language improvement.

In addition, contractors will be expected to create and update web pages that describe their efforts and components.  These web pages are to be marked up with the DAML language and kept up to date as the language evolves (at recognized programmatic intervals).  Additionally, contractors will be expected to provide machine-readability (DAML) descriptions of the functionality of their components, of their approach to evaluation, and of all other areas of interest to the project.  These marked-up sites will be used for initial deployment of DAML tools and for initial experimentation with DAML evaluation.

A.2.4 Caveats

While the DAML program focuses on access to machine-readable information, the automatic extraction of that information by use of language analysis or other NLP tools is not a key DAML focus.  Tool developers should focus on what their tools will do and how they will be evaluated, as well as on key technical innovations that will make them possible.  However, the focus of the DAML project is on the development and use of the markup language, and on the agent-based approaches they enable, and not on the development of specific computational techniques or interfaces.  Finally, research on human-computer interaction that is specifically enabled by DAML, or for working with DAML markup, is an interest of the program, but the application of generic technologies for HCI are not considered a programmatic goal.   Similarly, speech, gesture and multimedia approaches to interacting with DAML information are also not considered major goals unless they specifically show off some aspect of the use of a semantic markup.

A.2.5 Additional Sources of Information

DAML builds on a large number of current industrial, DARPA, and academic approaches. These include emerging web standards such as XML, SMIL and/or RDF (see http://w3c.org), current and former DARPA Information Systems Office programs (HPKB, I3, CoABS – see http://dtsn.darpa.mil/iso/), and university efforts in the development of ontological markups including SHOE (http://www.cs.umd.edu/projects/plus/SHOE/), OML (http://wave.eecs.wsu.edu/CKRMI/OML.html),  and On2broker (http://www.aifb.uni-karlsruhe.de/WBS/www-broker/).

B. TASK: The TASK program will extend the current scientific and mathematical foundations of agent-based computing with the goal of adding rigor to the engineering of agent-based systems and tools.  In particular TASK will develop mathematically correct techniques for modeling and analyzing agent behaviors, agent-design methods, and the design of agent-creation tools.  Using these models, TASK will compare the performance of competing agent-creation approaches to test agent behaviors with respect to mathematically validated domain models.  Key research goals will include  (1) Agent Behavior Models - develop methods for modeling the behavior of Agents operating in dynamic, and possibly chaotic, networking environments. (2) Robust Agent behaviors - Apply stochastic and/or heuristic-based optimization methods as a basis for achieving robust Agent performance in the context of such uncertain environments.   (3) Modeling Agent Systems - Model critical scalability, stability, and dynamic performance surfaces for developing large-scale agent systems.  (4) Agent Creation Tools - based upon the principles discovered in the preceding tasks, develop Agent Creation Toolkits to allow agents techniques to be utilized by non-agent-literate, subject domain experts.

B.1 TASK Technical Background

Realizing the agent-based computing vision requires the creation of a large number of agents. Agent development is currently a “black art”-- an arbitrarily complex software development. Part of the problem is that while there are many ad hoc agent creation methodologies, and many partial modeling solutions, there is very little agreed upon formalism for the analysis and modeling of complex, large-scale agent systems supporting interaction between large numbers of diverse and distributed heterogeneous information sources.

This program will focus on analyzing agent behaviors by exploring both mathematical modeling and empirical analyses of agent behaviors. In addition, TASK will strive to get participants to compare agent-creation approaches using these models, and to perform qualitative and meaningful quantitative comparisons of agent behaviors with respect to domain and problem features. The goals of this work include a better understanding of what agent-oriented programming really is, formal methods for the description and analysis of the behaviors of multi-agent systems, and methodologies for predicting and/or analyzing the behaviors of large-scale systems.

The TASK program also hopes to encourage interdisciplinary work that examines either the understanding of computation via the techniques of other fields (for example, models inspired by biological systems or economic techniques), the application of maths not traditionally used for computer modeling (for example, the use of statistical physics for large scale modeling), or the integration of techniques from differing computing traditions (such as hybrids of discrete and continuous analyses).  Also of interest are approaches that may prove successful for the analysis of datasets collected during the solving of complex problems by multi-agent systems.

Another goal of TASK is to fundamentally explain and formalize the notion of an “emergent behavior.”  Although this term is often used in an almost semi-mystical way to explain the performance of a complex task by a set of simple entities (such as the building of a complex termite hill by simple termite behaviors), there is little mathematical or other formal analysis that defines and clarifies the wide variety of types of emergent behaviors, or how to design entities or environments to encourage emergence.   Additionally, how to computationally recognize that a specific goal has been reached by a system “emergently” is still an open problem – TASK hopes to help solve these problems and to apply the results to the verification and validation of agent-based code.
 

B.2 TASK Technical Topic Areas

The key research goals of TASK will focus on mathematical modeling and the formal or large-scale experimental analysis of modern agent-based information systems.  Critically defining what is meant by the term “agent” will be a goal of the program, and proposers should make absolutely clear what they mean by the term “agent” where used in their proposals.  The emphasis of TASK is on information, rather than physical, agents.

In addition, TASK proposals should stress one or more of the following topic areas.

TASK participants will be asked to look for opportunities to work together and to look for opportunities to merge their approaches.  Interdisciplinary proposals, or those that cross traditional bounds in computing, are particularly sought.  TASK participants may be asked to demonstrate their techniques on common problems (for modeling) and/or datasets (for analysis) and submission of a proposal constitutes a willingness to be involved in such pursuits.

III. PROGRAM SCHEDULE

Proposal Due Date

Proposal abstracts must be submitted by 1600 local, 29 November 1999. Proposals must be submitted by 1600 local, 7 February 2000. Proposal abstracts and proposals must arrive at the Defense Advanced Research Projects Agency, 3701 North Fairfax Drive, Arlington, VA 22203-1714 and be marked “Attention: ISO BAA 00-07.”  Receipts will be sent to all offerors within two weeks of the closing date by email. For both proposal abstracts and proposals, electronic mail indicating receipt will be sent to offerors via both technical and administrative points of contact.

Expected Award Date, Anticipated Period of Performance

It is anticipated that all awards resulting from this BAA will be made during 3Q/GFY00.  Although the length of individual efforts should vary with level of difficulty and number of tasks, the total length of the technical effort is estimated to be 52 months from June 2000 through September 2004. Base proposals for individual efforts should be limited to 3 years, optional tasks  or options for the out years may be included.

Kickoff and Semi-Annual Technology Coordination Meetings

An initial program kickoff meeting will be scheduled for one (1) month after all of the contract awards (award dates may vary).   Subsequently, semi-annual technology coordination and program review meetings will be held.  These meetings will typically be known as Principal Investigator (PI) meetings.  One of the Semi Annual PI Meetings will be a joint meeting of the PI’s of all the Agent Based Computing thrust programs, i.e., CoABS, DAML, and TASK programs.  Additionally, all proposers should plan for DAML & TASK workshops, which will be conducted up to twice a year at various sites throughout the country.  The principal investigators and technology subsystem developers will be required to attend these meetings.  For costing purposes, proposers shall assume that these meetings will be divided between the East and West Coast of the Continental United States.

Reviews

DAML & TASK Reviews will be held concurrently with one of the Semi-Annual PI Meetings or Workshops.  Technology subsystem developers should plan to conduct and report on experiments and evaluations of their subsystems’ evolving capabilities.  These evaluations should be proposed to and approved by the DARPA program manager or designated agent.  The evaluations will be reviewed in program-wide meetings to monitor progress, determine performance and set directions for further development.  In addition, performers may be required to conduct periodic reviews as determined by the DARPA program manager.

Experimentation

Science based experimentation provides strategic guidance to programs, helps steer integration and helps evaluate both performance and effectiveness. Hardware and space within the Technology Integration Center (TIC) may be made available for experimentation.  The proposal may be bid with or without TIC reliance, however TIC reliance must be identified as either required or declined.  Involvement in the TIC, particularly by the DAML program integration contractor is further described above.
 

IV. DAML & TASK DELIVERABLES

Contractors shall submit the following:

A.  Monthly reporting of contract funds expenditures

B.  Quarterly Technical Progress Reports

C.  Presentation material for each meeting, conference, design review, seminar, etc. shall be prepared and delivered in accordance with the following:

 Original presentation materials prepared by the contractor for use in any meeting, seminar, conference, design review, etc. conducted under the auspices of this contract, shall be maintained by the contractor and provided to the Government when so directed.  Included in this requirement are copies of the original electronic files, which may have been used in the preparation of the materials.

D.  Final Technical Report

 The Final Technical Report shall cover the major technical aspects of the effect over the preceding period including synoptical analyses of the results of all tests and demonstrations.  The Final Technical report shall be in a form and to a depth suitable for distribution to Government personnel and defense contractors interested in this area of technology.

V. EVALUATION CRITERIA

Proposals will be selected through a technical/scientific/business decision process with technical and scientific considerations being most important. Evaluations will be performed using the following criteria listed in descending order of relative importance:

Criteria 1- 5 are listed in order of priority.

1.  Quality and Technical Merit:


 2.  Offeror’s Capabilities and Related Experience


 3. Approach to Technology Evaluation


 4.  Potential Contribution to the Solution of National Security Problems


 5.  Best Value


VI. PROPOSAL PREPARATION

General:

Proposals may address one or more of the areas identified within each program but each proposal must apply only to one program (DAML or TASK).  Proposals must clearly identify the program for which they are intended.  The cover page described below provides a blank for Program.  Proposals, although marked for an individual program, may be reviewed by Program Managers of other programs within this solicitation or other solicitations if appropriate.

Proprietary claims are strongly discouraged.  A goal of each Agent Based Computing program is that technologies be provided to other participants, and disseminated as widely as possible.  If proprietary claims are necessary, a summary of all proprietary claims must be submitted with the proposal package and include 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 include a statement to that effect.

Proposal Abstract and Proposal Preparation and Delivery

Proposal abstracts shall be prepared for all DAML and TASK areas of interest except the DAML Integration and Transition area.

Proposal abstracts and proposals shall be prepared in the following format:

 a.  on 8.5 x 11 inch papers, 1.5 or double-spaced
 b.  margins not less than one inch
 c.  at least 12 point type
 d.  numbered pages
 e.  one side printing

When submitting proposal abstracts or proposals, an original and three (3) hardcopies of the proposal must be submitted to:

Dr. Jim Hendler
DARPA/ISO
ATTN: BAA 00-07
3701 North Fairfax Drive
Arlington, VA 22203-1714

For both proposal abstracts and proposals, electronic mail indicating receipt will be sent to offerors via both technical and administrative points of contact.

In addition to hardcopies, offerors must send an electronic copy of proposal abstracts and proposals.  The electronic copy of the abstract and proposal may be emailed to BAA00-07@darpa.mil in any of the following formats:

a. Microsoft Word 97 or any format that can be read by the Microsoft Word 97 application (e.g., rich text format, .rtf).
b. Adobe Portable Document Format (.pdf)

As an alternative to the e-mail transmission, offerors may submit the electronic copy on one 3.5-inch floppy disk or 100 MB Iomega Zip disk labeled clearly with BAA00-07, proposer organization, proposal title (short title recommended).

Electronic copies of proposals will facilitate DARPA’s evaluation process, but if for any reason an electronic copy is not available or cannot be interpreted, DARPA will provide proposal abstract feedback and/or proposal evaluations based on hardcopy documents.

     PROPOSAL ABSTRACTS

Proposal abstracts shall consist of a cover page and no more than 5 pages of technical content divided according to the section descriptions A-C below.  Proposal abstracts should be stapled or otherwise held together.

The cover page must include:

a. BAA number,
b. BAA Program title (DAML or TASK)
c. Proposal title,
d. The words “Proposal Abstract”
e. Identity of prime offeror,
f. Complete list of subcontractors, if applicable,
g. Technical contact (name, address, phone/fax, electronic mail address),
h. Administrative contact (name, address, phone/fax, electronic mail address),
i. Type of business (large business, small disadvantaged business, other small business, Historically Black Colleges and Universities (HBCU) or Minority Institutions (MI), other educational, or nonprofit),
j. Duration of effort (differentiate basic effort and options),
k. Proposed costs: the following table of cost data should be included on the cover:

A. Vision: This must describe a hypothetical, yet relevant, advanced concept for DAML or TASK and its use supporting operational military capabilities.

B.  Key Technical Ideas and Innovative Claims:  What are you proposing to develop?  What are the technology foundations?  What leads you to believe your approach will work?  What impact will your technology have if you are successful?

C. Evaluation: How will you measure progress?  How will you prove your hypothesis?

Figures are encouraged, and are included in the overall page limit.

     PROPOSALS

Proposals shall consist of two separately bound volumes. (Do not use 3 ring binders.) Volume I shall provide the technical proposal and management approach and Volume II shall address cost.  Both volumes shall contain a cover page, a table of contents, and pages with technical or cost content as described below.  As described below, sections A-P of the technical proposal shall be limited to no more than 35 pages. Limitations within sections are indicated in the individual descriptions.

Note:  Proposals with less than the maximum number of allowed pages will not be penalized.  Proposals with sections exceeding the page limit indicated will not be evaluated.   Offerors are encouraged to submit concise, but descriptive, proposals.  Proposal questions should be directed to one of the points of contacts listed elsewhere herein.  Offerors are advised that only contracting officers are legally authorized to contractually bind or otherwise commit the Government.

    VOLUME I:  Technical Proposal

Volume I of the proposal shall include the following sections, each starting on a new page:

The cover page:  This must include:

a. BAA number,
b. BAA Program title (DAML or TASK),
c. Proposal title,
d. The words “Technical Proposal”
e. Identity of prime offeror,
f. Complete list of subcontractors, if applicable,
g. Technical contact (name, address, phone/fax, electronic mail address),
h. Administrative contact (name, address, phone/fax, electronic mail address),
i. Type of business (large business, small disadvantaged business, other small business, HBCU or MI, other educational, or nonprofit),
j. Duration of effort (differentiate basic effort and options),
k. Proposed costs: the following table of cost data should be included on the cover:

A.  Executive Summary:  (Limit: 3 pages) The summary should include: (1) a visionary system description that supports the goals of the BAA, (2) innovative ideas and tools proposed including key technologies and a brief synopsis relating this technology to previous research, (3) the central hypothesis and experiments to evaluate the research, and (4) the expected impact of the research if successful.

B.  Innovative Claims and Program Vision:  (Limit: 3 pages) This summary of innovative claims must identify any technical ideas to be pursued and their expected impact on the state-of-the-art.  This page should succinctly describe the unique proposed contribution.

C. Software Components Proposed:  (Limit: 3 pages) This section must describe the software deliverables of the proposed effort that will support  embody the innovative claims made in section B.  If none (for TASK) please so specify.

D Technical Description:  (Limit: 10 pages) The technical description section must include technical arguments to substantiate this research and to provide a comparison with other ongoing research indicating both advantages and disadvantages of the proposed effort/approach. (If proposing a novel mathematical or formal approach, provide enough detail for a non-expert to evaluate the work, citing the relevant technical work needed for a deeper understanding.)   This section will also describe the results, products, and transferable technology to be developed, and should mention the proposer’s directly relevant previous accomplishments and work in this or closely related research areas.

E  Evaluation Plan:  (Limit: 3 pages)  This section must provide a research plan that describes how the proposed approach is to be validated.  DARPA is aware that work at different stages of the scientific process must be evaluated in different ways ranging from feasibility demonstration through empirical hypothesis testing and/or rigorous proof.  Please explain what stage your technology is at now, and how it will move through others as it advances.  Where empirical evaluation is to be used, describe the critical experiments to be performed including a description of how relevant variables will be determined, what parameters will be measured, how they will be measured, and the software instrumentation and other experimental apparatus required to facilitate repeatable experimentation.  The evaluation plan must be consistent with the vision and proposed research products described previously.  Furthermore, the evaluation plan must be sufficient to strongly indicate success or failure of the hypothesis upon which the innovative claims in section B are based.    Proposers may expect to conduct their experiments at the Technology Integration Center (TIC), a contractor-operated DARPA-sponsored facility near DARPA in Arlington, Virginia.

F.  Experimentation and Integration–  Required only for the DAML Integration and Transition Proposers-  Limit 4 Pages

Integration offerors should identify how they will coordinate the efforts to test the hypotheses of DAML approaches. They must work with performing contractors and contractors of related programs within the ABC thrust in order to develop experiments in a common testbed environment. These experiments will be carried out in operational settings likely to be drawn from multiple military operational domains, primarily addressing the issues of asymmetric threat and in support of military C2 and operations. As all participants should expect to be directed to travel and work with other members of the program in order to participate in semi-annual experiments, the use of the TIC should be used as the primary planning opportunity.

With regard to support in the TIC, while each Program above will utilize the TIC in an individual manner, the DAML program integrator should plan to support a core lab facility.  Those proposing integration efforts will have to bid equipment and manpower to support the build up and maintenance of the program's core lab.  The programs will likely provide Government Furnished Space within the TIC, but those bidding integration efforts should provide an option for developing a core lab outside the TIC in case space is not available.

G .  Schedule and Milestones:  (Limit: 1 page) A graphic illustration which depicts major milestones of the research plan described arrayed against the proposed time and cost estimates.  Each milestone depicted shall have a corresponding Work Breakdown Structure describing proposed cost and effort in the proposed Statement of Work.

H.  Proprietary Claims:  (Limit: 1 page) Include here a summary of any proprietary claims to results, prototypes, or systems supporting and/or necessary for the use of the research, results, and/or prototype.  Any claims made in other parts of the proposal (such as Sections B and E) that would impact the claims in this section must be cross-referenced.  If there are no proprietary claims this section shall consist of a statement to that effect.  In addition, and where appropriate, Volume Two of each proposal shall have attached to it the information required by DFARS 252.227-7017, IDENTIFICATION AND ASSERTION OF USE, RELEASE, OR DISCLOSURE RESTRICTIONS (JUN 1995) and/or DFARS 252.227-7028 (JUN 1995) TECHNICAL DATA OR COMPUTER SOFTWARE PREVIOUSLY DELIVERED TO THE GOVERNMENT.

I. Statement of Work (SOW):  (Limit: 3 pages) This section must identify the scope, background, objective and approach of the proposed effort and describe the content and timing of specific tasks to be performed and specific utilization of subcontractors.  Include here a detailed listing of the technical tasks/subtasks organized by contract year. Also identify which key personnel and subcontractors (if any) will be involved.  The SOW may contain separately priced optional tasks to support technology transition as called for in this document.

J. Management Plan:  (Limit: 1 page) This section describes the overall approach to management of this effort, including a very brief discussion of the total organization, use of personnel, project/function/subcontractor relationships, government research and facility interface, and planning, scheduling and control practices.  For university researchers it will be sufficient to simply so state.

K. Security Plan: –  Required only for the DAML Integration and Transition Proposers-  Limit 2 Pages
State what level of security is required to carry out the proposed effort, if any.  If access to classified information is required, provide information specific to secure facilities, including storage and disposal of classified materials, security personnel and procedures to be employed.  Also include the clearances in place and those that would be required to carry out the project.  Discuss limitations foreseen.  Regardless of the security level of the proposed effort, all proposals submitted under this BAA MUST BE UNCLASSIFIED.

L. Technology Sharing Plan:  (Limit: 2 pages) This section should contain a clear description of how results will be made sharable throughout the DAML or TASK program and what use these results might be to other groups.  In addition, this section should address specific innovative approaches the offeror will take to facilitate technology sharing and/or communication.  The technology sharing plan should identify the potential transition customers and describe the overall approach to delivering results, products and technology.  In the case of the DAML Integration offerors, please identify how you will coordinate the transition activities of component developers.

M.   Facilities:  (Limit: 1 page) Include here a description of the facilities that would be used for the proposed effort.

N.   Government Furnished Property:  (Limit: 1 page) 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 proposer shall so state.

O.  Experience:  (Limit: 2 pages) This section describes relevant capabilities, accomplishments, and work in these or closely related areas along with the qualifications of proposed subcontractors.

P.  Key Personnel:  (Limit: 1 page)  Include a listing of key personnel along with the amount of effort to be expended by each person during each fiscal year. The list of key personnel MUST identify expected percentage of effort on the project, all other significant sources of support, and expected percentage of effort of all other significant sources of support.  If multiple proposals are being submitted in response to this BAA, indicate how they will be staffed if multiple awards are made.

Q.  Qualifications:  (Limit: 1 page per key person) This section contains a concise summary of the qualifications of listed key personnel along with other major sources of support for them.  Academic proposers should be sure to list their most important previously published papers if any.   (This section is not included in the page limit).

R.  Bibliography:  Include here a bibliography of relevant technical papers and research notes, which support the technical ideas in this proposal.  (This section is not included in the page limit).

    VOLUME II:  Cost Proposal

The accompanying cost proposal/price breakdown shall be supplied with a cost proposal cover page, together with supporting schedules, and shall contain a person-hour breakdown per task. Cost proposals have no page-length limitations; however, offerors are requested to keep cost proposals to 30 pages as a goal.

In general, the cost proposal should provide for a phased program over the duration of the project, supported by detailed breakdowns.   The cost proposal shall consist of a cover page, table of contents, A) Budget Summary, part 1 and 2, and B) Budget Details.  Details of any cost sharing proposed by the offeror should also be included in the cost section.

The cover page:  This must include:

a. BAA number,
b. BAA Program title,
c. Proposal title,
d. The words “Cost Proposal”
e. Identity of prime offeror,
f. Complete list of subcontractors, if applicable,
g. Technical contact (name, address, phone/fax, electronic mail address),
h. Administrative contact (name, address, phone/fax, electronic mail address),
i. Type of business (large business, small disadvantaged business, other small business, HBCU or MI, other educational, or nonprofit),
j. Duration of effort (differentiate basic effort and options),
k. Proposed costs: the following table of cost data should be included on the cover:

A.  Budget Summary:

Part 1: Detailed breakdown for all costs by Government fiscal year:

a. labor hours by labor category/tasks and subtasks; optional tasks/subtasks must be listed individually and costed separately;
b. personnel (name or designation, rate in dollars per labor hour, and percent time on project;
c. proposed contractor-acquired equipment (computer hardware for proposed research projects) should be specifically itemized with costs or estimated costs.  An explanation of any estimating factors, including their derivation and application, shall be provided.  Include under Budget Details a brief description of the offeror’s procurement method to be used;
d. travel;
e. other direct/indirect costs; and
f. materials

Part 2: Cost breakdown by task/sub-task using the same task numbers as in Technical Proposal SOW, Volume I, section I.  Options must be costed individually.

B.  Budget Details: Include any other relevant details that support section A above.

Each cost proposal shall contain a section which identifies the offeror's Taxpayers Identification Number (TIN), DFARS 204.7202-3; Corporate and Government Entity (CAGE) code, DFARS 204.7202-1; and Contractor Establishment Code (CEC), DFARS 204.7202-2. The codes provided shall be those of the offeror and not of the principal place of performance, if the two are different.

This announcement does not commit the Government to pay for any response preparation cost.  The cost of preparing proposals in response to the BAA is not considered an allowable direct charge to any other contract.  However, it may be an allowable expense as specified in FAR 31.205-18.

Administrative Support

Protection of Information:  It is the policy of DARPA to treat all proposals as competitive information and to disclose the contents only for the purposes of evaluation.  The Government intends to use Schafer Corporation and MITRE personnel as special resources to assist with the logistics of administering proposal evaluation and to provide advice on specific technical areas.  Personnel of these contractors are restricted by their contracts from disclosing proposal information for any purpose other than these administrative or advisory tasks.  Contractor personnel are required to sign Organizational Conflict of Interest Non-Disclosure Agreements (OCI/NDA).  By submission of its proposal, each offeror agrees that proposal information may be disclosed to these selected contractors for the limited purpose stated above.  Any information not intended for limited release to the contractors must be clearly marked and segregated from other submitted proposal material.

Organizational Conflict of Interest

Awards made under this BAA are 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 shall be furnished at the time of proposal submission to the Contracting Officer.  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.  This disclosure shall include a description of the action the Contractor has taken, or proposes to take, to avoid, neutralize or mitigate such conflict.  If the offeror believes that no such conflict exists, then it shall so state in this section.
 

VII. TECHNICAL AND ADMINISTRATIVE INFORMATION

1.  Technical or contractual questions shall be emailed to BAA00-07@darpa.mil or fax to (703) 516-6065 (Attn: BAA 00-07).  Email is preferred.  Regardless of how the question is sent to DARPA, both the question and answer (without the name of originator) may be appended to the Frequently Asked Questions (FAQ) file.  Technical and administrative questions will only be answered if they are submitted in writing.

2.  In addition to its publication in the CBD, an electronic copy of BAA00-07 can be found on the WORLD WIDE WEB at URL: http://www.darpa.mil (search under solicitation).  The associated PIP and FAQ can be found at http://www.darpa.mil (search under solicitation).

3.  Facsimile and Electronic mail:  If the offeror does not have access to the WORLD WIDE WEB, a request for the PIP may be emailed to BAA00-07@darpa.mil or faxed to (703) 516-6065, ATTN:  BAA00-XX INFORMATION.  Clearly indicate the items requested.  The message must include the name of the POC, phone number, fax number, and surface mail address to insure proper delivery.  Information will be surface mailed.  Be aware that surface mail will require more response time than other methods.

 4.  Surface mail:  If the offeror does not have access to e-mail, WORLD WIDE WEB or a FAX machine, written requests may be sent to:  BAA 00-07 INFORMATION, Suite 700 3701 N. Fairfax Drive, Arlington, VA 22203.  Clearly indicate the items requested.  The request must include the name of the POC, phone number, and surface mail address to insure proper delivery.  Information will be surface mailed.  Be aware that surface mail will require more response time than other methods.

VIII. OTHER IMPORTANT ADMINISTRATIVE INFORMATION

DARPA intends to use E-mail for some correspondence regarding BAA 00-07; however, hardcopy proposal abstracts and proposals are required. PROPOSAL ABSTRACTS AND PROPOSALS SENT BY FAX WILL BE DISREGARDED.  PROPOSALS SENT BY ELECTRONIC MAIL BUT NOT ACCOMPANIED BY HARDCOPIES WILL BE DISREGARDED.  The Government reserves the right to select for award all, some or none of the proposals received in response to this announcement.  All responsible sources may submit a proposal, which shall be considered by the Agency.  Historically Black Colleges and Universities (HBCU) and Minority Institutions (MI) 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 technology for exclusive competition among these entities.

This PIP, along with the Commerce Business Daily (CBD) announcement, constitutes a Broad Agency Announcement (BAA) as contemplated in FAR 6.102 (d)(2)(i).  Prospective offerors MUST also refer to this PIP before submitting a proposal.  DARPA anticipates that initial contractor selections will be made during the third quarter of the Government Fiscal Year 2000.