ET-SoC-1 diagram: detailed review

Rendered confirmation: the separate rendered review also confirmed the open drain joins in the shared 6T SRAM / sense-amplifier drawings.

draw6T, lines 4506–4525, instantiates the upper PMOS at y=222 and lower NMOS at y=302. mosV (4392–4405) ends source/drain leads at y±30, leaving a gap from y=252 to y=272 on both columns. The code never draws the drain-to-drain wires across that gap. Q and QB are placed at y=262, with access-transistor and feedback wires at y=256, 262 and 268: all land in the gap rather than on either transistor's drain. The resulting picture does not actually form the two inverters that hold the bit.

The same omitted join occurs in the embedded SRAM sense amplifier in buildCell (4564–4581), where the missing span is y=542–562 at x=240 and 420, and the embedded DRAM sense amplifier in buildDCell (5367–5384), where it is y=470–490. The separate lib.senseamp drawing already does this correctly at 7194, explicitly connecting each PMOS bottom to the corresponding NMOS top. Reuse that implementation pattern; add these vertical wires before placing junction dots and cross-coupled branches. This is more consequential than a cosmetic gap: it obscures the regenerative feedback that these scenes teach.

Primary circuit reference: MIT 6.152J lecture 18, slide 43, 6T SRAM. Verify the two vertical joins in the rendered lib.sram6t, shire.cell, DRAM-cell scenes, plus the small 6T inset beside the L1 latch.

Link to T15 · Source locators refer to the pinned review snapshot.

Locations: index.html:4182, which presents the card as drawing “at most” 88 W; lazy facts out.card.6 and out.host.5; D.onum.card_88 on index.html:1738.

Problem: out.card.6 combines a claimed 7.3 A / 88 W maximum with a highest-recorded draw of 87.8 W. out.host.5 uses that supposed maximum to compare the complete card with a host CPU. The public lab record now documents approximately 134 W during idle thermal runaway. Thus neither a universal upper bound nor an undated record is defensible.

Primary evidence: public card-behaviour record: lines 538–539 give 134 W at the end of the first runaway; lines 593–594 give 133.45 W and 133.65 W. The same record, line 162, explains the 88 W observation as random-data operation at 800 MHz before a governor step. These are different operating conditions.

Fix: label 87.8 W as a dated maximum in the particular workload campaign, not “at most”; name the regulator/card design limit separately only if an actual source supports it. Remove the absolute CPU comparison or explicitly compare the same workload campaign. An excellent compact headline would be “32 GiB · PCIe 4.0 ×8 · power depends on workload and temperature,” with the detailed observations in the panel.

Link to T01 · Source locators refer to the pinned review snapshot.

Locations: lazy fact tb.icg; the correct detail is index.html:7047, in the lib.icg view. Also inspect the L1 descriptions at lines 5482–5485 when consolidating terminology.

Problem: the fact says the integrated clock gate latches enable while the clock is high and ANDs it with the clock. This reads as a high-transparent latch, which would permit enable glitches while the output clock is high. The drawing's own panel correctly says the latch is transparent while low and holds enable while high. The fact is ambiguous because “latches” can mean captures or holds; the explicit phase description in the drawing is correct. Clarifying the wording avoids implying a high-transparent latch.

Primary evidence: ETH Zurich / University of Bologna generic ICG model, tc_clk_gating, updates clk_en when clk_i == 0 and then computes clk_i & clk_en (lines 43–48 in the web text).

Fix: “The enable latch is transparent while CLK is low and holds its value while CLK is high; the held enable is ANDed with CLK.” Reuse that one sentence in the fact, inspector, and educational summary.

Link to T02 · Source locators refer to the pinned review snapshot.

Locations: inline fact chip.harts (index.html:1738). The displayed instance calculation at index.html:7739–7742 is correct and already uses neighbourhood and local-minion coordinates explicitly.

Problem: the fact gives hartid = shire × 64 + minion × 2 + thread, then defines minion = hartid >> 1. The first formula needs the minion number within the shire; the second returns the chip-global minion ID. At hart 64, the fact's extraction gives shire 1 and minion 32, and reapplying the formula yields hart 128.

Primary evidence: ET platform hart.h, source lines 50, 62, 74 and 86. The API intentionally returns a global minion ID from get_minion_id().

Fix: spell all coordinate systems out: global_minion = hartid >> 1; shire = hartid >> 6; minion_in_shire = (hartid >> 1) & 31; neighbourhood = (hartid >> 4) & 3; minion_in_neighbourhood = (hartid >> 1) & 7; thread = hartid & 1; reconstruction hartid = 64*shire + 16*neighbourhood + 2*minion_in_neighbourhood + thread. A tiny worked example would prevent confusion in the shire → neighbourhood → minion zoom.

Link to T03 · Source locators refer to the pinned review snapshot.

Locations: lazy fact in.vpu.lane.fma.6, currently kind: measured; inline e-flip-model correctly says derived; FMA view index.html:6030–6035 and fact inspection.

Problem: the fact presents 2.5 million clocked register bits and 74 million multiplier-tree net toggles per random-data tile with a measured badge. The cited source explicitly obtains the event counts by simulating RTL on operands and fits energy coefficients to measured card power. Silicon net toggles were not individually observed. The current classification also obscures the already acknowledged Erbium-RTL-to-silicon assumption.

Primary evidence: energy manual, instruction chapter, section “Where the tensor unit's energy goes: per flip,” lines 53–67. Its independent validation is valuable, but it validates a predictive model, not direct access to every internal net.

Fix: use “derived / RTL simulation, fitted to measured power”; split the measured power and held-out prediction accuracy into separate measured facts. In the drawing say “In the simulated zero-operand case, the lane's pipeline clock is gated” rather than the unqualified “nothing toggles,” since the tensor state machines still consume energy and the card is still clocking elsewhere.

Link to T04 · Source locators refer to the pinned review snapshot.

Locations: inline L104 (index.html:1738), mesh component at index.html:7711–7713, inferred-layout component at index.html:7770, TensorSend flow at index.html:8501, route/reply helpers index.html:1839–1842.

Problem: L104 reports three-card routing experiments; two visible panels still say measured on two cards; the general inferred-layout panel still lists the route turning order as inferred. Moreover the full L104 statement has one measured badge even though its note carefully distinguishes directly observed load replies/store requests from the inferred small load requests/store acknowledgements. The TensorSend panel correctly notes that mapping TensorSend onto the request routing class was not tested; that caveat should not be lost in a broad “all routes measured” summary.

Fix: use a single evidence summary with packet types: “Load replies: y then x; tensor-store requests: x then y, measured on three cards. Small requests/acks and TensorSend packet-class assignment remain inferred.” Remove the stale general statement that the entire turning order is still unknown; retain the specific untested cases. The current route/reply helper distinction itself is consistent with the stated model.

