# Data pack: activity search against nine tender portals, September 2026

Every file here is derived from the saved result lists and grades of the runs on 15, 16 and 17 September 2026.

- summary_by_portal.csv: one row per portal. What the portal listed as open and what was counted in the test (the notice types both searches handle); relevant open tenders that appeared in either search's first 20 and first 100 results; found and missed by each side; the judge's precision and recall from the native-speaker checks.
- results_by_search.csv: one row per search per portal (900 rows). The two-word term, the full need it came from, the number of relevant open tenders that existed, and what each search showed in its first 20 and first 100.
- ranking_bands.csv: where the relevant tenders each search found sit in its list, by rank band, at 20 and 100 results.
- widget.json: the figures the page widget draws.
- lists/<portal>_results.json: for every search, both searches' result lists with rank, notice id and grade, and the ids of the relevant open tenders.
- human_checks/: the 300 notices per portal graded by a native speaker (human_core_<portal>.csv: 150 the judge called relevant; human_leakage_<portal>.csv: 150 it did not), with the key files giving the judge's grade and stratum for each row.

Definitions. A search is a two-word term a supplier would type, the same words in the portal's own search box and in ours on the same day. A relevant open tender is one the judge graded as being for that kind of work (grade 3 on both passes). Both searches are scored on the same set of tenders: those the portal listed as open on the day and in the comparison set (the notice types both searches handle), minus tenders released in the two days before the test and tenders closing on the day. Notice ids are OCDS ocids; the last segment is the portal's own id.