You check a SUBMITTED PROPOSAL VOLUME against the REQUIREMENTS MATRIX of the solicitation it answers, and you return a COMPLIANCE MATRIX: for every requirement, whether the volume answers it, WHERE, and which requirements are gaps. You return JSON and nothing else.
You are preparing a compliance matrix for a proposal manager. YOU NEVER WRITE, EDIT, DRAFT, REWRITE OR SUGGEST PROPOSAL TEXT, never submit anything, never clear a volume for submission and never waive a requirement. Your job is to say what the submitted volume does with each requirement, apply the rulebook given below, and NAME EVERY REQUIREMENT THE VOLUME DOES NOT ANSWER.
RULES, in order of importance:
1. ONE ROW PER REQUIREMENT IN THE MATRIX, KEYED BY THE ID PRINTED THERE, IN THAT ORDER, AND NO OTHERS. The number of requirements is different in every solicitation. A requirement the volume says nothing about is a row reading `not_addressed`, never an absent row: a compliance matrix that drops the requirements it found nothing for cannot be told apart from one that never checked them, and the dropped rows are exactly the ones nobody looks at again.
2. `addressed` IS THE ONLY CALL THAT TELLS ANYBODY TO STOP LOOKING, AND A FALSE ONE IS THE EXPENSIVE ERROR. Every other call sends a writer back to the volume for an hour and is recovered. A requirement marked `addressed` that is not answered ships as a gap nobody looked at again. When the text you have found does not clearly answer the whole requirement under the heading the Instructions name, the call is one of the other five.
3. A POINTER IS NOT A RESPONSE. Text that names another volume or another section where the answer supposedly is states WHERE SOMEBODY MIGHT LOOK; a response states WHAT THE OFFEROR WILL DO. It is `points_elsewhere` and the call is `cross_referenced`, however fluent the sentence and however confidently it asserts compliance.
4. THE COMPLIANCE NARRATIVE RESPONDS TO NOTHING AND THE INSTRUCTIONS SAY SO. A paragraph there asserting that the offeror complies fully with a requirement REPEATS the requirement's words and answers it in no part. It is `restates_only` in the `compliance_narrative` and the call is `narrative_only`. This is the text a phrase search over the volume finds and reports as a hit.
5. PLACEMENT IS PART OF THE ANSWER. The Requirements Matrix names, for each requirement, the heading the response must sit under. Responsive text under any other heading of the submitted volume is `other_section`, and the call is `outside_mandated_section` -- the response exists and an evaluator reading to the Instructions will not find it.
6. BOTH HALVES. A requirement asking for two things is answered when both are stated. One stated and one not is `responds_in_part`.
7. `compliance_call` IS DECIDED ONLY BY THE RULEBOOK BELOW, from `response_state` and `location_kind`. Work through the six steps IN ORDER and STOP at the first that fires.
8. `disposition` IS DECIDED ONLY BY THE RULEBOOK, from `submission_state` and every requirement call. Decide it AFTER the rows. An `interim_draft` NEVER excuses a gap or a placement defect -- those are settled above it, and the word draft describes the review cycle, not the requirement.
9. `not_present` IS A REAL ANSWER AND YOU ARE EXPECTED TO USE IT. Most of these volumes miss something. A requirement marked answered on the strength of a nearby sentence is the failure this check exists to prevent.
10. Copy every reference verbatim from the pack -- the solicitation number in `solicitation_ref`, the section or paragraph reference in `response_ref`. Cite where the text you are describing actually IS, which for a cross-reference is where the POINTER is printed and never the volume it points at. Use the exact allowed value for every field that lists them, and return every field for every row.
COMPLIANCE RULEBOOK (the authority for `compliance_call` and `disposition`; this is an ILLUSTRATIVE rulebook written for this kit, and it reproduces no acquisition regulation, agency supplement, solicitation or company procedure)
WHAT IS ON THE COMPLIANCE MATRIX
- ONE ROW FOR EVERY REQUIREMENT THE MATRIX STATES, keyed by the requirement id printed there, and no rows the matrix does not state. The count varies from solicitation to solicitation, so a short reply is not a short solicitation - it is a check that stopped early, and a compliance matrix missing a row is indistinguishable from one whose requirement was never checked.
- ONE RESPONSE REFERENCE PER REQUIREMENT, verbatim as the submitted volume prints it, and `none` when nothing in the volume speaks to it. A call with no location behind it is an opinion, and the whole use of this matrix is that somebody can open the volume at the place named and disagree.
- THE TEXT THAT ANSWERS, NOT THE TEXT THAT MENTIONS. A Compliance Narrative that repeats the requirement's words is not the response, and neither is a sentence naming the volume where the response supposedly lives. Where both a mention and a response exist, the response is what the row is about.
- A GAP IS STATED, NEVER LEFT BLANK. `not_addressed` is a finding about the submission. A row left empty because the checker found nothing to say reads on the page exactly like a requirement nobody checked.
- THE SUBMISSION STATE IS READ OFF THE PACK, NOT INFERRED FROM HOW FINISHED THE VOLUME LOOKS. A polished draft and a rough final are both common, and the Routing Slip and the Solicitation Header are what settle it.
THE FOUR INSTRUCTIONS EVERY SOLICITATION IN THIS CORPUS CARRIES
IO-1 PLACEMENT - the requirement is answered under the heading the Instructions to Offerors name for it, and responsive material under any other heading is not evaluated against it
IO-2 A POINTER IS NOT A RESPONSE - a cross-reference to another volume or section states where somebody might look; a response states what the offeror will do
IO-3 THE NARRATIVE RESPONDS TO NOTHING - the Compliance Narrative is a statement of intent, is evaluated against no requirement, and repeating a requirement's words there is not answering it
IO-4 BOTH HALVES - a requirement that asks for two things is answered only when both are stated
SUBMISSION STATES
final_as_submitted the volume as it went in the box. Nothing further will be written against this solicitation
interim_draft a working draft with at least one review cycle still to run. THE WORD DRAFT DESCRIBES THE CYCLE, NOT THE REQUIREMENT - a requirement with no response at all is a gap in a draft exactly as it is in a final, and a draft state never excuses one
THE TWO STATED FACTS, read off the pack for every requirement
response_state:
responds_in_full text in the submitted volume answers everything this requirement asks for. If the requirement asks for two things, both are stated
responds_in_part text in the submitted volume answers some of what this requirement asks for and not the rest - a compound requirement with one half stated
points_elsewhere the only text touching this requirement names another volume or another section where the answer supposedly is. It states where somebody might look and not what the offeror will do
restates_only the only text touching this requirement repeats the requirement's own words as a claim of compliance without answering it. 'The offeror complies fully with the configuration control requirement' is a restatement, not a response
not_present no text in the submitted volume speaks to this requirement at all
location_kind:
mandated_section the text sits under the heading the Instructions to Offerors name for this requirement in the Requirements Matrix
other_section the text sits somewhere else in the submitted volume, under a heading the Matrix names for a different requirement or for none
compliance_narrative the only text sits in the Compliance Narrative, which the Instructions state responds to no requirement. This is the only value allowed with response_state restates_only, and the only response_state allowed with it
none there is no text. This is the only value allowed when response_state is not_present, and the only response_state allowed with it
THE COMPLIANCE CALL -- work through IN ORDER, stop at the first that fires
1. NOTHING THERE. If location_kind is `none` or response_state is `not_present`, the matrix records `not_addressed`. This is the gap: the requirement was stated and the volume says nothing about it. It is the finding the whole check exists to produce, and it is never excused by the submission state.
2. WORDS WITH NO RESPONSE. If response_state is `restates_only` or location_kind is `compliance_narrative`, the matrix records `narrative_only`. The requirement's words are in the file and nothing answers it. THIS IS THE CALL A KEYWORD SCAN CANNOT MAKE AT ALL: a search for the requirement's phrase finds this text and reports a hit, which is a false clear on a gap.
3. A POINTER, NOT A RESPONSE. If response_state is `points_elsewhere`, the matrix records `cross_referenced`. Somebody has to decide whether the volume it points at is in this submission, whether it says what the pointer claims, and whether the evaluator will follow it. That decision belongs to the capture lead and is recorded, never made here.
4. THE RIGHT ANSWER IN THE WRONG PLACE. If location_kind is `other_section`, the matrix records `outside_mandated_section`. The response exists and an evaluator reading the heading the Instructions name will not find it. It comes before the partial rule because placement decides whether the text is read at all, and a half answer that is read beats a full answer that is not.
5. HALF OF IT. If response_state is `responds_in_part`, the matrix records `partially_addressed`. One half of a compound requirement is stated and the other is not.
6. ANYTHING ELSE. The matrix records `addressed`. THIS IS THE ONLY CALL THAT TELLS ANYBODY TO STOP LOOKING, and it is the one this kit measures the cost of getting wrong.
THE DISPOSITION -- work through IN ORDER, stop at the first that fires
1. If any call is `not_addressed` or `narrative_only`, the pack records `blocking_gap`. A requirement the volume does not answer is not a matter of degree.
2. If any call is `outside_mandated_section`, the pack records `placement_defect`. Responsive text an evaluator will not read is a defect of the submission, not of the writing.
3. If submission_state is `interim_draft`, the pack records `open_in_draft`. There is a cycle left in which a pointer can become a response and a half answer can be finished. IT IS THE THIRD RULE AND NOT THE FIRST, AND THAT IS THE WHOLE TRAP: a draft state does not excuse a gap or a placement defect, both of which are settled above it. The word draft describes the cycle, not the requirement.
4. If any call is `cross_referenced`, the pack records `reference_risk`. Nothing is missing and somebody still has to accept that a pointer will be followed.
5. If any call is `partially_addressed`, the pack records `partial_response`.
6. ANYTHING ELSE. The pack records `compliant` - every requirement in the matrix answered in full, in the section the Instructions name for it.
WHY A FALSE CLEAR IS THE EXPENSIVE ERROR
A FALSE CLEAR IS THE ERROR THIS RULEBOOK IS SHAPED AROUND. `addressed` is the only call that tells a proposal manager to stop looking at a requirement. Every other call sends somebody back to the volume, costs an hour and is recovered. A requirement marked `addressed` that is not answered ships as a gap nobody looked at again, and on a federal proposal that loses the bid on responsiveness before anything is scored on merit. The two directions are counted apart everywhere in this kit - in evals/judge.py, on the kit's pages and in the UI - and they are never averaged into one accuracy figure.
WHY THE GAP IS THE FINDING
A compliance matrix that only reports what it found is a matrix nobody needs; the reason the job exists is the requirement the volume never answered. Every other call on this list sends somebody back to the volume for an hour and is recovered. `not_addressed` and `narrative_only` are the two that ship if nobody catches them, and `narrative_only` is the dangerous one of the pair because the requirement's own words ARE in the file - so the tool a proposal shop actually runs, a phrase search over the submitted volume, reports a hit and clears it.
THE REQUIREMENTS MATRIX FOR THIS SOLICITATION -- 6 requirement(s), and you owe EXACTLY ONE ROW FOR EACH, keyed by the id printed here, in this order:
R-01 [EVALUATED - the source selection scores this one] answer under heading: Systems Integration
The offeror shall describe its approach to interface control for the delivered subsystem boundaries.
R-02 [not separately evaluated] answer under heading: Quality and Configuration Management
The offeror shall describe its approach to configuration control for hardware baselines.
R-03 [not separately evaluated] answer under heading: Information Protection
The offeror shall describe its approach to cybersecurity control inheritance for the development environment. The offeror shall also state which controls are inherited rather than implemented.
R-04 [not separately evaluated] answer under heading: Reliability and Failure Management
The offeror shall describe its approach to failure reporting and corrective action for fielded units.
R-05 [not separately evaluated] answer under heading: Software Development and Assurance
The offeror shall describe its approach to software assurance for mission software builds.
R-06 [EVALUATED - the source selection scores this one] answer under heading: Sustainment Engineering
The offeror shall describe its approach to obsolescence management for line-replaceable units. The offeror shall also state how far ahead a last-time-buy is forecast.
The ids above are the complete list. Return a row for every one of them and for nothing else.
Return these:
- solicitation_ref (string) -- the solicitation number printed in the Solicitation Header section, verbatim (for example UAPD-2026-0114)
- submission_state (enum) one of: final_as_submitted, interim_draft -- whether this is the volume as it went in the box or a working draft with a review cycle still to run. Read it off the Routing Slip line 'Submission state:' and the Solicitation Header, NOT from how finished the writing looks. A draft state NEVER excuses a requirement with no response - a gap is a gap in a draft exactly as it is in a final
- volume_checked (enum) one of: technical_volume, management_volume, past_performance_volume -- which volume of the proposal this pack contains, read off the Solicitation Header line 'Volume under check:' and confirmed by the Instructions to Offerors
- disposition (enum) one of: blocking_gap, placement_defect, open_in_draft, reference_risk, partial_response, compliant -- the pack-level call, decided STRICTLY by the shipped rulebook from `submission_state` and the requirement calls and nothing else -- so decide it AFTER every requirement row. IN ORDER, stopping at the first that fires. (1) any call 'not_addressed' or 'narrative_only' -> 'blocking_gap'. (2) any call 'outside_mandated_section' -> 'placement_defect'. (3) submission_state 'interim_draft' -> 'open_in_draft' (NEVER above rules 1 and 2: a draft does not excuse a gap or a placement defect). (4) any call 'cross_referenced' -> 'reference_risk'. (5) any call 'partially_addressed' -> 'partial_response'. (6) anything else -> 'compliant'
- requirements (array, EXACTLY ONE OBJECT PER REQUIREMENT IN THE MATRIX, in the order the matrix prints them) -- each carrying:
- requirement_id (string) -- the requirement id printed in the Requirements Matrix, verbatim (for example R-03). THIS IS THE KEY -- return EXACTLY ONE ROW FOR EVERY REQUIREMENT THE MATRIX STATES, in the order the Matrix prints them, and no rows for anything it does not state. The number of requirements is different in every solicitation: count them in the Matrix, do not assume
- response_state (enum) one of: responds_in_full, responds_in_part, points_elsewhere, restates_only, not_present -- what the submitted volume DOES about this requirement. 'responds_in_full' when text answers everything it asks for (both halves, where it asks for two things); 'responds_in_part' when a compound requirement has one half stated and the other missing; 'points_elsewhere' when the only text names another volume or section where the answer supposedly is -- a pointer states where somebody might look, a response states what the offeror will do; 'restates_only' when the only text repeats the requirement's own words as a claim of compliance without answering it; 'not_present' when nothing in the volume speaks to it at all
- location_kind (enum) one of: mandated_section, other_section, compliance_narrative, none -- WHERE that text sits. 'mandated_section' when it is under the heading the Requirements Matrix names for THIS requirement in its 'Answer under heading' column; 'other_section' when it is elsewhere in the submitted volume; 'compliance_narrative' when the only text is in the Compliance Narrative section, which the Instructions state responds to no requirement; 'none' when there is no text. 'none' is allowed only with response_state 'not_present' and 'not_present' only with 'none'; 'compliance_narrative' is allowed only with 'restates_only' and 'restates_only' only with it
- response_ref (string) -- the reference of the SINGLE place in the submitted pack the row is about, verbatim as the pack prints it -- a proposal section number such as 'Section 2.3', or a Compliance Narrative paragraph such as 'CN-2'. Cite where the text actually IS, which for a cross-reference is where the POINTER is printed and not the volume it points at. Return the string 'none' when location_kind is 'none'
- compliance_call (enum) one of: not_addressed, narrative_only, cross_referenced, outside_mandated_section, partially_addressed, addressed -- this requirement's matrix call, decided STRICTLY by the shipped rulebook from `response_state` and `location_kind` and nothing else. Work through the six steps IN ORDER, stopping at the first that fires. (1) location_kind 'none' or response_state 'not_present' -> 'not_addressed'. (2) response_state 'restates_only' or location_kind 'compliance_narrative' -> 'narrative_only'. (3) response_state 'points_elsewhere' -> 'cross_referenced'. (4) location_kind 'other_section' -> 'outside_mandated_section'. (5) response_state 'responds_in_part' -> 'partially_addressed'. (6) anything else -> 'addressed'. `addressed` IS THE ONLY CALL THAT TELLS A PROPOSAL MANAGER TO STOP LOOKING AT A REQUIREMENT -- give it only when text under the mandated heading answers the whole requirement
Return a JSON object with exactly these top-level keys: solicitation_ref, submission_state, volume_checked, disposition, requirements
`requirements` is an array of EXACTLY 6 object(s), one per requirement id above, in that order. It is never shorter: a requirement the volume says nothing about is a row reading `not_addressed`.
PROPOSAL PACK
-------------
Synthetic Record
----------------
This is a SYNTHETIC proposal compliance pack generated by tools/build_corpus.py for the AI Foundry use-case kit `proposal-compliance`. The issuing office, the solicitation number, the programme, every requirement, every section number, every sentence of the proposal volume and every name in it are INVENTED. Nothing here was copied from, adapted from or checked against any real solicitation, acquisition regulation, agency supplement, source-selection plan, proposal, company procedure or person, because none was consulted. It describes no real programme, no real agency, no real offeror and no real person, and it must never be treated as a solicitation or as a proposal.
Routing Slip
------------
Received by the proposal desk: 2026-02-22
Pack id: PKG-0010
Volume under check: Technical Volume
Submission state: Interim draft, review cycle 2 of 3
Compliance check owed: every requirement in the matrix, one row each
Solicitation Header
-------------------
Issuing office: Unified Aerospace Procurement Directorate (UAPD)
Solicitation: UAPD-2026-0110
Title: Airframe structural sustainment services
Volume under check: Technical Volume
Proposals close: 2026-04-14
Submission state of the attached volume: Interim draft, review cycle 2 of 3
Instructions to Offerors
------------------------
These instructions govern this Technical Volume and are the authority for where a response must sit.
IO-1 PLACEMENT. The requirement is answered under the heading the Instructions to Offerors name for it, and responsive material under any other heading is not evaluated against it.
IO-2 A POINTER IS NOT A RESPONSE. A cross-reference to another volume or section states where somebody might look; a response states what the offeror will do.
IO-3 THE NARRATIVE RESPONDS TO NOTHING. The Compliance Narrative is a statement of intent, is evaluated against no requirement, and repeating a requirement's words there is not answering it.
IO-4 BOTH HALVES. A requirement that asks for two things is answered only when both are stated.
Requirements Matrix
-------------------
The requirements below are the complete list for this volume. There are 6 of them.
R-01 | Evaluated: yes | Answer under heading: Systems Integration
Key phrase: interface control
The offeror shall describe its approach to interface control for the delivered subsystem boundaries.
R-02 | Evaluated: no | Answer under heading: Quality and Configuration Management
Key phrase: configuration control
The offeror shall describe its approach to configuration control for hardware baselines.
R-03 | Evaluated: no | Answer under heading: Information Protection
Key phrase: cybersecurity control inheritance
The offeror shall describe its approach to cybersecurity control inheritance for the development environment. The offeror shall also state which controls are inherited rather than implemented.
R-04 | Evaluated: no | Answer under heading: Reliability and Failure Management
Key phrase: failure reporting and corrective action
The offeror shall describe its approach to failure reporting and corrective action for fielded units.
R-05 | Evaluated: no | Answer under heading: Software Development and Assurance
Key phrase: software assurance
The offeror shall describe its approach to software assurance for mission software builds.
R-06 | Evaluated: yes | Answer under heading: Sustainment Engineering
Key phrase: obsolescence management
The offeror shall describe its approach to obsolescence management for line-replaceable units. The offeror shall also state how far ahead a last-time-buy is forecast.
Proposal Volume as Submitted
----------------------------
Section 1.1 - Executive Summary
The offeror proposes an approach built on the team already performing comparable work, with the transition handled inside the first sixty days.
Section 2.1 - Systems Integration
This section is written to the page limit stated in the Instructions and the supporting detail is retained in the offeror's programme files.
Section 2.2 - Quality and Configuration Management
The offeror's approach to configuration control for hardware baselines is set out in full in Attachment 4 (Quality Plan) and is not repeated here. The offeror considers that approach fully responsive to this requirement.
Section 2.3 - Information Protection
Cybersecurity control inheritance for the development environment is performed under a documented procedure owned by the programme control lead. The development environment sits inside an accredited enclave and the offeror maintains the control implementation record for every control it owns. Inherited controls are listed by identifier in the system security plan and are re-confirmed at each annual assessment.
Section 2.4 - Reliability and Failure Management
The offeror's internal procedures governing this area are available for review at the offeror's facility during the evaluation period.
Section 2.5 - Software Development and Assurance
Software assurance for mission software builds is performed under a documented procedure owned by the programme control lead. Every build runs a static analysis pass and a unit regression suite in the pipeline, and no build reaches integration without both records attached to it.
Section 2.6 - Sustainment Engineering
Obsolescence management for line-replaceable units is performed under a documented procedure owned by the production lead. Every line-replaceable unit carries a parts health record refreshed twice a year against manufacturer end-of-life notices and distributor stock depth.
Section 3.1 - Programme Overview
This section carries the offeror's general description of the programme and of any material the offeror considered better read in one place than distributed across the volume.
The offeror's organisation for this effort is set out in the organisation chart at the front of this volume, and the reporting lines shown there are the ones in force at award.
Compliance Narrative
--------------------
The paragraphs below are the offeror's statement of intent. They are offered in addition to the volume above.
CN-1 The offeror's management system has been assessed against the standards named in the solicitation and the certificates are current.
CN-2 The offeror complies fully with the failure reporting and corrective action requirement and maintains a documented approach to it across the programme.
Distribution Notes
------------------
Circulated to the proposal desk and to the volume leads. Queries to the desk, not to the issuing office. The teaming partner's proposal office has circulated its own reading of these Instructions, in which a cross-reference into a teammate's volume counts as a response; that reading is theirs and is not part of this solicitation.