Anatomy of a Watch Report

By Todd Heater · Published 6 August 2026 · A real run, taken apart section by section

Most tender alert services send a list of links, which gives you no way of telling what was searched, what was discarded, or whether the notice at the top is a genuine fit rather than the one that happened to contain your keyword.

A Bidwin Watch report is written so that all three can be checked. This page takes a real one apart, the run of 6 August 2026, and sets out what each part is for. The report itself can be downloaded from the box partway down or at the foot of the page.

Before the report: the watch that produced it

Watch runs on demand whenever you want to know what is out there, and on a schedule you set when you would rather not have to remember. This client's watch sweeps twice a week, on Monday and Thursday mornings.

The schedule behind the example report, running in the client's own Claude account.

The run header of the report records that cadence back to you, so the schedule and the report can be checked against each other. Because a scheduled run happens on your own machine, it needs the computer awake and online at the time, which is why a working morning is a better setting than an overnight one.

1. The run header: what was actually searched

The report opens with an account of the search rather than with an opportunity: the window covered, the portals queried, how many notices came back, how many touched the profile, how many survived deduplication, and how many passed the hard filter. On this run that chain ran 294 pulled, 12 touched, 9 after dedupe by OCID, and 4 through.

Publishing the funnel is what allows you to disagree with it. If 294 notices produce only four candidates you can reasonably ask whether the filter is too tight, and the raw list further down the report is what lets you check.

The header also records failures. This run covered seventeen days rather than the usual four, because the previous scheduled run had failed at retrieval when both portals returned an HTTP 429, and had left the ledger untouched rather than recording notices it never saw. That gap was logged at the time and closed by this run.

2. The scored shortlist: fit, and the evidence behind it

Each opportunity that passes the filter carries a fit score out of five, a recommended action, and the reasoning in full. The report labels the score as judgement rather than fact, and the rule that keeps it from being a guess is that an opportunity is scored against your evidence base rather than your ambitions: stated ambition in your watch brief widens what the watch looks for, but it never raises a score.

The top-scoring entry from this run is reproduced below, shortened, with the evidence markers left exactly as the report carries them.

The excerpt shows three things.

• Every fit claim names its file and its section, giving the document, the heading and the figure rather than a general assertion about track record, so a bid team can find the sentence behind any claim it intends to use.
• Alongside the case for the opportunity sit the qualifications against it, under "what would strengthen it" and, here, a gap serious enough to change the decision. A four out of five that questions whether the initial term is long enough to mobilise in is contributing to the bid/no-bid decision rather than supplying a lead.
• The deadline is assessed rather than printed. "Three weeks, viable" is a judgement about whether a response is realistic in the time available.

Low scores are treated the same way. A Get Work Ready programme in this run scored one out of five and was marked Skip, not because the work was wrong but because the buyer is in Northern Ireland and the brief rules that out. The report records that the subject fit was excellent and irrelevant.

3. The raw list: the notices the filter set aside

Every notice that touched the profile and was then culled is published, with the buyer, the matched CPV code, the deadline, the reason it was set aside, and its link or OCID. On this run that came to five notices, all dropped on geography.

If the filter is discarding something you would have bid for, this is where you find out, rather than six months later when the award notice appears. Notices that matched nothing at all are counted but not itemised, which keeps the report readable: 282 of them on this run, mostly road schemes and IT contracts.

4. Coverage and profile notes: where the search itself is weak

The closing section confirms whether retrieval was complete, records what has been stored, and reports any fault the watch has found in its own search profile. On this run both portals returned every page and nothing was truncated, which is stated with the page counts behind it.

One fault was found worth fixing. The region gate matched notices carrying ITL codes such as UKK2, or the literal word "England", but not notices whose only geography was a plain regional name like "East Midlands" or a city like "London". Nothing was lost this cycle, because both affected notices were out of scope for other reasons. The report records that the mechanism will drop genuinely relevant English notices the moment a buyer publishes one with a plain regional name, gives the one-line fix, and then says: I have not made this edit; the profile is yours.

A data-quality problem at source is flagged in the same section. Contracts Finder had stamped countryName: England on a Northern Irish buyer, and the report's conclusion is that region data from that portal should be treated as indicative, with geography checked against the buyer name.

5. The provenance footer: where every fact came from

The report closes by stating its own sourcing rules: notice facts come only from the OCDS records retrieved in that run, under the Open Government Licence; fit scores are judgement and are labelled as such; every fit claim cites the Support File behind it; nothing has been estimated; and no link has been constructed where the published data did not carry one.

The last of those governs a practical case. Where a record carried no usable link, the report gives the OCID and the source portal and asks you to search on it, rather than building a plausible URL from a pattern.

What happens next

Each recommended opportunity ends with the same offer: say the word and I'll build the tender project for this one, folder, evidence copied across, and a handover brief ready for the tender vet. Watch decides what is worth bidding for and Bidwin Core turns the chosen opportunity into an evidence-cited first draft, with nothing re-keyed between them.

What a Watch report cannot tell you

Watch sees published notices. It cannot show you a contract that was never advertised or an extension awarded quietly, and below-threshold notices on the devolved portals (Public Contracts Scotland, Sell2Wales and eTendersNI) are not yet covered, although many Scottish and Welsh buyers publish to Find a Tender as well. Fit scores are a professional judgement made against your files, which makes them a way of ordering your attention rather than a prediction of the outcome. The report is also only as good as the evidence base behind it: on this run the single strongest credential for one opportunity had to be flagged as an evidence gap, because it appeared in the client's brief but in none of their files.

Frequently asked questions

Figures on this page are taken from the Bidwin Watch run of 6 August 2026 and are reproduced in the downloadable report. Bidwin Watch uses public-sector procurement data from Find a Tender and Contracts Finder, published under the Open Government Licence v3. Last reviewed 6 August 2026.

← Back to all resources  ·  More about Bidwin Watch →