Responding to a civil agency RFI with a partner who can build it

The RFI is the only part of the acquisition you can still change

By the time a solicitation is published, the requirement is set, the evaluation criteria are written, and the competitive field is whatever the market research produced. The window in which any of that is still moveable is the request for information, and most responses waste it. They describe a capability, restate the agency's own problem back at it in nicer words, attach a capability statement, and get read for four minutes by a contracting officer building a market research memorandum. A response that shows a working thing and a path to deploy it inside the agency does something different: it changes what the agency believes is possible in the schedule and budget it has.

This is written for the capture manager shaping an acquisition that has not been released yet, who is deciding how much to invest in an RFI response and what a specialist engineering partner would add to it. The argument is that the marginal return on the RFI is higher than on almost anything else in the capture, and that the return comes from demonstrated capability rather than from length.

What the agency is actually doing with your response

Understanding the reader changes the writing. An RFI response is read by a small group with different questions.

The contracting officer is conducting market research and needs to document what the market can do, whether adequate competition exists, what size and socioeconomic categories are represented, and whether a set-aside is supportable. This reader is looking for facts to cite in a memorandum.

The program office technical lead is trying to find out whether the thing they want is buildable in the time they have, and what it would cost. This reader is the one who can still change the requirement, and the one almost nobody writes to.

The requirements author, often a contractor supporting the program office, is drafting a performance work statement and looking for language, structure and evaluation approaches to borrow. Text that is clear, specific and reusable has a way of appearing in the eventual statement of work.

Three readers, three different jobs. A response that serves only the first is a capability statement. A response that serves the second and third shapes the acquisition.

Why a demonstration outperforms a description

An RFI response that describes an approach asks the reader to imagine the result. A response that shows a result asks the reader to react to something. Those are different cognitive tasks and they produce different outcomes.

The mechanism is specific. A program office with an ambitious requirement and an uncertain schedule is carrying a private doubt about whether the thing is achievable at all. Everything in the market research either confirms that doubt or removes it. A vendor describing a phased approach with a discovery period confirms it. A vendor showing a pipeline that already ingests documents of the kind the agency holds, extracts structured fields with confidence scores, and produces an evaluation report against a labeled sample removes it. The technical lead who sees the second one starts thinking about a shorter schedule and a more ambitious scope, and that thinking ends up in the requirement.

There is a second mechanism, quieter and just as useful. A demonstration built on public data of the same shape as the agency's data forces the team to encounter the real engineering problems before the proposal. The multi-column layouts, the tables that break across pages, the entity matching with no authoritative identifier, the throughput at realistic volume. Teams that build the demonstration write a technical volume grounded in what they learned. Teams that write the volume first describe an approach nobody has tested, and it reads that way to an evaluator who has built things.

How to build the demonstration without agency data

The obvious objection is that the agency's data is not available before award. That is true and it is not the obstacle it appears to be, because what needs proving is the pipeline's behavior on data of the same shape, not on the agency's specific records.

The method is to construct a stand-in corpus with the same structural properties. Federal agencies publish a great deal: regulatory dockets, filings, inspection records, grant documents, public reports, contract files. Assemble a corpus from public sources that matches the target on the properties that break pipelines. Mixed scanned and native documents. Multi-column layout. Tables spanning pages. Forms whose layout changed over time. A wide spread of document lengths. Names and organizations that appear in several inconsistent forms.

Then build the real pipeline against it. Document classification, layout-aware extraction, per-element confidence, entity resolution with blocking and pairwise scoring, and an evaluation step that reports precision and recall on a labeled subset the team created and can describe. The point is not the number. The point is that the method is stated well enough that a technical reader can see it was measured rather than asserted, and that the same pipeline can be pointed at the agency's corpus in week one after award rather than week twelve.

State plainly in the response what the corpus is, where it came from, and how it differs from the agency's data. A reader who catches an overclaim discounts everything else in the document. A reader who sees a stated limitation trusts what remains.

The reference architecture, and why the authorization path belongs on it

Every serious RFI response includes an architecture diagram, and most of them are the same diagram: boxes for ingestion, processing, storage, model, interface, with arrows. That drawing tells the reader nothing they did not know.

The version that carries weight adds the things the program office worries about privately. Draw the authorization boundary on the diagram and mark what sits inside it. Mark which controls are inherited from the hosting platform and which the system provides itself, at least at the family level. Show where each class of data lives and which flows cross the boundary. Show the logging and audit record path, separate from the application logs. Show where a human review step sits in the workflow and what record it produces. Show the evaluation pipeline as a first-class component running in continuous integration rather than as an offline activity.

A diagram like that answers the question the technical lead cannot ask in an RFI without revealing the program's internal anxieties: does this vendor understand what it takes to get a system like this actually approved and running here. It is also, in practice, the content most likely to be reflected in the eventual statement of work, because the requirements author has been struggling to describe exactly this and now has language for it.

Questions are a shaping instrument, not a courtesy

