OT Project Description Builder
Overview
This skill walks an agreements officer (AO) or program office through structured prototype scope decisions and assembles the answers into a milestone-based project description for an Other Transaction agreement. The core insight: OTs structure work around technology maturation phases and technical milestones, not task/subtask CLINs or performance objectives. The program office defines what must be demonstrated at each gate, and the performer proposes how to get there.
Outputs (TWO SEPARATE ARTIFACTS -- never combined):
-
A .docx project description with milestone-based structure -- the agreement attachment. This document contains NO cost estimates, NO should-cost figures, NO funding profiles, NO cost-sharing calculations, and NO government budget data. It defines what the prototype must achieve, by when, and what constitutes success at each milestone.
-
A milestone handoff table -- an internal government workpaper presented in chat output only at the end of the skill run. This is the data handoff to the OT Cost Analysis skill. It is NEVER embedded in the project description document. It is NEVER saved as a companion file. It exists solely as a markdown table in the conversation so the user can review it and the downstream OT Cost Analysis skill can consume it.
No external APIs required. This is a decision tree + document generation skill.
Statutory basis: 10 USC 4021 (authority to carry out prototype projects), 10 USC 4022 (other transaction authority and follow-on production), 10 USC 4003 (definition of prototype project). NOT FAR-based. OTs operate outside the FAR; the project description replaces the SOW/PWS as the primary scope document attached to the agreement.
Related policy: DoD OT Guide (USD(R&E) / USD(A&S)), individual service OT policies (Army AFC, Navy NSWC, Air Force AFRL/AFWERX guidance). These are policy references, not binding regulations like the FAR.
Workflow Selection
Workflow A: Full Build (Default)
User needs a project description from a prototype concept or objective. Execute Acquisition Context Intake, then all three phases. Triggers: "write an OT project description," "build a prototype agreement," "I need a project description for an OT," "scope a prototype."
Workflow B: Convert from Existing Document
User has an existing SOW, SOO, BAA white paper, or proposal abstract and needs it developed into an OT project description. Start with Phase 0 (document intake), then Phases 1-3. Triggers: "convert this SOW to an OT project description," "develop this white paper into a prototype scope," "we have a BAA response and need a project description."
Workflow C: Scope Reduction
User has an existing OT project description or cost analysis output that exceeds budget or schedule. Walk through the milestone structure to identify what to cut or defer, then produce a revised document. Triggers: "this prototype is too expensive," "we need to reduce scope," "can we drop a phase," "defer TRL 6 to a follow-on."
Acquisition Context Intake
Before diving into the scope decision tree, collect four framing decisions that shape everything that follows. Ask these up front, in a single pass, before Block 1.
Intake Question 1: OT Type
| Type | Statutory Authority | Use When |
|---|---|---|
| Prototype | 10 USC 4021 | R&D, technology maturation, proof of concept through system demo |
| Production Follow-On | 10 USC 4022(f) | Transitioning a successful prototype to limited or full-rate production |
| Research | 10 USC 4021 | Basic or applied research, typically pre-TRL 4 |
If the user is unsure, default to Prototype -- it covers the widest range of OT work and is the most common. Production follow-on requires a completed prototype OT as a predecessor. Research OTs are less common and typically issued by service labs (NRL, ARL, AFRL).
Intake Question 2: Performer Type
| Type | Cost-Sharing Implication | 10 USC 4022(d) Path |
|---|---|---|
| Nontraditional Defense Contractor (NDC) | NDC participation satisfies 4022(d)(1)(A) | No cost share required if NDC has significant participation |
| Traditional + NDC Team | NDC sub or team member satisfies 4022(d)(1)(A) | Same as above |
| Small Business | Small business significant participation satisfies 4022(d)(1)(B) | No cost share required |
| Consortium Member | Depends on consortium structure and awardee | Varies by consortium agreement |
| Traditional (sole, no NDC/SB participation) | Must have cost-sharing arrangement per 4022(d)(1)(C) | Cost share required (typically 1/3 performer) |
| Traditional (with follow-on competition commitment) | Competitive follow-on satisfies 4022(d)(1)(D) | No cost share required but must compete production |
An NDC is defined at 10 USC 3014: an entity that is not currently performing, and has not performed for the prior one-year period, any DoD contract or subcontract subject to full Cost Accounting Standards (CAS) coverage under 41 USC 1502. The test is CAS full-coverage status, not a dollar threshold on contracts. Nonprofits performing DoD-relevant research and any other entity the contracting officer determines as nontraditional also qualify. The performer type determines whether cost-sharing is required and shapes the project description's cost-sharing section. Do NOT cite a dollar-value rule (e.g., "$500K+ in prior year"). That is not the statutory test and will cause mis-determinations.
Intake Question 3: TRL Entry and Exit
| TRL | Description | Typical OT Phase |
|---|---|---|
| 1 | Basic principles observed | Research OT |
| 2 | Technology concept formulated | Research OT |
| 3 | Proof of concept | Early Prototype |
| 4 | Component validation in lab | Prototype (design/build) |
| 5 | Component validation in relevant environment | Prototype (build/test) |
| 6 | System demo in relevant environment | Prototype (test/demonstrate) |
| 7 | System prototype demo in operational environment | Late Prototype / Pre-production |
| 8 | System complete and qualified | Production Follow-On |
| 9 | System proven in operational environment | Production |
Collect: TRL at project start (entry) and TRL target at project end (exit). This determines the number of phases and the nature of milestones. Most prototype OTs span TRL 3-6 or TRL 4-7. Research OTs are typically TRL 1-3 or TRL 2-4.
If the user gives a range wider than 4 TRL levels (e.g., TRL 2 to 8), flag that this may exceed typical prototype OT scope and suggest breaking into two agreements or phasing with go/no-go gates.
Intake Question 4: Consortium or Direct
| Approach | Description | Agreement Structure |
|---|---|---|
| Direct OT | Government awards directly to a single performer | Bilateral agreement between government and performer |
| Consortium-brokered | Award through a consortium organization | Agreement may route through consortium (DIU, AFWERX, NavalX, NSTXL, SOSSEC, MTEC, etc.) |
If consortium: identify which consortium. Consortium OTs often follow consortium-specific templates and add a management fee (typically 3-5%). The project description content is the same; the agreement wrapper differs.
Why these four questions come first
OT project descriptions must be shaped by the statutory authority, the cost-sharing path, the technology maturation scope, and the agreement structure. A TRL 3-6 prototype with an NDC performer reads differently from a TRL 6-7 production-readiness effort with a traditional prime requiring cost-sharing. Collecting these up front means Phase 1 can frame scope questions appropriately.
Phase 0: Document Intake (Workflow B Only)
When the user provides an existing document (SOW, SOO, BAA white paper, proposal abstract):
- Read and extract. Parse for: technical objective, current state of technology, systems involved, TRL in