1. Read the pack as received, not as expected
A real tender pack is rarely one clean PDF. It's a primary RFP document, a schedule of prices, standard conditions, sometimes a nested ZIP of drawings, and — frequently — addenda issued after the pack first went out. Preqivo ingests PDF, ZIP (including nested archives), DOCX, TXT, MD, CSV and XLSX, and builds a complete inventory of what was actually supplied before it decides anything about what the tender requires. Every document lands in one of three states: read in full, indexed for search (for larger PDFs), or logged as supplied-but-not-read with the reason why.
2. Build the requirement register, with a source for every line
The pack is then read for structured findings: an overview (issuer, reference, procurement type, a plain-English summary), key dates, mandatory gates, requirements categorised by type (technical, commercial, legal, H&S, insurance, experience, programme, submission, environmental, quality), evaluation criteria, submission checklist items, commercial terms, scope items, exclusions, and risks. Every one of those carries a citation back to the document, section and page it came from — because "the tender requires X" is only useful to a bid team if they can go and check it.
3. Reconcile the model's read against what was actually supplied
Large language models are good at reading text and worse at knowing, with certainty, what wasn't in front of them. So the engine doesn't take the model's first-pass "missing documents" list at face value — it's reconciled against the real, final leaf-document inventory (including everything found inside nested archives), so a document that genuinely was supplied under a slightly different filename doesn't get wrongly flagged as missing, and a document that genuinely wasn't supplied doesn't get silently dropped.
4. Run an independent verification pass
A second, independent pass checks the first pass's output rather than trusting it outright. Where the verification pass finds a correction — a miscounted mandatory gate, a missed cross-reference between documents — that correction is applied to the final analysis before it ever reaches the screen, and the verification section shows exactly what was corrected and why.
5. Surface risk as risk, not as buried prose
Ambiguities, omissions and genuine risks get their own structured register — severity (high/medium/low), type, the issue itself, why it matters, and where it came from — instead of being one paragraph in a hundred-page pack that a tired reader skims past on page 40.
6. Turn the register into a response plan
The same requirement/risk/gap register is what builds the response plan — every item groups into a section of work with an owner, a priority and a status, so a tender pack becomes an assigned, trackable body of work instead of a shared folder everyone re-reads independently.
7. Keep it grounded when the tender changes
Addenda and clarifications are common on anything but the simplest tenders. Inside a full Preqivo workspace, a new or amended source document is checked against the existing requirement register so a bid team sees exactly which requirements were affected by the change — not just that "an addendum was issued."