Full tender requirement evaluation

Why requirements are more complex than they appear

Requirements in a public tender are not a homogeneous mass. They fall into at least three categories, each with its own logic and different consequences for non-compliance. Selection requirements (eligibility criteria) define who may participate — turnover, experience, staff, certificates. Technical requirements describe what must be delivered — parameters, standards, methodologies, timelines. Administrative requirements govern how the bid must be submitted — format, order, notarisations, templates.

The problem is that the three categories are neither cleanly separated in the documentation nor equally visible. Technical requirements sometimes hide in a template; administrative requirements appear in a technical specification. The evaluation methodology may contain de facto requirements disguised as scoring criteria. The result: you read the notice carefully and believe you've caught everything; then the committee returns your bid because of a requirement on page 38 of the technical specification you hadn't seen.

Add to that the dynamics of clarifications — published questions and answers that sometimes introduce new requirements or modify existing ones. A clarification answer is legally binding if published in time, yet many participants don't read it carefully, or don't even know it's been published.

How full requirement evaluation works

The entire documentation corpus — notice, participation documentation, technical specifications, draft contract, templates, clarifications — is processed through a language model trained on a Bulgarian procurement corpus of over 205,000 decisions and protocols. The system doesn't read only the main text: it extracts requirements from footnotes, tables, and references to regulations and standards.

Every extracted requirement is categorised (selection / technical / administrative), tagged with the type of evidence required, and rated on a "visibility" scale — how easy it is to miss in a quick read. Requirements with a high risk of being overlooked receive a special flag and an explanation of why they're dangerous.

The result is a structured requirements register, formatted for direct use as a checklist during bid preparation. Every team member knows exactly what they're responsible for.

• Scanning of the full document corpus, including clarifications and answers.
• Categorisation: selection requirements, technical, administrative.
• Flags for requirements with a high risk of being overlooked.
• Evidence type for each requirement (document, declaration, certificate…).
• Noting whether the requirement applies to the participant, the consortium, or a specific expert.
• Reference to the exact text and page in the documentation.

Formal vs substantive requirements — a different strategy for each

The distinction between formal and substantive requirements is critical because the approach to handling them is fundamentally different. A formal requirement is procedural: a document must be certified in a specific way, a template must be filled in precisely, a declaration must be signed by a particular person. These requirements don't depend on the company's capacity — they depend on attention to detail. That's why formal errors are also the most painful: they could have been prevented.

A substantive requirement, on the other hand, tests real capacity: has a delivery of value X been completed, does the company hold certificate Y, is an engineer with qualification Z employed. Here the problem isn't an oversight but a genuine gap. The strategy differs: form a consortium with a partner, engage a subcontractor, or consciously decide not to bid.

The evaluation maps both types so you know in advance: "Can we meet everything formally, to the letter?" and "Do we meet all substantive requirements or do we need a partner?"

Requirements easy to miss — and why

Not all requirements are equally visible. Practice reveals certain categories that are disproportionately often overlooked. Requirements stated only in a template (not in the main text); requirements introduced by reference to a regulation; requirements for a signature from a specific officeholder; requirements that apply only in a consortium or when using the capacity of a third party — all of these are "silent" traps.

Especially treacherous are cumulative requirements: "the participant or each member of the joint venture must…" vs. "at least one member of the joint venture must…" The difference between "each" and "at least one" determines a completely different strategy for structuring the consortium. Misread — exclusion.

The flags in the evaluation mark precisely these nuances. We don't just extract the requirement; we explain exactly what the condition is, what form of evidence is required, and for which participant it applies.

Sample requirements register

The table below is an illustrative sample from a requirements register. It shows the format of the result, not a specific real tender. The actual register covers every requirement across the full documentation.

How the evaluation fits into bid preparation

A full requirement evaluation is not an end in itself — it's the entry point for the entire preparation process. The requirements map directly structures the work plan: who on the team gathers which documents, who checks certificate validity dates, who prepares the technical proposal for which parameters.

Combined with the fit assessment (fit score), the requirements register gives a complete picture: you know both whether your company meets the requirements and exactly what you need to prove. Without this combination you work in pieces — you may know that "we need an ISO certificate" but not who exactly signs the declaration, in what form, or by what date.

The practical effect is reducing the likelihood of a missed requirement to near zero — not because the team has become more careful, but because every requirement is exhaustively listed and assigned before preparation has even begun.

• The register is formatted as a directly usable checklist during preparation.
• Each requirement is linked to a responsible person or team role.
• Risk flags prioritise attention when resources are limited.
• Clarifications and answers are integrated, not processed separately.

What you get

We deliver a structured requirements register, formatted for direct use during bid preparation — not an academic analysis but a working tool.

• An exhaustive list of all requirements, categorised by type.
• Flags for requirements with a high risk of being overlooked, with explanation.
• Evidence type and exact documentation reference for each requirement.
• Distinction between formal and substantive requirements.
• Integrated requirements from clarifications and answers.
• Checklist format, ready to be distributed across the team.