Responding to a DARPA BAA: From Proposer's Day to White Paper to Full Proposal

Fewer than one in five white papers submitted to a DARPA Broad Agency Announcement result in an invitation to submit a full proposal. Of those full proposals, roughly half receive funding. Run the numbers and the reality is stark: the pipeline from first reading a BAA to holding a signed contract has a success rate somewhere south of ten percent. Yet the organizations that win DARPA awards consistently are not necessarily the largest or best-funded -- they are the ones that understand that the BAA response process is a campaign, not a document.

That campaign starts months before a single word of proposal text gets written. It begins with Proposers' Day, moves through white paper submission and program manager engagement, and culminates in a full proposal that has already been shaped by dialogue and strategic positioning. Each stage has its own logic, its own failure modes, and its own opportunities to build competitive advantage. This is how the process works -- and where most teams go wrong.

How DARPA BAAs Actually Work

DARPA does not operate like NIH or NSF. There are no standing study sections, no percentile cutoffs, no A0/A1 resubmission cycles. Instead, DARPA uses Broad Agency Announcements -- open solicitations that describe a research problem and invite proposals from anyone who can solve it. Each proposal is evaluated on its own merit against the BAA's stated criteria, not ranked against competing submissions.

There are two distinct types of BAA to understand. Program-specific BAAs are tied to a named program with defined technical areas, milestones, and often a fixed budget. Office-wide BAAs, maintained by each of DARPA's six technical offices -- the Information Innovation Office (I2O), Defense Sciences Office (DSO), Microsystems Technology Office (MTO), Biological Technologies Office (BTO), Strategic Technology Office (STO), and the Tactical Technology Office (TTO) -- are standing solicitations refreshed annually that accept ideas outside any named program. The office-wide BAAs are where genuinely novel concepts can find a home, but they also demand more specificity from the proposer because there is no predefined program structure to anchor against.

Most program-specific BAAs follow a two-step process. Step one is an abstract or white paper, typically three to five pages, sometimes up to ten. DARPA reviews these for relevance and technical merit, then issues invitations for full proposals. Step two is the full proposal itself -- a substantially more detailed document covering technical approach, management plan, cost proposal, and organizational qualifications. Submitting a full proposal without first submitting an abstract is technically permitted in some BAAs but widely understood as a signal that you do not know how DARPA works. Nearly every experienced performer submits an abstract first.

Proposers' Day Is Not a Conference -- It Is a Qualifying Round

When DARPA announces a new program, it typically hosts a Proposers' Day event, either in person (usually in the Arlington, Virginia area) or as a hybrid event with virtual participation. These events are listed on the DARPA events feed, usually four to eight weeks before the abstract deadline. Many teams treat Proposers' Day as an information session -- show up, listen to the briefings, collect the slides, and go home. That approach wastes the most valuable part of the event.

The briefings matter, but the real value of Proposers' Day is access to the program manager. DARPA PMs are not bureaucratic administrators. They are technical experts recruited from academia, industry, or government labs on three-to-five-year rotations. They designed the program. They wrote the BAA. They will evaluate your white paper and, if you are funded, serve as your primary government point of contact for the life of the effort. A PM who has seen your face, heard your two-minute pitch, and understands your technical angle will read your white paper with context that a cold submission cannot provide.

Three things to do at Proposers' Day that most teams skip. First, sign up for a sidebar meeting. DARPA typically offers brief one-on-one slots with the PM -- fifteen to twenty minutes -- that can be scheduled in advance or on-site. These are not optional. Second, arrive with a one-page concept summary that articulates your technical approach, your team's relevant capabilities, and what makes your angle different from the obvious approaches. Hand it to the PM. Third, ask the PM directly which technical area your concept fits best and whether there are aspects of the problem that are underserved by current submissions. Program managers are allowed to have these conversations. They want performers who are solving the hard parts of their program, not just the parts that are easy to propose.

Before You Write: Engaging the Program Manager