Link to T05 · Source locators refer to the pinned review snapshot.

Locations: inline dram.leg, L46, lat-dram-chip (index.html:1738); deeper corrected explanations at index.html:5593–5594 and (source lines 5620); lazy DRAM latency facts.

Problem: dram.leg labels about 66 of the 91 extra cycles as the memory shire. Deeper views correctly explain that the residual includes the L3 home's miss handling and To_Sys crossings, as well as the memory shire and PHY. These are materially different attributions. Also the high-level “25–28” range permits either one or two bursts while the detailed x16/BL16 line transfer specifies two 32-byte bursts for a 64-byte line.

Fix: make the summary agree with the deeper view: approximately 28 minion cycles of programmed DRAM timing, plus approximately 63 cycles of unseparated L3-home miss handling, crossings, controller and PHY, plus the fitted mesh term. Keep the numerical decomposition explicitly inferred/derived. This does not challenge the measured 91-cycle fitted intercept; it corrects which physical components can be credited with it.

Link to T06 · Source locators refer to the pinned review snapshot.

Location: inline fact mm-perw, index.html:1738.

Problem: the statement labels the fp32 / fp16 / int8 triplets all as board GFLOP/s per W. INT8 arithmetic is not floating point. Elsewhere mm-rate, mm-peak and the tensor inspector correctly use TOP/s for int8, so the fact table contradicts the units in the diagram.

Fix: use GFLOP/s/W for the fp32 and fp16 columns and GOP/s/W for int8, or use an explicitly defined generic “Gop/s/W” table with datatype headers. State that one multiply-accumulate counts as two operations. Preserve pJ/MAC versus pJ/FLOP distinctions in energy panels.

Link to T07 · Source locators refer to the pinned review snapshot.

Locations: inline mm.dram; flow G table index.html:8834 and DRAM callout index.html:8916.

Problem: the page places 15,042–15,663 cycles/op beside 0.309–0.312 TFLOP/s as though these were reciprocal measures of the same execution interval. At 1,024 minions, 600 MHz and 8,192 FLOP per 16³ tile, those mean-cycle bounds imply 0.321–0.335 TFLOP/s. The numbers themselves are supported; they use different aggregation rules.

Primary evidence: public MMB results JSON, items[item=MMB-a].per_card.<card>["fp32-tensor-DRAM"]: cycles_per_op_mean_based is 15,042–15,663; cycles_per_op_max_based spans approximately 16,132–16,278; info_tflops_range is 0.309–0.312. The latter cycle range is consistent with the throughput.

Fix: show both “mean minion: 15.0–15.7k cycles/tile” and “whole kernel / slowest minion: 16.1–16.3k cycles/tile, 0.309–0.312 TFLOP/s,” or use only the max-based cycles next to chip throughput. This makes the small load-imbalance effect visible rather than appearing to be arithmetic drift.

Link to T08 · Source locators refer to the pinned review snapshot.

Locations: inline dram.capacity; DRAM overview at index.html:5576; lazy out.card.5; deep DRAM part inspector index.html:5616–5618.

Problem: the main DRAM description says the V3 cards have Micron LPDDR4X. The card-photo fact says the documents show SK hynix and Micron variants and the maker on the lab cards is not recorded; the deeper part panel says the Micron part number/density is unconfirmed. The cited V3 document's first page names a Micron bring-up plan, which does not establish that every measured lab card uses it.

Primary evidence: public V3 card document, PDF page 1.

Fix: choose a consistent scope: “32 GiB LPDDR4X on the measured cards; vendor document includes a Micron variant; exact part per lab card not confirmed” until a public part photo or mode-register read establishes the per-card identity. Do not invent a specific DRAM process node when zooming to the generic memory cell.

Link to T09 · Source locators refer to the pinned review snapshot.

Locations: minion.l1d, minion.tensorload, pcie.staged, pcie.h2d, pcie.d2h, dram.capacity and many labels; flow G at index.html:8826 uses 16×64 B = “1 KB”; the PCIe source explicitly uses 268,435,456 B = “256 MB.”

Issue: the page alternates KiB and KB, while numerical capacity calculations are binary and GB/s throughput is decimal. This is familiar engineering shorthand but unnecessarily ambiguous in an educational page that spans physics and software.

Fix: use KiB/MiB/GiB for capacities and working sets, GB/s and TB/s for decimal throughput. A one-line convention in the fact legend is acceptable if changing every vendor quotation is undesirable. NIST binary-prefix guidance distinguishes the units explicitly.

Link to T10 · Source locators refer to the pinned review snapshot.

A chip-level viewer can encounter physical die geometry, the shire's logical block diagram, an Erbium-derived FMA, generic SRAM circuitry and measured timings within a few clicks. The existing scoped caveats are good, but the most valuable badge is often in the details panel. Keep an always-visible short scope line such as “Logical block diagram · Erbium RTL · silicon layout unknown” or “Measured on three cards · 600 MHz · board power.” This is especially useful for the FMA view: the existence of 17 partial products comes from shared arithmetic hardware RTL, while the picture's compression stages and physical areas are educational approximations.

Link to T11 · Source locators refer to the pinned review snapshot.

Current facts often name a precise local repository file and line but link only to a general report. Add the actual public source permalink and immutable commit, and for measurements expose the JSON path plus campaign/card/clock/temperature scope. Example: the hart-ID claim should link directly to the exact hart.h, and the FMA model should link directly to the model and validation source. A single fact record should supply every repeated prose summary, so the two-card/three-card and inferred/measured drift cannot recur.

Link to T12 · Source locators refer to the pinned review snapshot.

Locations: D.scales["lib.finfet"].blurb (index.html:1738); power-FET frame index.html:7420; lazy tb.powerfet. The 3D companion correctly distinguishes the two in runtime-segment.js:236.

Problem: the main n-channel description says current flows from source to drain after describing an electron inversion layer. With positive drain bias, electrons drift source → drain, while conventional current flows drain → source. The vertical n-channel power-MOSFET text similarly calls the downward source → drain path “current”; that direction is the electron flow. Neither use is qualified as electron current.

Primary evidence: MIT 6.004 MOSFET teaching notes define the higher-potential diffusion as drain in this example and describe conventional current drain → source. The linked 3D companion already expresses this correctly and can supply consistent copy.

Fix: “With the drain positive relative to the source, electrons drift from source to drain; conventional current flows the opposite way.” For the vertical power device, label any downward arrow “electrons” and the upward arrow “conventional current,” or omit a direction until the selected bias is stated.

Link to T13 · Source locators refer to the pinned review snapshot.

