The queue that is past its own date

Of the 95 entries in the confirmed tier of NESO's connection register, the tier NESO says carries a confirmed connection date, 17 were already past that date in the copy published on 15 September 2026: 17.9% of the tier's entries, and 18.5% of its capacity.

Another copy of the register prints 2 of those 17 dates as not yet past, so on that reading it is 15 entries. Both readings are set out below, and neither is quoted here without the other. Across the whole register, 98 entries (96 distinct project ids) say their date has passed and do not say “Built”.

None of this says that any project is late. The register records a date and a status, not delivery, and NESO describes the status as its best-known classification. What is counted is what the document says.

A single copy cannot tell a date written last week from one written years ago. One project shows why the copies have to be kept: the register has called the 2,450 MW project at Eggborough by three different names, has given its old name to a different project (in January 2024), and in every one of the 511 copies that show it, from November 2018 to September 2026, has printed its status as “Awaiting Consents”.

Two later copies, counted the same way. The method was sealed in DECLARATION-v3.md (SHA-256 dd396986922a1604…) and its amendment before the copies NESO published on 25 September 2026 and 29 September 2026 were counted. In both, 18 of the confirmed tier's 103 entries are past their date (17.5% of its entries, 17.7% of its capacity; 16 on the other reading), and across the register the list went from 94 to 95 entries, only because one date arrived. The section “Two later copies” below has both counts and the comparison.

Census over the copy of 2026-09-15. Declaration DECLARATION.md, SHA-256 400b42f72b8c77759f88702d113594cdb2bb1b397f903486aaf39e92c7bc4b6d, frozen and witnessed before any figure here was computed. Run 2026-09-17.

The mystery

In the copy of NESO's TEC Register published on 2026-09-15, 98 entries carrying 12,034.86 MW have an effective date earlier than that publication date and a project status other than “Built” (96 distinct project ids, 11,984.86 MW, on the second reading below).

That sentence is deliberately narrow. It is not the claim that 12,034.86 MW of generation and storage is late — the register cannot support that, and this investigation does not make it. It is the claim that this many entries say the date has passed and do not say Built. What such an entry means is the second question, and the register does not answer it.

The evidence

One copy of the register and nothing else: data/raw/neso/tec-history/2026-09-15_neso-ckan.csv, SHA-256 d13406e495746f1b80e725321a5c7f95e21e0da16830bb6bd1f94ece172c9d5b, 2,200 rows, fetched from the NESO data portal on 2026-09-15 and journalled with its resource URL and publication basis.

Every row of that copy falls in exactly one of four classes, which is check C3:

Those two numbers meet: the copy carries 377 rows at “Built”, 15 of them dated, so 362 “Built” rows are undated — exactly the 362 undated rows in the copy. Every row with no effective date is a row the register calls Built. The register appears to clear the date once a project is built, which is why the residue this census measures — a date in the past with a status that is not Built — is the set of entries the register has neither moved on nor cleared.

For scale, the same copy carries 586,036.24 MW dated on or after 2026-09-15 across 1,736 rows, of which 503,676.63 MW is at status “Scoping”.

By status, as the register prints it

By plant type, as the register prints it

The register prints compound plant types; this census keeps them whole and does not split a combined entry across its technologies.

By the year the date fell in

The earliest dates on the list

What the count is of: the confirmed tier

This section is version 2 of the declaration (DECLARATION-v2.md, SHA-256 82856d65ae7300fca7e8ddb5ff43cff3bceb38fdc7b25fb42a761906930ef0b3), frozen after the census above had run and before any figure in this section was computed. Version 1's census is unchanged by it.

Under NESO's connections reform the queue is sorted into tiers. NESO's own published definition, pinned in this repository (data/raw/neso/neso-g2wq-evidence-handbook-resources.html, SHA-256 cb5c712b7f43fa54…, fetched 2026-08-23), says it in these words:

Gate 2 applies to projects that meet the new requirements for readiness and Strategic Alignment. These projects can secure a confirmed connection date, connection point, and queue position. Gate 1 applies to projects that do not meet the Gate 2 criteria. […] Gate 1 projects will not be assigned a confirmed connection date but may progress through future windows if readiness is demonstrated.

