The technical volume: 15 pages that win Phase I

The technical volume is the scoring document

At 50-60% of the total score in Phase I, the technical volume is where proposals are won. Everything else — cost, bios, commercialization — is either pass-fail or supporting evidence. The technical volume is the document a reviewer reads, scores, and defends in review panels. Every page should earn its place.

1. Section 1 — Problem statement: Lead with the problem in the agency's language. Use the topic's own terminology. Reviewers decide on page one whether you understand the actual problem.
2. Section 2 — State of the art: What exists today? What does it miss? Position your approach against named alternatives, not vague "current solutions."
3. Section 3 — Innovation: Precisely state what is new. The NSF-style "what is the scientific question?" format works across all agencies.
4. Section 4 — Technical approach: Methods, models, architectures. Include a milestone chart with deliverables tied to payment.
5. Section 5 — Team and facilities: Reviewer asks: can these people actually build this? Lead with the most relevant credential for this specific topic.

Most agencies cap the technical volume at 15-20 pages including figures and tables. This piece assumes a 15-page budget, which forces the discipline needed to win. If the solicitation allows 20, the additional pages go into the technical approach and SOW sections, not the front matter.

Page-by-page structure

Pages	Section	Purpose
1	Project summary + identification	4-sentence abstract, problem statement, topic reference.
2	Phase I objectives	3-5 measurable objectives mapped to topic outcomes.
3-4	Background and state of the art	Related work, why existing approaches fall short, where your approach fits.
5-9	Technical approach	The core. Architecture, methods, algorithms, reasoning. Figures here.
10-12	Phase I statement of work	Tasks, deliverables, schedule. Task-month matrix.
13	Relationship to Phase II	How Phase I feasibility evidence sets up Phase II prototype-to-deployment.
14	Team and facilities	PI bio summary, key personnel, facility access, compute environment.
15	Commercialization summary	Dual-use narrative, customer targets, transition path.

The first page carries the most weight

The first page is read twice: once on the reviewer's first pass and once during scoring. Everything else is read at most once. Structure the first page as: a 4-sentence summary at the top (problem, approach, novelty, deliverable), then the problem identification section below it. Do not waste the first page on company background or generic framing.

Win themes should appear explicitly on the first page. A win theme is a one-sentence positioning claim that the proposal then supports with evidence. "Our approach reduces inference latency by 40% while maintaining accuracy equivalent to state-of-the-art transformer baselines" is a win theme. It should appear in the summary, be supported by the technical approach, and be restated in the Phase II relationship section.

Technical approach — the 5 pages that win

The technical approach is the longest single section and the most important one. Structure it as:

The anti-pattern: five pages of marketing prose about how novel the approach is, with no architecture diagram, no equations, no data plan. That reads as smoke to a technical reviewer.

SOW — the contract

The statement of work is a contract. Tasks, deliverables, acceptance criteria, and schedule. A strong SOW has 5-8 tasks, each with 2-5 subtasks, a deliverable, an acceptance criterion, and a month. A task-month Gantt-style matrix on a single page makes the plan legible.

Specific patterns: Task 1 is always kickoff + planning. The final task is always final report + deliverable. Middle tasks align to the objectives. Deliverables should include code, data, and a written report per major task. Avoid vague deliverables like "interim progress" — use "deployable inference container with documented API."

Background and state of the art

Two pages. The purpose is to demonstrate that the PI knows the field. Cite 10-20 papers or prior works, covering the dominant approaches and their limitations. End with a positioning paragraph: "Our approach differs from prior work in X, Y, and Z specific ways." Do not turn this section into a literature review — it is a positioning section.

Phase I to Phase II relationship

One page, often underweighted by first-time firms. Reviewers in Phase I are already thinking about Phase II. A clear statement of how the Phase I feasibility evidence sets up a Phase II prototype, with a credible transition target identified, raises the Phase I score meaningfully. This section should name the program office, mention the commercialization plan's top customer, and state the Phase II dollar range you would target.

Team and facilities

A paragraph per key person. For the PI, state years of experience, relevant prior delivery, and any distinctive credential (Kaggle Top 200, specific agency delivery, etc.). Attach full bios separately if the solicitation allows.

Facilities is short: compute environment (e.g., "AWS GovCloud with FedRAMP Moderate baseline"), data access, any security posture, office and collaboration setup. For an AI firm, the honest answer is usually software-defined infrastructure, and that is fine.

What reviewers skim vs read

Skimmed: background section (especially lit reviews), facilities section, any dense paragraph in the middle of a page.

Read closely: first page, architecture diagram and caption, risk table, SOW task matrix, Phase II relationship paragraph, commercialization summary.

Act accordingly: put your strongest content in the read-closely zones, and do not waste prose on the skimmed zones.

Editing passes

A technical volume is not a first draft. Run three passes: (1) technical correctness — does every claim hold up; (2) win-theme placement — does each win theme appear on page 1 and reappear in approach and Phase II sections; (3) cut pass — reduce every paragraph by 20%. Most technical volumes get better shorter.

Frequently asked questions