Locations: global GATE() state narration index.html:6270; mixed p-/n-row scene (source lines 6275–6310), especially (source lines 6304); fin scene (source lines 6351); channel estimate at (source lines 6380–6381). Facts el.rails, el.switch, el.off-channel.

Problem: “gate at 0 V means off” depends on transistor type and source potential; the overview contains both p-type and n-type rows. The code actually highlights only the selected lower n-channel device (rows 5.5/6.5 at lines 6289–6293), so this is a missing label/condition, not evidence that the p-channel drawing's state is implemented backward. “No electrons under it” and “nothing flows” are also too absolute: the immediately adjacent caveat and deeper off-state view explicitly describe nonzero subthreshold leakage and an average carrier estimate.

Fix: label the switch “Selected nMOS · source at 0 V, drain positive.” Describe its drive as VGS, and say “below threshold: very little mobile inversion charge; a small leakage current remains.” A pMOS comparison can state that with its source at VDD, gate0V gives a negative VGS and can turn it on. Do not generalize the 0.002-electron estimate to every physical transistor: it is a chip-average leakage allocation plus an assumed transit time, not a measured microscopic occupancy.

Link to T14 · Source locators refer to the pinned review snapshot.

Rendered confirmation: the separate rendered review confirmed the displayed cin connection described below. The counterexample is a mathematical check of the pictured logic, not a hardware test.

lib.adder, lines 6911–6937. The tree forms group G and P from a and b only. The cin wire at 6933 enters s0; every higher sum receives the preceding group's G, and cout comes straight from G7. Carry must be C[i+1] = G[i:0] OR (P[i:0] AND cin). In the drawn tree cin therefore affects only the low sum bit.

Concrete counterexample: a=0xFF, b=0x00, cin=1 should produce sum 0x00, cout 1. Interpreting the stated group equations and the drawn connections produces sum 0xFE, cout 0. Independent exhaustive checking over all 131,072 8-bit input triples finds 32,768 mismatches; all have cin 1. Adding the missing P·cin term makes all 131,072 pass. This models the teaching drawing; the site itself is not executing an adder simulation.

Fix either propagate cin through a boundary generate term (g0 = a0·b0 + p0·cin) or explicitly form every output carry from G/P/cin. Draw the original per-bit p connections to the final sum boxes as well. If the intended example always has cin 0, label that restriction and remove the misleading free cin input. Primary derivation: MIT 6.004 carry-lookahead lesson transcript. Candidate route: die/memshire:0/lib.adder (atomic unit), also core ALU and FMA final-adder branches.

Link to T16 · Source locators refer to the pinned review snapshot.

These independent endpoint calculations use wire (source lines 4381) (straight line segments) and actual invSym, xorSym and flopSym returned pin locations, rather than inferring connectivity from prose. Group these as one systematic drawing issue, with the most visible examples as evidence:

• Full adder, 6128–6131: a runs diagonally from (-80,80) to (181,95); its carry-AND tap is placed at (0,80), while that input wire is at y≈84.598 when x=0. The b wire runs (-80,140)→(181,125), but the carry tap is (40,140), while the wire there is y≈133.103. Both carry-network branches have junction dots beside the input wires. Route inputs horizontally through the tap points before jogging to the XOR pins. The full-adder Boolean formula and eight-row truth table are correct.
• Flip-flop, 6214–6215: CK branch ends at (250,400). The inverter centered (250,380) is horizontal, with input (234,380) and output (271.2,380); neither reaches the branch nor master latch bottom y=360. Rotate the inverter and wire its actual input/output, or use an explicitly labeled inverted-enable pin. Route: die/memshire:0/lib.flipflop via settings/DFI.
• PLL, 7142–7144: five horizontal inverters are drawn 60 units apart but no wire connects one inverter's output to the next input. First output is (701.2,240), next input (724,240); each link has a 22.8-unit gap. Feedback starts at x=960 whereas last output is 941.2, and returns to 668 whereas first input is 664. Connect every returned pin to make the claimed oscillator ring.
• ROM, 7172 and 7182–7183: bitlines stop at y=560; output inverters sit at y=600 with horizontal inputs x=bx−2. No wire connects these. The previous ROM polarity correction is present and correct; this is a separate missing connection.
• Comparator, 7103–7107: an XNOR's actual output is (X(i)+38,150), but reduction-tree wires start (X(i)+22,180). Connect the output pins before the NAND/NOR reduction. The reduction's intended logic polarity is correct.
• Counter, 7087–7089: each Q pin returned by flopSym is (X(i)+60,343⅓), but feedback begins (X(i)+70,410), outside the register's bottom-right corner. Use Q for the feedback branch and D for the increment result, or explicitly present the registers as portless blocks. Increment equations themselves are correct.
• LPDDR DQ circuit, 5427–5434: the pad/package trace stops at x=700, y=180, while ODT/receiver starts at x=720, y=180, leaving an unmarked 20-unit break in the signal that is meant to be received. Extend the trace to the receiver junction.

Implementation improvement: make all symbol helpers return named pins, route from those values (never guessed coordinates), then run a lightweight endpoint audit in the SVG construction. Allow intentional net labels/open terminals explicitly. Do not run a naive check requiring all illustrative boxes to be complete netlists; focus on circuits claimed to explain current paths or Boolean dependencies.

Link to T17 · Source locators refer to the pinned review snapshot.

The SECDED matrix at 7153–7157 is a valid extended Hamming(13,8) parity-check matrix. Do not change its dots. But the encoder tooltip 7158–7159 says every row is a check bit equal to XOR of the marked data bits. This is false for the fifth, overall-parity row, which also marks c0, c1, c2, c3. Its encoding equation is c4 = XOR(d0…d7,c0…c3).

Example: only d3=1 (Hamming position 7) gives c0=c1=c2=1, c3=0, so c4 must be 0. Taking data-only parity gives 1, making a nominally clean codeword fail the overall check. Exhaustive enumeration: the data-only reading gives wrong c4 for 128 of 256 data words. Correct encoding with the supplied matrix passes all 256 codewords, 3,328 single-bit-error cases and 19,968 double-bit-error cases. Replace the tooltip with “The first four check bits are parity over the marked data positions; the fifth is overall parity over data plus those four checks. On a read, XOR every marked bit in each matrix row to form the syndrome.” Also qualify “all zeros means no error” as “no error detected”; SECDED promises correction of one error/detection of two, not detection of every larger corruption.

Link to T18 · Source locators refer to the pinned review snapshot.

