A part named only in prose has no record, and no check in the repo can see it

Four parts that the corpus talks about constantly had no accelerator record at all, and every mention of them lived in free text: Cerebras CS-4 / WSE-3 Turbo (named in five records, including by the CS-3 record itself, which says 'A separate record for CS-4 / WSE-3 Turbo should be created if needed'), AWS Inferentia gen-1 (named by the Inf2 record's own '10x lower latency compared to Inferentia' and by the AWS product page's 'first-generation Inferentia'), AWS Trainium gen-1 (priced in data/supply/aws-ec2-trn1-trn2-trainium at $1.34 and $1.55 per chip-hour, and named in the Neuron runtime source), and Tenstorrent Grayskull (listed as a live supported backend in data/engines/niche-tt-metal.json, so a reader would conclude a Tenstorrent user can run on it today).

The dangling-reference check cannot detect this, and the reason is structural. tools/validate.py resolves references in id-bearing fields - sources, affected_by_hardware, accelerator_ids, format_id, engine - against the set of record ids. A part named inside a notes STRING resolves to nothing and is counted by nothing. So the failure mode is not a broken reference, it is the ABSENCE of a reference: the corpus is internally consistent while missing a third of a product line. Three further mechanisms compounded it, and each is independently sufficient to produce the gap: (1) GENERATIONAL ASYMMETRY. For AWS Neuron the repo held Inf2, Trn2 and Trn3 and neither gen-1 part. Inf2 and Trn2 arrived via EC2 instance pages (the per-chip figures were DIVIDED OUT of instance aggregates, which is a visible, uncomfortable derivation that invites a record), and Inf1 and Trn1 have no such pressure because nobody derived a per-chip number from them - so nobody wrote them down. (2) A DEFERRED TODO INSIDE A NOTE. The CS-4 gap was not an oversight; a previous pass wrote the instruction to create the record into the CS-3 record's notes and then stopped. A TODO in prose has no schema, no validator, no owner and no due date, and it silently outlasts the pass that wrote it. The same deferral appears in the Trainium2 record: 'Trainium3 ... exists and is shipping ... it is deliberately not modelled here' - which was correct when Trainium3 was future hardware and wrong once aws-trainium3 was added while the sentence stayed. (3) A LIVE-BACKEND CLAIM WITH NO HARDWARE BEHIND IT. niche-tt-metal lists tenstorrent-grayskull in supported_backends, an id-resolved-looking string in an id-bearing list, yet no accelerator record existed. This is the most dangerous shape of the four because it makes an end-of-life part look supported. The vendor's own Grayskull page says 'Software support for Grayskull has been discontinued', with last supported versions TT-Metalium v0.55 and firmware fw_pack-80.14.0.0.fwbundle - a fact no record in the repo carried before this pass. A FOURTH, ADJACENT AND WORTH NAMING SO A LATER PASS DOES NOT REPEAT IT: aws-trainium2 carries process_nm 5 and aws-trainium3 carries process_nm 3, and NOT ONE source in data/sources/ supports a process node for any Neuron generation. Those are unsupported values in a field a reader will use for cost-per-transistor reasoning, and they were found only because this pass asked what every field on a new record rests on.

When auditing coverage for a part family, sweep every record's notes and free-text fields for family-member NAMES, not just for ids - the ids sweep is what validate.py already does and it has a zero hit rate for this defect. Then, for each named-but-unrecorded part, decide explicitly: record it, or record why not. Record it when a first-party page publishes something. Inf1, Trn1, Grayskull and WSE-3T each had one within a single fetch, so the cost was one source record plus one accelerator record each. Record an explicit NEGATIVE when no first-party figure exists. The new cerebras-wse-3t record has vram_gb null and names both documents read and the figure absent from each, which makes the gap auditable instead of invisible - that is a better outcome than no record, because a reader who wants the WSE-3T's SRAM capacity learns that Cerebras does not publish it, rather than learning nothing. Do NOT fill a gap with an inference to make coverage look complete. The tempting moves here were all wrong: dividing a Trn1 instance aggregate to get a per-chip bandwidth (an average, not a peak), carrying 44 GB from the CS-3 wafer onto the WSE-3T (a different wafer), or inferring a Grayskull SRAM figure from the 1 MB-per-core arithmetic without saying it was arithmetic. Three of the four new records are 'draft' or 'deprecated' rather than 'verified' precisely because completeness was not available and was not faked. When an existing record's notes say a record 'should be created', treat that as a required action in the current pass rather than as information for a future one. And where a value has no supporting source - as with the AWS process nodes - either find the source or null the field; do not leave it populated because it is plausible.

WHAT THIS PASS ADDED, all four with first-party sources: aws-inferentia1 (Inf1, status draft - the gap that mattered most, since it is the baseline every '10x better than Inferentia' claim on the AWS site is measured against, and that baseline was not in the repo), aws-trainium1 (Trn1/Trn1n, status draft, including a recorded first-party conflict between the 0.8 TB/s per-chip figure and the 612.5 GB/s that the 16-chip instance aggregate divides to), tenstorrent-grayskull-e150 (status DEPRECATED, because the vendor has discontinued software support - a deprecated record is the honest status and is more informative than no record), and cerebras-wse-3t (status draft, with the unpublished SRAM capacity as an explicit null). WHY 'DEPRECATED' IS THE RIGHT STATUS AND NOT A DEFECT TO AVOID: the schema's deprecated value means this record documents a part that should not be deployed against. For Grayskull that is exactly the fact a reader needs, and it is the fact that corrects niche-tt-metal's supported_backends list. A reader choosing hardware who finds no Grayskull record concludes nothing; a reader who finds a deprecated one with the vendor's last-supported-software versions concludes the right thing. WHAT WAS DELIBERATELY NOT ADDED, as filler, having been looked for and not found: Qualcomm AI250 (named in two source records; no spec sheet published, so a record would have been five nulls and a press mention), the Tenstorrent QuietBox and Galaxy workstations (named in the tt-metal perf tables, but they are systems built from cards the repo already records, and a system record would duplicate rather than add), Samba and Samba 7B (a MODEL family in data/models/, not an accelerator), and Grayskull as a separate pair of records for e75 and e150 (one record with both variants' figures in notes, because they are one part with two SKUs and the e150 is the one worth having figures for). THE COST-PER-TOKEN READER IS THE ONE WHO PAYS FOR THIS, and the corpus already said so: data/supply/w5s-throughput-priceable-coverage-2026-10-05 lists 'MISSING RENTAL RATE - the accelerator has no per-GPU-hour supply record anywhere' as its largest group, and separately records that aws-ec2-trn1-trn2-trainium 'has no Trainium throughput record'. A missing accelerator record is not only a coverage statistic; it is a price row whose accelerator_ids point at a part that does not exist, which is how Trn1 got priced under the id aws-trainium2.