Which requirements can a vendor actually be held to?
The agent reads each as-bid capability line from the SOW/RFP, flags aspirational language a test range cannot score, and decomposes it into verifiable requirements — each carrying the four attributes that make it contractible: a trigger, a concrete threshold/metric, a verification method, and an authoritative source. Its Testability Index is how many of those four are present. You confirm or override each call.
For one capability line, what does the test range get?
Pick a capability line to see its full decomposition scored: the average Testability Index, the share of clauses that name a verification method, and how many clauses are fully contractible (4/4). The table below is the draft Requirements Verification Traceability Matrix — hand it to the test authority as the verification backlog.
| Testable requirement | Trigger | Threshold / metric | Method | Authoritative source | Index |
|---|
Across the portfolio, what does untestable language cost?
A requirement that is not testable as written gets discovered as a problem downstream — in test, or worse, in production — where fixing it costs far more than specifying it correctly up front. That spread is the avoidable exposure. This is the figure a program review needs: the rework and verification churn untestable requirements carry, and the program obligations they sit against. Adjust the cost drivers — every input is visible and editable.
How the agent works (and its limits)
Two cooperating agents share one knowledge base. The decomposition agent retrieves the governing authoritative text for each capability line (DoDD 3000.09 for human-judgment and decision authority; JCIDS CDD/CPD for KPPs and KSAs; the TEMP for verification method; MOSA / UMAA / UCI for open-architecture conformance) and rewrites the as-bid language into verifiable requirements. For each clause it identifies the four attributes that make a requirement contractible — trigger, threshold/metric, verification method, authoritative source — and flags aspirational language. Every decomposition is agent-proposed; a human reviewer confirms or overrides, and that state is what the summary reflects.
The verification agent scores a line's decomposition into the numbers a source-selection board or a test planner needs: the average Testability Index, verification coverage, and the count of fully-contractible clauses. A clause's index can never be raised by asserting it — only by supplying the missing attribute.
Architecture. This build runs against a FastAPI backend that puts the reasoning model behind one swappable interface (Anthropic Claude via Bedrock in cloud/GovCloud; an open-weight model on vLLM/Ollama for air-gapped range networks; a deterministic mock for offline demos) and retrieval behind another (pgvector on Postgres in production; in-memory lexical for the demo). The frontend is dependency-free static files and does not know which is live.
Limits. Decompositions are engineering and acquisition judgements: the agent accelerates the requirements analysis, it does not replace the program office, the operational test authority, or contracting review. Nothing here is a determination of adequacy, compliance, or airworthiness. The capability set, thresholds, and program figures in this build are illustrative and abbreviated for demonstration.