The conversation should not end at Proposers' Day. Between the event and the white paper deadline, send the PM a follow-up email. Reference your sidebar discussion. Attach a refined version of your one-pager. Ask specific technical questions about scope, metrics, or evaluation approach. DARPA's culture encourages this -- their own guidance says to talk to the PM before submitting.

This pre-submission engagement serves two functions. It helps you refine your concept so the white paper actually addresses what the PM cares about, rather than what you assumed from reading the BAA text alone. And it signals seriousness. A PM who receives a well-crafted email demonstrating deep understanding of the problem space will remember that proposer when the white paper arrives.

One critical nuance: do not ask the PM to validate your idea or tell you whether you should propose. That puts them in an awkward position and they will not do it. Instead, ask questions that show you have already done the technical work -- "We are considering approach X for Technical Area 2; does the program envision this being evaluated against metric Y or metric Z?" -- and let the answer shape your submission.

Writing the White Paper That Gets an Invitation

The white paper or abstract is a screening document. Its purpose is not to describe your entire research plan -- it is to convince the PM that your concept is technically sound, meaningfully different from the state of the art, and worth the investment of a full proposal review. Most white papers that fail do so for one of four reasons.

The concept is incremental. DARPA's stated mandate is to pursue "high-risk, high-payoff" research. If your proposed approach is a ten-percent improvement over existing methods, the PM will pass. The white paper must articulate a step change -- a fundamentally new approach, not an optimization of a known one. DARPA explicitly discourages low-risk, low-uncertainty proposals and even warns that overemphasis on cost efficiency signals a lack of ambition.

The technical area alignment is wrong. Every program BAA defines multiple technical areas, each with specific objectives and sometimes different evaluation teams. Proposing across multiple technical areas in a single white paper -- or worse, being vague about which area you are targeting -- creates review confusion and almost always results in a rejection. Pick one technical area. Own it.

The team cannot execute. DARPA evaluates teams, not just ideas. Your white paper should make clear who will do the work, what their relevant experience is, and why this specific team is the right one for this specific problem. If your team lacks a critical capability, name the gap and describe how you intend to fill it through teaming arrangements, not hand-waving.

The metrics are absent. DARPA programs are structured around quantitative milestones. A white paper that describes a research direction without specifying what success looks like -- what you will measure, what threshold constitutes a meaningful result, and how you will demonstrate it -- is a white paper that has not internalized how DARPA evaluates progress.