lib.booth, 6976–6977: its selector tooltip says a 2:1 mux chooses X or 2X “or neither (for 0).” A 2:1 mux alone cannot choose neither. The drawing shows the X/2X selector and sign XOR but no zero control. Keep the correct radix-4 recoding table, but draw a zero-enable mask (or label a third zero choice) and the +1 correction input for negative digits. For X=3, y=0, all Booth digits are zero; a bare X/2X mux still emits nonzero data. This is an omitted schematic control, not a fault in the recoding table. All 256 signed 8-bit values reconstruct correctly from the shown table in the independent check.

Link to T19 · Source locators refer to the pinned review snapshot.

• FIFO 7114–7127: head/tail equality alone cannot distinguish full from empty after wrap. Label an extra wrap bit, occupancy counter, or reserved-slot convention next to “full? empty?”. Current blocks are generic and could include that state implicitly; report as needed explanatory detail, not a confirmed false claim.
• PCIe lane 7219: replace “each way on a pair of wires” with “one differential pair per direction (two pairs per lane)”. The TX±/RX± drawing is already correct; the existing phrase is grammatically ambiguous rather than definitively false. Intel-hosted PCIe base specification, physical-layer architecture, makes lane structure explicit.
• Explain that an asynchronous multi-bit FIFO uses coordinated pointer synchronization (often Gray pointers), whereas the two-flop drawing in buildXing (source lines 4707–4724) is a generic single-bit synchronizer. The existing “generic circuit” badge is helpful; retaining it and naming the signal being synchronized prevents readers treating it as a complete bus-crossing circuit.

Link to T20 · Source locators refer to the pinned review snapshot.

Confirmed in code and by the rendered audit. phSwitch() (main 10149–10165) calls endTour() and stopFlow() whenever the portrait/mobile layout query changes. The query is (max-width: 899px) and (max-aspect-ratio: 1/1) (1788). It then rebuilds the geometry and calls resetCap(), so this is a state reset, not just a new layout.

Reproduction: at 390×844, open Load → DRAM, pause at stage 3 / 6 (L3 home), then rotate/resize to landscape. The rendered audit observed Explore with no flow stages, an enabled Replay button, and the live-region text still reading “Stage 3 of 6: L3 home.” stopFlow() (8281–8286) never clears #st-live; only showStage() (8252) and a speed change update it.

Fix: snapshot and restore flow key, stage, playing/paused status, tour index, follow state and selected route while rebuilding responsive geometry. Clear or replace the stage live region when a flow truly stops. Test portrait → landscape → portrait during a flow, while paused, during a still tour slide, and inside a deep circuit.

Link to I01 · Source locators refer to the pinned review snapshot.

Confirmed with a geometry test. In C0() (runtime-segment.js 178–193), i.section is used only within if(i.dielectric). Default state is dielectric off; the Open cutaway button is enabled and its label/pressed state changes anyway (Ro, 258–259; event 269).

Reproduction: fresh #metal → click Open cutaway before Show dielectric. The state says the cutaway is open, but the model is unchanged. Comparing the actual Three.js model outputs with section false/true and dielectric false produced 161 children in both cases and identical part, position, geometry, color and opacity signatures. With dielectric enabled, the cutaway has an effect. The other three modes’ cutaways changed their geometry as expected.

Fix: opening this cutaway should reveal the dielectric automatically, or disable the dependent control with “Show dielectric to cut it away.” A combined “Inspect dielectric section” action is clearer than an enabled no-op.

Link to I02 · Source locators refer to the pinned review snapshot.

Source-confirmed interception risk; browser behavior varies. Ge() (runtime-segment.js 101–116) handles +, =, -, R, Home and arrows, then prevents default, without checking ctrlKey, metaKey or altKey. The main page already has the correct modifier guard at 9865.

Reproduction to verify in each browser: focus the 3D canvas and press Cmd/Ctrl+plus, Cmd/Ctrl+minus or Cmd/Ctrl+R. When the browser dispatches those key events to the canvas, the handler triggers model zoom or camera reset and calls preventDefault; reserved shortcuts may be handled differently by the browser or operating system. Browser/OS combinations vary, so verify on Mac and Windows before closing the issue.

Fix: return early for modifier combinations reserved to the browser. Keep unmodified +/- and R as canvas shortcuts. Include the visible keyboard-help text in the canvas’s accessible description: currently its aria-describedby (3D HTML 37) includes only mouse/touch help and the scene explanation.

Link to I03 · Source locators refer to the pinned review snapshot.

Confirmed data/code inconsistency. Main factSplit() (9525–9543) uses all facts as its denominator but draws only measured/spec/derived/inferred. The inline data has 304 facts, all in those four categories. The lazy file adds 813 facts. After loading it, total = 1,117, while the four displayed categories sum to 839 (75.1%); 278 facts in outside (155), generic (97), unknown (18), owner (3), and hypothesis (5) have neither bar segment nor legend entry.

There is also a path dependency: lazyIdle() (3502–3507) keeps deferring while a tour or flow is active; Summary’s counts use Object.keys(F) at the time it opens. A direct tour can therefore report 304 facts, while the same Summary after deep exploration reports 1,117. Main prose intentionally distinguishes the chip dataset from the extension, but the tour’s generic “Every number on this diagram” total does not.

Reproduction: compare a fresh direct #tour=17 against Summary after opening a deep level and letting its facts load. On the latter, compare legend counts to the headline and full bar length.

Fix: use a stable defined dataset for the Summary (explicitly “304 chip-flow facts” if intentional), or wait for the full dataset and draw all nine kinds, optionally with a clearly labeled “Other sources” aggregate. Show counts and percentages that add up to the total.

Link to I04 · Source locators refer to the pinned review snapshot.

Confirmed static mismatch. Main 6463 defines [6, 10, 12, 'M0-M4: the finest wires']; the loop at 6466 renders six rows. M0 through M4 is five levels. The following groups add three and three more rows.

Fix: either draw five rows for M0–M4 or label the group “Fine wiring · illustrative.” The page correctly says ET-SoC-1’s actual layer count is unpublished, so an exact M0–M4 designation is unnecessary. Make the illustrative tier grouping as explicit as it already is in the 3D companion.

Link to I05 · Source locators refer to the pinned review snapshot.

Rendered UI observation. At 390px viewport, the minion diagram is roughly 340px wide, with labels below approximately 8px and about 160px unused space below the drawing; four rows of flow controls occupy the area above. This makes the available diagram harder to read even before descending to circuits.

Code explains the risk: the minion frame is 1,140×760 units (1786); narrow layout keeps that entire frame (1794–1796), while copied circuit typography begins at 17–30 drawing units (4330). phFit() can further shrink/compress text (1805–1814). These are not screen-pixel minimums.

Fix: a compact flow selector, a branch/level navigator, a large focused diagram crop, and a readable selected-part sheet. Preserve overview via a small context map and move fine labels into a persistent panel. A separate mobile exploration proposal demonstrates this treatment.