Most RFI responses either ask no questions or ask questions the agency cannot answer without disclosing acquisition-sensitive information. Both waste a channel.

Useful questions have a shape. Each one reveals that the asker has thought about a real constraint, and each one has an answer that would change the design. Whether the target environment already carries an authorization the system could inherit from. Whether historical records are available in their original form or only through a reporting layer. Whether the agency has labeled data for evaluation and who has authority to accept a labeling standard. Whether the workflow requires a human decision step for outputs of a particular class, and what record that step must produce. What the record retention schedule requires of the audit trail.

Asked in an RFI, these do three things at once. They give the agency information it can use, because a question of that kind often surfaces a decision the program office still has open. They signal competence more efficiently than any paragraph of prose. And the answers, when they come in the solicitation or at an industry day, are worth more to the team that asked than to anyone else, because that team already knows what it will do with each answer.

How the integrator and the specialist divide an RFI response

The division that works assigns each part to whoever carries the risk it addresses.

One sequencing rule matters more than the split. The demonstration has to start before the response is written, because it takes weeks and because what it teaches belongs in the text. Teams that decide to build a demonstration two weeks before the RFI is due end up with a screenshot instead.

From RFI to award, and what carries forward

The value of the RFI investment is realized later, in three ways.

The requirement is shaped. If the reference architecture's structure, the evaluation approach, or the phrasing of a performance requirement appears in the eventual statement of work, the team that wrote it starts the proposal already aligned to the requirement, while competitors are interpreting it.

The proposal is faster and better. The architecture, the estimate, the measured results and the identified risks are already written and already tested. A proposal team that starts from that material spends its weeks on the mission narrative and the evaluation criteria rather than on figuring out the technology.

The oral presentation or demonstration factor is already answered. Where a solicitation includes a technical demonstration or an oral presentation, having built the thing months earlier is decisive, because the team can show it running and answer questions about failure modes rather than describing a plan.

Count the cost honestly. Building a real demonstration is weeks of engineering time at risk, and it is not the right investment on every pursuit. It is the right investment where the program is large enough to matter, where the technical approach is a scored factor, and where the agency's private uncertainty about feasibility is the thing standing between the program and an ambitious requirement.

The conflict rules to check before the response goes out

An RFI response is market research, and responding does not create a conflict. Writing the requirement does. FAR Subpart 9.5 governs organizational and consultant conflicts of interest. Under FAR 9.505-2, a contractor that prepares or assists in preparing a work statement for a competitive acquisition generally may not supply that system or those services, subject to stated exceptions. FAR 9.505-1(a) bars a contractor providing systems engineering and technical direction without overall contractual responsibility from supplying the system or its major components, and from being a subcontractor or consultant to a supplier of it.

The practical line is between offering information and drafting the requirement. Answering an RFI, describing an architecture, and showing a demonstration are ordinary market research participation. Being engaged by the program office to write the performance work statement is a different act with a different consequence, and a team that holds an existing support contract with the same office should map that scope against the coming acquisition before it invests in the pursuit. FAR 9.504(a) puts the identification duty on the contracting officer early in the process, which is exactly when the team should have done its own check.

How we work on an RFI response

Precision Federal builds AI systems, data platforms, cloud infrastructure and full-stack web and mobile software and delivers them into production inside federal agencies. On a shaping effort we work as the integrator's specialist partner and we build the demonstration.

In the first two weeks we assemble a public stand-in corpus that matches the target on the properties that break pipelines, stand up the ingestion and extraction path, and report what we found in the data. In the following two to four weeks we build the working pipeline end to end, produce measured results with a stated method, draw the reference architecture with the boundary and control inheritance on it, and draft the technical questions. The integrator's capture team keeps the mission framing, the agency relationship and the acquisition strategy, and decides what goes in.

The integrator keeps the output. The demonstration code, the corpus, the pipelines, the architecture and the evaluation material are assigned by present written assignment, with our pre-existing tooling named, excluded and licensed back perpetually so the assets remain usable on the next pursuit without us. We are a small business, which is relevant where subcontracting content matters to the eventual acquisition. On the response itself we take whichever posture the capture team wants, named or behind the integrator's brand.

Shaping work is priced as a fixed-price increment against a written deliverable list, so the investment is a known number before it starts rather than an open commitment. The first step is one email with a one-page brief: the agency and the anticipated acquisition, what is known about the requirement, the expected release window, what the demonstration would have to show to matter, and the contract instrument. We return a scoped, priced statement of work.

Bottom line

The RFI is the last point at which the requirement is still soft, and the response that changes it is the one that removes the program office's doubt about feasibility. That takes a working pipeline on a corpus of the right shape, an architecture with the authorization boundary drawn on it, results with the method stated, and questions that reveal real constraints. All of it carries forward into the proposal, into the oral presentation, and into the first weeks after award. It costs weeks of engineering at risk, which is why it belongs on the pursuits where the technical approach is scored and the scope is ambitious. On those, it is the cheapest position the capture ever buys.

Frequently asked questions