Government proposals and evaluation debriefs as AI training data

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

What a usable proposal-and-debrief record contains

A usable record joins one solicitation to one offeror's submission and the government's documented reaction to it. Without that join you have either public RFP text, which anyone can collect from SAM.gov, or unlabeled proposal prose, which teaches style but not what wins. The commercial value sits in the link, so the record must preserve stable identifiers across documents.

The core components are:

• Solicitation package: RFP or RFQ, Section L (instructions), Section M (evaluation factors), SOW/PWS, CDRLs, amendments and Q&A responses. These are public and can be refetched by notice ID.
• Submitted proposal: technical, management, past performance and price volumes as submitted, with page limits and formatting intact, plus any final proposal revision after discussions.
• Compliance matrix: the contractor's requirement-to-section crosswalk, usually an Excel sheet keyed to L/M paragraph numbers and "shall" statements.
• Debriefing: the written or transcribed government debrief, plus the contractor's own capture notes.
• Outcome: award or loss, the awardee if known, protest status and any corrective action.

Generic RFP response libraries are a different product; see licensing RFP responses and proposals for that intent. This page covers the government-specific pairing of proposals with evaluation outcomes, part of the wider industry-specific operational data guide.

Why the debriefing is the label you want

The debriefing is the best outcome label because the FAR prescribes what it must contain for negotiated procurements. Under FAR 15.506, a postaward debriefing must cover the government's evaluation of the offeror's significant weaknesses or deficiencies, the overall evaluated cost or price and technical rating of the awardee and the debriefed offeror, past performance information on the debriefed offeror, the overall ranking if one was developed, and a summary of the rationale for award. The agency also keeps an official debriefing summary in the contract file. FAR section numbers on this page are as of October 2026; the FAR overhaul is rewriting parts through agency class deviations, so confirm current numbering with counsel.

That structure maps directly onto training targets. Weaknesses and deficiencies give span-level negative labels on proposal sections, ratings give ordinal targets per evaluation factor, and the award rationale gives a short natural-language explanation. For larger DoD awards, DFARS 252.215-7016 adds follow-up questions and, at the top threshold, a redacted source selection decision document.

Two limits shape what a debrief can teach. FAR 15.506 bars point-by-point comparisons with other offerors' proposals and the release of FOIA-exempt material such as trade secrets and cost breakdowns, so debriefs describe one bid in isolation. Debriefs are also uneven: some are a two-paragraph letter, others a full slide deck with factor-level findings, so record the debrief type as a feature.

Who can license which documents

The contractor that wrote the proposal is generally the party that can license it, because FAR 3.104-4 allows a contractor to disclose its own bid or proposal information while barring disclosure of bid, proposal and source selection information to unauthorized persons. In practice, rights review has to work document by document rather than at the proposal level.

Ask suppliers which proposals carry restrictive legends, which teaming agreements restrict reuse of partner content, and whether any debrief arrived with handling instructions. Contractors weighing this from the supply side can read licensing data as a government contractor.

CUI, ITAR and EAR screening before anything moves

Screening for controlled information must happen at the supplier, before export, because some content cannot legally go to an AI vendor at all. 32 CFR Part 2002 governs how executive-branch CUI is identified, handled and decontrolled [2], and defense proposals often quote or summarize CUI from the solicitation's technical attachments, CDRLs or prior contract deliverables.

Export controls are the second filter. ITAR defines technical data as information required for the design, development, production, manufacture, operation or maintenance of defense articles [3], and technical volumes for weapons-system, space or sensor programs can cross that line. Under the EAR, releasing controlled technology to a foreign person inside the US can be a deemed export [4], which matters if your annotation team or model developers include foreign nationals.

Practical screening steps for a supplier's export:

1. Exclude any proposal with classified annexes and any program with a DD Form 254.
2. Search for CUI banner markings, "CUI//" category markings, distribution statements (B through F), and ITAR or EAR warning legends, and drop the whole document when one appears.
3. Run a keyword and classifier pass for ECCNs, USML categories, and part-level design parameters in technical volumes.
4. Have the contractor's export control officer sign off on the release list.
5. Prefer civilian-agency procurements (IT services, professional services, facilities) when the use case does not need defense content.

Treat this as a release gate, not a cleanup task. Once controlled content enters a training corpus, removing it from model weights is not a reliable remedy.

Procurement integrity and personal data limits

Procurement integrity rules mean a clean dataset contains only the supplier's own bid material plus public and received documents. FAR 3.104-4 restricts disclosure of contractor bid or proposal information and source selection information, and requires source selection material to carry the legend "Source Selection Information-See FAR 2.101 and 3.104". Any page with that legend, or any competitor's pricing or technical approach obtained informally, should end the review for that document.