So a date in the Gate 2 tier is a confirmed date in NESO's own sense. Every copy of the register this archive holds from 2026-05-19 carries a Gate column; the archive holds none at all between 22 July 2025 and that date, so the column's earlier history is not reconstructable here. Two cautions, both declared before this was computed: the register does not print the words “Gate 1” and “Gate 2” — it prints 1 and 2, and reading those as the two tiers is the one interpretation made here; and NESO's definition says nothing about a blank cell, so a blank is reported as a blank and is never called “not assessed” or folded into either tier.

The copy, split by Gate (G1)

The overdue entries, split by Gate (G2)

17 of the 95 entries in the confirmed tier are already past their confirmed date, carrying 2,497.92 MW of the tier's 13,524.45 MW. That is 17.9% of the tier's rows and 18.5% of its capacity. The two shares are close here, which is a coincidence of this copy and not a general fact; they are computed and printed separately for that reason, and neither stands for the other.

Which statuses sit inside the tier (G3)

9 of the 17 overdue confirmed-tier entries — 1,172.8 MW — read “Scoping”. That is the status the register prints for 1,484 of this copy's 2,200 rows, 1,449 of which are dated in the future. The page draws no conclusion from that pairing; it is what the two columns say side by side.

Every overdue entry in the confirmed tier (G4)

What the gated copies show (G6), and the question they answer

A single copy cannot say whether a confirmed date was set and then passed, or whether the entry was moved into the confirmed tier with the date already gone. Only the copies can, and the archive holds 4 that carry a Gate column: 2026-05-19, 2026-08-22, 2026-08-25, 2026-09-15.

In every one of the 17 cases, the date had already passed in the first of these copies whose Gate cell reads 2. Not one of them was given a confirmed date in these copies and then watched it go by: each was published into the confirmed tier carrying a date that was already behind it, some by weeks and some by more than two years. That covers 2,497.92 MW. It is a statement about what the register published and when, not about any project's readiness and not about delivery.

Correction, 24/09/2026 (before publication). The sentence "each was published into the confirmed tier carrying a date that was already behind it" says more than G6 shows, and R12 requires the page to say where the four copies do not settle the question. The gated copies are not consecutive: no copy is held between 19/05/2026 and 22/08/2026 (95 days). Fifteen of the 17 first read 2 on 22/08/2026, and for 7 of those 15 (Whitelaw Brae Windfarm, Persley Croft BESS, Holmston Farm Battery Energy Storage System, Lovat Estate BESS, Windy Standard III Wind Farm, Balbougie Energy Centre, Whitelaw Brae BESS; 293.3 MW) the date fell inside that gap, so they may have entered the tier in a copy not held here while the date was still ahead. For them the four copies do not settle it. For the other 10 the date had already passed in the last gated copy before the first that reads 2. A blank Gate cell in that earlier copy is not interpreted (R10), so even for those 10 this is a statement about the copies held, not about when NESO assessed them. The sentence above is kept as written; this note governs it. The 7 and 10 are a reading of the committed G6 rows and are not promoted to any slot.

And the figure has to carry this against itself. 2 of the 17 rows, 550 MW, are rows some copy above publishes with a date that is not past at all:

The census rule reads each copy as it is spelled and does not apply the day-month correction to a single copy, so those rows are inside the count above, as declared. On the other reading the confirmed tier's overdue capacity is 1,947.92 MW over 15 rows. Both numbers are published here; anyone quoting the larger one should quote this paragraph with it.

Repetition (G5). None. No two of the overdue confirmed-tier rows share a project id, and no two share a project name: the two 540 MW offshore platform rows are printed as separate entries, Platform 1 and Platform 2, with different project ids and different project numbers. There is no double count to net off and no second reading to publish.

What this section does not say. That any of these projects has failed to deliver, or will. The register records a tier and a date; it does not record delivery, and nothing is inferred about it here. Nor is anything said about whether NESO's assessment was right — that is not a question this evidence can reach.

Two later copies: 25 September 2026 and 29 September 2026

