Know who holds the contract, and when it ends, months before the rebid.

Rebids are usually found late

Public contracts are renewed on a cycle. By the time a new tender is advertised, the incumbent has often had months to build the relationship and shape the requirement.

Award notices often carry the supplier, value and contract period, but how often they do, and how reliably, is exactly what we are measuring below.

Example alert format

Data coverage: the locked protocol, and what we do not know yet

An alert is only possible when a public release has both a usable end date and a named incumbent. We are measuring how often that is true in real OCDS data, rather than assuming it.

How the cells will be filled and classified

1. Run. The locked v1 script is executed once per source (Contracts Finder, Find a Tender) on a networked machine, with window 1 Jan to 31 Dec 2024 and base seed 20240101, drawing up to 100 award-stage releases per sector per source.
2. Export. The script exports the raw per-cell counts (n of N for each measure), the run date and the script version. These are copied into the tables below unedited.
3. Thin flag. Any cell with N under 30 is marked thin and receives no launch classification.
4. Classify. Each non-thin cell is classified on its Alertable (both) share against the pre-registered thresholds (60% and 30%, set out under “Planned pilot” below). The thresholds are not altered after the results are seen.
5. Re-runs. If a run is repeated, the previous run stays on record and the reason for the re-run is logged here.

What the run export must contain

This is the hand-over format. Each field maps to one cell below, so the page can be filled verbatim without recalculation. If any field is missing from the export, that cell stays “Not measured yet”. If an export contradicts the locked parameters or is internally inconsistent (for example a count larger than its sample size), the page refuses to fill any cell.

Locked sampling protocol (v1)

1. Sources. Public OCDS release packages from Contracts Finder and from Find a Tender. Each source is sampled and reported separately, because the two publishing regimes differ in notice structure.
2. Stage. Award-stage releases only: releases whose tag includes award or contract. Tender-only and planning-only releases are excluded.
3. Sample window. Releases published from 1 January 2024 to 31 December 2024 inclusive (publication date), the same for both sources so results are comparable. This is a fixed historical window, chosen so the sample cannot be changed as new notices arrive. It is not a forecast of which contracts expire when.
4. Sector assignment. By CPV code, using the list below. A release matches a sector if its main classification, or any item classification, is in that sector's list (a division-level code matches its descendants). A release matching more than one sector is counted once, under its main-classification sector, and the overlap count is reported. Releases that match no sector, or lack a CPV code, are counted separately as unclassified and are not forced into a sector.
5. Draw. Per sector and per source, up to 100 releases, after de-duplicating by release identifier (ocid) and sorting the pool by ocid. The draw uses a seeded pseudo-random generator with base seed 20240101, combined with the source and sector name for each cell so cells are independent and repeatable. If fewer than 100 releases exist in the window, we take all of them and report the actual number. A cell with fewer than 30 releases is marked thin, and its percentages are shown with that warning.
6. Scoring. Each release is scored once against the definitions below, using the field mapping below. We report counts out of the sample size, then the share, never the share alone.
7. Repeatability. The extraction script version, seed and window are recorded in the run record below so anyone can re-run the same draw. Any change to this protocol after results are seen will be logged on this page with the reason.

Proposed CPV list (locked before the run)

This is the locked v1 list. Broad codes such as the machinery divisions may pull in contracts that are not plant hire or maintenance, so we will report how many sampled releases were manually judged out of sector, if any.

What counts as “usable”

Usable end date

A contract end date is present in a parseable form, or can be derived from a published start date plus a published duration, and is not earlier than the start date. Checked in order: contracts[].period.endDate, awards[].contractPeriod.endDate, then start date plus durationInDays from the same blocks. Dates that are missing, malformed or contradictory do not count. We do not use tender.contractPeriod as a substitute, since it describes the planned rather than the awarded contract.

Named incumbent

A supplier is named on the award (awards[].suppliers[].name). Releases with no supplier, or only a placeholder, do not count.

Award value

A value and currency are published for the award or contract (awards[].value or contracts[].value). A value of zero or a missing currency does not count.

Alertable

Both a usable end date and a named incumbent are present. This is the figure that decides whether an alert can be built for that contract.

Extension option stated

The release says whether extensions or renewals exist, either as structured data (such as a maximum extent date or renewal description) or explicit text. It does not mean they will be used. Silence is counted as “not stated”, not as “no extension”.

Run record

These cells will be filled from the first completed run and dated. Until then, treat this page as a statement of method only.

Known limits we will report whatever the numbers show

Frequently asked questions