Across the non-NVIDIA, non-AMD scale-up fabrics audited together, every vendor who states a direction states an AGGREGATE one, the per-link rate is usually never published at all, and three different null bandwidths mean three different things

Auditing every non-NVIDIA, non-AMD scale-up fabric in this repo at once (2026-10-05) surfaces three traps that a record-by-record reading does not, because each fabric hides exactly one of them. TRAP 1 - THE CORPUS-WIDE CONVENTION IS AGGREGATE, AND EVERY VENDOR WHO SAYS SO SAYS THE SAME THING. Four independent vendors label a bidirectional aggregate in their own words: Huawei '2 x 8 x 1.68 TB/s (bidirectional)', Intel 'Networking (bidirectional) 1200 GB/s', Cambricon '聚合带宽200GB/s Bi-direction', Iluvatar '双向' on its 64 GB/s inter-chip row. Four more, from a prior pass, agree: Intel PCIe, AMD's Infinity Fabric 128 GB/s per-link label, Moore Threads' 'BIDIRECTIONAL 128GB/s' consumer wording, and Huawei again on RoCE. So the corpus is not split between per-direction and aggregate vendors - it is split between vendors who LABEL the convention and vendors who do not, and the unlabelled ones are the entire problem. HuaWei is the only vendor caught using both conventions on one page ('bidirectional' for UB Link, 'unidirectional' for UBoE and RoCE in adjacent rows), which is the strongest possible evidence that neither word is careless. TRAP 2 - bandwidth_gbps IS DESCRIBED BY THE SCHEMA AS 'PER LINK, UNIDIRECTIONAL' AND THAT IS WRONG FOR MOST OF THESE RECORDS. The interconnect schema's bandwidth_gbps description says 'per link, unidirectional'. Of the twelve fabrics above, the ones where that is actually accurate are NVIDIA NVLink, AMD XGMI, PCIe and the NIC-port standards. It is wrong, or at best meaningless, for: Gaudi 3 (the real unit is a 200 GbE PORT - 25 GB/s - and the useful numbers are sums over 21 or 24 of those ports, so reading the schema literally understates the fabric by 21x); Huawei UB Link, UB and HCCS (NO per-link figure is published anywhere; Huawei only ever publishes per-NPU and per-system sums, and interconnect/huawei-ub-link now says so explicitly); Iluvatar's inter-chip link (a single shared aggregate, no port count); Cambricon MLU-Link (published as a per-chip aggregate, and the per-port breakdown is 4 ports x 16 lanes x 50 Gbps); MetaX MetaXLink (an 8-card domain aggregate). A reader who trusts the schema's field description and assumes the stored number is a per-link rate will be wrong for most of the Chinese and Intel fabrics in this directory, and the direction of the error differs per record - understate Gaudi by 21x, overstate nothing, but compare Huawei's 392 against a real link rate that does not exist. TRAP 3 - THREE NULL bandwidth_gbps VALUES IN THIS DIRECTORY MEAN THREE DIFFERENT THINGS, AND THE SCHEMA HAS NO FIELD TO TELL THEM APART. This is the sharpest trap and the reason this gotcha exists. interconnect/roce.json and interconnect/ethernet-uec.json carry null bandwidth because the thing has no intrinsic link rate (a transport, and a standard whose rate is set elsewhere) - that is a DEFINITIONAL null. interconnect/biren-blink.json carries null because the vendor published two aggregates and no per-link form, so no per-link number could be derived without inventing a divisor - that is a SOURCING null. interconnect/iluvatar-bi-v150-and-bi-v250-fabric.json and interconnect/enflame-s60-fabric.json carry null because we read the vendor's own page and found nothing - a VERIFIED NEGATIVE. And interconnect/iluvatar-bi-v150-and-bi-v250-fabric.json's scale_out is null for a fourth reason: the vendor is SILENT on whether the path extends beyond the host, which is neither absent nor denied. Four meanings, one value, and the schema's additionalProperties:false means there is nowhere to put a verified_negatively flag on an interconnect record the way engines and accelerators have (schemas/interconnect.schema.json has no such field, and adding one is out of scope for an interconnect-only pass). Until that field exists, the ONLY thing separating these records is prose in bandwidth_basis - so the prose is load-bearing and must be read, and it must never be shortened to 'not published'.

Two independent causes that reinforce each other. FIRST, per-direction-vs-aggregate is a genuine ambiguity in the underlying specifications, not just sloppiness: an Ethernet or PCIe link physically carries traffic in both directions at once, so 'the bandwidth of this link' is 200 Gb/s or 400 Gb/s depending on whether you mean one direction or the sum, and no standards body settles it. NVIDIA resolved it for NVLink by publishing bidirectional aggregates in marketing while quoting per-direction rates in spec tables; AMD's Infinity Fabric inherited the aggregate habit. The Chinese vendors, working mostly from secondary reporting, default to the aggregate. Every one of them is internally consistent. The corpus-wide pattern is therefore not error, it is a convention that has to be re-established per vendor, which is precisely the thing a schema field cannot do for you. SECOND, and specific to Chinese accelerator vendors, the spec sheets publish SYSTEM-LEVEL aggregates because that is the number a buyer asks for. Huawei's pages lead with '1.72 PB/s' and '13.4 TB/s per server'; Iluvatar's interface row leads with a single shared '64 GB/s'; Cambricon's leads with '200GB/s 是PCIe 4.0带宽的3.1倍'. Nobody publishes the link count, lane width or signalling rate, because nobody is asked for it. The result is a body of published numbers in which the per-link quantity - the one the schema's field description asks for - is systematically the missing one. The third trap's cause is structural rather than vendor behaviour: this repo established early that 'looked and it is not there' and 'never looked' must not be the same value, and added verified_negatively to the engine and accelerator schemas to enforce it. The interconnect schema predates that decision and never got the field, so interconnect records carry the same distinction in prose only, where a future edit can silently erase it.

