Corrections

Epoch AI's GPU-clusters CSV emitted "Total number of AI chips" = 100,000 as a power-derived inference, flagged verbatim in the CSV's Note column ("Chip amount roughly estimated based on power capacity. Assuming for now that they're using GB300s, but this hasn't been officially confirmed"). Scrutica's ingest passed the value through with is_estimated = true but no second-source check. The physical sanity bound also fails: 200 MW / 100,000 GB300 = 2.00 kW/GPU is infeasible at GB300 TDP 1.4 kW with chip-share-of-power 0.49 (per-chip envelope = 0.98 kW < TDP); 200 MW / 35,000 GB300 = 5.71 kW/GPU is plausible. The Epoch CSV estimate predates the November 2025 Commerce Dept disclosure that anchored the actual chip ceiling.

A new editorial overlay table, editorial_facility_numerical_corrections, allows numeric column values to be corrected at display time without modifying the substrate (CLAUDE.md §16; mirrors the type/name correction tables already shipped). The Stargate UAE Phase 1 correction landed as 3 paired INSERTs (total_gpu_count, peak_pflops_fp16, h100_equivalent_gpus). The substrate verbatim row remains unchanged so Epoch CSV refreshes do not re-introduce the inflated value. The ingest pipeline (scripts/ingest-epoch-gpu-clusters.ts) now flags any Epoch CSV row whose Note column matches the power-derived inference pattern with a chip_count_power_derived_estimate data-quality flag, surfacing peer rows (~13 GB200/B200 facilities matching the same pattern) for future correction once operator-direct disclosure emerges.

A prior migration altered the canonical country column shape from full names ("United States") to ISO2 codes ("US"). Two accessors — the NL query engine tool-executor and the /api/query route — were not updated during the migration and continued filtering the new ISO2 columns using full country names, producing a silent zero-row intersection.

Accessors now route through a canonical async countryToIso2() wrapper (src/lib/data/country-iso2.ts) that ensures query parameters and extracted tool entities match the database column shape. The accessors also apply strict sanitization, returning zero rows for unrecognized input rather than throwing 500 errors.

A database migration added the chain_stub_count column with DEFAULT 0 NOT NULL, but the precompute script was never re-run after the column was introduced. The live substrate carried the default zero values for all 4,529 rows, which the application faithfully rendered.

The precompute script was re-run to populate the column correctly. A persistent parity check script was wired into the pipeline to assert chain_stub_count values match real-time hop counting, ensuring any future stale precompute state is caught immediately.

The GPU spec table was originally populated per chip family (H100) rather than per SKU variant (H100-SXM, H100-PCIe, H100-NVL). Form-factor variants diverge from the family baseline on memory type and capacity, and the single-entry approach hid those divergences.

GPU spec entries in lib/data/chip-classifications.ts are per-SKU rather than per-family. Each entry requires a source URL pointing to NVIDIA's specific datasheet for that SKU. The change applies to all subsequent additions (R200, B300, TPU v6e, etc.).

PostgREST — Supabase's auto-generated REST API — caps query results at 1,000 rows by default and returns no warning or metadata flag indicating truncation has occurred. Any Scrutica query against a table larger than 1K rows was silently returning a partial result set, which the code then treated as complete.

A site-wide fetchAllRows() helper (exported from lib/supabase/server-user.ts) automatically paginates any query expected to return >1K rows. Data-access modules that query the supply-chain, BIS, and cascade tables now route through this helper, with the cap documented inline so it is caught on review rather than re-discovered.