Link to I06 · Source locators refer to the pinned review snapshot.

Confirmed from markup/event model; alternative fact lists do exist. n() (1754–1757), src() (7632), and SVG text factories emit plain spans/text with data-f, without focusability or a source action. The source popup appears via pointerover or focusin (7959–7969). A keyboard user can reach the li.fact source lists (7626), but cannot focus the specific inline figure that prompted the question. The main SVG’s instruction says every part is a button; individual sourced numbers are not.

Reproduction: Tab through the headline KPIs or a flow caption; the dotted source numbers are skipped. To identify a source, the reader must open details and locate a separate fact list. In the narrative, lk() (10089) sends all fact identifiers to the top of #facts, rather than directly to the relevant row or a prefiltered table.

Fix: make the sourced number an explicit button/link opening a persistent evidence drawer, and offer a stable per-fact deep link. Keep the useful hover preview. Do not make every decorative text node tabbable; group sources around the selected value or part.

Link to I07 · Source locators refer to the pinned review snapshot.

Design limitation, already documented. This is an optional sharing improvement, not a broken promise.

Confirmed serialized-state behavior. In lnkAnchor() (9938–9942), a tour’s still slide serializes as tour=N, but while its flow is active it serializes solely as flow=…, optionally stage=…. The receiving route (lnkGo, 9978–9987) starts a standalone flow. This is partly documented at 1044–1047, so it is a limitation rather than an undisclosed promise violation.

Reproduction: during tour step 7 (Load → DRAM), pause, copy link, open it. The same flow/stage is represented, but Next at the last stage no longer continues the tour and the tour’s progress is gone.

Improvement: serialize both tour and flow/stage state, or label the copied link explicitly “Link to standalone flow.” This matters when sharing a teaching sequence.

Link to I08 · Source locators refer to the pinned review snapshot.

The main page has rich evidence labels but inconsistent vocabulary between KWORD (derived → “model”, spec → “documented”, outside → “outside source”; 3100-ish), circuit badges (“documented”, “textbook”), and the Summary (“specified”, “derived”). The 3D page uses a different design system and states the generic scope clearly in its footer, while the “ILLUSTRATIVE GEOMETRY” badge disappears below 1100px (3D CSS 12).

Use one persistent small sentence/badge: what is physically measured here, what is documented, and what is a teaching construction. A generic geometry badge should remain visible on mobile. Keep the richer provenance behind it. Do not collapse “outside source” and “ET-specific documented” into the same status.

Link to I09 · Source locators refer to the pinned review snapshot.

resetButton calls only It.reset() (runtime-segment.js 273). Camera reset Ce() (76) restores zoom/yaw/pitch and stops orbit; sliders, selected material, cutaway, dielectric visibility, and flow playback remain unchanged. Rename it “Reset view.” If a “Reset model” action is desired, keep it separate and actually restore the scene state.

Link to I10 · Source locators refer to the pinned review snapshot.

hl() (261–269) retains slider values, dielectric visibility and paused status across scene navigation, but resets selected component, cutaway status, orbit and camera. Re-entering Channel always opens its cutaway; re-entering FinFET always closes it. This hybrid policy is surprising when comparing modes.

Choose either per-scene remembered state or clearly defined defaults on every scene change; expose a reset if values are remembered. Update the screen-reader state sentence to describe exploded/lifted geometry: Ro() currently says “Assembled view” whenever cutaway is off, even with Layer separation 100% or Gate lift 100%.

Link to I11 · Source locators refer to the pinned review snapshot.

Interaction-design recommendation. Pausing time does not necessarily imply freezing positions while geometry changes. The following is a proposal for making that distinction explicit, not a claim that animation continues while paused.

ss() builds a new model for every slider event; model animation time _e is retained. In Metal, path length changes with spread. Carrier phase is calculated as (time * 1.3 + index * pathLength / count) % pathLength (C0, 188–193), so changing layer separation moves carriers even when the flow is paused. Camera stability is good; paused state should be equally predictable. Preserve normalized phase per particle when rebuilding, or define the pause action as “Pause time” and show that geometry changes still reposition the path.

Link to I12 · Source locators refer to the pinned review snapshot.

The canvas consumes every wheel event (me, 98–100, listener 121) and has touch-action:none across its full area (original 3D CSS 11 and runtime setup). This is declared in the drag/scroll help, so it is intentional, but on a phone the 390px canvas can occupy much of the viewport and vertical swipes started there cannot scroll the page. Prefer deliberate gesture entry, an explicit “Interact with model” mode, or a persistent obvious page-scroll edge. On desktop consider zoom on wheel only when the canvas is focused or a modifier is held.

Link to I13 · Source locators refer to the pinned review snapshot.

Main .dots button is 8×8px (656) with closely spaced targets. Existing flow buttons and stage chips provide alternatives, so this is not asserted as an independent WCAG failure. Increase the invisible hit region/spacing or turn this into a labeled “Step 7 of 17” navigator. Avoid 17 unlabeled dots dominating the Tab sequence.

Link to I14 · Source locators refer to the pinned review snapshot.

Main lazy data loading treats a failed fetch as terminal (lazyData, 3488: done or failed returns); there is no Retry action. A temporary network failure leaves deep sources unavailable for the entire page session, even after network recovery. Provide Retry and a clear persistent source status. On stop, reset the stage live region as described in I01. In 3D reduced motion handling is good, but the note “Motion starts paused for reduced motion” stays shown after the user intentionally starts flow; phrase it as a preference explanation rather than current state.

Link to I15 · Source locators refer to the pinned review snapshot.

Main requestAnimationFrame clock runs continuously even with no jobs (2240-ish). The 3D viewer stops for document.hidden, but Metal/Channel continue updating while visible in the tab and scrolled completely out of view (Ae, 13; rt, 15–17). Pause rendering when the stage is offscreen and has no required animation work. This is a performance/battery recommendation, not a measured latency claim.

Link to I16 · Source locators refer to the pinned review snapshot.

Rung: p.electron. Evidence: line 6637 says Its charge is ${on('el_q')}, exactly; D.onum.el_q.t is positive 1.602176634 × 10⁻¹⁹ C. The linked fact p.electron.1 correctly begins with negative charge.

The positive value is the elementary charge magnitude, not the electron's signed charge. Use either “Its charge is −1.602176634 × 10⁻¹⁹ C” or “The magnitude of its charge is …”. This is an internal display/data mismatch, not a judgment about simplification. NIST constants distinguish the positive elementary charge and negative electron charge-to-mass ratio.

Link to L01 · Source locators refer to the pinned review snapshot.

