Published on Mon Aug 24 2026 00:00:00 GMT+0000 (Coordinated Universal Time) by Jacob Cavazos

Every federal RFP is a compliance document. Buried in its 80 to 300 pages are hundreds of requirements, each marked by a specific word: “shall.” The Federal Acquisition Regulation defines “shall” as a mandatory requirement. A proposal that fails to address a single “shall” is non-compliant, and non-compliant proposals are eliminated without further evaluation.

Finding every “shall” in an RFP is the first and most important step in proposal development. If you miss one, you lose. It does not matter how well-written your proposal is, how competitive your pricing is, or how strong your past performance is. A missed “shall” is a death sentence.

Most contractors do this manually. A proposal manager reads every page, highlights every “shall,” and builds a compliance matrix in a spreadsheet. For an 80-page RFP, this takes two to three days. For a 300-page RFP, it takes a week. And humans miss things. A tired proposal manager on page 47 of a 300-page RFP will miss requirements. Studies of manual document review consistently show error rates of 5-15% for repetitive extraction tasks.

The question is: can AI do this better? The answer depends on what kind of AI you use.

Why LLMs Fail at Requirement Extraction

Large language models are probabilistic. They generate text by predicting the next token based on statistical patterns. This makes them good at writing, summarizing, and translating. It makes them bad at exhaustive extraction.

When you ask an LLM to “find all the shall requirements in this RFP,” it does not scan the document systematically. It reads the text, identifies patterns that look like requirements, and generates a list. The list is probably mostly correct. But “mostly correct” is not “complete,” and in federal procurement, incomplete means non-compliant.

Three specific failure modes make LLMs unsuitable for requirement extraction:

Inconsistent extraction. Run the same RFP through the same LLM twice and you will get different requirement lists. The model’s output depends on its sampling temperature, the context window, and the specific tokens it has generated so far. A requirement that appears on the first run may not appear on the second. This is not a bug — it is how probabilistic generation works. For a compliance task that demands 100% capture, probabilistic extraction is the wrong tool.

Hallucinated requirements. LLMs can generate requirements that do not exist in the RFP. The model sees a pattern — “the contractor shall provide security services” followed by several sub-requirements — and may generate additional sub-requirements that follow the pattern but were not in the original text. These hallucinated requirements pollute the compliance matrix and lead the proposal team to address things that were not asked for, while potentially missing things that were.

Missed requirements. LLMs have context window limits. A 300-page RFP may not fit in a single context window, requiring the document to be processed in chunks. Requirements that span chunk boundaries — where the “shall” clause starts on one page and the detailed requirement continues on the next — get split and may be missed entirely. Even within a single context window, the model may skip over requirements that are phrased unusually or embedded in tables, figures, or formatting that the model does not parse well.

For a deeper treatment of why probabilistic systems cannot guarantee factual accuracy, see our analysis of deterministic AI and why it matters for enterprise.

How Deterministic Extraction Works

Deterministic extraction does not use a language model. It uses rule-based logic — regular expressions, pattern matching, and structured parsing — to find and classify requirements. Given the same input, it produces the same output every time. It does not hallucinate because it does not generate. It extracts.

The process works in five stages:

Stage 1: Text Extraction and Cleaning

The RFP PDF is converted to text using PDF parsing libraries. The raw text is cleaned to remove page headers, footers, and formatting artifacts. Word breaks caused by PDF line wrapping are fixed — “Solicitati on” becomes “Solicitation,” “require ment” becomes “requirement.” Hyphenated line breaks are joined. Page numbers and document control headers are stripped.

This stage matters because PDF extraction is noisy. A typical 80-page RFP produces 250,000+ characters of text, and 5-10% of that is formatting garbage. If you do not clean it, the garbage ends up in your requirements.

Stage 2: Requirement Detection

The cleaned text is scanned for imperative language. The FAR defines three levels of obligation:

• “Shall” — mandatory. The contractor must do this.
• “Should” — recommended. The contractor ought to do this.
• “May” — permissive. The contractor is allowed to do this.

Each sentence containing one of these words is extracted as a candidate requirement. The extraction uses regular expressions that match the imperative word, the surrounding clause, and the sentence boundary. This is not fuzzy matching — it is exact pattern matching.

Stage 3: Definition Splitting

Many “shall” sentences in RFPs are not requirements — they are definitions. “‘CO’ means Contracting Officer” is a definition, not a requirement. “‘Confidential Information’ shall mean all information related to the Contract” looks like a “shall” requirement but is actually a definition.