This section is version 3 of the declaration (DECLARATION-v3.md, SHA-256 dd396986922a16041766de865bcf9d145583dcecdd9b6fb438114b8eb34f262f) and its amendment 1 (DECLARATION-v3-amendment-1.md, SHA-256 35b74e13301a0a1c60d61ad9d8ade65387252bfd4aed1a94153c6fc573e4f419), each frozen and witnessed before any figure it governs was computed. Versions 1 and 2 above are unchanged by it.

The same count, run on the copy NESO published on 25 September 2026 and on the first copy it published on or after 29 September, finds 94 entries carrying 11,854.86 MW on 25 September 2026 (92 distinct project ids, 11,804.86 MW) and 95 entries carrying 11,940.36 MW on 29 September 2026 (93 distinct project ids, 11,890.36 MW) with an effective date earlier than that copy's own date and a status other than “Built”.

In the confirmed tier, 18 of its 103 entries are past their confirmed date in both copies, carrying 2,560.92 MW: 17.5% of the tier's entries and 17.7% of its capacity. Another copy of the register prints 2 of those dates as not yet past; on that reading it is 16 entries and 2,010.92 MW, in both copies. Neither figure is quoted without the other.

Between the two copies, 4 days apart, every one of the 94 entries on the first list is still on the second, and 1 joined, because the date it already carried arrived; none left.

The method was checked first

Before either count, the code for this version was run on the captured copy of 15 September 2026, which has the same SHA-256 as the copy versions 1 and 2 read. It reproduced version 1's 98 selected rows line for line and all 25 of its totals and breakdowns, and version 2's 17 confirmed-tier rows with G1 to G6, to the penny (check C10, evidence/v3/method-check.json). It passed.

The copies

Each copy's date is the day of its CKAN last_modified, as for every copy this archive has pinned. The first is named by its digest in the declaration; the second is the first copy the daily capture holds dated on or after 29 September. The capture runs once a day, so a copy NESO published and replaced within a day would never be seen; the capture's manifests hold a record of the register for every day from 29 September to the day it fetched this one (30 September 2026), so no day was missed.

NESO's filename names the day before each copy's date (24 September 2026 and 28 September 2026). Read against the filename's date instead, no entry moves on either copy.

The second copy spells its dates differently. Every one of its 1,834 dated cells is written YYYY-MM-DD, where the copy of 25 September 2026 and every earlier captured copy write DD/MM/YYYY. The declaration's schema check (N0) required the old spelling, so it stopped the run before anything about that copy was computed (evidence/v3/n0.json). Amendment 1 was then written from the schema report alone, approved and witnessed: the new spelling is read year, month, day, which is how the register's earlier ISO copies (22 and 25 August 2026, read by version 2) were read; and the day-month swap test the series uses for exactly this case was run first between the two copies. It found 0 dates that differ between them among entries it could match, 0 of them explained by exchanging day and month, so it did not flag the copy (F11 did not fire). A change of spelling alone never moves an entry in the comparison below, which compares dates, not the way they are written. The copy also prints capacities with two decimals (540.00); they are the same numbers.

Side by side

The calendar alone moves entries into the count as their dates arrive, so every difference is read with both dates: 25 September 2026 and 29 September 2026, 4 days apart.

Entry by entry

Every entry on either list, matched by its project id and stage:

No project id and stage is on more than one row of either copy, so every entry is classed. The classes add up to each copy's own totals (check C11). An entry whose date arrived is not late for having arrived, and an entry that leaves has not been delivered for leaving; the register prints what changed, not why.

The breakdowns, side by side

By status, as the register prints it

By plant type, as the register prints it

By the year the date fell in

The earliest dates on the list

The same ten entries head both lists:

On 25 September 2026, 8 of the 94 carry 0 MW, 2 project ids appear on more than one entry, and 18 dates could be read with day and month exchanged, 2 of them (500 MW) would then not be past. On 29 September 2026, 8 of the 95 carry 0 MW, 2 project ids appear on more than one entry, and 18 dates could be read with day and month exchanged, 2 of them (500 MW) would then not be past. In a copy that spells dates YYYY-MM-DD the other reading would be YYYY-DD-MM, which is not a spelling the register has used; the figure is given in the same form for both copies, as declared.