Rung: p.planck. Evidence: lines 6653–6655 place the quark marker at log10(8.6e-19) while its label reads 4.3 × 10⁻¹⁹ m; the electron marker is at log10(4e-20) while its label reads 2 × 10⁻²⁰ m. The named scale metadata uses twice the bound as a diameter, while bound.words and ONUM explicitly describe radii.

Both markers are displaced by log10(2) = 0.301 decades from their printed numerical labels. The proton marker is at twice its rms charge radius too, and the nucleus uses yet another equivalent-sphere convention. Choose an explicit common axis convention (“characteristic length”, or “diameters; particle bounds shown as 2r”) and give each tick the value actually plotted. A scalar log ruler must not silently switch radius and diameter. ZEUS's paper calls 4.3 × 10⁻¹⁹ m an effective radius limit; Gabrielse's review likewise calls 2 × 10⁻²⁰ m a radius bound.

Link to L02 · Source locators refer to the pinned review snapshot.

Rungs: p.quark, p.planck. Evidence: line 6632, line 6656, and facts p.planck.3, p.planck blurb. The Planck stage draws an “unexplored” interval beginning below the electron marker, but labels it with the quark interval's “16 powers of ten”.

The page's electron limit is already 21.5 times smaller than its quark radius limit. The radius-to-Planck gaps are 16.425 decades for the quark and 15.093 for the electron; even using the plotted electron diameter yields 15.394. More fundamentally a model-dependent radius bound is not a hard boundary beyond which no experiment has probed any physics. Replace with “About 15 orders of magnitude separate this electron-structure bound from the Planck length; the interpretation of these bounds depends on the model.” Preserve the useful distinction between an unmeasured particle size and a measured upper bound. Sources: ZEUS, Gabrielse group.

Link to L03 · Source locators refer to the pinned review snapshot.

Rung: p.atom. Evidence: line 6533 draws inner shells at 0.16 R and 0.45 R; outer shell is at R. Line 6555 says the clouds are “densest at these radii”. Fact p.core.1 gives 3.9 pm, 21 pm and roughly 118 pm, whose relative radii are 0.033 R, 0.178 R and R.

The graphical inner radii are about 4.8× and 2.5× the page's own estimates. A Bohr-like schematic is reasonable and the “clouds, not orbits” caveat is welcome, but “densest at these radii” turns a schematic into a quantitative claim. Either draw the stated proportions or change the label to “schematic shell positions, deliberately separated for legibility”. Also distinguish spatial probability density from radial probability distribution if retaining “densest”.

Link to L04 · Source locators refer to the pinned review snapshot.

Rung: p.nucleus. Evidence: line 6586; scale blurb “Nothing in a chip ever touches it”; fact p.nucleus.8 says electronics “never change a nucleus”.

Normal transistor switching does not cause nuclear reactions. But radiation-induced nuclear reactions in semiconductor material are a known route to single-event effects. This distinction is relevant to a chip explainer. Replace with “Ordinary transistor switching changes electronic states, not nuclei” and, optionally, one short note on energetic radiation. NASA/JPL explicitly describes energetic nuclear recoil fragments in semiconductor single-event effects in JPL Publication 00-6; NASA's SEE criticality analysis describes proton-induced nuclear reaction products. This is a wording correction, not a claim of a measured ET-SoC-1 fault.

Link to L05 · Source locators refer to the pinned review snapshot.

Rung: localgroup. Evidence: line 3734 combines “more than 130 known galaxies” with “nearly 10 million light-years”. Fact out.localgroup.1 cites an older NASA description: more than 30 galaxies and nearly 10 million ly. Fact .5 cites 134 within 1 Mpc of the centre, then says “counted that way” the group is 5.1 Mpc (17 million ly) across. The size metadata remains 10 million ly.

A census within radius 1 Mpc cannot itself establish a diameter of 5.1 Mpc. These can be different boundary conventions, but they must be identified as such instead of combined as one quantitative definition. Keep a single dated membership/extent convention, or describe the group as a few Mpc across with membership depending on the boundary. No external value is needed to demonstrate the internal mismatch. Verify the modern count against a primary Local Group catalogue before replacing it.

Link to L06 · Source locators refer to the pinned review snapshot.

Rung: sf. Evidence: D.scales.sf.note explicitly derives 11.0 km from √(121.51 km²), and also states that the depicted outline spans 16.4 × 17.2 km. The blurb and fact out.sf.3 call 11 km a crossing of the city; line 3918 uses the associated 54 µs fibre figure.

The square root of area is a valid characteristic length but not the width of an irregular outline. A “map, to scale” scene should name which quantity its headline is using. Either use an explicitly marked 11 km reference path (“For an ideal 11 km fibre path …”), or use a displayed east-west/north-south extent and recalculate. This is a geometry/label mismatch, not an arithmetic error in 54 µs.

Link to L07 · Source locators refer to the pinned review snapshot.

Wording clarification. The intended confinement claim is sound; the issue is whether the parenthetical examples read as the complete set of allowed hadrons.

Rung: p.quark. Evidence: fact p.quark.7 says “only colourless combinations (three quarks, or a quark and an antiquark) exist on their own”. The point that free quarks are not observed is sound; the parenthesis reads as exhaustive.

Replace with “only colour-neutral combinations are observed, including ordinary mesons/baryons and exotic multiquark hadrons.” CERN's experiment reports observed pentaquark and tetraquark states. “A proton has three valence quarks” is also a more accurate stage title than simply “three quarks”.

Link to L08 · Source locators refer to the pinned review snapshot.

Rung: package. Evidence: PKK = 7.6 at line 4210; top view width is 45 * PKK; line 4243 defines the bottom view bw = 45 * PKK * 0.9. The scene says “drawing to scale” and has one 10 * PKK scale bar at line 4252.

The bottom-view package is 10% smaller than the top view despite representing the same 45 mm object. Make both views the same scale or provide a separate “bottom view ×0.9” caption/bar. This is a direct code-derived size discrepancy, independent of font/layout rendering.

Link to L09 · Source locators refer to the pinned review snapshot.

Rung: package. Evidence: line 4231 layer thicknesses 1.2 + 0.8 + 0.15 + 1.6 + 0.5 = 4.25 mm. Line 4242 captions the drawing as heights ×5, “3.95 mm in all; layer heights generic”.

The generic-layer caveat is good, but a precise overall height and explicit ×5 still invite measurement. Normalize the generic layers to the 3.95 mm maximum, or call the section schematic and remove the exact vertical magnification. State maximum overall height consistently; the data fact says “at most 3.95 mm”.

Link to L10 · Source locators refer to the pinned review snapshot.