The deterministic extractor identifies definitions by checking for patterns: “means,” “includes,” “refers to,” “shall mean,” “shall include.” When a “shall” sentence is identified as a definition, it is split out of the requirement list and stored separately. The requirement text is cleaned to contain only actual obligations.

Stage 4: Deduplication

RFPs often repeat requirements across sections. The same security requirement may appear in Section C (Statement of Work), Section H (Special Contract Requirements), and Section L (Instructions to Offerors). The deterministic extractor normalizes requirement text (lowercase, remove punctuation, trim to first 80 characters) and groups identical requirements. Duplicates are marked but kept for traceability — you need to know that a requirement appears in multiple places so you can address it in multiple sections of your proposal.

Stage 5: Categorization and Prioritization

Each requirement is categorized into one or more of 13 categories: cybersecurity, technical, management, pricing, personnel, reporting, compliance_legal, data_privacy, subcontracting, transition_pop, past_performance, general, and security. Categorization uses keyword matching — a requirement containing “NIST,” “CMMC,” “encryption,” or “800-171” is categorized as cybersecurity.

Requirements are also prioritized:

• Critical — requirements with specific timelines (“within 24 hours”), security obligations, cybersecurity mentions, or penalty clauses. These are the requirements that, if missed, most likely result in elimination.
• Important — requirements with specific action verbs (“shall provide,” “shall submit,” “shall maintain”). These are mandatory but less likely to cause elimination if partially addressed.
• Standard — general “shall” requirements without specific timelines or security implications.

Real Results: 586 Requirements from an 82-Page RFP

We tested the deterministic extractor on a real federal RFP: the House of Representatives IT Services Solicitation (OAM20047S), an 82-page PDF for technology services contracts.

The extractor found:

• 586 total requirements (488 mandatory, 9 recommended, 89 permissive)
• 577 unique requirements (9 duplicates identified and marked)
• 101 critical requirements (security, cybersecurity, specific timelines)
• 66 important requirements (specific action verbs)
• 321 standard requirements (general mandatory)
• 6 evaluation factors extracted from Section M (Technical Approach, Management Approach, Past Performance, Corporate Capabilities, Price, Key Personnel)
• 353 requirements mapped to evaluation factors (60% of all requirements)

The extraction took under 10 seconds on a single CPU. No GPU required. No API calls. No network access. The same RFP processed through an LLM would take minutes, cost API fees, and produce a different result on each run.

The Prolog Knowledge Base

The deterministic extractor does not work in isolation. It is backed by a Prolog knowledge base containing 497,343 “shall” requirements extracted from the Code of Federal Regulations, the Federal Acquisition Regulation, and the Defense Federal Acquisition Regulation Supplement.

This knowledge base allows the extractor to cross-reference RFP requirements against the full body of federal procurement law. When an RFP says “the contractor shall comply with FAR 52.204-21,” the extractor can pull the actual text of FAR 52.204-21 from the knowledge base and add its specific requirements to the compliance matrix.

The knowledge base is structured as Prolog facts:

• shall_requirement/4 — extracts all mandatory requirements
• far_clause/1 — identifies FAR clause references (52.xxx)
• dfars_clause/1 — identifies DFARS clause references (252.xxx)
• cyber_requirement/4 — identifies cybersecurity requirements (NIST, CMMC, 800-171)
• cui_requirement/4 — identifies CUI/controlled unclassified information requirements

Prolog is the right tool for this because it is deterministic, declarative, and designed for rule-based reasoning. You define what a “shall” requirement looks like, and Prolog finds all of them. No probability. No hallucination. No variation between runs.

The Hybrid Approach: Deterministic Extraction + LLM Generation

Deterministic extraction solves the compliance problem. It does not solve the writing problem. A compliance matrix with 488 requirements is not a proposal — it is a checklist. You still need to write the proposal.

This is where LLMs are useful. Once you have a verified, complete compliance matrix, you can feed each requirement to an LLM and ask it to generate a proposal response. The LLM handles the writing. The deterministic engine handles the compliance.

The key insight is that the LLM is not making compliance decisions. It is taking a verified requirement and generating prose that addresses it. If the requirement says “the contractor shall provide 24/7 security monitoring,” the LLM generates a response describing your 24/7 security monitoring capabilities. The LLM cannot miss a requirement because the requirements were already found by the deterministic engine. It can only generate a bad response to a requirement it was given — and a bad response is fixable, while a missed requirement is not.

This is the architecture we use: deterministic extraction for compliance, LLM generation for drafting, deterministic verification for checking that the draft addresses the requirement. For a comparison of how different AI proposal tools handle this split, see our rating of 8 govcon AI proposal tools.