The confirmed tier in each copy

The entries past their date, by Gate cell, with each Gate's two shares of its own total (row share first, capacity share beside it):

The same entries are in the confirmed tier and past their date in both copies:

No two of them share a project id or a project name in either copy.

What the 8 copies with a Gate column show

Gate cell and date as each copy prints it, for every entry above, in each copy's own spelling of the date.

All 18 were already past their date in the first of these copies whose Gate cell reads 2. For 11 of them the date had already passed in the last copy held before that one, so in the copies held they entered the tier already behind their date. For the other 7 (Whitelaw Brae Windfarm, Persley Croft BESS, Holmston Farm Battery Energy Storage System, Lovat Estate BESS, Windy Standard III Wind Farm, Balbougie Energy Centre, Whitelaw Brae BESS; 293.3 MW) the date fell between the last copy held before and the first that reads 2, a stretch of 95 days with no copy held, so these copies do not settle when they entered the tier. A blank Gate cell in an earlier copy is not interpreted. Benthead Solar first reads 2 in the copy of 25 September 2026, after version 2's count.

The two readings of the tier's figure come from these entries, which some copy prints with a date that is not past:

What this version never claims

• That any difference between the two copies was caused by the announcement of 29 September, by any policy, by NESO's connections reform or by the queue fee. The copies are days apart, and the register records dates and statuses, not reasons.
• That an entry whose date arrived is late, or that an entry leaving the list was delivered.
• That either count measures the queue's health. Each measures what one copy of the register printed on its own date.

Falsifiers declared before the run. None fired, on either copy or in the comparison (F1 to F11, including the filename reading, unmatched entries and the swap test).

Expert corner for version 3

• Declaration investigations/017-the-overdue-queue/DECLARATION-v3.md, SHA-256 dd396986922a16041766de865bcf9d145583dcecdd9b6fb438114b8eb34f262f; amendment investigations/017-the-overdue-queue/DECLARATION-v3-amendment-1.md, SHA-256 35b74e13301a0a1c60d61ad9d8ade65387252bfd4aed1a94153c6fc573e4f419; both witnessed by OpenTimestamps and RFC 3161 tokens from freetsa.org and DigiCert and committed with their proofs.
• Copies read from the local mirror of the daily capture after each digest was checked against the committed manifest that recorded it: 25 September 2026, raw/neso/tec-register/2026-09-26/da0b67b5ea34a85606f3a98269916f647c32a0f3b496f91a1136e80069175a6c (manifest 2026-09-26.ndjson, SHA-256 d4f2e3c341017e91aea18f519dce75e77f20ada73925dd3d8ecab06c3144e081); 29 September 2026, raw/neso/tec-register/2026-09-30/d1ccd9e210b4f6bc8f3b0e83d54032dc61f247dbbc1d9e469a342b7766ee5746 (manifest 2026-09-30.ndjson, SHA-256 ddfa00291f53a73666318573764e42bdf8175469e16931a4d9a21ba3f664c47a).
• Capture schema report (archives/tec-register-capture/) the censuses were checked against: 918a20994341bdaab1b00df5ed6046adca396d93d04874fc9e261f84df39fda3 for 25 September 2026, 857dfc88949a95b3553d96fa25bd84fbed6f4ed433f1090f324140b644975ebd for 29 September 2026 (regenerated with that copy in it, N0).
• Evidence: evidence/v3/method-check.json (C10), evidence/v3/2026-09-25/, evidence/v3/2026-09-29/ (census.json, rows.ndjson, gate.json, gate-rows.ndjson, append-only), evidence/v3/n0.json, evidence/v3/a2-swap-test.json, evidence/v3/comparison.json.
• Checks that had to pass on each copy: C1′ the status counts equal the capture schema report's for this copy; C2′ dated plus undated is every row; C3′ the four classes partition every row; C4′ the copy carries no flag and the partial-export rule does not make it suspect; C5′ selected rows written append-only, no committed line changed; C6′ the Gate counts equal the capture schema report's for this copy; C7′ the cross-tab reads exactly the rows this census of the copy selected; C8′ the Gate split sums to this version's census of the copy; C9′ every selected row's Gate cell is in the copy's vocabulary; and in the comparison: C11 D2's classes sum to each census's selected rows and MW.