Rungs: lib.fin, p.wrap. Evidence: D.ring.ticks maps lib.fin to 6 nm with fact n7.fin-width; D.scales.lib.fin.m is 52 nm, the height. Line 6768 labels the tick with the node's short title, without indicating width.

Neither number is wrong, but the same named object appears 8.67× different depending on the navigation surface. Label the ring “fin width, 6 nm”, while the stage says “fin height, 52 nm; width, 6 nm”, or adopt a consistently named characteristic dimension throughout. This general rule also helps atomic spacing, rms radii, orbital diameters, and region extents.

Link to L11 · Source locators refer to the pinned review snapshot.

Rung: studio45. Evidence: the main lab room is correctly dashed and marked “which room: inferred” at 4037–4048, but warehouse text (4063–4065) calls its stair the lab's end, the shop's description (4072) says “The lab is above it”, and the section label (4101) is simply “the lab”. The rack is drawn at a precise wall position (4049 onward), with no local location qualifier.

Carry the uncertainty into every affected tooltip/label: “possible lab room”, “rack shown for scale; position assumed”. The uncertainty is already documented; this is a consistency fix, not a request to infer the missing room or publish its location.

Link to L12 · Source locators refer to the pinned review snapshot.

Rung: studio45. Evidence: S45L=36.66, S45W=8.84 at 4010 derive from the exterior footprint; the drawing labels the ground-floor interior 36.1 × 8.5 m and the lab room 9.7 × 8.1 m. The drawn upper shop-end rectangle spans 36.66−26.4 = 10.26 m by 8.84 m. The header says “measured plans, to scale”.

This may correctly be exterior dimensions including wall thickness, but the current geometry does not distinguish wall faces. Show a thin wall band or mark the written room sizes “interior”; draw the interior bounds at their own measured dimensions if room comparisons matter. Do not report this as proof the measured plan is wrong: it is an exterior/interior convention ambiguity. Also the section's upstairs level at 3.3 m is inferred, whereas the header foregrounds measurement.

Link to L13 · Source locators refer to the pinned review snapshot.

Rung: stars. Evidence: line 3780 says “drawn to scale”; line 3785 labels one marker “Proxima and α Centauri” at the Proxima distance 4.2 ly and an arbitrary angle. Alpha Centauri A/B are farther away, and are collapsed into one symbol.

Use “Sun–Proxima distance to scale; marker positions schematic” or label the single point only Proxima and put the binary-system context in its tooltip. The existing frame-size and “star” dot are otherwise pedagogically reasonable.

Link to L14 · Source locators refer to the pinned review snapshot.

Rungs: moon, localgroup, laniakea, milkyway, universe. The page usually does this well: the Solar System says “orbits to scale, planets not”, Laniakea says schematic, the Milky Way says artist's concept, and the CMB thumbnail is identified as an all-sky projection. Preserve those distinctions. Apply them consistently to the Moon (its radius is clamped to at least 2.5 SVG units; actual radius is 1.36 units at the orbit scale), the enlarged navigation dots, and all inset photos. Suggested shared tags: “distance to scale”, “symbol enlarged”, “illustration”, “inset at separate scale”. This is a visual-language improvement, not a claim the current Moon header “orbit to scale” is false.

Link to L15 · Source locators refer to the pinned review snapshot.

Rung: p.electron. Evidence: line 6638 and fact .4: “It is round: its charge sits within 4.1 × 10⁻³² m of its centre”.

The numerical operation d/e is correct as an equivalent dipole displacement. But it constrains an electric dipole moment/asymmetry, not the radius containing the electron's charge. It is especially easy to confuse with the nearby 2 × 10⁻²⁰ m structure bound. Safer: “No permanent electric dipole moment was detected; the bound corresponds to d/e < 4.1 × 10⁻³² m. This is an asymmetry bound, not a particle-size measurement.” NIST's JILA explanation itself uses “roundness” as an analogy while explaining what was measured. The primary Roussy et al. paper is the best direct citation.

Link to L16 · Source locators refer to the pinned review snapshot.

Rung: p.nucleon. Evidence: lines 6595, 6609 and fact p.quark.3 state about 1% of the proton is quark masses, while fact .4 gives 9% from scalar quark condensates in a lattice decomposition. The .3 source note already says the simple sum is illustrative, but the stage drops this qualifier.

Use “The sum of the three valence current-quark mass parameters is about 1% of the proton mass; this is an illustration, not a mass decomposition. Most mass comes from QCD dynamics.” Link the detailed decomposition separately. The actual lattice calculation reports the 9%, 33%, 37%, and 23% terms and their scheme/scale/uncertainties. Avoid presenting either simplified picture as an observer-independent division of the proton.

Link to L17 · Source locators refer to the pinned review snapshot.

Rung: p.nucleon. Evidence: line 6592 calls 938.272 MeV the proton's mass; line 6609 calls 2.16 and 4.70 MeV the quarks' weights. The electron fact uses MeV/c² correctly. Natural units are common in particle physics but are not declared in this general-audience ladder.

Use “rest energy 938.272 MeV” or “mass 938.272 MeV/c²”, and likewise for quark masses. A small one-time natural-units note would also resolve this, but consistent explicit units are clearer here.

Link to L18 · Source locators refer to the pinned review snapshot.

Rung: p.nucleus. Evidence: size.p.nucleus adopts diameter 8.06 fm from √(5/3)×3.1224 fm; .5 gives 2.3×10¹⁷ kg/m³ and a 5 mL teaspoon of 1.1 billion tonnes, calculated with the smaller 1.2 A^(1/3) radius rule.

Using the displayed equivalent-sphere radius produces about 1.69×10¹⁷ kg/m³ and 0.847 billion tonnes. Both are legitimate rough nuclear-density illustrations if their conventions are stated; the page currently hides the switch. Say “order 10¹⁷ kg/m³” or recalculate from the selected diagram radius. This is an internal convention issue, not a newly measured density.

Link to L19 · Source locators refer to the pinned review snapshot.

Rungs: lib.si, lib.channel, p.dopant. Evidence: el.kt says the dopants are “all ionised”; p.dopant.2 says nearly every dopant contributes its electron, but dope.n-sd and dope.count-sd correctly describe a heavily doped source example with only ~1/13 electrically active.

Ionisation of an isolated active donor and electrical activation of every chemically incorporated dopant are different questions. Add “isolated, electrically active dopants at ordinary doping levels” to the room-temperature teaching statement, and explicitly contrast this with clustering/inactivation at the very high source/drain concentration. The page already has the needed numbers; make the bridge clear rather than treating 2 kT alone as universal proof of complete ionisation.

Link to L20 · Source locators refer to the pinned review snapshot.

