RFP shred and the compliance matrix

A capture team's first move on a new solicitation is to "shred" the RFP — break Sections L (Instructions to Offerors), M (Evaluation Factors), the SOW/PWS, and the FAR clause list into the atomic, individually-trackable requirements the proposal must satisfy. FedGrade does that structural pass for you, then builds the compliance matrix off the result. Both are Pro+ capabilities.

The shred

Paste or upload a solicitation and FedGrade parses it into structured requirements. Every extracted requirement carries a citation back to its exact location in the source: the UCF section, the detected heading label (e.g. L.4.2, M.1, SOW 3.1), character offsets into the document, a page number when the source has page breaks, and a verbatim snippet. A reviewer can verify every requirement against the original.

Requirements are typed:

• instruction — Section L, how to format and submit.
• evaluation — Section M, how the offer is scored.
• sow — the work to be performed.
• clause — a FAR/DFARS clause reference.
• constraint — a submission constraint (page limit, font, due date, format).

Deterministic by default

The default shred is 100% deterministic — regex and heading-structure parsing, no model, no network, no nondeterminism. It splits the document into UCF sections, then breaks L/M/SOW into numbered paragraphs and shall / must / will obligation sentences, and harvests clause references and submission constraints. Expect it to capture explicitly enumerated requirements well (Section L numbering is highly regular) and to be weaker on obligations buried in prose.

An optional LLM-assisted pass runs the deterministic shred first, then asks the configured model to surface obligation sentences the regex missed — constrained to verbatim spans of the source. Any span FedGrade can't re-locate verbatim is dropped, never trusted. The model is assistive recall only; it never relaxes the citation discipline.

The compliance matrix

Once the RFP is shredded, FedGrade builds the compliance matrix (a.k.a. cross-reference or traceability matrix): one row per requirement, mapped to the proposal section that addresses it, the evaluation factor it scores under, and a status — addressed, partial, or gap.

The cross-walk is a deterministic keyword/heading match with explicit, inspectable scoring — not an LLM. It is intentionally conservative: it proposes a responding section and a status, and a human confirms or overrides each row in the UI.

Gap detection is the high-value output. A gap row is a requirement no section appears to answer — an unanswered requirement and a likely non-responsive finding at evaluation. Pink/Red/Gold reviewers gate on exactly this.

Honest limits

The keyword cross-walk finds the obvious mappings (an L "technical approach" item → a "Technical Approach" section) and reliably flags the unmistakable gaps. It will produce false "partial" results when a section answers a requirement in different words — which is why every row is editable and the status is a starting point, not a verdict.

Export and reach

The matrix exports to XLSX and rides inside the capture package. FedGrade respects the proposal-management boundary — it builds the compliance matrix starter; it is not a Privia / Loopio / PROPRICER replacement.