Sources-sought case / September 7, 2026
The buyer wants a technical response. A product brochure does not answer the RFI.
The Army's DARTS request asks about developing a TRL 7 prototype using existing commercial components and mature solutions. Its questions reach architecture, component maturity and cost assumptions.
This source-backed example shows how to prepare a supportable capability response. It does not turn a market-research request into a solicitation or establish that a respondent already has a completed TRL 7 system.
01 / Prepare the right response
Separate the proposed system from the evidence held today.
01.1
Development objective
Explain the path to the requested prototype outcome. Do not describe planned integration or testing as completed work.
01.2
Component maturity
Give the basis for each maturity claim and identify the tested configuration. A mature component does not establish maturity of the integrated system.
01.3
Cost assumptions
Make the assumptions behind the estimate visible. An unsupported total gives the buyer little basis for evaluating the proposed development approach.
DARTS RFI sections 1.3, 2.1, 2.2 and 3.0, read in the official SAM.gov notice.
02 / Where Deep Fathom fits
Use the response method before evaluating a product.
Prototype-response intelligence is a research concept here. These guides provide an educational method. A compliance-platform evaluation becomes relevant only when a separate assessment or compliance-evidence problem appears.
- 01
Assign the technical answer
Ask the person responsible for the proposed capability to review the present-tense claims.
- 02
Record the evidence
Preserve test conditions, configuration and limitations alongside each supported statement.
- 03
Label development work
Separate existing capability, integration work and planned validation.
- 04
Check the response instructions
Review format, page limit, permitted material and unresolved timing with the actual notice.
03 / Read the source questions
Marketing material alone is insufficient.
Marketing materials are not considered a sufficient response to this RFI.
| Source section | Requested subject | Review action |
|---|---|---|
| 1.3 and 2.1 | Development objective, system architecture and component maturity. | Describe what exists and the evidence supporting the proposed approach. |
| 2.1 | Architecture tradeoffs, reasoning and assumptions. | Explain the choice and the limitations, not just the selected component names. |
| 2.2 | System, installation and maintenance estimates with assumptions. | Give each estimate a basis and preserve dependencies. |
| 3.0 | Word/PDF white paper, 15-page limit excluding an optional compliance matrix. | Check the response shape before assembling a brochure. |
04 / A supportable response record
Give the technical owner something precise to review.
Synthetic example: a team has tested two components separately but has not demonstrated their combined behavior. Its response should identify the component tests, the integration plan and the untested system-level result. Calling the whole solution demonstrated would overstate the evidence.
Use the capability-evidence CSV to connect each claim to a source, configuration, date and limitation. The team should then compare those records with the RFI's actual questions.
A response owner can make a reasoned decision to answer only when the requested information is supportable. The notice's voluntary, non-solicitation posture does not make accuracy optional.
05 / Preserve the stage and timing limits
This is a request for information, not an award promise.
The source disclaims a commitment to a later procurement and compensation for preparing the response. The listed schedule does not establish a future award or participation entitlement.
The EDT/EST discrepancy remains open. Follow notice history and obtain clarification before relying on a precise submission time. This page does not reproduce restricted technical material or claim a complete attachment review.
Platform evaluation / A separate compliance need
Identify the compliance-evidence question, if there is one.
Use the public guides to prepare the technical response. If the work exposes an assessment or compliance-evidence gap, describe that problem to Deep Fathom for a relevant platform demonstration.
Do not include CUI, credentials, proprietary technical details or controlled attachments in this form.
Limitations
- One official sources-sought example, not a prototype-opportunity market census.
- Proposed development capability is distinct from a completed TRL 7 system.
- No proposal-writing, maturity-certification or opportunity-matching product is offered.