Rung: lib.channel. Evidence: el.off-channel estimates 0.002 electrons as board/chip-average leakage current divided among all transistors times an assumed 0.2 ps transit time. et.leak-per-tr helpfully says that this average is not what any one off transistor passes, while the lib.channel blurb and transistor teaching visual make the result feel device-specific.

Keep this as an order-of-magnitude illustration, visibly labelled “rough global-average model; not a measured channel occupancy”. The saturated silicon transit-speed assumption and average over mixed rails/states/devices are not a model of a particular transistor's subthreshold residence time. Do not increase the apparent precision by animating exactly zero/one electron as a measurement.

Link to L21 · Source locators refer to the pinned review snapshot.

Rungs: universe, p.wrap. Evidence: the universe size is explicitly calculated as the particle horizon (46.2 Gly radius); line 3689 calls the CMB “the edge of what we can see”. The drawing puts the CMB almost exactly at the outer circle.

For a general audience this is close and useful, but the labels should say “oldest electromagnetic light we observe” and “last-scattering surface, near the observable horizon”. The CMB is not a material wall or an outside view of the entire universe. The page already correctly describes the WMAP thumbnail as seen from inside and should preserve that strength. NASA cosmic history distinguishes recombination/first freely travelling light from the earlier theoretical history.

Link to L22 · Source locators refer to the pinned review snapshot.

Rungs: p.planck, p.wrap. Evidence: p.planck.5 and ring.mid correctly use the observable universe's diameter; line 6667 says “From here to the edge of what we can see is 61.7 powers of ten”. Radius would give about 61.43, rather than 61.73 decades.

Say “From the Planck length to the observable universe's diameter”. The geometric mean √(1.616255×10⁻³⁵ × 8.738989×10²⁶) = 0.1188 mm is correct and is a good teaching moment. Keep the L1/panel comparison marked as estimated, because those chip dimensions are order-of-magnitude inferences.

Link to L23 · Source locators refer to the pinned review snapshot.

Rung: solar. Evidence: line 3809 gives the date in the detail text; lines 3812–3813 simply label the marker “173 au, one light-day” on the main stage. On the audit date, 2026-10-14 (Wed, week 42), the milestone is still in the future.

NASA confirms one light-day from Earth on 2026-11-18 (Wed, week 47). The scientific value is not wrong. Make the main label “one light-day on 18 Nov 2026” or “projected milestone”, and specify Earth, since the orbit plot's origin is the Sun. This prevents the figure from masquerading as live position data.

Link to L24 · Source locators refer to the pinned review snapshot.

Rung: p.wrap; facts e.qcd.5, e.stars.4; line 6791. The useful claim is that primordial matter later became the chip's stellar-made silicon. Saying its individual “protons and neutrons formed 14–24 µs after the Big Bang” suggests every current neutron/proton retained its identity through later weak and nuclear reactions. Likewise the epoch label “particles get their masses” is broader than the Higgs mechanism's role; most proton mass is QCD dynamics, as the proton stage explains.

Suggested copy: “Primordial quark matter became hadrons; much later, stellar nuclear reactions built the silicon nuclei.” Change the electroweak label to “Higgs field gives elementary particles mass”. This is an interpretation/teaching refinement, not an objection to the thermal-history order of magnitude.

Link to L25 · Source locators refer to the pinned review snapshot.

Every rung should carry a compact quantity + provenance badge, rather than only a naked number and broad type: “diameter”, “width”, “height”, “spacing”, “radius bound”, “frame width”, or “schematic”. sizeWords at lines 3097–3098 appends “across” to almost all positive m, even when the stored value is a gate pitch, crystal-cell size, fin height, or chosen frame. APPROX only contains inferred and unknown, so approximate outside values look more exact than many derived values. Add per-record dimensional semantics and uncertainty rather than guessing from source kind.

Link to L26 · Source locators refer to the pinned review snapshot.

The city/state/Bay Area use fibre delay, Bernal/29th Street/rack use vacuum light time, and the board comparison uses an assumed FR-4 velocity. Their arithmetic is sound, but scrolling through them can feel like one common latency ladder. Show a small “vacuum”, “ideal fibre”, or “PCB estimate” badge beside each time and clock-tick count; explain that real routed networks add distance and processing. Do not present these physical lower bounds as network benchmarks.

Link to L27 · Source locators refer to the pinned review snapshot.

The rack identity, host RAM, firmware clock/rail values, recorded power maxima, population counts, and Voyager distance age differently from the speed of light or package dimensions. Add “as measured [date]” to machine state and “census [year]” to populations. b.3 is 2012–2016 ACS compared with a 2020 city total; it should not read as a current population estimate. The “highest power on record 87.8 W” issue in out.card.6 and “at most 88 W” in out.host.5 were sent to the technical reviewer for checking against later public measurements; do not conflate a vendor power budget with an observed physical ceiling.

Link to L28 · Source locators refer to the pinned review snapshot.

The page is unusually transparent about its evidence, including “book not read” and “paper not read” source notes. Keep that honesty, but upgrade consequential details to checked primary pages/DOIs rather than Wikipedia chains, unattributed textbook rules, or bare repository paths. Quark-radius limits deserve confidence level and model assumptions on the visible badge; mass decompositions need scheme/scale; dates/uncertainties need to survive from the fact table into the teaching label. “Documented” should not visually flatten a generic textbook analogy, an external foundry-node estimate, a vendor ET-SoC-1 specification, and a laboratory measurement into the same certainty.

Link to L29 · Source locators refer to the pinned review snapshot.

Rendered/API observation: the published page description still advertises six data flows and a 12-step tour. The current interface contains eleven flows and a 17-step tour. The on-page Versions section ends at 1 October despite the later geographic/cosmic additions and the reviewed 14 October snapshot.

Improve: update page metadata and the short public version history from the same release record used to build the diagram. A reader should see the current breadth and the date of its latest substantive change. This is stale documentation, not a claim that a flow is missing.

Link to R01 · Source locators refer to the pinned review snapshot.

Rendered UI observation: “? Zoom out” and question-mark ancestors intentionally conceal destinations in the outer ladder. This can be playful in a presentation, but it obscures where Up goes and makes it harder to return to a known scale.

Improve: show named destinations by default. Keep a separately selected mystery/presentation mode if the reveal is part of the teaching sequence. Treat this as a design preference, not a broken route.

Link to R02 · Source locators refer to the pinned review snapshot.

Rendered UI observation: inside the shire and minion, the legend still lists memory-shire/LPDDR4X, PCIe and I/O (Maxions) categories that are absent from that scene. The root die key is useful, but its context is no longer local.

Improve: switch to a scene-specific key, keeping a small “Global chip key” disclosure for reference. Reserve visual space for the units and evidence status that explain the diagram currently in view.

Link to R03 · Source locators refer to the pinned review snapshot.