Format conventions vary by BAA, but a strong white paper typically runs three to five pages and covers the problem statement (in the proposer's own framing, not just parroting the BAA), the proposed technical approach, key innovations and differentiation from prior work, team qualifications, and a rough schedule with milestones. Keep the writing dense and technical. DARPA PMs are subject matter experts -- they do not need background tutorials on their own program area.

Building the Right Team

DARPA proposals live and die on team composition. The agency funds performers who can execute ambitious technical work on compressed timelines, and the team section of a proposal is where reviewers assess whether that execution is realistic.

For university-led teams, this often means partnering with an industry integrator or a defense prime that can provide systems engineering, test infrastructure, or a transition pathway to operational use. For small businesses, it may mean teaming with a university lab that brings deep domain expertise or specialized facilities. The key is complementarity -- every team member should fill a specific capability gap, and the proposal should make clear who does what.

Teaming arrangements should be formalized before the full proposal stage. At minimum, have a signed teaming agreement that defines roles, work share, intellectual property provisions, and payment terms. DARPA also requires proposers to disclose organizational conflicts of interest for all team members, along with a mitigation plan. Leaving this for the last week before submission is a common and avoidable source of proposal delays.

One structural consideration that separates experienced DARPA performers from newcomers: think about your team from the PM's perspective. The PM needs performers who can hit aggressive milestones across a multi-phase program. If your team has never worked together before, explain why the collaboration will work. If your PI has never managed a DARPA-scale effort, address that directly and describe the management structure that compensates for it.

From Invitation to Full Proposal

If your white paper earns an invitation, the full proposal is where the real work begins. DARPA typically allows 30 to 45 days between invitation and full proposal deadline -- a window that feels generous until you account for institutional review, cost volume preparation, and the inevitable back-and-forth with subcontractors on budget details.

The full proposal is evaluated on three primary criteria, listed in descending order of importance in most BAAs: overall scientific and technical merit, potential contribution and relevance to the DARPA mission, and cost realism. Note the phrasing -- cost realism, not cost minimization. DARPA's own guidance warns that "undue emphasis on cost may motivate proposers to offer low-risk ideas with minimum uncertainty and to staff the effort with junior personnel." They are telling you explicitly: do not lowball. Staff the effort with the people who can actually do the work, price it honestly, and let the technical merit carry the proposal.

The technical volume should expand on everything the white paper introduced -- detailed approach, risk mitigation, schedule with go/no-go decision points, and a clear description of deliverables at each phase. Include preliminary results or proof-of-concept data if you have them. Quantify everything. If the BAA asks for a system that achieves a specific performance metric, your proposal should explain not just how you plan to get there but how you will measure and verify it.

The management volume matters more than most teams realize. DARPA programs typically run 36 to 48 months across two or three phases, with down-selects between phases. Your management plan should describe how your team will coordinate across organizations, how you will track progress against milestones, and how you will communicate results to the PM. Monthly technical reports and quarterly reviews are standard -- build those into your schedule and budget.

The Mistakes That Kill Proposals

Beyond the white paper failure modes, full proposals fail for a set of predictable reasons that are worth naming explicitly.

Ignoring the BAA's evaluation criteria. Every BAA lists its evaluation criteria, usually with explicit priority ordering. Proposals that allocate most of their page count to the team's credentials while underserving the technical approach -- when technical merit is the top-weighted criterion -- are proposals that did not read the instructions. Structure your proposal so that page allocation mirrors the evaluation weights.

Generic transition plans. DARPA is a mission agency. The agency exists to create technological capabilities for national security. A proposal that describes excellent basic research but cannot articulate who will use the technology, how it will be transitioned to an operational environment, and what the pathway from prototype to deployment looks like is missing the point of DARPA funding. Name the transition partner. Describe the integration pathway. Make the connection to a military or intelligence community need specific and concrete.

Underestimating the cost volume. The cost volume is a compliance document, but it is also a credibility test. Reviewers will flag budgets where senior personnel are allocated at implausible percentages, where travel is undercosted, where major equipment purchases are unexplained, or where subcontractor costs are suspiciously round numbers. Build the cost volume bottom-up from your technical plan. Every line item should trace to a specific task.

Where the Current Opportunities Are

DARPA's six technical offices each maintain active BAAs. The I2O office-wide BAA, with its focus on artificial intelligence, machine learning, cybersecurity, and resilient software, is currently one of the most active solicitation vehicles for AI and computing researchers. DSO's office-wide BAA covers foundational science, advanced materials, and novel sensing -- areas that are seeing renewed investment as the agency pushes into quantum computing and next-generation electronics. STO and TTO continue to fund autonomous systems, electronic warfare, and networked battle management concepts.

Individual awards under these BAAs range from roughly $500,000 to $5 million or more, depending on scope. Multi-phase programs at the larger end can run to tens of millions across all performers. The key variable is not the dollar amount but the alignment between your concept and what the PM is trying to build.

The DARPA BAA process rewards preparation, technical depth, and relationship-building -- not just writing skill. The teams that win are the ones that show up at Proposers' Day with a concept already in development, engage the PM with substantive technical questions, submit white papers that demonstrate a genuine advance over the state of the art, and deliver full proposals backed by realistic cost estimates and credible execution plans. Every step builds on the one before it, and skipping any of them is visible to the people making the funding decisions. If you are tracking DARPA opportunities and need to move quickly from concept to structured proposal, Granted can help you organize the technical narrative and compliance requirements before the deadline closes.