The read your team cannot perform
By the time a technical volume is finished, everyone who wrote it has lost the ability to read it. That is not a comment on anyone's skill. It is how writing works. The author knows what the sentence means, so the sentence reads clearly. The author remembers the meeting where the approach was chosen, so the approach seems justified on the page even when the justification never got typed. The author has read the solicitation nine times and now answers it from memory instead of from the text. A reader who arrives cold, with the solicitation open in one window and the volume in the other, has none of that memory to fill the gaps. That reader sees only what is actually on the page, which is exactly what the evaluation panel will see.
Federal evaluators read this way by rule. FAR 15.305(a) says proposal evaluation is an assessment of the proposal against the factors and significant subfactors stated in the solicitation. Not against what the offeror meant. Not against the offeror's reputation. Against the stated factors, applied to the submitted text. GAO's protest record is built on that principle: an offeror carries the burden of submitting an adequately written proposal, and an agency is not obligated to reconstruct a good idea from a vague description of it.
So a pre-submission review has one job. Read the volume the way a panel with four hours and eleven proposals will read it, then tell the writing team where that panel will stop, hesitate, or shrug.
Where volumes lose points — frequency across the reads we run
Editorial weighting from our own review reads — illustrative, not a measured statistic.
Pass one: responsiveness to the literal ask
The first pass ignores quality entirely. It asks one question per requirement: does the volume contain a passage that a stranger would agree answers this, using language close enough to the solicitation that no interpretation is required?
The mechanic is a requirements matrix built from the source text, not from the writing team's outline. Every "shall," "must," "the offeror will describe," and "proposals should address" in Section L and in the statement of work becomes a row. Section M, or the SBIR equivalent block of evaluation criteria, becomes a second set of rows. Then each row gets a page and paragraph pointer into the volume, or it gets flagged. In DoD SBIR volumes, the criteria are usually the same three: technical merit and innovation, qualifications of the principal investigator and team, and commercialization potential. In NIH SBIR, the reviewers score significance, investigators, innovation, approach, and environment on the nine-point scale and write an overall impact score. NSF asks for Intellectual Merit and Broader Impacts by name. Whatever the set, the volume should let a tired reader find each one without hunting.
Two failures show up over and over. The first is the paraphrase gap: the solicitation asks for a "verification and validation approach," the volume has a strong section called "Testing," and the evaluator scanning for the phrase never lands on it. The fix costs one heading. The second is the quiet skip: a sub-requirement buried in the third sentence of a dense paragraph in the topic description, which nobody transcribed into the outline, and which the panel scores as absent. A cold reader working from the source text finds both in an afternoon.
Pass two: evidence quality
Once every requirement has an answer, the second pass grades what is under the answer. The test is blunt: for each claim, what would a skeptical engineer accept as proof, and is that proof on the page?
There is a hierarchy here, and evaluators apply it whether or not they name it. A measured number from a build you ran outranks a vendor benchmark. A vendor benchmark outranks a citation. A citation outranks an adjective. "Our approach reduces false positives" is an adjective wearing a lab coat. "On the 41,000-record public sample described in Section 3.2, the pipeline held recall at 0.94 while cutting false positives from 18% to 6%, measured against the hand-labeled subset" is evidence. The second version also gives the panel something to write on the scoresheet, which matters more than most offerors realize: a strength has to be quotable to survive the consensus meeting.
The evidence pass also flags the reverse problem, which is rarer and more expensive. Some volumes carry a genuine, hard-won result stated so modestly that it reads as routine. A team that already built the ingest layer and ran it against real agency-format data will sometimes describe that in half a sentence, in past tense, in the middle of a background section. That is the single most valuable fact in the bid and it belongs in the first hundred words of the section that scores it.
Pass three: strengths an evaluator can actually score
Source selection language has real machinery behind it. A strength is an aspect of a proposal that has merit or exceeds specified performance in a way beneficial to the government. A significant strength appreciably exceeds it. Weaknesses, significant weaknesses, and deficiencies run the other direction. Panels build ratings out of those counted items, then narrate the rating. That means the practical question for every page of a technical volume is: what strength statement could an evaluator write from this, in one sentence, without inventing anything?
Most volumes have four or five real strengths and bury three of them. The review marks each candidate strength, checks whether it appears above the fold in its own section, and checks whether the surrounding prose gives the evaluator the words. This is also where the reviewer checks that the strength is tied to a benefit the customer named. A clever architecture with no stated consequence for the mission is a paragraph the panel enjoys and does not score.
The same pass checks proportion. If the evaluation criteria weight technical merit at 35 points, personnel at 25, and program management at 20, then a volume that spends nineteen pages on technical merit and six paragraphs on the team is arguing against its own scoresheet. Weighting on the page should track weighting in the criteria, within reason.
Pass four: risk, said out loud
Risk sections are where a hostile read pays for itself. The common pattern is a table of five generic risks (schedule slip, staffing, data access) with mitigations that amount to "we will monitor it." Every experienced evaluator has read that table a hundred times and it scores nothing. Worse, it signals that the offeror either has not thought about the hard part or is hiding it.
A reviewer from outside the team can name the hard part without political cost, because they have no stake in the approach. If the technical risk is that the labeled data may not exist at the fidelity the method needs, say so, then show the fallback method, the trigger that switches to it, and what the deliverable looks like on the fallback path. Panels reward that. It reads as engineering judgment rather than optimism, and it converts the biggest hole in the bid into a paragraph the panel can score as a strength.
The same pass looks at the assertions the volume makes about rights and access, because those quietly become risks in the evaluator's mind. Data rights under DFARS 252.227-7013 and 252.227-7014 are asserted in the proposal, not negotiated later, and SBIR data carry a 20-year protection period from award under the SBA SBIR/STTR Policy Directive. If the volume promises delivery of a container the offeror does not have the right to deliver, or is silent on background intellectual property it plainly relies on, an evaluator will note it. So will a contracting officer.
The compliance layer that decides whether anyone reads the rest
Before any of the above matters, the volume has to be evaluated at all. Page caps are the most common hard stop. DoD Phase I technical volumes commonly run to 20 pages, with individual components capping at 15; NSF Phase I allows a 15-page project description; NIH allots 6 pages for the Research Strategy. Solicitations routinely say that material beyond the limit will not be read, and portals enforce limits mechanically on the uploaded PDF. Font floors and one-inch margins appear in the same instructions. A volume that fits by shrinking type is a volume that fails a spot check.
Mandated structure is the quieter killer. When an announcement prescribes section headings, an order, or a fill-in form, that structure is a material term. Volumes with a better structure of their own get set aside as non-responsive without a technical read. The review checks the volume against the instructions line by line: heading names and order, required certifications, page and file naming, the resume format when one is prescribed, and the boundary between what belongs in the technical volume and what belongs in cost. Cost detail leaking into a technical volume is a routine finding, and in the other direction, a technical narrative hiding in the cost volume is worse.
| What gets checked | Inside the writing team | Outside review |
|---|---|---|
| Requirement coverage | Checked against the outline the team built | Checked against the source text, row by row |
| Clarity | Reads clearly to people who know the answer | Read once, at speed, with no prior context |
| Evidence | Remembered from the work | Graded only on what is printed |
| Risk | Politically costly to name | No stake in the approach; names it plainly |
| Strengths | Known to be there | Must be findable in the first read |
| Format | Checked late, under deadline | Checked first, against the instructions |
What it costs in time
A full read of a 15 to 20 page technical volume takes eight to twelve hours of reviewer time and two to three business days of calendar time. Nothing about it is exotic. The cost is attention, applied in a fixed order, by someone who was not in the room when the approach was chosen.
How a review runs
What comes back
Three artifacts, and they are meant to be worked, not admired.
The matrix. Every requirement and every evaluation criterion, with the page and paragraph that answers it, or a flag. Rows with flags are the first thing to fix, because an unanswered requirement is a scored zero regardless of how good the rest is.
The scored read. The volume evaluated against its own stated criteria, written in evaluator voice, with strengths and weaknesses called out as a panel would phrase them. Reading your own proposal in that voice is uncomfortable and useful in equal measure.
The ranked fix list. Every finding sorted by point impact against the time it takes to fix, so that a team with two days left knows which six changes to make and which twelve to skip. Findings that require new work rather than new words are marked as such, because those are decisions for the offeror, not the reviewer.
- The technical volume as a PDF, in the form you intend to upload
- The solicitation, announcement, or topic text, verbatim
- The evaluation criteria section, if it lives in a separate document
- Any question-and-answer record the agency has published
- The close date and time, with the time zone
- A note on which sections are still moving
When to schedule it
Ten business days before close is the right target for a first read, with a shorter second read on revised sections at five days. That spacing exists for a reason: findings in pass one and pass four often require new content, not new sentences, and content takes days. A review delivered 36 hours before upload can only produce cosmetic fixes, which are the fixes with the smallest point impact.
Late is still worth doing when the alternative is nothing. A four-hour compliance-and-responsiveness pass in the final 48 hours catches the failure modes that cost the entire bid: a missed mandated form, a page cap breach, a requirement with no answer, a certification left out. Those fixes are cheap in words and enormous in consequence. Submission deadlines themselves are not negotiable, and the late-proposal rule at FAR 52.215-1(c)(3) is applied strictly, so the plan should never depend on a portal being forgiving in the last hour.
What this review is not
It is not ghostwriting. The volume stays the offeror's work, in the offeror's voice, and the findings come back as findings. It is not a copy edit, though obvious errors get marked. And it is not a prediction. Nobody can promise a rating from outside the panel. What a review can do is remove the reasons a panel would score you down for something other than the merit of your idea, which is the only part of the outcome anyone controls.
We already run an internal color-team review.
Good, and keep it. An internal team catches structure, tone, and consistency better than any outsider because it knows the program. What it cannot do is un-know the approach. Run both. The internal read makes the volume coherent; the cold read tests whether coherence survives a stranger.
The volume contains export-controlled or proprietary technical data.
We are SAM.gov active, CAGE 1AYQ0, and JCP / DD-2345 certified, and we work under a mutual NDA before anything is sent. Classified material stays out of scope entirely and should never travel by email in any case.
We are already at the page cap. Where does new content go?
Out of the paragraphs that repeat the topic description back to the government. Most volumes carry one to two pages of restated background that scores nothing. The fix list flags those first, so that a finding requiring new content arrives with the space to put it.
Would you review a bid you might otherwise compete for?
We decline any review where we are bidding the same announcement, and we say so on day one rather than after reading. If the fit is right the better answer is often to team on it. That conversation takes ten minutes and we will raise it if we see it.
Send us a volume
Our engineers write and evaluate technical volumes for federal, state, and commercial customers, as prime and as subcontractor, across AI and machine learning, data platforms, and cloud. Our team is led by a former professor in technology who ranks in the top 200 of more than 200,000 on Kaggle and holds seven cloud certifications, with twenty years of building production systems for federal agencies across five consulting firms, three of them federal. Behind that sits a standing bench of named engineers, licensed professional engineers, and domain specialists in defense, health, energy, transportation, and public-sector data. We read volumes the way panels read them because we write to those panels every week.
Send two things to [email protected]: the technical volume as a PDF, and the evaluation criteria section of the solicitation. Add the close date in the subject line. You will get a yes or no within one business day, and if it is a yes, a marked-up read with the matrix, the scored read, and the ranked fix list within three business days. If the close is inside 72 hours, write "48-hour pass" in the subject and you will get the compliance-and-responsiveness read instead, same day where the calendar allows.
Frequently asked questions
Four things, in order: compliance with the literal instructions (caps, mandated structure, forms), responsiveness to every requirement and evaluation criterion, the quality of evidence sitting under each claim, and whether the strengths and risks are stated in language an evaluator can score. Style comes last and matters least.
Because the team reads its own text with the missing information supplied from memory. Gaps that a panel would see as absent read as present to the author. A reviewer with no prior context is the only way to test what is actually on the page.
Ten business days before close for the main read, with a shorter second look at revised sections around five days out. Findings often require new content rather than new wording, and content takes days to produce.
Eight to twelve hours of focused reading and writing for a 15 to 20 page volume, spread over two to three business days. A compliance-only emergency pass runs about four hours.
No one outside the panel can promise a rating. What a review removes is the set of reasons a panel would mark you down for something other than the merit of the idea: a missed requirement, an unsupported claim, a buried strength, a risk section that says nothing.