uv run --group registers python investigations/017-the-overdue-queue/run.py \
    --version 3 --seal dd396986922a \
    --amendment-seal 35b74e13301a --phase check --copy next

recomputes the second copy's census and fails if a committed row would change; --copy reference does the first, and --phase method-check reruns C10.

The exhibit: one project, traced across every copy

A census of one copy cannot tell a reader whether a date that has passed is news or is eight years old, and it cannot see the entries whose date has not passed yet but has been rewritten repeatedly. For that the copies have to be read in sequence. The As-of Connection Record Certificate is 014's instrument for exactly that, and it is applied here to Eggborough CCGT - OCGT - BESS, 2,450 MW at Eggborough 400kV Substation, whose first stage is dated a fortnight after the copy this census reads.

It takes more than one certificate, and that is the first finding: the register has called this project three different things. A reader who searches today's copy for its current name and then looks for that name in older copies finds nothing before 1 July 2025.

Each bundle below is hash-addressed: its manifest's SHA-256 is the certificate id, the manifest lists every evidence file with its digest, and both the manifest and the certificate are witnessed by OpenTimestamps and by RFC 3161 tokens from two authorities. python3 verify.py inside a bundle recomputes every digest offline.

Eggborough, 2014-01-31 to 2026-09-15

Bundle eggborough-2014-01-31-2026-09-15, certificate id 9896e04cbaf031b5a3de8668e6c9fc8567c0575c161af620388e94087430c54c. 700 copies consulted (2014-01-31 to 2026-09-15); 2 with no matching row, 75 ambiguous, 2 suspect.

Every status the register published for this project's own row in the copies this bundle consulted — the row whose published plant type names a gas turbine plant or the hybrid label, which is what separates it from the coal station that shared its name until 2020 and from the storage project that took the name in 2024:

Eggborough CCGT and BESS, 2024-01-05 to 2025-07-22

Bundle eggborough-ccgt-and-bess-2024-01-05-2025-07-22, certificate id 0ed046aeba0f7d93c34b5fd78287dcbde92dc1eccc78eb0380452f011e3889e8. 107 copies consulted (2024-01-05 to 2025-07-22); 2 with no matching row, 11 ambiguous, 0 suspect.

Every status the register published for this project's own row in the copies this bundle consulted — the row whose published plant type names a gas turbine plant or the hybrid label, which is what separates it from the coal station that shared its name until 2020 and from the storage project that took the name in 2024:

Eggborough CCGT - OCGT - BESS, 2018-11-08 to 2026-09-15

Bundle eggborough-ccgt-ocgt-bess-2018-11-08-2026-09-15, certificate id 73b9152d2479f61cd5854ed1274f857a268bb2cede720e7bcb56d93ce1736b5c. 512 copies consulted (2018-11-08 to 2026-09-15); 506 with no matching row, 6 ambiguous, 1 suspect.

Every status the register published for this project's own row in the copies this bundle consulted — the row whose published plant type names a gas turbine plant or the hybrid label, which is what separates it from the coal station that shared its name until 2020 and from the storage project that took the name in 2024:

Eggborough CCGT - OCGT - BESS, stage 1, 2025-07-01 to 2026-09-15

Bundle eggborough-ccgt-ocgt-bess-2025-07-01-2026-09-15, certificate id 268237d523cfa2a94a211250fe363b18efdd39873b254aa3419cf3026d47ec09. 6 copies consulted (2025-07-01 to 2026-09-15); 0 with no matching row, 0 ambiguous, 0 suspect.

Every status the register published for this project's own row in the copies this bundle consulted — the row whose published plant type names a gas turbine plant or the hybrid label, which is what separates it from the coal station that shared its name until 2020 and from the storage project that took the name in 2024:

