How do you prove feasibility for Direct-to-Phase-II without a Phase I?
Direct-to-Phase-II skips the funded Phase I, but only if you demonstrate Phase I-equivalent feasibility with evidence you generated yourself. For a team with a real deployment or product it is the best deal in the program: you walk in with the hardest argument already won. Most teams still fumble it in one of two directions.
Direct-to-Phase-II (D2P2) skips the funded Phase I. You go straight to the big award, but only if you can demonstrate Phase I-equivalent feasibility with evidence you generated yourself. For a team with a real deployment or a real product, this is the best deal in the program: you walk in with the hardest argument already won.
Most teams fumble it anyway, in one of two directions.
The two ways to fail the feasibility bar
Direction one: you sound like the work is done. You describe a finished, deployed system so confidently that the reviewer thinks "this is a product, not research; why are they asking us to fund it?" Feasibility over-proven becomes a funding-rationale problem.
Direction two: you sound like a science project. You describe what you intend to build with no evidence any of it works yet. That is exactly the risk a funded Phase I exists to retire, and you skipped it. The reviewer cannot take the bet.
The winning proposals thread this precisely: demonstrated foundation, then named new work with named uncertainty.
What "Phase I-equivalent evidence" actually looks like
Commercially or independently validated evidence is acceptable. A prior government contract is not required. What persuades, in order of strength:
- A production deployment with a named customer and a user count.
- Real artifacts the system has already produced, described by content (page counts, entity counts, the analyses performed), with dates.
- Hard performance numbers from real use, not projections.
- A documented feasibility study plus an end-user who will say it matters.
Write this section entirely in the past tense. "Beacon delivered multi-hundred-page landscape reports to a government customer last fiscal year" is feasibility. "Beacon will generate reports" is a promise, and promises are what Phase I was for. Keep the architecture detail in the supporting documents so this section stays inside its page budget and stays focused on evidence, not design.
The move most teams miss
Your existing commercial product is your proven foundation. The defense modifications are the funded new work. Same argument, two vocabularies:
| Specific-topic Technical Volume | AFWERX / Agility Prime dual-use | |
|---|---|---|
| Proven foundation | "Phase I-equivalent feasibility (what we proved)" | "Non-Defense Commercial Solution" |
| Funded new work | "Phase II technical approach (the new build)" | "Proposed Adaptation of the Commercial Solution" |
Same evidence. Different label. Stop rebuilding the argument from scratch for each format.
One caveat that decides whether this works: commercial proof only counts when it maps to the technical risk the solicitation actually cares about. A flying commercial aircraft does not prove a contested-environment autonomy claim. Prove the feasibility the topic is asking about, not just that your product exists.
The four-part objective block
For each Phase II objective, write exactly four labeled parts. This is the engine that keeps you on the right side of both failure directions:
- Proven today: the evidence from your feasibility section that makes this credible.
- Phase II new build: the specific new R&D the money funds.
- Technical uncertainty resolved: the named hard problem this removes. If there is no uncertainty, it is not research and does not belong in a Phase II.
- Acceptance: a measurable metric or a named report the Government accepts.
Halyard's objective, done right. Proven today: Beacon resolves entities across federal and commercial sources in production. Phase II new build: a continuous multi-source enrichment service with a named adversary-capability watchlist. Technical uncertainty: cross-source identity resolution when signals are sparse and conflicting. Acceptance: the Government accepts a validated watchlist report meeting a stated concordance threshold against an expert-curated list. Nothing in there says "we already did this." Nothing says "trust us." It says: here is the proof, here is the hard new thing, here is how you will know we did it.
One sentence on stakeholders
D2P2 proposals often name government stakeholders. The winning move is to name them without over-claiming: "These stakeholders are important for long-term transition but are not strictly required for project success; we list them to encourage participation." You get the credibility of real names without promising commitments you do not have.
Get the feasibility argument right and the rest of the proposal has a foundation to stand on. The milestone table and the disqualifiers are next. Back to the main playbook.
Free, no signup
Grade your draft before a reviewer does
Paste your draft. Get the disqualifiers and a per-criterion score in your browser. Your draft never leaves your device.
Open the Reviewer Scorecard →