Why 95% Accuracy Is Not Enough

The most common defense of LLM-based extraction is “our tool is 95% accurate.” This sounds impressive until you do the math.

A typical federal RFP contains 100-500 “shall” requirements. At 95% accuracy on a 100-requirement RFP, you miss 5 requirements. At 95% accuracy on a 500-requirement RFP, you miss 25 requirements. Each missed requirement is a potential elimination.

Federal compliance is binary. A proposal either addresses every “shall” or it does not. There is no partial credit. There is no “we got 95% of the requirements.” The evaluator’s checklist has a box for each requirement, and every box must be checked. A proposal with 95% of the boxes checked is non-compliant.

The tool vendor’s marketing says 95%. The contractor’s cover letter says 100%. That gap — the 5% — is the contractor’s risk. The tool vendor carries no liability. The contractor carries all of it. If the proposal is eliminated because of a missed requirement, the tool vendor loses nothing. The contractor loses the contract, the revenue, and potentially the past performance record that would have helped win future contracts.

Deterministic extraction does not claim 95% accuracy. It claims 100% of the requirements that match the extraction rules. If the rules are correct, the extraction is complete. If a requirement is phrased in a way the rules do not catch, it is missed — but the miss is consistent and fixable. You update the rule, re-run the extraction, and the requirement is found. With an LLM, the miss is random. You cannot fix what you cannot reproduce.

When to Use Each Approach

Use deterministic extraction when:

• You need 100% capture of every “shall” requirement
• The output must be reproducible (same input, same output every time)
• You are building a compliance matrix that will be audited
• You need to cross-reference requirements against FAR/DFARS clauses
• You cannot afford hallucinated requirements

Use LLM generation when:

• You have a verified compliance matrix and need to generate proposal prose
• You need to write executive summaries, technical approaches, or management narratives
• You need to tailor boilerplate text to a specific RFP’s requirements
• You need to generate past performance narratives

Use the hybrid approach when:

• You want both compliance and quality
• You want deterministic extraction to find every requirement and LLM generation to write every response
• You want deterministic verification to check that each response addresses its requirement

The contractors who get this right will use deterministic tools for what they are good at — extraction, verification, coverage — and use LLMs for what they are good at — generation, retrieval, workflow. The contractors who get this wrong will trust an LLM to find every requirement, skip the deterministic verification, and discover the gap when they receive a notice of elimination.

Frequently Asked Questions

What is deterministic RFP requirement extraction?

Deterministic RFP requirement extraction is the process of using rule-based logic — regular expressions, pattern matching, and structured parsing — to find and classify every “shall,” “should,” and “may” requirement in a federal RFP. Unlike LLM-based extraction, deterministic extraction produces the same output every time it processes the same input. It does not hallucinate because it does not generate text — it extracts text that matches defined patterns.

Why not just use ChatGPT to extract RFP requirements?

ChatGPT and other LLMs produce different results on different runs, can hallucinate requirements that do not exist in the RFP, and may miss requirements that are phrased unusually or embedded in tables. For a compliance task that demands 100% capture, probabilistic extraction is the wrong tool. A 95% accurate LLM misses 5 requirements on a 100-requirement RFP, and each missed requirement can cause elimination.

How many requirements does a typical federal RFP contain?

Federal RFPs vary widely. A small RFP may contain 50-100 “shall” requirements. A medium RFP like the House of Representatives IT Services solicitation contains 488 mandatory requirements across 82 pages. A large RFP (DoD, DHS) can contain 500-1,000+ requirements across 300+ pages. The number of requirements scales with the scope and complexity of the contract.

What is a Prolog knowledge base and why is it used for RFP compliance?

Prolog is a declarative programming language designed for rule-based reasoning. A Prolog knowledge base stores facts (e.g., “FAR 52.204-21 contains 17 shall requirements”) and rules (e.g., “a cybersecurity requirement is any shall requirement containing NIST, CMMC, or 800-171”). Prolog can query these facts and rules to answer questions like “which FAR clauses are referenced in this RFP?” or “which requirements are cybersecurity-related?” It is deterministic, reproducible, and does not hallucinate.

Can deterministic extraction and LLM generation work together?

Yes. The optimal approach is deterministic extraction for compliance (finding every requirement) plus LLM generation for drafting (writing a response to each requirement). The deterministic engine ensures 100% requirement capture. The LLM generates prose that addresses each verified requirement. A deterministic verifier then checks that each generated response actually addresses its requirement. This hybrid approach gives you both compliance completeness and writing quality.

Written by Jacob Cavazos