For a stretch of this year, Scrutica’s Threshold Atlascounted a Micron DRAM fab among the United States facilities whose power draw could clear the EU AI Act’s 10²⁵ FLOP training threshold. The fab cannot train anything. The row that put it there carried 576 MW and one wrong word in one column, and 576 MW is a large number to be wrong about when the question on the page is which sites could, in principle, run a frontier model.
The error is more general than one fab, and the fix is duller and more load-bearing than the catch. This note is about the column.
The row
The record is a single line from the New York Independent System Operator’s interconnection queue — the public register of projects requesting a grid connection in New York. Queue position 1627, project name “Micron Fab 2,” Onondaga County, interconnecting at the National Grid Clay 345 kV substation; generation type “Load.” “Load” means what it says: a request to draw power. It asserts nothing about what the power is for. The queue does not know, and does not claim to know, whether position 1627 is a data center or a steel mill. It knows the megawatts.
Scrutica’s ingest of that queue did make a claim. It assigned every grid-queue row a facility_type of hyperscale_dc— a defensible prior for a large new interconnection request in 2026, when hyperscale data centers are the marginal load driving much of the queue, and a wrong one for this line. “Micron Fab 2” is the company’s leading-edge DRAM megafab at the White Pine Commerce Park in Clay, announced October 2022; Micron’s own release scopes the site at up to four 600,000-square-foot cleanrooms. The 576 MW is process and tool load — the power a fabrication line draws to etch wafers, not the power an accelerator cluster draws to train a model. Even the substation is named Clay.
Why one word moved the count
The Threshold Atlas asks a narrow question of every facility: given its power (or chip inventory, or disclosed capacity) and a set of exposed estimation assumptions, how many FLOP could a training run on this site accumulate, and does that clear a statutory line such as the EU AI Act’s 10²⁵? The page carries a short exclusion list for facility types whose power is definitionally not training compute — logic_fab, memory_fab, packaging— and drops them before any FLOP is estimated. A chip fab’s megawatts run lithography and deposition; converting them into a training-FLOP figure is a category error, and the atlas refuses to make it.
The list is the guardrail. It is also the entire vulnerability, because the filter keys on facility_type and nothing else. A fab labelled hyperscale_dcwalks straight past it — which is what happened. With the wrong word in the column, the row’s 576 MW went through the power-path estimate and a memory fab stood in the same column as an AI training campus, on the strength of a default that was right for the queue in general and wrong for the one line where it mattered most.
The tempting misreading is that a number was wrong. No number was wrong. 576 MW is correct; NYISO’s “Load” is correct; the FLOP arithmetic did exactly what it is written to do. The defect sat upstream, in a classification the ingest asserted more confidently than its source supported. An error in a category propagates further than an error in a value, because everything downstream that branches on the category inherits it — and here the branch was “count this site or don’t.”
There is a sharper embarrassment in the file history. The ingest campaign’s own schema-analysis notes, committed in March, had already flagged the row: “Semiconductor fab (not DC). Reclassify.” The flag lived in a markdown file no pipeline reads. The knowledge existed for three and a half months; it just wasn’t wired to anything.
The correction, and the one thing it corrected
The row’s facility_type was changed from hyperscale_dc to memory_fab. That is the whole fix. It moves the record into the exclusion set, so the atlas now drops it before estimation, as it always should have. The 576 MW is untouched; the NYISO figure and its “Load” descriptor are preserved verbatim. Nothing about the site’s real grid footprint changed — only the claim about what the footprint is for.
Two details of how the correction landed matter more than the correction.
First, it was an overwrite of a wrong value, not the filling of a blank. The record already carried hyperscale_dc; an ingest default is not a missing field awaiting a curator, it is a positive assertion made at write time, and here it was false. A fill-if-null enrichment — the polite, safe kind — would have declined to touch a populated column and left the error standing. The distinction is the difference between “we hadn’t classified this yet” and “we classified it, and incorrectly.” The second class is harder to find, because the field looks answered.
Second, the change landed as an editorial correction with a before/after precondition and its own citation, not as a script that reaches into the database and edits the row. Scrutica’s ingests re-run; a silent overwrite is overwritten right back on the next refresh, and the correction evaporates with no record of why it was made. The durable form keeps the prior value, the corrected value, the reason, and the source — so the next person to look at Micron Fab 2 sees not just memory_fab but the note explaining that the grid-queue ingest had defaulted it to hyperscale_dc, and why that was wrong.
What the case is actually about
A cross-source compute catalog buys breadth by ingesting registers that were never built to answer its question. The NYISO queue is an interconnection ledger: an excellent source on who is drawing large amounts of new power in New York, and a silent one on why. OpenStreetMap tags buildings; PeeringDB registers interconnection facilities. Each is authoritative for its own purpose and mute on facility type, so the ingesting system supplies one — a default, mostly; the register has no opinion to consult. Every supplied value is a place where a confident guess can enter a record wearing the same clothes as a sourced fact.
The lesson is not that the guardrail failed; the guardrail did its job the moment its input was true. It is that a filter is only as good as the field it reads, and the field it reads is frequently the softest thing in the record — a category the source never asserted, inferred at ingest under a prior that is right on average and wrong on the cases that matter. For a threshold count, the cases that matter are exactly the large-megawatt outliers, where “hyperscale by default” is most tempting and most consequential. One fab in a threshold count is a small error in isolation and a disqualifying one for a page whose purpose is to be trusted about which sites could train a frontier model. Getting the count right depends less on the FLOP methodology, which is transparent and adjustable, than on the classification underneath it, which is neither visible on the page nor, until it is wrong, obviously load-bearing.
Facility-type hygiene is not a glamorous invariant. It shows up once, when a memory fab is standing in the training-compute column — at which point it is the only thing that matters.
Per-claim sources
Cite this note
@misc{scrutica_facility_type_and_the_threshold_count_2026,
author = {Gringras, David},
title = {A memory fab in the model-training column},
year = {2026},
month = jul,
howpublished = {Scrutica Analysis},
note = {Dated note, published 2026-07-19; corrections logged at https://scrutica.com/corrections},
url = {https://scrutica.com/analysis/facility-type-and-the-threshold-count}
}Gringras, D. (2026, July 19). A memory fab in the model-training column. Scrutica Analysis. https://scrutica.com/analysis/facility-type-and-the-threshold-count
This URL is stable and the note is dated: its substance changes only through the public corrections process. If a claim here is later found wrong, the disclosure lands at /corrections with what was shown, the corrected value, and the root cause; the note then links the correction at the affected passage.