ot-project-description-builder

OT Project Description Builder

Purpose and operating boundary

Create a milestone-based .docx project description for a Research OT under 10 U.S.C. 4021, Prototype OT under 10 U.S.C. 4022, or a follow-on production action under 10 U.S.C. 4022(f). Define the technical outcome, phase logic, deliverables, completion evidence, Government responsibilities, and agreement-specific controls without making the Agreements Officer's authority, participant-status, successful-completion, or follow-on-eligibility determination.

Produce two separate outputs:

1. One project-description .docx suitable for the agreement file. It contains no cost estimate, should-cost, labor rate, milestone amount, funding profile, Government budget, or pricing conclusion.
2. One MILESTONE HANDOFF TABLE in chat after document validation. It is an internal workpaper for OT Cost Analysis and never a document section, appendix, or companion file.

No external API is required.

Reference map

Load only what the active workflow needs:

• authority-and-scope-rules.md before stating authority, participant status, contribution treatment, prototype scope, or follow-on provisions.
• question-blocks.md when collecting or confirming inputs.
• document-specification.md in full before building the .docx.
• professional-product-standard.md before building the .docx.
• handoff-specification.md before presenting the chat-only milestone handoff.
• validation-gates.md before generation and again before delivery.
• runtime-adaptation.md when selecting input, document-generation, rendering, validation, or delivery capabilities.

Non-negotiable gates

1. Correct authority: 10 U.S.C. 4021 covers basic, applied, and advanced research. 10 U.S.C. 4022 covers prototype projects. Section 4022(f) covers follow-on production contracts or transactions. Never label a prototype as a 4021 action.
2. Authority is supplied, not selected: Explain the three paths when needed, but require the user or Agreements Officer to identify the authority. Do not default an uncertain request to Prototype OT.
3. Correct prototype conditions: Under 4022(d)(1), Path A is significant participation by a nontraditional defense contractor or nonprofit research institution; Path B covers all significant non-Government participants being small businesses or nontraditional defense contractors; Path C requires at least one-third of total project cost from non-Federal sources; Path D is a senior procurement executive's written exceptional-circumstances determination. There is no Path D competition-commitment option.
4. Status and contribution facts are not inferred: Do not decide nontraditional status, small-business status, significant participation, the applicable 4022(d) path, contribution ratio, contribution valuation, or fee. Record the user's approved facts and source. Research and follow-on production contribution arrangements are also supplied, not defaulted.
5. TRL is optional: Use TRL only when supplied or genuinely useful. A prototype can address a proof of concept, model, process, agile development, novel commercial application, operational utility, or a combination. Do not force every project through a hardware-style TRL ladder.
6. Milestones precede prose: Present the derived phase and milestone structure, including completion evidence and pending decisions, then end at the approval question. Do not generate the .docx in the same response.
7. Artifact separation: Keep pricing, labor hours, contribution arithmetic, cost figures, funding, and skill-routing language out of the document. Keep the milestone handoff in chat only.
8. Data rights are negotiated: Record the supplied posture by deliverable and distinguish background from agreement-generated material. Do not state that FAR or DFARS clauses control unless the agreement incorporates them.
9. Follow-on language stays conditional: Record user-supplied predecessor, competitive-selection, and successful-completion facts without deciding eligibility. Do not promise award or say 4022(d) is a follow-on requirement.
10. Every placeholder closes: Each [TBD] must name an owner, trigger, and disposition method in Constraints and Assumptions.
11. Independent document validation: Run the bundled validator, render the document, inspect every page, fix defects, and repeat. Do not treat DOCX creation alone as proof of usability.