Government tender search, and the coverage question nobody answers

Why the data is scattered

Federal opportunities are published federally. Each state runs its own portal. Councils publish separately again, sometimes through a shared platform and sometimes on their own website. Universities and health services publish independently. New Zealand has its own national service, which is free and structured and entirely separate.

None of that is dysfunction — each of those bodies is meeting its own transparency obligation, and meeting it well. The consequence is simply that a supplier who could plausibly bid across three tiers has to check a dozen places, each with a different search box, a different category scheme and a different idea of what a closing date field means.

That is the actual problem an aggregator solves. It is a boring problem and it is a real one, and it is worth being clear that the value is in the collecting rather than in the data — because the moment a service implies the data itself is exclusive, it has started misrepresenting what you are paying for.

What aggregation actually costs

One source publishes a closing date with a time zone and another publishes a date alone. One uses a standard category taxonomy, another uses its own labels, a third uses free text. Some mark a tender closed; others simply stop listing it. A tender can appear on both a state portal and an aggregating platform, with different reference numbers and slightly different titles.

So the work is normalising: one date format, one jurisdiction scheme, one notion of open, and a fingerprint that recognises the same tender arriving twice from two places. None of that is visible in the product and all of it is where the effort goes.

There is a deliberate omission worth naming. The corpus has no location filter, because location is populated on a small minority of rows while jurisdiction is populated on all of them. A location filter would look useful and would silently hide most of the corpus from anyone who used it — a filter that quietly removes what it cannot classify is worse than no filter.

The empty-result problem

You search for civil works closing this month and get nothing back. Either there genuinely are none, or the source that would have carried them failed on the last run and its rows are missing. Those are opposite conclusions and the naive interface renders both as an empty list.

For a supplier the difference is a missed bid. For an agent calling this as a tool the difference is worse, because the agent will report "no matching tenders" with the same confidence in both cases and nothing downstream can distinguish them.

So every search returns coverage: which sources were searched, and which returned nothing. An empty result means no match in what we searched — never that no such tender exists. That phrasing is deliberate and it is load-bearing.

What we cannot reach

A public source registry lists every source: what it is, how it is accessed, what its robots.txt permits, how many tenders we hold from it, and its status on the last run. It is free to read and needs no key.

It includes the sources we do not have. Portals behind authentication walls are named as such. Sources whose robots.txt refuses automated access are named as refused rather than fetched anyway — a robots file is a request, and ignoring it to improve a coverage number is the kind of decision that is invisible until it is not.

This is the opposite of how coverage is normally marketed. The instinct is to publish the count and leave the gaps unstated, because a named gap reads as a weakness. It reads that way right up until somebody loses a bid to a tender that was never in the feed, at which point an unstated gap becomes a much larger problem than a stated one.

Matching versus alerting

The standard product is a keyword or category alert: pick your terms, receive everything that matches. It works, and its failure mode is volume — the categories are broad, so the inbox fills with tenders that share a label and nothing else, and the filtering you were paying to avoid lands back on your desk.

The alternative is to read what a company actually says it does and rank open tenders against that, returning the capabilities a tender needs that the company states, and the requirements it asks for that the company does not mention. That is a shortlist with reasons attached rather than a feed.

The honest framing of such a score: it is relative fit among the results returned, not a probability of winning. Nothing in a tender notice can tell you about incumbent relationships, pricing, or the twenty other bidders. A score that implied otherwise would be selling certainty about a competitive process it cannot see.

Search is free and needs no key. Matching costs, because it reads a website and runs a scoring pass — and being clear about which half is which is part of not overselling either.

Using it

SEARCH IS FREE AND UNAUTHENTICATED. Filter by jurisdiction — AU, NZ, or a specific state — plus tier, category, closing date and free text. It is a plain REST endpoint, so an agent can call it as a tool without an integration.

READ COVERAGE FIRST, especially when the result is empty. The coverage block is the difference between "there are none" and "we could not see them", and it is the only part of the response that can tell you which one you are looking at.

CHECK THE SOURCE REGISTRY when a source matters to you. If your work comes from one particular state portal, it takes one call to see whether it is in the feed, when it last ran, and whether it can be read at all.

AND GO TO THE ORIGINAL BEFORE YOU BID. The corpus carries the notice and a link; it is not the tender documents, and a summary is not a specification. The aggregation exists to find the opportunity, not to replace reading it.