The circuit in a spreadsheet

Every result on the circuit now downloads as a file. downloads.php links a CSV and a JSON of the published programme, with a licence line above them, and both are built by the same tool from the same rows the race pages render. Validation diffs the generated files against the data on every run, so the spreadsheet and the page cannot drift apart without the build failing.

What is in it, as at this publication: 21 cards across ten venues, 198 runner rows, and 72 finishing lines from the eight resulted races. Each runner row carries the race slug, the venue, the draw id, the seed, the book, the saddlecloth number, the barrier or box, the runner and its trainer, the numbers held, the true share, the published price and the implied percentage. Each finishing line adds the position, the margin, and the time where the code records one. Resulted cards carry their Win, Place, Forecast and Tricast figures as reference numbers.

There is no prizemoney column, in the file or anywhere else. Nothing is staked on this circuit, so nothing is won, and the field prints an em dash rather than a figure somebody might quote.

The seed is the point

The two columns that make the file different from a results list are the seed and the weight vector. Given both, a past race recomputes: feed them back into GP-Draw 4.2 and the same finishing order comes out. GLI-33 v1.1 §A.6 requires an operator to keep enough material to reconstruct its virtual events for the past 90 days, by some combination of text, logs, video, graphics or screen captures (read 18 October 2026). That is a record-keeping duty owed to a regulator, not a publication duty owed to a reader, and no commercial virtual product publishes the numbers. Publishing them is the same idea discharged the other way round.

Why nobody else does this

Partly because the authoritative source cannot be read. 49s.co.uk holds the results history for the main shop circuit and serves it through a client-side application whose interface refuses unauthenticated requests: a request to its latest-results endpoint returned HTTP 403 on 18 October 2026, and archived captures contain only the application shell. Nothing on it is indexable, quotable or linkable, and every other site in the niche exists to work around that.

Mostly, though, because the history is deliberately discarded. An archived aggregator states its own policy in one line: "Results shown refer to today's races and are therefore cleared at midnight each day." The most functional aggregator in the niche offers a date picker covering 2025 and 2026 and no further, publishes no margins, times or dividends, drops the rider name the feed carries, and has no interface, no CSV and no charts of any kind (all read 18 October 2026). One site advertises "instant finishing orders, starting prices (SP), winning margins, jockey statistics, and detailed race cards" and, across three pages fetched the same day, published no race data at all.

So the archive is the asset, and it is an asset by default. Keeping a season of results is not a technical achievement. It is a decision not to delete them.

What to do with it

The obvious exercise is the one this desk runs on every column: take the weight column, take the finish column, and check whether the published chances are being honoured. Across the eight resulted cards the best-weighted runner won two against 2.2 expected, which is the sort of sum the file exists to let somebody else do without taking our word for it. The arithmetic is set out on how-it-works.php and the columns are defined in the glossary.

Circuit cards, fields and results are generated by the GP-Draw simulation and published with their seeds. Corrections to the files go to the desk and are printed in the column that got them wrong.