Read bandwidth_basis before comparing any two bandwidth_gbps values in data/interconnect/. It is the only field that records what the number actually is. Specifically: (1) Establish the vendor's direction convention once, from the vendor's own label, and apply it to every unlabelled figure from that vendor. Do not mix conventions within one vendor's numbers. (2) Never divide a published aggregate by a port count unless the vendor published that port count. Huawei's 784 GB/s per NPU, Intel's 1200 GB/s per card and Cambricon's 200 GB/s per chip are all sums; the divisors are not published. (3) For sizing a scale-up job, the number that matters is the per-direction per-device figure with scale-up and scale-out separated. For Gaudi 3 that is 525 GB/s per direction per card (21 of 24 ports), NOT the 1200 GB/s headline; for Huawei UB Link it is 840 GB/s per direction per NPU at 16 NPUs; for Ascend 910B's HCCS it is roughly 90 GB/s per NPU chip-to-chip. The headline figure overstates the usable fabric in every case. (4) When a fabric has no per-link figure, say so in the basis string in the same words every time - 'NOT PUBLISHED' - so a grep for it finds all of them. And when a null means 'we looked and there was nothing', name the URL that was read and the date, as interconnect/iluvatar-bi-v150-and-bi-v250-fabric.json does for the BI-V150 page. A null that names its URL is checkable; a null that does not is indistinguishable from not having looked. (5) When a vendor's domain is unreadable, do NOT file the absence as 'this vendor publishes no fabric figure'. File it as an access failure and keep it at draft status, as interconnect/enflame-s60-fabric.json does - the S60 almost certainly has a fabric; we simply cannot read Enflame's documentation centre.

Filed by the w7f non-NVIDIA/non-AMD interconnect pass, 2026-10-05. This gotcha is the aggregation of twelve interconnect records that individually each documented one of their own conventions and collectively show that the conventions are not independent. WHAT THE PASS FOUND, IN ONE LINE EACH: - Gaudi 3 [[intel-gaudi3-roce-scaleup]]: scale-up is 21 of 24 x 200 GbE ports on a passive baseboard; 25 GB/s per port per direction recorded, 525 GB/s per direction scale-up per card, and the 1200 GB/s headline reconciles exactly as 24 x 200 Gb/s x 2 directions. Gaudi 2's 600 GB/s is the same 24 ports, so the 2x generation gain is a port-count gain at constant per-port rate. - Huawei UB Link [[huawei-ub-link]]: direction now VENDOR-PROVEN, because Huawei's own prose '13.4 TB/s per server' is exactly half its own '2 x 8 x 1.68 TB/s (bidirectional)' (26.88 / 2 = 13.44). 1.72 PB/s / 1024 = 1.6797 TB/s, i.e. exactly the 16-NPU full-mesh per-NPU rate, so per-NPU bandwidth is FLAT from 16 to 1024 NPUs and the pod grows only by adding NPUs. No per-link figure exists at any level. - Iluvatar [[iluvatar-bi-v100-chip-to-chip]]: a real published scale-up figure, 64 GB/s bidirectional, sitting on the SAME card row as a second, different 64 GB/s for the host link - same number, two fabrics, which is the single easiest way to mis-file this card's interconnect. - Iluvatar BI-V150 [[iluvatar-bi-v150-and-bi-v250-fabric]]: verified negative. Vendor page returns HTTP 200 with NO specification section at all (zero occurrences of 规格, 接口, PCIe, GB/s, 互联, or even the part number). Iluvatar's disclosure went backwards between generations. - Enflame [[enflame-s60-fabric]]: verified negative ON ACCESS, not on disclosure. Both enflame-tech.com AND support.enflame-tech.com return identical Tencent Cloud WAF 403s with distinct per-request UUIDs. Filed at draft, not verified, deliberately. - MetaX MetaXLink [[metaxlink]]: the vendor publishes an 8-card 896 GB/s aggregate with no direction and no port count, and the two supernode pages (C500X optical DragonFly, C550 3D Mesh electrical) publish TOPOLOGY AND TOPOLOGY ONLY - 'up to 64 cards', 'photonic-electronic hybrid' - with no bandwidth figure at all. Topology without bandwidth is the MetaX signature. - Cambricon MLU-Link [[cambricon-mlu-link]]: independently re-verified against the vendor page, which does say '聚合带宽200GB/s Bi-direction' and gives the breakdown '4 ports, 16 Lanes, 50 Gbps' = 200 GB/s per direction. A prior agent's finding that the 200 GB/s on the MLU370 record is MLU-Link and NOT a host figure is CONFIRMED and is now vendor-verbatim rather than inferred. OPEN ITEM FOR A FUTURE PASS, DELIBERATELY NOT DONE HERE: adding verified_negatively to schemas/interconnect.schema.json would let these negatives be machine-readable instead of prose-only. AGENTS.md permits extending a schema and it is backward compatible, but this pass was scoped to data/interconnect, data/sources and data/gotchas only, so the schema was not touched. Until it is, the four-null-meanings distinction in TRAP 3 survives only in bandwidth_basis prose, which is the weakest possible guarantee and the reason this gotcha is filed at severity major rather than minor.