The document and the decision it feeds
Every prototype other transaction competition opens with a short document. The Defense Innovation Unit calls it a solution brief. Consortium managers call it a white paper, submitted against a Request for White Papers or a Request for Solutions. Program offices running their own commercial solutions opening usually just say white paper. Same document, same job: it is read once, scored against three or four published criteria, and answered yes or no. It is not a small proposal. It is the gate in front of the proposal.
The money behind that gate is real. DoD obligations through other transactions for prototyping and production grew from $1.8 billion in fiscal 2016 to more than $18 billion in fiscal 2024, according to GAO's 2025 review, with prototype other transaction obligations alone above $16 billion in fiscal 2024. Almost none of that money is reachable without first clearing a white-paper filter.
The good news for a firm that writes well is that the filter is published. DIU's own commercial solutions opening guide states the Phase 1 page limit, the three criteria, the order they are applied in, and the specific things that get a brief cut. Consortium requests do the same in their instructions to offerors. Very few submissions are written as though anyone read that section.
Three flavors of the same document
The variants differ in length and in how much cost detail they demand, but they converge on the same evaluation logic. DIU's guide limits a Phase 1 solution brief to five pages or fifteen slides and applies a strict pass/fail review. A consortium request typically allots four pages to the technical section and adds short fixed-length sections for facilities, key personnel, security, and price. Both hold meritorious submissions that cannot be funded immediately for up to 180 days.
| Axis | CSO solution brief | Consortium white paper | Full prototype proposal |
|---|---|---|---|
| Length | Five pages or fifteen slides | Around four pages of technical content plus short fixed sections | No practical limit; statement of work, schedule, and priced basis |
| Cost content | Rough order of magnitude, pressed hard at the pitch stage | Total solution ROM on the cover page and a structured estimate; supporting budget detail is not read | Full pricing, milestone payment schedule, commercial pricing substantiation |
| Evaluation stance | Binary yes/no on relevance, innovation, technical merit, applied in that order | Merit-based against the stated need; not ranked against other papers | Negotiation, not competition — down-select has already ended |
| What a pass buys | A 60-minute pitch: 20 minutes presenting, 40 minutes of questions | An invitation to submit a prototype project proposal | An agreement, milestones, and a start date |
| Turnaround | Roughly a 10-day evaluation sprint at DIU | Weeks, and a 180-day hold window for meritorious but unfunded papers | 30 to 60 days from request to signed agreement at DIU |
| Who reads it | A small team: program manager, technical experts, an agreements officer | Government evaluators plus consortium and support staff under NDA | Agreements officer, program manager, and the sponsoring end user |
Write to the criteria, in the order they are applied
DIU's guide is explicit that evaluators apply three yes/no factors in strict order: relevance to the area of interest, then innovation and uniqueness, then technical merit and feasibility. A consortium request that lists relevance to the stated need, technical merit and feasibility, and uniqueness of the approach is asking the same three questions with the second and third swapped.
Order matters more than most authors assume. Relevance is tested first and it is tested alone. A paper that establishes relevance on page three has already been decided on page one. Every sentence before the relevance argument is spent capital.
The second structural fact is that these papers are judged on their own merit, not against each other. Both DIU's guide and published consortium requests say so directly. That kills a habit carried over from full and open competition: writing to beat a field. There is no field in the reviewer's hands, only your paper and a threshold. Comparative language aimed at unnamed competitors reads as noise. Absolute claims with numbers attached read as evidence.
What kind of evidence survives the filter
The published pass conditions reward one thing above all: results that already exist. DIU's guide lists "working prototype or live pilot data" as a pass signal and "theory slides, no demo or data" as an instant kill. That single contrast should drive how a firm allocates its five pages.
How different evidence holds up under a first-round review
Editorial weighting against the published Phase 1 pass conditions and kill triggers. Illustrative rather than measured.
Read that ranking as a page-budget instruction. If the top two rows are available to a firm, they belong on page one or two, in a sentence a reviewer can lift. If only the bottom two rows are available, the honest move is usually to find a different call rather than to dress up a plan as a result.
Relevance is a rewriting problem
The area of interest is generally about a page long and lives on the DIU site for roughly fourteen days. A consortium statement of need is similar in length. That short text is the entire universe the reviewer is scoring against, and its wording is the vocabulary the evaluation will be written in.
DIU's guide includes a useful artifact: an example of acceptable and unacceptable evaluator documentation. The acceptable version names the gap, names the field-proven architecture, gives a measured multiple over current systems, and states an integration window in days. The unacceptable version says the vendor "claims solid tech and fast deployment." The difference is not evaluator skill. It is whether the source document handed them specifics.
So write the sentence the reviewer has to write. One paragraph, at the top, in the government's own words: this is the gap as the call states it, this is what our system does about it, this is the number, this is who has already seen it work, this is how long integration takes. Everything after that paragraph is support.
Two related rules from the same guide. Keep the submission unclassified. And make it stand entirely on its own — the guide says explicitly that a brief may not rely on cross-references or assumed context. A prior conversation with a program office does not travel with the file into the evaluation room.
What "innovative" means to this reader
The published kill triggers for the innovation factor are blunt: a cosmetic tweak to legacy technology, a single-digit improvement at best, buzzwords with no proof. The pass conditions are equally blunt: a method not yet in government use, step-change performance rather than incremental, and a clear differentiator such as a patent, a dataset, or an approach no rival offers.
For a software firm the differentiator is rarely the model architecture, because the architecture is usually public. It is more often a dataset nobody else has assembled, an error rate measured under conditions the government cares about, an integration into a system of record that took real work, or a deployment posture (air-gapped, edge, accredited) that competitors cannot match this quarter. Name that thing in one sentence and defend it with one number.
A statutory footnote worth knowing: the FY2026 National Defense Authorization Act, signed December 18, 2025 as Public Law 119-60, amended the commercial solutions opening authority at 10 U.S.C. § 3458 so that it is no longer restricted to innovative commercial solutions, and added explicit follow-on production authority. That widens what a CSO can buy. It does not widen the prototype other transaction statute, and it does not change DIU's published innovation filter. A catalog item still fails an innovation criterion that is still being applied.
Technical merit is an evidence section, not an architecture section
The third switch tests whether the technology is already proven and can scale at commercial speed. Its kill triggers name the three ways technical sections go wrong: no demo or data, integration hurdles ignored, and timelines that cannot meet a rapid fielding pace.
Give the number with its conditions. A detection rate is meaningless without the false-alarm rate it was measured at, the dataset, and the hardware. Reviewers who work in the field discount an unconditioned number to zero, and a technical expert on the panel is specifically tasked with flagging unverified claims.
Name the integration surface. Which system, which interface, whose data, and who has to grant access. A paper that treats integration as a later problem is telling the reviewer the schedule is fiction.
Put dates on the delivery plan. Not a Gantt chart — a short sequence with what exists at each point. Prototype other transactions pay on milestones, so a reviewer is already reading your plan as a payment schedule.
Say what would falsify it. A stated acceptance criterion, offered before anyone asks, is the strongest credibility signal available in five pages. It also becomes the completion language that governs the follow-on decision later.
Price at the white-paper stage
Most requests want a rough order of magnitude, and they want it early. Published consortium requests put the total solution ROM on the cover page and prescribe a structure for the estimate, while stating plainly that additional budget backup will not be considered at this stage. DIU treats ROM as a live pitch criterion, then moves at Phase 3 to commercial pricing, where the agreements officer asks only for the data needed to determine price reasonableness and to confirm the number matches how the firm prices commercially.
That tells a bidder exactly what a ROM is for. It is a judgement signal, not a bid. The reviewer is asking two questions: does this price match the work described, and does it match what this company charges everyone else. A round number with a one-line basis and a milestone shape answers both. A precise number with no basis answers neither and invites the assumption that the scope was reverse-engineered from an imagined budget.
Not binding, but it sets the band
A rough order of magnitude does not obligate anyone. It does establish the range the effort is planned against, and a proposal that arrives at Phase 3 far above its own ROM spends its credibility explaining the gap instead of negotiating the work. Price the effort you actually described, state the basis in one line, and split it into milestones a program office can stop after.
The statutory paragraph most papers leave out
A prototype other transaction can only be used when one of four conditions in 10 U.S.C. § 4022(d)(1) is met: a nontraditional defense contractor or nonprofit research institution participates to a significant extent; or every significant non-federal participant is a small business or a nontraditional defense contractor; or at least one third of total project cost comes from non-federal sources; or the senior procurement executive determines in writing that exceptional circumstances justify an innovative business arrangement.
"Nontraditional" is defined at 10 U.S.C. § 3014 as an entity not currently performing, and not having performed for at least one year before the solicitation, any DoD contract or subcontract subject to full coverage under the Cost Accounting Standards. The test is CAS coverage, not size or revenue. Because contracts with small businesses are exempt from full CAS coverage, small businesses are generally treated as nontraditional under this authority. "Significant extent" has no percentage threshold; DoD guidance points to supplying a new key technology, performing a significant share of the effort, or causing a material reduction in cost or schedule or a material increase in performance.
Two sentences in the white paper handle all of this, and almost nobody writes them. State which condition the team satisfies and why. If the argument is significant participation, state which of the four contribution types applies. The agreements officer has to document this before award, and a paper that supplies the language is easier to advance than one that creates homework.
The same logic applies to the prototype determination itself. Section 4022(e)(5) defines a prototype project to include a proof of concept, model, or process (including a business process), reverse engineering to address obsolescence, a pilot or novel application of commercial technologies for defense purposes, agile development activity, the creation, design, development, or demonstration of operational utility, or any combination of those. DIU's award file must explain how the project meets that definition. Use the statute's own words for your effort and the explanation writes itself.
Say something about data rights before anyone asks
Data rights appear as a named evaluation criterion at the DIU pitch stage, and the agreement itself starts from vendor terms and commercial license agreements that are only lightly tailored. That is a large advantage for a firm that arrives with a position and a hazard for one that does not, because the standard defense data rights clauses do not attach on their own — an other transaction is not a procurement contract, so nothing supplies them unless the agreement does.
A short paragraph in the white paper is enough at this stage. What background intellectual property predates the effort. What license the government gets in what is delivered. Which components are third-party or open source. Firms that raise this early get a calmer Phase 3; firms that raise it late get a negotiation with a schedule already published.
One handling note that surprises people. Published consortium requests treat submissions as source selection information under 41 U.S.C. § 2101(7), disclosable only as § 2102 allows — and then state that government support contractors, consortium staff, and other member companies may see the material for administrative and evaluation support under nondisclosure agreements and conflict-of-interest certifications. Mark proprietary content properly, and do not put anything in a white paper that would be damaging in the hands of a support contractor.
The transition sentence
Section 4022(f) permits a follow-on production contract or transaction without further competition when competitive procedures were used to select the prototype participants and those participants successfully completed the project. That provision is why prototype awards matter out of proportion to their size, and it starts working in the white paper.
DIU's guide states the objective plainly: the goal is not simply a successful prototype but a prototype prepared to transition to a production contract or agreement, fielded and sustained by a program of record. A white paper that names the receiving program, the sustainment owner, and a measurable definition of "successfully completed" is answering a question the evaluator has been told to care about. A white paper that ends at demonstration is asking the government to imagine the rest.
The sequence a white paper sits at the front of
Format discipline, which decides more outcomes than it should
Published requests are specific about mechanics, and the specificity is not decoration. A late file or an oversized section can end the effort before a technical reviewer sees it. The recurring instructions across public requests look like this.
- One PDF, portrait orientation, pages numbered sequentially, each major section starting on a new page
- Single spacing, one-inch margins, an 11-point minimum body font, and figures that stay legible when reduced
- Section page limits observed exactly — technical, facilities, and key personnel are counted separately
- Nothing classified in the submission, and proprietary material marked where it appears
- Cover page complete, including the total solution ROM price where the request asks for it
- Yes/no compliance questions answered as yes or no, including the cybersecurity and export-control items
- No cross-references to other submissions, prior meetings, or attachments the request did not invite
The last item catches experienced firms most often. A capability deck built for a program office briefing carries assumed context in every slide. Dropped into a Phase 1 pile, it reads as a company overview rather than an answer, and company overviews trip the relevance switch first.
Common objections, answered plainly
Can we reuse the capability deck we already briefed?
Only as raw material. The published instruction is that a brief must stand entirely on its own with no assumed context, and the first criterion tested is relevance to the specific call. A deck organized around what the company does has to be reorganized around what the call asked for, which in practice means a new document with reused figures.
Should we submit more than one paper against the same call?
Often yes. DIU's guide explicitly encourages the government side to allow multiple solutions from one company, on the reasoning that it increases the pool of ideas and the odds of project success. Each submission is judged on its own merit rather than ranked against the others, so two genuinely different approaches do not cannibalize each other. Two near-identical papers waste the reviewer's ten days and your own.
Do we need a program sponsor before we write?
Not to submit. It changes the odds considerably, because relevance is judged against a gap that a real end user already confirmed, and a paper written by someone who has spoken to that user reads differently on the first page. Where a sponsor relationship does not exist, the substitute is precision: quote the call's own language, address the stated gap directly, and resist the urge to broaden the offer.
Bottom line
An other transaction white paper is a compliance document wearing a technical document's clothes. The criteria are published, the order is published, the page limit is published, and the specific failure modes are published. A firm that reads that section and writes to it is competing against a large field of submissions that did not.
Three moves carry most of the weight. Put the relevance argument in the first paragraph, in the call's own vocabulary. Lead the technical case with a measured result and the conditions it was measured under. Hand the agreements officer the statutory sentences — which condition the team satisfies and how the effort meets the prototype definition — instead of leaving them to be reconstructed. Everything else in the document is support for those three.
None of it rescues a weak fit. The filter is designed to cut generic technology looking for a problem, and it is good at it. When the gap in the call is not a gap your firm can close with something that already works, the correct answer is to skip the call and spend the week on one where it is.
Frequently asked questions
Follow the request exactly. DIU's commercial solutions opening guide caps a Phase 1 solution brief at five pages or fifteen slides. Consortium requests commonly allow about four pages of technical content plus short fixed-length sections for facilities, key personnel, security, and price. Shorter than the limit is acceptable; longer is a compliance problem.
No. Both DIU's guide and published consortium requests state that each submission is evaluated on its own merit against the stated need, not ranked against competitors. The practical consequence is that comparative marketing language does nothing, while an absolute claim with a number and its measurement conditions does a great deal.
Usually yes, as a rough order of magnitude. Published consortium requests put a total solution ROM on the cover page and prescribe an estimate structure, while stating that additional budget backup will not be reviewed at this stage. Detailed pricing comes later, where the agreements officer checks that the number matches the work and matches the firm's commercial pricing.
It is commonly held rather than rejected. DIU places meritorious solutions in a portal for up to 180 days and may request a proposal if resources appear. Consortium requests use a similar 180-day window from the submission date. A "no" in that window is frequently a resource decision rather than a technical one, which makes the same material worth adapting for the next call.
A small team. On the DIU model, technical experts evaluate and flag unverified claims, a program manager drives the pass or cut decision, and an agreements officer guards process integrity and signs the down-select. Consortium reviews add consortium staff and government support contractors under nondisclosure agreements, which is why proprietary marking matters.