You can describe a prototype in a sources-sought response when the actual request invites information your team can usefully provide. State what exists today, what has been demonstrated and what remains planned. Do not present an unfinished product as production-ready or assume the buyer will accept a particular maturity level.
The notice’s questions decide what the response needs to answer. A polished product description cannot substitute for missing evidence.
Read the maturity question before writing the pitch
Does the request ask about an existing commercial product, a demonstrated prototype, a development approach, production capacity or delivery by a specified date? Those are different claims.
If the notice does not explain whether developing capabilities are relevant, use its questions process to ask. FAR 15.201 recognizes exchanges about feasibility and industry capabilities, but it does not guarantee acceptance of a particular prototype response.
Use a claim-and-evidence table
| Statement | Evidence to provide | Boundary to preserve |
|---|---|---|
| The prototype performs a function | Dated test, configuration and observed result | Test conditions and functions not tested |
| The product integrates with a system | Demonstrated interface and environment | Planned interfaces or untested versions |
| The team can build units | Actual production evidence or a clearly labeled plan | Capacity, suppliers and lead times not established |
| A feature is on the roadmap | Planned work and dependencies | It is not available capability |
| Delivery is possible by a target date | Supported schedule with assumptions | Dependencies and approvals outside your control |
Do not assign a formal technology-readiness level merely because a general definition sounds close. If the buyer requests a particular maturity framework, use its definitions and retain the supporting assessment.
A clearly hypothetical response
Suppose an RFI asks whether a sensing product can operate outdoors for a stated period. Your team has demonstrated the core sensing function on a laboratory bench but has not completed environmental testing.
A supportable answer says that the laboratory prototype demonstrates the function under the described conditions. Outdoor endurance remains untested. It can explain the planned test and dependencies without claiming the requested endurance result.
That answer gives the buyer information it can interpret. “Field-ready sensing platform” would collapse the demonstrated result and future work into one unsupported claim.
Explain the participation role
For a dated public example, the DARTS sources-sought case separates a requested prototype development capability from evidence of an already demonstrated system. It also shows why technical maturity, cost assumptions and response instructions belong in separate checks.
State whether you would supply the product, develop it, integrate another company’s component or work under a prime. Attribute partner capabilities to the partner and identify what relationship is actually established. Do not turn a possible teaming discussion into committed capacity.
Use the prime and subcontractor comparison if the proposed role is still being decided.
Review the final response
Have the technical owner check every present-tense claim against evidence. Have the commercial owner check commitments, assumptions and delivery language. Follow the notice’s page limits, format and marking instructions, and avoid including sensitive technical details through an unsuitable channel.
The capability statement evidence worksheet helps separate demonstrated facts from plans. This is an educational method, not a government maturity determination or a Deep Fathom proposal-generation service. Source reviewed September 7, 2026.