How contrl Reads an RFP: A Technical Walkthrough

TL;DR: When you upload an RFP to contrl, the system runs a multi-step analysis: document parsing, requirement extraction, evaluation criteria mapping, compliance matrix generation, and priority scoring. This post walks through each step and explains what's happening under the hood.

We get asked a lot about what contrl actually does when it 'reads' an RFP. It's a fair question. 'AI reads your document' is vague enough to mean almost anything, from basic text extraction to something genuinely useful. This post walks through the actual pipeline, step by step.

Step 1: Document parsing

RFPs arrive in various formats. PDF is most common. Some come as Word documents. Government RFPs sometimes ship as ZIP files with multiple attachments across different formats. The first job is turning all of this into structured, readable content.

This sounds simple but isn't. PDFs are particularly tricky because they're display formats, not data formats. A table in a PDF looks like a table to a human reader, but to a parser, it's just a collection of text fragments positioned on a page. Headers, footers, page numbers, and watermarks need to be identified and removed. Multi-column layouts need to be reconstructed into a linear reading order.

contrl handles this locally on your machine. The document never leaves your computer. The parser extracts text, tables, and structural elements while preserving the hierarchical relationships between sections, subsections, and their content.

Step 2: Requirement extraction

Once the document is parsed, contrl identifies individual requirements. This is where things get interesting, because requirements in RFPs are rarely clean and numbered. A single paragraph might contain three separate requirements embedded in dense procurement language. Cross-references point to requirements defined in appendices. Conditional requirements ('if proposing Option A, also address...') create branching paths.

The extraction engine looks for obligation language ('shall', 'must', 'is required to'), conditional structures, cross-references, and section-specific evaluation criteria. Each extracted requirement gets tagged with its source location, section reference, and any conditions or dependencies.

The output is a flat list of discrete requirements, each traceable to its exact location in the original document. This becomes the foundation for the compliance matrix.

Step 3: Evaluation criteria mapping

Evaluation criteria tell you how the client will score proposals. They're the single most important piece of information in any RFP, and they're often buried in a section that many teams skim too quickly.

contrl maps each extracted requirement to the relevant evaluation criterion. If the RFP says 'Technical Approach will be evaluated on a 50-point scale, with emphasis on scalability and integration with existing systems,' every requirement that touches technical architecture gets tagged with that context.

This mapping serves two purposes. First, it tells the Win Theme engine which areas carry the most weight, so the strategic positioning can align with what the client will actually score. Second, it helps the content generator calibrate how much detail each section needs. A requirement under a heavily weighted criterion deserves more space than one under a lightly weighted criterion.

Step 4: Compliance matrix generation

The compliance matrix is the proposal team's tracking document. It maps every requirement to a response section, assigns responsibility, and tracks completion status. Most teams build this manually in Excel, and it takes 4-8 hours for a complex RFP.

contrl generates a draft compliance matrix automatically from the extracted requirements. Each requirement is mapped to a proposed response section, cross-referenced with the evaluation criteria, and flagged with a priority score based on the criteria weighting.

The matrix is a draft, not a final document. The proposal manager reviews it, adjusts section assignments, and confirms the mapping. But starting from a structured draft instead of a blank spreadsheet saves significant time and reduces the risk of missing requirements.

Step 5: Priority scoring

Not all requirements are equally important. A requirement under a 50-point evaluation criterion matters more than one under a 10-point criterion. A 'shall' requirement is more critical than a 'should' or 'may.' A requirement that appears in both the technical and management sections signals something the client cares deeply about.

contrl assigns a priority score to each requirement based on these signals. High-priority requirements get flagged for the Win Theme engine and receive more detailed treatment in the content generation phase. Low-priority requirements get compliant responses without the same level of strategic emphasis.

This scoring is transparent. You can see why each requirement received its priority level and adjust the scoring if your team disagrees with the assessment. The goal is to give you an informed starting point, not to make decisions for you.

What happens next

After the RFP analysis is complete, the results feed into the Win Theme generation step, which is a separate post. The key point is that contrl's proposal content isn't generated from a generic understanding of the RFP. It's generated from a structured analysis that understands which requirements matter most, how they connect to evaluation criteria, and where the strategic opportunities are.

The entire analysis runs locally, takes minutes rather than the hours a manual process requires, and produces artifacts (compliance matrix, requirement database, criteria map) that are useful even if you never use contrl for content generation.