Audit of lead_time_weeks provenance across data/supply: every numeric value states its basis, and the structural-na class is doing more work than its definition allows

NO price_usd: this record audits lead-time provenance and carries no money figure at all. A lead time is a duration, not a price, and putting one in price_usd would be the exact category error this audit exists to prevent.

lead_time_weeks is null STRUCTURALLY: the subject is a completed audit of the lead_time fields, not something to be delivered. Stating this explicitly is in the spirit of the audit - the field exists to stop 'nobody publishes it' from reading as 'instant on-demand', and an audit record is the clearest possible case of the quantity not applying.

AUDIT RUN 2026-10-05 over all 119 pre-existing records in data/supply/ (the directory held 122 including the four w5s-prefixed records added by this same wave, three of which set lead_time_weeks null with a structural-na basis). The question was whether a lead time with no source is a guess that reads as a fact. The short answer: NO GUESSES REMAIN, and the provenance machinery is stronger than the schema's own definition strictly requires. Details, and the one place where the enum is being stretched. === THE HEADLINE: THERE ARE ONLY THREE NUMERIC LEAD TIMES IN THE ENTIRE DIRECTORY === Every other record has lead_time_weeks null. That is the correct shape for this corpus, which is overwhelmingly cloud rental and secondary-market asking, but it means the audit's real question is not 'is each number sourced' - it is 'is each NULL honestly labelled'. Both halves check out. 1. cdw-enterprise, lead_time_weeks 6, source 'published'. Basis: CDW's own printed window for the accelerator SKUs on that record. This is the only record in the directory where a channel states a lead time, and it is quoted from the channel itself. 2. cdw-rtx-pro-6000-workstation-cards, lead_time_weeks 6, source 'midpoint-inference'. Basis: the midpoint of the only range CDW publishes for that part ('4-6+ Weeks'), with the inference flagged as a midpoint rather than dressed up as a published figure. This is the correct use of the enum value and a good model for the directory. 3. rent-aws-ec2-gpu-hourly-2026-10-04, lead_time_weeks 8, source 'published'. Basis: AWS's own published number from the EC2 User Guide. It is the Capacity Blocks booking horizon, and the basis says so, so a reader cannot mistake an 8-week reservation lead time for an 8-week wait to buy a GPU on demand. === NULL NUMBERS ARE ALL LABELLED, AND THREE DISTINCT REASONS ARE DISTINGUISHED === The schema defines 'published', 'midpoint-inference', 'structural-na' and 'unknown', with structural-na defined as 'the number does not apply because the channel is structurally instant (on-demand cloud rental, peer-to-peer marketplace, spot capacity) - NOT the same as nobody publishes it'. The corpus uses 97 structural-na, 23 published, 2 midpoint-inference, 0 unknown. Every record in the directory carries a non-empty lead_time_basis (0 empty). Reading the bases, three genuinely different situations are being recorded, and it matters that a reader can tell them apart: (a) THE CHANNEL IS STRUCTURALLY INSTANT. On-demand cloud rental, spot capacity, peer-to-peer marketplaces and metered API terms have no order-to-delivery lead time because there is no order. 66 of the 97 structural-na records are cloud or secondary-market and mean exactly this. This is the definition working as intended. (b) NOBODY PUBLISHES IT, AND THE CHANNEL IS NOT INSTANT. This is the case the parent brief cared about, and it is handled correctly: 21 records carry source 'published' with a NULL lead time, and every one of their bases says so in as many words - 'NEGATIVE, DELIBERATELY NOT STRUCTURAL' plus either 'this is a quote-only channel - no price and no lead time is published on any page' or 'this channel routes to request a quote or shows a stock count instead, so the number exists elsewhere in the market and is not surfaced here'. The second phrasing is especially good: it distinguishes 'nobody knows' from 'this particular channel does not print it, and CDW does'. The affected records are nvidia-dgx-direct, nvidia-hgx-oem-systems, supermicro-gpu-systems, dell-poweredge-xe-ai, hpe-proliant-compute-xd, qct-gpgpu-servers, intel-gaudi-oem-systems, amd-instinct-oem-systems, amd-mi325x-mi350x-passive-oam-liquid-required, servers-direct, itcreations-accelerator-catalogue, and the retail listings amazon-rtx3090-renewed-channel, bestbuy-rdna4-consumer-discrete, bh-photo-workstation-gpus, microcenter-in-store-gpus, microcenter-refurb-rtx-3090, new-retail-rtx-5090-amazon, newegg-consumer-gpus, newegg-refreshed-arc-b580, overclockers-uk-4090-new-channel, overclockers-uk-arc-and-rtx5090-channel. (c) THE QUANTITY IS NOT A LEAD TIME AT ALL. ppl-sup-aws-egress-negative, ppl-sup-uptime-pue-negative, rent-pricing-not-public-negatives-2026-10 and us-electricity-industrial-tariff-2024 price electricity, egress and PUE, and their bases say the accelerator is only listed as the load that consumes them, so there is no order-to-delivery step. grid-interconnection-queue-power-not-chips states its subject's wait is measured in YEARS (the LBNL 'Queued Up' interconnection queue), not weeks. These are cases where a null is not an absence of information but the absence of a category. === THE ONE PLACE THE ENUM IS BEING STRETCHED, STATED PLAINLY === Ten records use 'structural-na' for a channel that is NOT structurally instant, so a reader who reads the enum strictly would expect something else there. These are not errors - each basis explains itself and the reasoning is sound - but they should be named rather than left for the next reader to trip over: - SEVEN OEM/integrator/datacentre records whose real wait is CONSTRUCTION, not GPU allocation: ai-datacentre-power-capacity-run-cost, dgx-h100-h200-10kw-air-cooled-node, gb200-nvl72-rack-120kw-liquid-required, gb300-nvl72-rack-1400w-per-gpu, h100-pcie-air-cooled-vs-sxm-liquid, liquid-cooling-retrofit-cdu-density-ceiling, used-8x-h100-sxm-node-system. All seven bases say the lead time is set by construction, electrical service and cooling/CDU plumbing, not by GPU allocation (verified 2026-10-05: each of the seven bases contains the word 'construction'). This is a genuine third category: the accelerator is not lead-time-constrained, but the SYSTEM is, and the weeks number that matters is a build schedule nobody in this corpus publishes. Note used-8x-h100-sxm-node-system also carries availability 'discontinued', which is a stronger and more useful signal than any lead time. - nvidia-marketplace-geforce prices a vendor LAUNCH MSRP, and its basis says the storefront is not the seller, so the record is not describing a transaction with a lead time at all. - colo-vantage-liquid-to-rack-not-to-chip and colo-vantage-power-density-tiers are quote-only colo engagements whose bases say the construction timeline is the real cost. These two carry availability 'lead-time' while having a null lead time, which is defensible precisely because the basis explains that the wait is a build. IF a future revision adds an enum member, 'construction-bound' is the value these seven want. Until then the existing bases carry the meaning, and the audit's conclusion is that they do carry it. === WHAT WOULD ACTUALLY IMPROVE, AND IS OUT OF SCOPE HERE === The one genuine weakness is not in the supply records but in the schema, which is out of this wave's write scope: lead_time_source cannot distinguish 'nobody publishes it' from 'published but I chose not to record it', and the corpus works around this by using source 'published' with a null value plus a prose basis. That is a reasonable convention and it is applied consistently across all 21 affected records, but it is load-bearing prose rather than structure. A sibling who owns schemas/ could consider whether the 'unknown' enum member is the right home for case (b) - 'not established' - rather than 'published' with a null. That is a one-line schema change and would make 21 records self-describing without editing any of them.