Pre-proposal material carries similar care. FAR 15.201 encourages industry days, RFIs and draft RFP exchanges but requires them to stay consistent with procurement integrity requirements [1], so meeting notes that record government officials' informal remarks deserve the same scrutiny as debriefs.

Proposals are also full of personal data: key personnel resumes, clearance levels, salary-adjacent labor category mappings, and reference contacts in past performance volumes. Expect names, emails, phone numbers and resume details to be removed or replaced, and remember that a resume is identifiable from its career history alone. NIST SP 800-188 is a useful reference on the limits of traditional de-identification [5]. Government-authored past performance evaluations, such as CPARS reports, are a separate question and should be confirmed with counsel before any inclusion.

A record schema for compliance-matrix extraction and drafting

The schema should keep requirement IDs stable across the solicitation, the compliance matrix and the debrief, so a single "shall" statement can be traced to the proposal section that answered it and to any weakness the evaluators cited. JSON Lines works well because each record is one UTF-8 JSON object per line [6], which streams cleanly into SFT and evaluation pipelines.

Illustrative example: invented to show structure; it does not describe an available dataset.

{"record_id": "opp-000417-req-L.3.2.1",
 "solicitation": {"notice_id": "XXXX-26-R-0001", "agency": "civilian", "naics": "541512", "set_aside": "SB", "eval_basis": "best_value_tradeoff"},
 "requirement": {"source": "Section L.3.2.1", "text": "The offeror shall describe its approach to transition-in within 30 days.", "eval_factor": "M.2 Technical Approach"},
 "proposal_response": {"volume": "I", "section": "2.3", "page_span": [14, 16], "text_ref": "vol1_s2.3.txt", "author_party": "prime"},
 "compliance_matrix_row": {"status": "compliant", "cross_ref": "Vol I 2.3"},
 "debrief": {"type": "written_postaward", "factor_rating": "Acceptable", "findings": [{"kind": "weakness", "text": "Transition staffing plan lacked named leads.", "maps_to": "L.3.2.1"}]},
 "outcome": {"result": "loss", "protest": "none"},
 "screening": {"cui_check": "pass", "export_check": "pass", "pii_method": "replace_names_v2", "partner_content": "excluded"}}

Useful splits follow from this shape. Requirement-to-section pairs train compliance-matrix extraction, sections tied to strengths train drafting, and factor-level ratings support win-probability models. Hold out whole opportunities, not individual requirements, so the same solicitation never appears in train and test; see private evaluation sets versus public benchmarks for why held-out operational data matters.

Quality checks before you train

Quality problems in this data come mostly from broken links between documents, not from the text itself. Check these before signing:

• Version alignment: the proposal matches the final amendment it answered, and final proposal revisions replace initial submissions rather than duplicating them.
• Label coverage: the share of opportunities with a written debrief versus only an award notice; losses without a debrief give a result but no reason.
• Win/loss balance: contractors keep wins more carefully than losses, which skews win-probability models.
• Template leakage: boilerplate reused across dozens of proposals can dominate drafting data; deduplicate at the paragraph level.
• Redaction artifacts: replaced names and rates should be consistent tokens, so drafting models do not learn to emit "[REDACTED]".
• Agency mix: NAICS, contract type (FFP, T&M, cost-plus) and evaluation basis (LPTA versus best-value tradeoff), since LPTA debriefs carry little qualitative signal.

The AI training data compliance guide covers the documentation side, including what to keep for your own training-data disclosures.

How SourceX approaches this data

SourceX sources operational datasets from US companies on request and manages the commercial process, including licensing agreements and ongoing purchases. Proposal and capture archives fall within the documents and workflow records it looks for, but nothing is held in stock and a request does not guarantee a match. Buyers describe the data, not the businesses, and SourceX looks for US businesses that hold it; every release is approved by the supplying company.

Each dataset is rights-reviewed for ownership and consents and delivered under a license defining records, uses, term and delivery. Personal details such as names, emails and phone numbers are removed or replaced before delivery, the method is recorded and a sample is checked, though no method is perfect. Delivery runs through private, access-controlled workflows only after an executed agreement and supplier approval. Procurement teams can also review buyer guidance for procurement services, and you can start a data request as a buyer.

Request government proposal and debrief data

SourceX sources operational datasets from US companies on request, including documents and workflow records, and manages licensing under terms agreed per deal. Every dataset is rights-reviewed and released only with the supplying company's approval. Describe the solicitations, document types and outcome labels you need at SourceX for buyers.