Most tender search tools are built on one feed. That is a reasonable engineering decision, and it is why they miss things. Public procurement in Europe is published through a patchwork: the EU-level notice board, national platforms with their own formats, regional buying centres that only maintain a website, and municipalities that upload a PDF and call it published.

Kosmo's job starts before you ever ask a question. The database has to contain the tender — with its documents — or the rest is a language model guessing. This is what that work looks like.

Where the notices come from

Three layers, each with its own failure mode:

  • The EU-level feed. Above the thresholds, notices are published in standard electronic forms with structured fields: buyer, CPV codes, value, deadlines, lots, award criteria. This layer is the easiest to ingest and the least complete — most contracts below the EU thresholds never appear in it.
  • National and regional platforms. Every member state runs its own procurement portal, and many run several. Some offer an API or an export; most offer a search page and an RSS feed that quietly changes shape. This is where the majority of the volume is, and where the crawling budget goes.
  • The long tail. Regional development agencies, utility companies, hospitals, universities and municipal websites that publish procurement notices in whatever format the person responsible prefers. Often a link to a PDF, sometimes a table inside a page, occasionally a scanned image.

Over 4,000 portals is not a claim that every portal is equally well covered. It is the current size of the source list, crawled daily, with per-source health tracked so a portal that stops returning notices is a bug we see rather than a silence you never notice.

The same tender, five times

A single contract can appear as a prior information notice, a contract notice, a corrigendum, a national-language version, an English version, and a re-publication after a deadline extension. Treat those as six opportunities and you will send someone the same tender six times in one morning, which is how a useful product becomes noise.

So the first thing that happens to an incoming notice is not search. It is identity: buyer, internal reference, procedure type and the document set. Notices that describe the same procedure are grouped, and the group keeps the newest deadline and the newest set of documents. A deadline extension is not a new tender — it is an update to one, and the update is the part a bid manager actually needs to see.

Titles lie; documents do not

“Supply of IT equipment” is a title. Underneath it, in lot 3 of the specification, there is often a three-year managed service commitment, an on-site response time of four hours, and a requirement for two references from contracts of a similar size in the last three years. Matching on the title will show you the tender. Only the documents tell you whether it is worth a week of your team's time.

That is why every notice in the database is chased down to its attachments and read: the specification, the evaluation grids, the contract draft, the annexes with the mandatory certificates, and the question-and-answer file that accumulates amendments until the deadline. Scanned pages get OCR'd, because a large share of them are scans of a printed document.

Reading the documents also changes what can be answered. A question like “can we meet the requirements?” stops being rhetorical once the requirements are a list of numbered clauses, each one checkable against your certificates and references.

Daily means watching for change, not just for new

A tender is not an event, it is a process with edits: a corrected value, an added lot, a moved deadline, a clarification that changes the evaluation weighting. A pipeline that only inserts new records gives you a database that is right on the day a notice is published and wrong afterwards.

Each fetch therefore compares against the previous state of the notice and stores what changed. The interesting output is not “4,000 new notices today”; it is “these three tenders you are watching changed, and one deadline moved forward by six days”.

What we still get wrong

Honesty is cheaper than a support ticket later:

  • Scanned annexes. OCR gets most of it and mangles tables. A requirement buried in a scanned pricing table can be missed — which is why the fit assessment points at the page it read, so you can check it.
  • Portals that hide behind a login. Where a platform requires registration to see the documents, we can index the notice but not the attachments, and we say so instead of pretending the document set is complete.
  • Language. Machine translation is good enough to triage and not good enough to submit. Drafts that go into a bid are produced in the language of the tender, and the original clause stays one click away.
  • Freshness at the edges. Some municipal sites publish weekly at best. Daily fetching means we notice within a day, not that the source is current within a day.

What this means if you are bidding

Treat any tender database — ours included — as a starting point, and the documents as the truth. The useful question is not “how many tenders are in here?” but “when this tender appears, will the thing that tells me to bid or to skip already be read?”

That is the part we are building. Coverage is table stakes; the reading is the product.