No change between the two copies in force.

Reading the bundles in order

• The coal station's capacity leaves the register in the copy of 23 September 2015: the stage TEC goes from 0 to −1,940 MW and the cumulative total from 1,940 MW to 0, effective 1 April 2016.
• A second row named Eggborough appears in the copy of 8 November 2018. The bundle's extract for that copy publishes it as 2,450 MW, effective 1 April 2022, status Awaiting Consents, plant type CCGT — beside the coal row, by then “Built” at 1,870 MW.
• The published target date then moves: 1 April 2022 until the copy of 2 April 2020; 1 October 2024 in the copy of 9 April 2020; 1 October 2025 in the copy of 23 April 2021; 1 October 2026 in the copy of 16 September 2022. It has not moved since — four years on the same date.
• Six of the changes listed above are the register printing one of those dates with day and month exchanged and then exchanging them back (1 October 2024 and 10 January 2024; 1 October 2025 and 10 January 2025). The certificate records what was published; the day-month correction is a test between two consecutive copies, which a certificate does not apply.
• In the copy of 5 January 2024 the name Eggborough stops being this project's. That one copy changes the customer, the capacity, the target date, the status, the plant type and the project id — the register has given the bare name to a different, smaller project, and this one continues under Eggborough CCGT and BESS.
• In the copy of 24 December 2024 that entry becomes two rows: the split into stages. By the copy of 1 July 2025 the name is Eggborough CCGT - OCGT - BESS, stage 1 at 1,999 MW effective 1 October 2026 and stage 2 at 451 MW effective 1 October 2027.
• The bundles between them see this project in 511 copies of the register, from 2018-11-08 to 2026-09-15, and in every one of them the status reads “Awaiting Consents” — it has never read anything else.

The two readings, and which one this investigation takes

The Planning Inspectorate decided the development consent order for the Eggborough gas plant on 20 September 2018, under the Planning Act 2008, for up to about 2,500 MW. The register's first copy showing this entry as “Awaiting Consents” is seven weeks later, and every copy since says the same.

So either the status field means a consent other than that order — there are others a project of this kind needs — or the field has not been refreshed in eight years. This investigation does not choose. It publishes the record and says that the register does not, on its face, distinguish the two. The question has been put to NESO under the Environmental Information Regulations (FOI/26/216, answer due 13 October 2026) and the answer will be published here when it arrives, whichever way it goes.

The consent order decision date above is stated from the public planning record and is not pinned in this repository; everything else in this section is a line of a witnessed certificate bundle. Pinning it is outstanding.

That is the general point the exhibit is for. A status in this register is not dated, and a reader of one copy cannot tell a value written last week from one written in 2018. The census above counts 98 entries whose date has passed; it cannot tell you, from that copy alone, which of them the register has simply stopped looking at. Only the sequence of copies can, and the sequence is not published — it has to be rebuilt.

What this does not say, and what could move it

It does not say that any capacity is late. The register's status is NESO's own best-known classification, and NESO says so. A row whose date has passed and whose status is not “Built” may have connected without the status being refreshed — which is the same staleness this investigation is about. The claim is about what the document says, and only that.

Zero-capacity rows. 8 of the 98 carry a published capacity of 0 MW. They are counted in the row count and add nothing to the MW total, so the row count and the MW figure are not two views of the same thing. Every selected row carries a capacity the register's number formats can read; none had to be excluded.

Rows sharing a project id. 2 project ids appear on more than one selected row. Counting rows gives 12,034.86 MW; counting each id once and keeping the largest of its rows gives 11,984.86 MW over 96 ids. Both readings were declared before the run and both are published; the rows are:

Day and month. Every dated cell in this copy is written DD/MM/YYYY, and the archive's schema report records that no other spelling appears in it. Six copies elsewhere in the archive do exchange day and month, so the census publishes the sensitivity: 18 of the selected rows (4,072.2 MW) have a date that could be read the other way round, and 2 of them (500 MW) would then not be past the date at all. The day-month correction is a test between two consecutive copies and is not applied to one copy.

Against the ungoverned figures that prompted this. The declaration records, before the freeze, what the author had already seen from an ad-hoc script outside this repository. The run agrees with it on the headline (98 rows, 12,034.86 MW), on the yearly table, on the eight zero-capacity rows, on the earliest entry, and on the scale line. It differs in two places, and the run is what is published:

• The scratch figures split the register's compound plant types across their technologies, which put 5,175 MW under Energy Storage. This census keeps compound types whole, as declared, so Energy Storage System alone is 3,706.95 MW and the rest sits under the combined labels in the table above.
• The two project ids that appear twice are the ones the scratch named, but not what it said they were. They are two genuine multi-stage entries — stage 1 and stage 2 of the same project, with different capacities and different dates — not a platform counted twice. Neither is a double count, which is why the two readings of the unit differ by 50 MW and not by more.

Falsifiers declared before the run. None fired. The three were: that day-month swapping could move more than a fifth of the selected MW into the future; that the copy carried a schema-report flag or a partial-export suspicion; and that the two readings of the unit differed by more than a tenth.

Expert corner

• Declaration: investigations/017-the-overdue-queue/DECLARATION.md, SHA-256 400b42f72b8c77759f88702d113594cdb2bb1b397f903486aaf39e92c7bc4b6d, witnessed by OpenTimestamps and by RFC 3161 tokens from freetsa.org and DigiCert at the moment of the freeze, and committed with its proofs by scripts/freeze.
• Version 2 of the declaration, the Gate cross-tab: investigations/017-the-overdue-queue/DECLARATION-v2.md, SHA-256 82856d65ae7300fca7e8ddb5ff43cff3bceb38fdc7b25fb42a761906930ef0b3, witnessed the same way and frozen after version 1 had run. Its evidence is evidence/gate.json and evidence/gate-rows.ndjson; NESO's definition of the tiers is pinned at data/raw/neso/neso-g2wq-evidence-handbook-resources.html, SHA-256 cb5c712b7f43fa545725bae4cb942c2c4353b8c0a2095c5a65ce7694de6bb514.
• Checks version 2 had to pass: C6 the Gate counts equal the schema report's for this copy; C7 the selection is version 1's, unchanged; C8 the Gate split sums to version 1's committed census; C9 every selected row's Gate cell is in the copy's vocabulary.
• Archive schema report version 1's reading rules were written against: SHA-256 ce3c61d735ff6349b553e6956d43ee042bd45a85995696dc15fff8620d33f570 (archives/tec-register/). Version 2 was written against be060a7c671887010b3ad93c2d57f2c3caff0b01ed9dbe1dbbc6f91aac39b211, which adds the Gate vocabulary to the same pass and changes no status count, so version 1's check C1 passes against both.
• The one copy: data/raw/neso/tec-history/2026-09-15_neso-ckan.csv, SHA-256 d13406e495746f1b80e725321a5c7f95e21e0da16830bb6bd1f94ece172c9d5b, 421,159 bytes, source neso-ckan, publication basis: CKAN resource last_modified 2026-09-15T16:48:30.055757 and filename tec-register-15-september-2026.csv; fetched live 2026-09-15
• Measure: MW Increase / Decrease as published, read as Decimal. The cumulative column is never added to it and never substituted for it.
• Boundary: an effective date strictly earlier than 2026-09-15, the copy's own publication date — not the date the census was run.
• Selected rows, one line each as published: evidence/rows.ndjson (98 lines, append-only). Summary: evidence/census.json.
• Checks that had to pass: C1 the status counts equal the schema report's for this copy; C2 dated plus undated is every row; C3 the four classes partition every row; C4 the copy is in the series' reading with the same row count, and is not suspect.

Reproducibility

uv run --group registers python investigations/017-the-overdue-queue/run.py \
    --seal 400b42f72b8c --phase check

recomputes the census from the same copy and fails if a committed row would change. scripts/check-rules maps every rule in the declaration to the test that holds it; scripts/verify-proofs checks the declaration's timestamps against the roots committed under trust/tsa/.

This page is FINDINGS.md with a lead added, both pure functions of the committed evidence (evidence/) and of the corrections in corrections.json.