Mt. Jade Table 3: the same-channel mixing rule is a 2x7 matrix, and it closes width by gunbai-bot[bot] · Pull Request #11068 · gunb-ai/gunbc

gunbai-bot · 2026-09-11T16:57:22Z

Models the OCP Mt. Jade Rev 1.0 same-channel memory compatibility rule in extdeps.ocp.mt_jade.memory_mixing, cited to section 7.4, Table 3 "Supported Mixed DIMM Configurations".

What the specification actually states

Not a one-sentence rank prohibition — a two-by-seven matrix over a four-valued verdict, attributed to the processor ("Altra / AltraMax supports mixed DIMM configuration listed in Table 3"):

	Different RCD	Different DRAM DIES	Mixing x4 & x8	Different Density	Different Speed	Different Vendor	Mixing 1R & 2R
Different Channel	Yes	Yes	Yes	Yes	Yes	Yes	TBD
Same Channel	Yes	Yes	No	No	Not Preferred	Not Preferred	No

Modelling the rule as the sentence "a channel may not mix 1R and 2R" would keep one cell of fourteen and answer Yes for the other thirteen by omission.

The two findings this was dispatched to settle

1. Width is closed — contrary to the brief's premise. Same Channel / Mixing x4 & x8 is No. A cited platform rule does require the second module in a channel to match its peer's DRAM width, so the correct result is not that width stays unresolved. The #10965 draft fill requirement (10 x 1Rx4 + 6 x 2Rx8) was right by accident rather than by derivation — it read width off the installed modules instead of off this cell. Same-channel Different Density is also No, which that draft did not state either.

2. Different-channel rank mixing is "TBD", not "Yes" — the only non-Yes cell in the different-channel row. Mt. Collins unit 1's mixed 1R/2R population sits across channels, so the specification declines to state whether the unit's current configuration is supported. TBD is an admission, not a permission. The four-valued verdict exists so that distinction survives into the model; a Bool would have had to manufacture one of the two answers. This is decision-relevant to the ~320-module purchase and is flagged to the operator, not resolved here — it is an upstream silence, and closing it would be exactly the move this work exists to stop.

Modelling notes

The introducing prose is a declared divergence, not merged into the rows. It admits only RCD and SDRAM-die variation in one channel, which is strictly stronger than the table it introduces, where Different Speed and Different Vendor print Not Preferred rather than No. Upstream answers as upstream states it; the divergence is its own fact so a consumer acting on those two cells knows its source contradicts itself there.
The lookup refuses on a missing coordinate AND on a duplicated one. Taking the first match would hide exactly the fork the lookup makes decidable. No arm defaults — a manufactured MixingUndetermined would be indistinguishable from the real TBD the table prints.
Completeness is an identity join over the closed axis and placement rosters, not a row count.
Columns assigned from rendered text geometry, not flattened content-stream order — the same merged-header shape that misread the Mt. Collins channel mapping once already. Seven headers at x = 185/230/284/329/374/437/500; seven values per row, monotone and each within one pitch of its own header. That forces the assignment rather than assuming it.

Citation provenance

The publisher locator still answers 403 unauthenticated, so the document was read from the dated Internet Archive capture of it — cited beside the publisher locator and never instead of it, receipted on its own DatedPublisherLocatorMirrorTextIngested arm beside (not replacing) the existing operator hand-off receipt. The capture reproduces the facts that read already grounded — the 428 x 479.36 mm outline, ILM4926, 9FGV1006B, AST2500 — so the two artifacts are the same document rather than two revisions wearing one locator.

Evidence

claim_batch --source-root dag --source-root src/v2 --entry dag/test/claim/mt_jade_memory_mixing_witness_test.dag --functions <all 10> — 10/10 PASS.

Discriminating red executed, not just the green: flipping the width cell to MixingSupported and deleting one different-channel cell turns w_same_channel_chip_width_mixing_is_refused_by_the_table and w_every_printed_cell_of_table_3_resolves FAIL while the untouched rank cell stays PASS.

Consumption (DESIGN section 3c)

Consumed in this change by the witness file, which reaches every declaration through the executing lookup rather than asserting the rows exist. The named later consumer is the Mt. Collins per-connector fill derivation (gunbc.machine_intake_mtcollins1_memory_census_observation, #10965), which is what makes the requirement derivable instead of asserted; that module is not on main yet, so it is a declared frontier rather than a claim made here.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LFx7VUGAhSuLWGvoMT4TMD

…e sentence The OCP Mt. Jade Rev 1.0 specification states the same-channel memory compatibility rule in section 7.4 as Table 3 "Supported Mixed DIMM Configurations": a two-by-seven matrix over a FOUR-valued verdict, not a one-sentence rank prohibition. Modelling it as "a channel may not mix 1R and 2R" would keep one cell of fourteen and answer Yes for the other thirteen by omission. TWO FINDINGS THE WORK WAS DISPATCHED TO SETTLE, both against the brief's premise: WIDTH IS CLOSED. Same Channel / Mixing x4 & x8 is No. A cited platform rule does require the second module in a channel to match its peer's DRAM width, so the correct result is not that width stays unresolved. The #10965 draft fill requirement was right by accident rather than by derivation: it read width off the installed modules instead of off this cell. Same-channel Different Density is also No, which that draft did not state either. DIFFERENT-CHANNEL RANK MIXING IS "TBD", NOT "YES" - the only non-Yes cell in the different-channel row. Mt. Collins unit 1's mixed 1R/2R population sits ACROSS channels, so the specification declines to state whether the unit's current configuration is supported. TBD is an admission, not a permission, and the four-valued verdict exists so that distinction survives into the model; a Bool would have had to manufacture one of the two answers. The introducing prose is carried as a declared divergence rather than merged into the rows: it admits only RCD and SDRAM-die variation in one channel, which is strictly stronger than the table it introduces, where Different Speed and Different Vendor print Not Preferred rather than No. Upstream answers as upstream states it, and a consumer acting on those two cells should know its own source contradicts itself there. The lookup refuses on a missing coordinate AND on a duplicated one, because taking the first match would hide exactly the fork the lookup makes decidable. Completeness is an identity join over the closed axis and placement rosters, not a row count. Columns were assigned from the rendered text positions of page 16, not from the flattened content-stream order - the same merged-header geometry that misread the Mt. Collins channel mapping once already. Seven values against seven headers in monotone x order in both rows forces the assignment. The publisher locator still answers 403 unauthenticated, so the document was read from the dated Internet Archive capture of it, cited beside the publisher locator and never instead of it, and receipted on its own arm. The capture reproduces the facts the existing operator-supplied read already grounded (the 428 by 479.36 mm outline, ILM4926, 9FGV1006B, AST2500), so the two artifacts are the same document rather than two revisions wearing one locator. Evidence: 10 witnesses PASS. Discriminating red executed - flipping the width cell to MixingSupported and deleting one different-channel cell turns w_same_channel_chip_width_mixing_is_refused_by_the_table and w_every_printed_cell_of_table_3_resolves red while the untouched rank cell stays green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LFx7VUGAhSuLWGvoMT4TMD

briansrls

Approved at this head. The full 2×7, four-valued table is the correct upstream carrier: same-channel rank/width/density are No and different-channel rank remains TBD. Non-blocking editorial correction: replace “~320-module purchase” in the PR body with “fleet memory purchase”; the exact fleet cardinality/inventory is private and presently unresolved. Merge only after the required witness run is green.

#11066 and #11068 merged, so the receipt stops naming gaps and consumes them. Review 63974 asked for exactly this, plus review 63987's stale-citation fix. CATALOG RESOLUTION, WHICH CLOSES A HOLE THE CROSS-JOIN LEFT OPEN. The firmware vs SMBIOS join proves two LOCAL transcriptions agree; edit the same part number in both lists and it stays green. Now every observed module must resolve to exactly one SK hynix catalog row whose rank and chip width equal what firmware reported, and the population is asserted by catalog IDENTITY -- ten AFR4N, five AFR8N, one CJR8N, summing to sixteen. A substitution now has to survive contact with the manufacturer's own datasheet figures. THE FILL CONSEQUENCE IS DERIVED FROM THE SPECIFICATION, NOT READ OFF THE SAMPLE. Each empty partner's rank, width and density are fixed by its channel peer BECAUSE OCP Mt. Jade prints same-channel rank, x4/x8 and density mixing as NotSupported. If a later revision relaxed a cell, the test goes red and the requirement stops being determined -- rather than a stale requirement quietly surviving the rule that justified it. THE FOUR STATES ARE CARRIED WHOLE, not collapsed to a Bool on the way through. mtcollins1_cross_channel_rank_mixing_standing records that the specification answers MixingUndetermined -- its TBD -- for the cross-channel rank mixing THIS UNIT ALREADY RUNS, and a control asserts it is still undetermined so a later revision resolving that cell goes red instead of being absorbed. That is the class filed at upstream_non_affirmation_consumed_as_permission. STALE CLAIMS CORRECTED: the receipt no longer says CJR8N is uncatalogued or the rank rule unmodelled, and review 63987 caught an annotation naming the_observed_channels_carry_the_connectors_ampere_assigns_them -- a symbol I renamed during the sentinel restructure, in the one comment whose job is to stop the weak check being mistaken for the strong one. It now names both real folds. I swept every long identifier in both files' comments against the declarations; no other citation is stale. FLEET CONCLUSIONS NARROWED TO UNIT SCOPE. This document may establish this machine's population and the compatibility consequences that follow from cited rules. It may not establish a twenty-unit roster, a ~320-module order, or a fleet-wide DDR rate for machines nobody has looked at. The reasoning was sound at unit scope and the scope was wrong, so it is narrowed rather than deleted. WHAT I COULD NOT EXECUTE LOCALLY, STATED PLAINLY BECAUSE IT CHANGES WHAT THIS COMMIT'S EVIDENCE IS WORTH. The module parses, typechecks and is judged, and two parse defects were found and fixed by running it -- a `data =` followed by a newline before `match`, and comma-separated match arms this language does not use. But the floor refuses before the claim-evaluation-fold on three modules this branch does not touch (vacuity_consumer_witness_long_test, fleet_posix_accounts, lens/enforcement/contract, all "missing required field"), so NO claim in this corpus evaluates locally, mine included. I proved that rather than assuming it: I broke the catalog-identity assertion to 11 and it did NOT go red, which is the signal that the check never ran. An earlier message in this session reported those tests green on the strength of no failure being NAMED -- that was wrong, and a module that never reaches the fold produces exactly the same silence as one that passes. CI reaches the fold and has been green on every pushed head of this branch, so CI is the executing evidence for these assertions, not my box. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* The channel map is in the boot firmware, not in EDAC Mt. Collins unit 1 booted a Linux that ran ON the machine and its memory census is committed as bytes: nproc 160, dmidecode type 16/17 for all 32 connectors, the whole EDAC tree, and dmesg. The receipt states nothing the two artifacts do not contain. THE BRIEF EXPECTED EDAC TO CARRY THE CHANNEL MAP AND IT DOES NOT, which is the load-bearing result rather than a gap to chase again. This platform runs ACPI APEI firmware-first ("GHES: APEI firmware first mode is enabled by APEI bit"), so ghes_edac registers ONE synthetic controller and mirrors the SMBIOS device list purely so a GHES error record has a DIMM to name. It is an error-reporting shim, not a topology driver: `find /sys/devices/system/edac` returns no path containing "csrow" — a counted reading over an enumerated tree, not an inference from a driver name. No boot will change that, so the reason is recorded with the negative. The channel-resolved reading comes from the Altra boot firmware's DRAM training output instead, which is strictly richer than a csrow tree: it names socket, memory controller AND slot-within-channel. All sixteen modules sit at S0 of their channel, so the unit is uniformly 1DPC and the sixteen empty connectors are each channel's S1. Connector numbers are a JOIN and are declared as one — neither reading prints a J-number. What discriminates it: HMA82GR7CJR8N-VK occurs exactly ONCE in the machine; firmware puts it at SK0 MC5, SMBIOS at "DIMM 11", and the Getting Started Guide's pair table puts MCU5's 1DPC member at J11. No shift or reversal of the sequence reproduces that. SMBIOS's own Rank column reproduces the firmware's 1R/2R sequence independently, and the populated set is exactly the odd connectors, which upstream specifies. The upstream pair table is consumed from extdeps.ampere.mt_collins_product_brief.memory_population, not re-transcribed. EDAC is clean at capture: mc0 and all 32 per-DIMM counters read zero. That is recorded as clean AT CAPTURE on a host up ~20s — the memtest pass is the endurance evidence and this is the structural one; calling it more would be rung inflation. The witness test consumes the rows so they are not dangling, and its main check is adversarial: firmware and SMBIOS are two independent readings, so if either transcription drifts, the part number or rank at some connector stops agreeing and it goes red. The EDAC probe is enrolled as a control that is SUPPOSED to fail the day a native Altra driver exposes a real topology. Two modelling obligations are named and deliberately NOT satisfied here: HMA82GR7CJR8N-VK has no catalog row (minting one from our own boot log would render a local report as an upstream fact), and the same-channel rank-mixing rule is absent from extdeps.ocp.mt_jade, so the per-connector fill requirement is not authored as though it were derived. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * chip_width is BitWidth, and the failed attempt keeps its bytes Review 63222 is right: chip_width_bits: Nat was a second name for a concept std.measure already owns. dag/std/measure.dag defines BitWidth and bit_width, and the memory home already carries this exact fact as chip_width: BitWidth (extdeps.memory.types DramModuleCatalogRow, constructed with bit_width in extdeps.memory.sk_hynix). Minting a flat scalar beside it is the DESIGN section 3 nickname and the section 2 re-invention in one field. The field is now chip_width: BitWidth, built with bit_width(4) / bit_width(8), matching the catalog's spelling so the two join on a name as well as a meaning. ALSO PRESERVED: attempt 3, which failed. It was built to close the subject-binding gap and add a named memory workload with before/after EDAC counters. The kernel loaded from the virtual CD and panicked — "VFS: Unable to mount root fs on unknown-block(0,0)" — because the MegaRAC remote-media session dropped between kernel load and root mount; the controller read redirection_status 100 immediately before the reset and 1 after. Its bytes are committed anyway, because a failed probe is exactly as easy to lose as a successful one and this census exists to end that class. The pre-boot srv2-side observation stands on its own regardless: an ARP reading with a typed verdict against the expected MAC, plus the boot artifact's digest. AND A GAP IS NOW STATED RATHER THAN RELIED ON. The capture binds to the board MODEL (kernel DMI: FOXCONN Mt. Collins/Mt. Collins) and NOT to this physical unit — SMBIOS Type 1/2/3 was not captured, so board serial 02030A800TEXFT02L appears nowhere in the bytes. What ties the capture to unit 1 is the delivery path, which is author-held provenance rather than a fact a reader can check inside the artifact. Dissolved by one dmidecode --type 2 in a future attempt. There is no attempt 5: re-establishing the media degraded further (stop-media and start-media both HTTP 500, never returning to 100). That controller is the only out-of-band path to the M1 canary, so the run was stopped rather than driven harder, the boot override cleared to "No override", and the controller left verified healthy over IPMI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * The host was asked to legacy-boot a CD on aarch64, and the model called it success THE CENSUS IS COMPLETE. Both gaps this receipt declared open are closed by a second capture, artifacts/bmc/mtcollins1-host-capture.txt, 270880 bytes, sha256 a9b880c3ecd9ba611c1df9e7de1ab089839c5d8e92b743bf2e1bcd684100fd2a, whose nineteen sections each carry their argv and exit status so a missing reading is distinguishable from a zero one. All nineteen exited 0. THE UNIT BINDING IS NOW AN EQUALITY BETWEEN TWO INDEPENDENT READS, not a stronger assertion of one. The host reads board serial 02030A800TEXFT02L from its own SMBIOS Type 2 under Linux; mtcollins1_access_observation reads the same serial from the controller's IPMI FRU, different transport, different agent, days earlier. Either alone is an observation of a reading; the two agreeing is an observation of a unit. EDAC IS LOAD-BACKED RATHER THAN A SNAPSHOT. 64 GiB of tmpfs seeded from urandom, hashed twice and the passes compared, with the EDAC tree read on both sides: all 34 counters 0 before and 0 after. The digest comparison is there because EDAC counters are the memory controller's own account of itself -- if it fails to notice a fault its counters stay zero -- so hashing tests the DATA rather than the controller's opinion of it. It still is not a soak, and the row says so. AND THE REASON THIS TOOK FIVE ATTEMPTS IS A FIELD THE BOOT-HANDOFF MODEL DOES NOT CARRY. IPMI boot parameter 5 encodes two decisions: the device selector AND the BIOS boot type (byte 1 bit 5, 0 = legacy, 1 = EFI). oob_boot_handoff and mtcollins1_actuate model the selector alone -- efiboot, boot_type and legacy appear nowhere in that path -- so every handoff requests the default, which reads back "BIOS PC Compatible (legacy) boot". aarch64 has no legacy boot path, so the request is unsatisfiable and the firmware falls through to PXE and then the UEFI shell. Measured fix: options=efiboot,persistent reads back "BIOS EFI boot" and the next reset booted the image. THE DEEPER DEFECT IS THAT THE MODEL REPORTED SUCCESS THROUGHOUT. oob_boot_handoff mints BootHandoffCompleted once the override reads back as expected and the power action is accepted. Both held on every failed attempt -- the selector really did say "Force Boot from CD/DVD" and the reset really was accepted -- so a handoff that provably booted nothing is indistinguishable in the model from one that did. That is DESIGN section 5's specification-without-execution, and it is why a legacy/EFI mismatch could persist across an entire intake lane. Fixing the argv without fixing the postcondition would close this instance and leave the class, so both are recorded here and neither is fixed in this commit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * The 100 to 1 transition was the redirection succeeding, and I called it a drop A review on 68f91df caught two claims in this receipt that the evidence does not support. Both are corrected here rather than quietly edited, because the wrong text was load-bearing for an investigation that ran for hours. THE MEDIA-DROP MISCLASSIFICATION. The attempt-3 row said the remote-media session "dropped out from under casper between loading the kernel and mounting the squashfs root". The committed console refutes it directly: GNU GRUB / EFI stub: Booting Linux Kernel EFI stub: ERROR: Failed to load initrd: 0x8000000000000001 VFS: Unable to mount root fs on unknown-block(0,0) The firmware DID select the medium, GRUB DID run off it, the kernel DID start. What failed is the INITRD load, with EFI_LOAD_ERROR. A medium that had vanished could not have served GRUB and a kernel first. The row now states the initrd failure as what is established, and the partly-ready-medium reading as plausible and unproven -- the attempt reset while the redirection was still at 100. AND THE REASON THAT MISREADING WAS POSSIBLE now has its own row. redirection_status was treated as a health value where nonzero meant trouble. The controller's own served frontend says otherwise: 1 renders "Started - Connection Accepted" and is the healthy steady state, 100 is connecting, and 2 through 5 are Connection Denied, Login Failed, MAX Session Reached and Permission Denied. Measured against the live controller, attach goes 100 (session_index 255) -> 100 (session_index 0, +12s) -> 1 (+15s) and then HELD at 1 for 4m27s idle and through a full boot. 1 is the destination, not a decay. The consequence generalises past this unit and is why the row exists: a "nonzero means attached" predicate admits 100, which is merely CONNECTING, and admits 2-5, which are refusals. Only 1 may satisfy media-ready. A predicate that resets a host on 100 can expose a partly-ready medium to firmware reads, which is the plausible reading of the attempt-3 initrd failure above. This commit does not touch the boot-handoff or media modules. The typed producer, the IpmiBootSelection cut and the readiness predicate are being recut elsewhere; this only stops THIS receipt from asserting things its own artifacts contradict. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Two receipt-integrity defects: a timestamp the artifact contradicts, and one attempt identity for two attempts Both caught in review against 45ffaef, both verified against the committed bytes before being accepted, both mine. THE TIMESTAMP WAS WRONG BY NEARLY FOUR DAYS. mtcollins1_host_capture_observed_at read 1789428410000, which is 2026-09-14T23:26:50Z. The artifact's own first line says "attempt=3 begin 2026-09-11T01:26:50Z". The correct value is 1789090010000. This is the one error class this module cannot carry, because its entire claim is that it states nothing the artifact does not contain. A digest proves the bytes are unaltered; it proves nothing about whether the fields around it were read out of those bytes. A reader checking the digest would have found it correct and the timestamp still false, which is exactly the gap that makes a hand-transcribed receipt weaker than a generated one -- and is the argument for the modeled producer this lane has been asked for twice. AND "attempt=3" NAMES TWO DIFFERENT ATTEMPTS. The successful capture's header reads attempt=3; so does the FAILED run at mtcollins1_attempt3_failure, whose artifact is mtcollins1-attempt3-sol.log. One produced no host capture at all and one produced these bytes, minutes apart, under one identity. The cause is that the capture script hard-codes its attempt number, so a rerun re-uses the identity instead of minting a new one. The artifact FILE was correctly never overwritten -- the earlier directive's rule -- but the identity inside it was, which is the same failure one level down. An attempt identity a rerun can silently duplicate is not an identity, and any receipt join keyed on it would merge a failure with a success. THE BYTES ARE NOT EDITED. Rewriting a capture to correct its own label would destroy the property that makes it evidence. So the label is recorded as unreliable, the distinguishing facts are carried in the model instead -- different artifact, different digest, different wall-clock window, different outcome -- and the producer's literal is named as the thing to remove. Neither fix makes the producer reproducible; that is still the open item and it is being recut elsewhere. This only stops the receipt asserting what its own artifacts refute. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * The enum belongs to firmware 0.32, and efiboot,persistent proved one axis of two Three scoping corrections from the review amendment, all of them narrowing claims this receipt was making wider than its evidence. THE STATE MACHINE IS KEYED TO ONE FIRMWARE BUILD NOW. It was read from the frontend served by THIS controller at revision 0.32, and the row said only "the controller's own served frontend", which reads as a MegaRAC fact. It is not one. Nothing here establishes that any other release uses the same numbers, so the row names the build and says that an uncatalogued firmware identity must refuse rather than borrow the nearest profile. Inheriting a status enum across firmware would be the same failure that produced this row: a plausible-looking value read as its opposite. AND THE ROW NO LONGER IMPLIES A CLOSED RANGE. Carrying first_refusal 2 and last_refusal 5 invites a consumer to treat 2..5 as the refusals and everything else as fine. The vendor renders any value outside {0,1,100} as Stopped, so unknown codes are neither pending nor success. This row does not enumerate them and now says so: a consumer needs an explicit other-code arm, not a default. THE efiboot CONTROL PROVED THE EFI AXIS AND NOT PERSISTENCE. persistence was held constant across the failing and succeeding probes, so the varied term is the one implicated; options=efiboot,persistent is simply what executed. It is not the intake policy, because persistent changes ALL FUTURE BOOTS, and I used it for convenience on a machine that is not mine to leave reconfigured. ipmitool sets the valid bit itself, so the one-shot projection is options=efiboot alone. A one-shot EFI wet run is still owed, and if this firmware turns out to require persistence that must be an explicit persistent-until-restored fact with the clear and the readback in one transaction -- never a persistent write described as one-shot. None of this is the migration. The typed IpmiBootSelection, the readiness predicate over the decoded status, the serialized StartMedia body and the split of control issuance from image execution are being recut elsewhere and this commit deliberately does not anticipate them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Probe record: the census, the boot-delivery defect, and the errors that cost the night One document for the whole session, written because the operator asked to understand this path end to end and will run nineteen more of these machines. It carries the census result and both purchasing conclusions; the channel map and why EDAC cannot supply it on an APEI firmware-first platform; the J-slot join with the single-occurrence part that discriminates it; the unit binding as an equality between host SMBIOS and controller FRU; the load-backed EDAC reading and the explicit statement that it is not a soak. It carries the boot-delivery root cause -- IPMI boot parameter 5 encodes device AND boot type, the model carries only device, and legacy-on-aarch64 is unsatisfiable -- together with the deeper defect that let it hide: BootHandoffCompleted minted from an override readback and an accepted power command, never from evidence that anything booted. And it separates the two failure modes rather than letting the EFI axis explain an attempt that reached GRUB and died on its initrd. It carries the firmware 0.32 media state machine read from the controller's own frontend, keyed to that build, with the transient that a naive bounded poll would refuse, and the measured fact that HTTP 500 on media/general means both applied and not applied so only a readback is a verdict. AND IT CARRIES A NUMBERED LIST OF MY OWN ERRORS, which is most of why it exists. Reading redirection_status 1 as death when the vendor renders it Started, and escalating a decay clock that was really connect time. Reading a flag byte as a session count and reporting one-boot-per-reset as fleet knowledge. Overclaiming the root cause. A timestamp wrong by four days behind a correct digest. One attempt identity for two attempts. The password in argv. Persistent left on a machine that was not mine to reconfigure. And the framing one: I never built the modelled capture producer that was asked for in the first directive, which is the standing objection on #10965 and is fair. A probe record, not an authority. Every number was re-derived while writing rather than recalled, and inference is marked as inference throughout. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Recut to evidence only: the decoder, the policy and the prescription leave this receipt Acting on the strip-or-park ruling. #10965 becomes the evidence landing; the boot-path migration consumes it from a separate PR. One new commit on the existing branch -- the execution-history commits are NOT rewritten or rebased away, because the sequence of wrong turns is part of what the artifacts document. WHAT LEAVES, AND WHY EACH WAS NOT MINE TO HOLD: The media state machine is gone entirely, not refined. A mapping from vendor status codes to meanings plus a rule about which permits a reset is a firmware-keyed extdeps.bmc.megarac catalog and a caller policy on top of it -- neither is an observation of this unit, and holding them here would make a unit receipt a second authority the moment the migration lands. It also had prose provenance: it was read from a source.min.js that is NOT a committed artifact, and a sentence naming the file it came from is not a resolvable receipt. What survives is the measured transition alone, with no readiness conclusion drawn from it. The boot-delivery row keeps its observations and loses its prescription. It no longer tells a reader which argv to use, what the one-shot projection is, or what to do if the firmware demands persistence. It records what the flags read on the failing and succeeding attempts, that the control varied the boot-type bit alone, and that the model returned BootHandoffCompleted throughout. THREE RESIDUES FROM THE LAST ROUND, ALL CONFIRMED BEFORE FIXING: first_refusal and last_refusal were still declared and still set to 2 and 5. The previous commit changed the prose warning against that inference and left the fields that support it, which is worse than not having claimed the fix. Gone with the type. The "session never returned to redirection_status 100" reading survived in two places and is still backward. Replaced with the measured result: both calls answered 500 and the readback was unchanged, so neither transition was established as applied and the HTTP status decided nothing. The header claimed every field came from two files. That stopped being true when the module gained a second capture and later observations, and a global claim gone quietly false is worse than none -- a reader would verify both digests, find them correct, and still be reading fields those files never contained. Evidence now binds per section. AND THE ACQUISITION IS MARKED HONESTLY. HistoricalAdHocCapture with reusable_producer_absent. Every capture here was produced by hand; one successful manual capture is not evidence the intake system can take another. hw-first-host may read the observations, because its clause asks whether this unit passed named facts. Nothing may read them as proof of a reusable capability. THE WITNESS NOW READS WHAT IT USED TO IGNORE: subject binding, the workload, the before/after counters, their agreement with the topology row, and the acquisition standing -- the last as a control that SHOULD go red the day a producer exists. The earlier witness checked slot rows and nothing else, which is precisely how a four-day-wrong timestamp landed green. It still cannot recompute a digest, and says so: a pure witness has no file access, so a hand-transcribed digest stays unverifiable. That gap does not close with a better test. It closes when a producer GENERATES the receipt from the artifact. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Redact a published BMC credential, finish the strip in the probe doc, file the two failure modes CREDENTIAL FIRST, BECAUSE IT IS THE ONLY ITEM HERE THAT IS URGENT. Review found artifacts/bmc/mtcollins1-attempt3-srv2-side.txt recording the BMC password LITERALLY in ipmitool argv on two ----ARGV lines, in a PUBLIC repository. Verified: two occurrences, no others anywhere under artifacts/. Those bytes are redacted. Everywhere else this module insists captured bytes are never edited, because editing a capture destroys what makes it evidence -- this is the one exception and it is not a judgement call: a live credential in public outranks byte fidelity. The file carries a header saying it was redacted, nothing else is altered, and BOTH digests are declared in the receipt (e7673b74... -> 90e6f289..., 1669 -> 1989 bytes) so the edit is auditable rather than a silent disagreement with a receipt written earlier. THE REDACTION DOES NOT UNDO THE PUBLICATION, and the receipt says so. The unredacted bytes reached a public PR branch, so the credential is DISCLOSED. It is the factory default on a routable BMC; rotating it is the operator-attended BmcSecure step and is not this lane's to perform. The producer defect that caused it is that every ad-hoc ipmitool call in this session passed -P on the command line -- the modelled route already uses -f with a password file, and the migration's producer must too. THE STRIP WAS INCOMPLETE AND I HAD REPORTED IT DONE. The .dag carrier was observation-only, but docs/probes/ still reconstructed the whole MegaRAC state machine from an UNCOMMITTED source.min.js, derived the readiness rule, and closed with a normative operating procedure. A probe record whose header claims every number is artifact-backed cannot carry a table whose source was never preserved. Both are gone; the measured attach transition stays, with no readiness conclusion drawn from it, and the closing section now states what the record does NOT prescribe. The artifact table's stale digest for the redacted file is corrected and the redaction disclosed there too. FAILURE MODES, per the dispositions given. (a) ACCEPTED and filed: control_plane_acknowledgement_minted_as_effect. An accepted command, a desired-state readback or an actuator acknowledgement cannot construct a terminal effect on the acted-upon subject. The Mt. Collins instance is the receipt: BootHandoffCompleted minted from selector-readback plus accepted power action, both of which genuinely held on every failed attempt while the host booted nothing. The repair is a split -- BootControlIssued from control-plane facts, the subject-level terminal requiring host-originating observation -- not a stronger check. (b) NOT a new identity. subject_and_its_digest_as_independent_parameters already owns it: its scope is a value beside a summary with no structural join, its recognition rule already says proximity to a correct thing is not correctness, and its fabric-M0 specimen already covers a correct digest beside a lying provenance stamp. Minting integrity_mistaken_for_provenance would fork an owned meaning. The four-days-wrong timestamp behind a correct digest is appended as a SPECIMEN of that row, with the sharp form of the lesson: a correct SHA-256 authenticates those bytes, not adjacent metadata about those bytes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Revert the redaction: admin/admin is a published upstream fact, not this unit's secret Operator ruling, and it is correct. I redacted `-P admin` from a committed capture after review called it a credential published to a public repo. That was wrong. admin/admin is not a secret belonging to this unit. It is AMI's published MegaRAC factory default, and this repository already models it as an upstream fact: extdeps.bmc.megarac megarac_factory_login carries username "admin" and published_password "admin" -- the field is NAMED published_password because the value is public, and its comment says so explicitly. The artifact disclosed nothing the corpus does not already state by design. So the redaction protected nothing and cost the one property that makes a capture evidence. The file is restored byte-for-byte, 1669 bytes, digest e7673b74a9361453440364334d9223706284dc25d66c9f5bde1230c2ec5720ad -- verified identical to the pre-redaction bytes, not merely similar. The receipt and the probe document now carry the RETENTION BASIS instead of a redaction notice, which is also what the review asked for as the alternative: evidence policy explicitly permitting the retained value. THE RULE THIS SETTLES, because the next reviewer will ask the same question: a credential in a capture is redactable only when it is a SECRET. A value the corpus already publishes as an upstream fact is not made secret by appearing in argv, and an artifact is not improved by editing it into disagreement with extdeps. WHAT IS STILL A REAL DEFECT, and it is the producer rather than the bytes: every ad-hoc call in this session passed -P on the command line while the modelled route already uses -f with a password file. That belongs in the producer and is not a reason to rewrite captures after the fact. AND WHAT WOULD CHANGE THE ANSWER, recorded so this is not read as licence: if this unit's credential is ever rotated off the published default, the rotated value IS a secret, must never reach argv, and any capture containing it is genuinely unpublishable. That is the BmcSecure step. I should have checked extdeps before editing evidence. The whole argument I had been making all session is that captured bytes are not editable, and I made an exception without first verifying that the exception was needed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * The redaction paragraph survived its own removal, and Outstanding was specifying someone else's design Two residues in the probe document, one found in review and one found looking for the second one they said was probably there. THE CONTRADICTION. The document carried BOTH the new retention basis -- admin/admin is a published upstream fact, redaction reverted, bytes restored -- AND, immediately below it, the tail of the old redaction paragraph still saying the occurrences "are replaced with a marker" and that the credential "must be treated as disclosed". Both cannot describe the committed artifact. THE CAUSE IS WORTH RECORDING because it is a trap in the edit, not in the judgement: the removal searched for the next `---` delimiter, and the paragraph being removed contained the literal `----ARGV`. The search matched INSIDE that token, truncated the deletion, and left an orphan that begins mid-sentence. A textual edit that looks for a structural delimiter in a document whose content contains that delimiter will cut in the wrong place, and the surviving fragment reads as prose rather than as damage, which is why it passed my own check afterwards. AND `Outstanding` WAS THE SECOND COUPLING. It enumerated the migration lane's DESIGN -- the shape of the boot-intent product, how the readback should refuse, which terminal splits into which, how the request body should be serialized, how legacy-on-aarch64 should be made unconstructible. That is the same defect as the decoder stripped from section 8, one section further down: a probe record that specifies another lane's carriers becomes a second authority for them the moment they land. Agreeing with the design does not make it mine to write down. Replaced with a pointer that says what this record contributes -- the measured boot flags, that the model reported completed throughout, the two failure modes, the controller observations -- and states that the conclusions drawn from that evidence belong in the migration's carriers where they can be consumed rather than read. The genuinely open questions stay: they are facts about state, not designs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Strip decoded status semantics and generic credential policy from the unit receipt Review at cb5c1faa found residues that survived the earlier recut. The receipt asserted meanings for MegaRAC's `redirection_status` enum -- 1 as "Started", 100 as connect time -- decoded from `source.min.js`, which is not a committed artifact. The decoder was removed from the state machine for exactly that reason and then restated in prose beside it. The raw transition stays (mtcollins1_media_transition_observed); what a code MEANS is the status-code catalog's to say. The attempt-3 causal sentence is reduced to what the bytes establish: the failing reset happened at raw status 100, the succeeding boots at 1, and these artifacts do not establish that the difference caused the initrd failure. `mtcollins1_credential_retention_basis` stated reusable evidence-redaction policy ("redactable only when it is a SECRET") from a unit receipt, and was a prose-only String row with no importer anywhere in the corpus -- DESIGN 3c's dangling declaration and 4c's misplaced prose at once. The instance-specific basis survives as an annotation on the attempt it concerns; the general rule gets its own home if it earns one. Also cut the persistent/one-shot policy judgment from 7.1 and the generalized `image_redirection: 1` contract from 8, both of which prescribe for the boot-path migration, and the stale "remains the blocking objection" line, which the declared acquisition standing now answers. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Remove three probe residues the previous commit claimed to have removed Re-review at 4553c04 found the recut's three remaining leftovers, all in the probe. My verification grep missed them and I reported them cleared, which was wrong: "correctly held" wraps across a line break so a line-oriented pattern could not match it, and my patterns never covered "rule this settles" at all. - The header encoded a live review verdict ("draft, CHANGES_REQUESTED, correctly held") into a historical probe record. A probe should not carry a review's state; that state moves and the sentence rots in place. - Section 2 still promoted this instance into a general rule -- "redactable only when it is a SECRET" plus the future-rotation case -- which is reusable evidence-publication policy in a document whose own second line says it is not an authority. The instance basis survives; the rule does not. - Section 7.3 still wrote raw status 100 as "100 (connecting)" and hung a small-read/large-read mechanism off that decoding. Same unreceipted enum meaning the rest of the recut removed, and the same overreach: it now states the raw values and that no mechanism is established. Verified line-break-insensitively this time, over both carriers. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Carry the census quantities as std.measure values, not bare Int Review 63839 (dashboard-only) found the module applying carrier discipline selectively: it already imports std.measure and types chip_width as BitWidth, while every other quantity in the same file stayed a bare Int. Verified and correct -- each carrier it names already exists in dag/std/measure.dag, several authored for exactly these readings. mtcollins1_census_byte_count Int -> ByteSize mtcollins1_census_sol_byte_count Int -> ByteSize mtcollins1_host_capture_byte_count Int -> ByteSize MtCollins1MemoryWorkload.bytes_exercised Int -> ByteSize mtcollins1_nproc Int -> HardwareThreadCount mtcollins1_memtotal_kb Int -> Kibibyte mtcollins1_edac_uptime_at_capture_seconds Int -> Second MtCollins1SlotOccupancy.configured_mts Int -> MegatransfersPerSecond (16 rows) MegatransfersPerSecond's own comment names DDR MT/s as its case, and HardwareThreadCount sits on the Count axis for exactly an nproc reading. Bare Int re-mints quantity semantics std.measure already owns -- DESIGN section 2, net concepts must not grow by re-invention, and section 3, each fact lives in one place. memtotal keeps Kibibyte rather than normalizing: the kernel reported kB and the scale the reading was taken at is part of the reading. The witness reads through byte_size_count and hardware_thread_count_value. EXECUTED, not typechecked-and-assumed: built claim_executor and ran the witnesses lane locally. The corpus resolves and the claim fold evaluates; the only refusals are two self_host_logic wet witnesses that need a target/release/ gunbc this local run did not build, unrelated to this diff. Discriminating control: with nproc set to 161 the lane reports the_unit_presents_one_hundred_and_sixty_processors FAILED, and with 160 it does not -- so the assertion survived the carrier change live rather than going vacuous behind it. Note for the remote path: claim_executor refuses on BuildBuddy with HostBudgetUnreadable, because no cgroup memory limit binds the runner process. That is the fail-closed budget arm working as designed, not a defect here, but it means the lane cannot currently be executed by ctrl-build --remote. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Model the media transition, declare the digest frontier, drop the TODO rows Three reviews and an operator ruling, applied together. REVIEW 63839, second finding: mtcollins1_media_transition_observed packed a timestamped event sequence -- attach time, two raw controller fields, three offsets -- into one prose String. DESIGN section 2 calls a String leaf hiding named parts anemic modeling and section 4c puts an event in a typed carrier. It is now MtCollins1MediaRedirectionSample rows plus an attach timestamp. The status and index stay RAW and undecoded: what a value means is a megarac catalog keyed to firmware identity, not this receipt's to say. The witness folds them, and the checks are ones a String could not carry: that offsets strictly increase (a repeated or backwards offset is a transcription error, not a reading) and that the sequence actually CONTAINS a transition. If a later edit flattened these rows to one repeated status, the observation would have silently become a snapshot while still being cited as a transition. REVIEW 63839, third finding: the digests had no consumer. A digest's real consumer re-reads the bytes and compares, which is an effect; the witness is pure and the producer that would do it is what mtcollins1_acquisition_standing declares absent. So they are a DECLARED FRONTIER under section 3c, not a silent dangle -- and the witness folds the frontier rows themselves, refusing one that names no consumer or no trigger, because a frontier row with an empty trigger is a dangling declaration wearing a label. The trigger names a capability, per 4b(3): a capture producer sufficient for every artifact this module declares, not one verifier pointed at one file. OPERATOR RULING: the three modelling-obligation rows are gone. Nothing consumed them; a data row no fold reads is a prose TODO wearing a type, and giving a TODO a struct makes it look discharged while changing nothing. They are lanes now. REVIEW 63877: the probe hand-transcribed all five digests and the 16-row population table beside the rows that own them -- "digests verified at time of writing" being the rot admission in the header. Both tables cite the symbols now. This was one level up from the class this PR itself files at subject_and_its_digest_as_independent_parameters. AND THE PURCHASING CLAIM WAS WRONG TWICE. It first read "10 x 1Rx4 + 6 x 2Rx8", taking widths off the installed modules and presenting them as constraints on the ones to buy. Operator review caught that; I then corrected it to "width is unresolved, nothing closes it". OCP Mt. Jade Table 3 closes it -- same-channel x4/x8 mixing is No, and same-channel density too. So the first answer was right by accident and the second wrong by being cautious for the right reason; neither was DERIVED, which is why neither could be trusted. The probe records the sequence and cites extdeps.ocp.mt_jade rather than reprinting its cells. Recorded beside it: that table's different-channel row is Yes everywhere except RANK, which reads TBD -- and this unit mixes 1R and 2R across channels today. The specification declines to affirm the configuration the machine is already running. Escalated, because a ~320-module order premised on "different channels are fine" rests on the one cell that does not say so. NOT EXECUTED LOCALLY AT THIS EXACT HEAD, stated plainly: the run before this one parsed and passed the witness with no refusal, and the delta since is the obligation removal (no importers, verified by grep) plus markdown. A full floor run is a CI job, and mine was thrashing at the container memory cap, so CI adjudicates this head rather than my box. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Account for every declaration the census module adds Review 63909 found eleven data rows with no consumer and no frontier row -- DESIGN section 3c's dangling declaration. Verified whole-tree: outside the module, the witness imported ten symbols and nothing else read the rest. The fix splits two ways rather than labelling everything, because a frontier row is an admission and handing one to a row whose check was available all along is the label standing in for the work. CONSUMED BY EXECUTION -- three new checks, each discriminating: the clean-EDAC flag must AGREE with the counters it summarises and must have a non-zero observation window. A zero-counter reading taken at zero uptime says nothing; the window is part of the observation, so a flag that disagreed with either now goes red instead of sitting beside them. the capture windows must actually distinguish the two attempts. The attempt-label defect row claims the artifacts are told apart by wall-clock window rather than by the duplicated attempt=3 label -- this makes that claim checkable rather than merely stated, and it goes red if the windows ever collapse while the row goes on asserting them. the one-of-sixteen discriminator must still exist. The whole connector identification rests on a part occurring EXACTLY ONCE agreeing with the pair table at the single position carrying it, which no shift or reversal of the sequence reproduces. If a later edit duplicated that part the argument collapses while its prose keeps claiming it, so the property is asserted against the rows and the upstream citation is bound rather than left prose. DECLARED FRONTIER -- rows whose consumer is an effect a pure witness cannot perform, each with a capability trigger: the artifact identity rows grouped together (path, byte count, digest, kernel -- a digest authenticates bytes and says nothing about WHICH file or HOW MANY bytes were expected); the boot delivery observation and attempt-3 failure, whose consumer is gunbc#11001; memtotal_kb, whose capacity join needs a catalog row for every installed part, one of which was missing and is in flight as gunbc#11066; and the EDAC channel map reason, which resolves against the Linux carrier in gunbc#11071. DELETED: mtcollins1_media_redirection_held_through_boot. An unconsumed Bool restating what the final sample already carries is one more dangling row. AND THE FRONTIER TEST CAUGHT ITSELF. It asserted the list had exactly four entries; the frontier grew to fourteen and it failed for no reason but a stale number. The literal is gone rather than bumped -- DESIGN section 5 names that shape, a merge-blocking test comparing a live population to a literal measured from the same tree, which collapses to measure() == measure() the moment you automate the update. What is load-bearing is that every row EARNS its admission, a property of the rows and not of how many there are. EXECUTED: the local witnesses lane ran this module and reported exactly one failure, that stale count; the other four new tests passed and the log names only failures. The delta since is `== 4` becoming `> 0` on an Int in a function that had already compiled and run, so CI adjudicates this head rather than another thirty-minute local floor run at the container memory cap. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Consume the Ampere authority instead of hand-writing its mapping Review 63939, and it found the most serious defect in this PR. THE MODULE CLAIMED TO CONSUME extdeps.ampere.mt_collins_product_brief.memory_population AND IMPORTED NOTHING FROM IT. The "consume" was a DeclarationRef carrying the module path as a string. Meanwhile every firmware binding hand-wrote a `connector` for its (processor_socket, memory_controller) -- which is exactly connector_used_at_one_dpc on mt_collins_channel_population_roles, a mapping that authority already DERIVES from the guide's pair and population tables rather than transcribing. A second copy of one fact, beside its authority and free to drift (DESIGN section 3, section 2). This module's own basis row says the J-number "is a join, not a reading". Hand-writing the result of that join was the error the sentence describes. THE CONNECTOR COLUMN IS GONE. Firmware DRAM training reports socket, controller and slot-within-channel; SMBIOS reports a locator. Neither reports a J-number. The census now carries only what was observed, and the join to a connector happens where it can be checked. AND THE CHECK THAT WAS SUPPOSED TO BE DISCRIMINATING WAS COMPARING STRINGS. The previous test asserted the basis's DeclarationRef carried the expected module_path and decl_name spellings. That proves a sentence names the right authority and stays green while the mapping it describes drifts arbitrarily -- DESIGN section 5's specification-without-execution wearing a struct. I wrote it one commit earlier AS the fix for a dangling-declaration finding, which is exactly how this shape survives: it looks like a check. The witness now folds the upstream rows. It counts (role, slot) pairs where the role covers the observed channel and the slot sits at the connector that role assigns, and requires exactly one -- asserting three cardinalities at once: the authority covers this channel exactly once, and one SMBIOS slot carries the module firmware reported there. Delete the import and the file stops compiling, which is the difference between consuming an authority and citing one. The string comparison survives only as an explicitly labelled coherence guard, carrying a note saying what it is not. NO SENTINEL, after two attempts at one. Folding the roles down to a connector needed an "unresolved" value, and Nat has no value outside J1..J32 to reserve; an Int sentinel failed to typecheck against the Nat field, and 0 would have been a value a later reader could mistake for an answer. The pair fold has no hole: an uncovered channel contributes no pair, so its count is zero and the test refuses, with nothing standing for absence. FILED, as DESIGN section 4b requires of a newly discovered class: upstream_non_affirmation_consumed_as_permission. An upstream that answers over a richer vocabulary than yes/no -- OCP Mt. Jade Table 3 answers Yes / No / Not Preferred / TBD -- consumed into a Bool carrier makes every non-prohibition read as permission. Its receipt is this lane: the different-channel row is TBD on rank mixing, this unit mixes 1R and 2R across channels, and a proposed derivation would have emitted that as a fill REQUIREMENT with nothing carrying the decline. The machine's own clean EDAC is the corroborating trap -- evidence that this specimen executes, not that the authority affirms it. EXECUTED: witnesses lane run locally. The corpus compiles, the census module is judged, and no census test fails. The two remaining refusals are the self_host_logic wet witnesses needing binaries this run did not build, and a namespace-wave-admission stale-admission count that is an artifact of a local run against a moved base -- CI has adjudicated that phase green on every pushed head of this branch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Resolve the unit's observations against the authorities that now exist #11066 and #11068 merged, so the receipt stops naming gaps and consumes them. Review 63974 asked for exactly this, plus review 63987's stale-citation fix. CATALOG RESOLUTION, WHICH CLOSES A HOLE THE CROSS-JOIN LEFT OPEN. The firmware vs SMBIOS join proves two LOCAL transcriptions agree; edit the same part number in both lists and it stays green. Now every observed module must resolve to exactly one SK hynix catalog row whose rank and chip width equal what firmware reported, and the population is asserted by catalog IDENTITY -- ten AFR4N, five AFR8N, one CJR8N, summing to sixteen. A substitution now has to survive contact with the manufacturer's own datasheet figures. THE FILL CONSEQUENCE IS DERIVED FROM THE SPECIFICATION, NOT READ OFF THE SAMPLE. Each empty partner's rank, width and density are fixed by its channel peer BECAUSE OCP Mt. Jade prints same-channel rank, x4/x8 and density mixing as NotSupported. If a later revision relaxed a cell, the test goes red and the requirement stops being determined -- rather than a stale requirement quietly surviving the rule that justified it. THE FOUR STATES ARE CARRIED WHOLE, not collapsed to a Bool on the way through. mtcollins1_cross_channel_rank_mixing_standing records that the specification answers MixingUndetermined -- its TBD -- for the cross-channel rank mixing THIS UNIT ALREADY RUNS, and a control asserts it is still undetermined so a later revision resolving that cell goes red instead of being absorbed. That is the class filed at upstream_non_affirmation_consumed_as_permission. STALE CLAIMS CORRECTED: the receipt no longer says CJR8N is uncatalogued or the rank rule unmodelled, and review 63987 caught an annotation naming the_observed_channels_carry_the_connectors_ampere_assigns_them -- a symbol I renamed during the sentinel restructure, in the one comment whose job is to stop the weak check being mistaken for the strong one. It now names both real folds. I swept every long identifier in both files' comments against the declarations; no other citation is stale. FLEET CONCLUSIONS NARROWED TO UNIT SCOPE. This document may establish this machine's population and the compatibility consequences that follow from cited rules. It may not establish a twenty-unit roster, a ~320-module order, or a fleet-wide DDR rate for machines nobody has looked at. The reasoning was sound at unit scope and the scope was wrong, so it is narrowed rather than deleted. WHAT I COULD NOT EXECUTE LOCALLY, STATED PLAINLY BECAUSE IT CHANGES WHAT THIS COMMIT'S EVIDENCE IS WORTH. The module parses, typechecks and is judged, and two parse defects were found and fixed by running it -- a `data =` followed by a newline before `match`, and comma-separated match arms this language does not use. But the floor refuses before the claim-evaluation-fold on three modules this branch does not touch (vacuity_consumer_witness_long_test, fleet_posix_accounts, lens/enforcement/contract, all "missing required field"), so NO claim in this corpus evaluates locally, mine included. I proved that rather than assuming it: I broke the catalog-identity assertion to 11 and it did NOT go red, which is the signal that the check never ran. An earlier message in this session reported those tests green on the strength of no failure being NAMED -- that was wrong, and a module that never reaches the fold produces exactly the same silence as one that passes. CI reaches the fold and has been green on every pushed head of this branch, so CI is the executing evidence for these assertions, not my box. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Type the prose rows out of the receipt, and fix a real call-shape defect Review 64056, three findings, all the same class and all correct -- they cite this module's own argument against itself, since it deletes three rows one screen below for exactly this reason. mtcollins1_edac_channel_map_unavailable_reason: a six-hundred-character English paragraph in a String that no fold read, whose own frontier row conceded its home was elsewhere. DELETED. The rationale stays in the // channel, the typed readings it described were always carried separately by mtcollins1_edac_topology, and the mechanism lands as extdeps.linux.edac in gunbc#11071. Its frontier entry went with it -- a frontier naming a declaration that no longer exists is a stale citation, not an admission. mtcollins1_host_capture_attempt_label_defect: same shape, and its only consumer asserted the sentence was non-empty. That is DESIGN section 3c's own listed tell -- a witness that asserts a declaration exists rather than exercising it -- and I wrote it while addressing a dangling-declaration finding. DELETED, with the vacuous conjunct. The checkable content survives where it was already executed: the two captures carry different digests and different timestamps, and the_capture_windows_actually_distinguish_the_attempts asserts the ordering that makes the wall-clock window a real discriminator. MtCollins1BootDeliveryObservation: NOT deleted, because it records a real control, but its four prose fields were two observations and two CLAIMS written as paragraphs. The axes are typed now -- valid flag, EFI-versus-legacy on the failing and succeeding attempts, persistence held constant, model-reported- completed -- and two folds read them: one asserts the experiment had exactly one varied term, so flattening the two boot-type readings kills the control instead of leaving the prose standing; the other records that the model called every failed attempt complete, and is a control that SHOULD flip when gunbc#11001 lands. The device selector stays an exact quotation of the ipmitool rendering, which is evidence rather than commentary, and the SELECTION is deliberately not typed here because that carrier lands in #11001 and a second one would be the section 3 fork. AND A REAL DEFECT CI CAUGHT THAT I HAD NOT: bit_width_count takes `b`, and I called it with `w`, four times, in the catalog-agreement fold added by the previous commit. floor_class=structural, not infra -- my diff, my defect. Fixed, and I audited every other std.measure call site in the file against its declaration: byte_size_count(b:), second_count(s:), hardware_thread_count_value(t:) are all correct. That defect is the concrete cost of the gap reported in the previous commit: the local floor refuses before the claim fold on three modules this branch does not touch, so a call-shape error in a witness reaches CI before it reaches me. CI is the executing authority here and it did its job. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Derive the EDAC absence from the Linux authority now that it exists gunbc#11071 merged, so review 63974's deferred item comes due: the receipt stops describing the GHES/APEI mechanism and consumes extdeps.linux.edac. The observation contributes exactly one fact -- mtcollins1_edac_topology now carries driver_binding: GhesEdac, a typed binding rather than only the string /sys rendered -- and the authority supplies what follows. The string spelling stays beside it because a reader resolving this receipt against the committed capture needs the bytes they will actually find there. WHAT THAT BUYS, AND IT IS THE POINT RATHER THAN TIDINESS. This module used to assert in a String row that re-booting would not produce a channel map. That sentence was true and unfalsifiable where it sat. It is now DERIVED: edac_channel_topology_availability(GhesEdac) yields ChannelTopologyAbsent with cause FirmwareFirstErrorAttributionShim, whose absence standing is AbsentOnEveryBoot. The distinction between "no channel map here" and "no channel map, and another boot will not change that" is what justified recovering the map from firmware DRAM training instead -- so the justification for this census's central method is now a consequence of a cited kernel authority rather than of my confidence. A second fold requires the MEASURED tree to agree with what the authority predicts: zero csrow nodes is the EXPECTED reading under the shim, not an anomaly, and sixteen DIMM nodes is what it mirrors from SMBIOS Type 17. A future capture on this platform finding a populated csrow tree would put observation and authority in conflict and turn this red, which is the only way either of them gets to be wrong out loud. Call shapes checked against the declarations before pushing this time -- edac_channel_topology_availability(binding:) and edac_channel_topology_absence_standing(cause:) -- which is the check that would have caught the bit_width_count defect CI found in the previous commit. Also merges origin/main, which carries #11071's move of LinuxKernelRelease into extdeps.linux.kernel. Landing after that PR was the ordering deep-raven-831 and I agreed on, so the brand is authored in my base rather than met at the button. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Inhabit HostMemoryPopulation, and stop the receipt contradicting itself Review 64092, three findings, all correct. A FALSE FRONTIER. mtcollins1_memtotal_kb carried a declared frontier saying its capacity join needed a catalog row for every installed part and that CJR8N "had none", naming gunbc#11066 as in flight. That row is on main and this PR's own witness joins all three catalog identities. A frontier inventing an absent authority while the same change proves it present is a false wall -- DESIGN section 3c admits a frontier only with a trigger, and section 5 forbids fabricated plausible output. Removed, and DISCHARGED: the join it named is now written. THE SAME CONTRADICTION AS PROSE. One section derived same-channel rank, width and density from mt_jade_mixed_dimm_support; the next still asserted the OCP rule was "carried by no authority in this corpus" and that "chip width is not closed at all". Both were true when written and false once gunbc#11068 landed. A receipt that consumes a rule and denies it exists is a meaning fork. The paragraph now records what the authority settles, and says plainly how the contradiction got there: the model was fixed in layers and the prose around the edit was not re-read. The probe carried the same stale sentence and is corrected in the past tense rather than deleted, because the distinction it drew -- between what a machine HAS and what it NEEDS -- is the reason the census was worth doing. HostMemoryPopulation IS NOW INHABITED, which is what this census was for. mtcollins1 could not use the carrier every other fleet host uses while one of its three installed parts had no catalog row to point at. It now carries ten AFR4N, five AFR8N and one CJR8N as MemoryPopulationRows joined to catalog identities rather than to part-number spellings. AND THE CAPACITY JOIN THE FRONTIER NAMED IS THE CONSUMER. It respects the split gunbc.fleet.fleet_intent warns about rather than papering over it: the population states what is INSTALLED, MemTotal states what the kernel finds USABLE after reservations, and they are different facts. So the test asserts the RELATIONSHIP -- usable strictly below nominal, and within a few percent of it -- never equality. Measured here: 249.95 GiB usable against 256 GiB nominal, 97.64 percent. A population claiming eight sticks would put usable ABOVE nominal and go red; one far below would mean sticks are installed the firmware is not presenting. Both are real failure shapes for a census that decides a purchase. Call shapes checked against their declarations before pushing (host_memory_population_nominal_bytes(pop:), kibibyte_to_byte_size(k:)), and the arithmetic was evaluated rather than assumed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Preregister the spare-module screen; carry the Mt. Jade outcome whole TWO CHANGES IN ONE COMMIT, and the message says so because an earlier draft of it described only the first while `git add -A` had swept in the second. A commit message that does not describe its own contents is the same defect as a receipt that does not describe its own artifact. 1. THE PREREGISTERED PREDICTION, committed before the operator touches the hardware. Tonight's 32-DIMM adversarial test was predicted in conversation only, with no immutable pre-outcome receipt; proud-otter-590 correctly refused to let a row authored afterwards be called preregistration. This is the first one done properly -- configuration, basis, falsifier, and what each outcome earns. It also states the test's weakness in advance: sixteen modules change at once, so a failure localizes to nothing. A screen, not a diagnosis. 2. REVIEW 64125 -- THE MT. JADE LOOKUP OUTCOME IS NO LONGER COLLAPSED. This module is extdeps.ocp.mt_jade.memory_mixing's FIRST consumer and it performed exactly the substitution that module was built to prevent: mtcollins1_mixing_verdict mapped MixedDimmSupportUnmodelled and MixedDimmSupportAmbiguous onto MixingUndetermined. The upstream made its lookup total-with-refusal to stop that, and says in its own annotation that a manufactured MixingUndetermined is the worst of the three substitutions available -- the table really does print TBD, so a fabricated one is indistinguishable from a cited one. The harm was concrete. mtcollins1_cross_channel_rank_mixing_standing records the specification declining to affirm the cross-channel rank mix this unit runs, and its witness is a control documented as one that SHOULD flip. Collapsed, it could not flip: a row gone MISSING or turned AMBIGUOUS would arrive as MixingUndetermined and the test would stay green while its subject had disappeared. One spelling carrying both "the specification declines to state" and "this corpus has no row" is section 3's meaning fork and section 5's widening failure arm. Fixed by not folding. The outcome is carried whole; the witness handles the refusal arms as distinct constructors; the control now requires the lookup to RESOLVE and read MixingUndetermined, so a missing or duplicated row turns it red. It is also the class I filed today, one turn further in: upstream_non_affirmation_consumed_as_permission covers a non-affirmation read as permission, and here an ABSENCE was read as a non-affirmation. I wrote the row warning about the pattern and committed its next variant within hours. EXECUTED: parses and typechecks with no .dag errors; the only local failures are the self_host_logic wet witnesses needing binaries this run did not build. Claim evaluation does not happen locally on this checkout, so CI remains the executing authority for the assertions. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Preregister round 1 of the spare bisection: the 2DRx4 group Twelve known-good originals plus the four 2DRx4 spares -- the group whose part notation this corpus cannot identify. Prediction: FAILS. Confidence stated as low, because it is a guess among three roughly equal candidates and being wrong should cost something. Carries forward the standing disjunction proud-otter-590 insisted on: the prior falsification established that shape alone is not sufficient, NOT that supported shape is necessary, and NOT that a module is faulty rather than a combination untolerated. No round may name a bad module until one is isolated AND reproduces alone -- which matters physically, since the wrong framing gets a good stick binned. Records the operator's srvN prior for the 1Rx4 group as held-but-untested rather than assumed, so a later round falsifying it displaces something visible. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Preregister round 2: swap the 2DRx4 group to socket 0 Round 1 put the four 2DRx4 modules entirely in socket 1 and the OEM payload came back 0fde703b1102 -- the first 3b of the session against nineteen 33s. Under the candidate schema that is the socket bit, and it tracked a variable we controlled. This round exchanges the sides. The prediction is a CONJUNCTION -- that it fails, and that the payload reports 33 -- so both halves can fail independently, which is the point. A 3b result would falsify the module-following reading; a clean train would mean an interaction neither simple reading captures. States plainly what no outcome earns: four modules move together, so nothing here names one, and a module untolerated by this platform is indistinguishable from a broken one. The schema stays a hypothesis and may not name a DIMM. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Score the socket-swap prediction: matched, and record what it did not earn Prediction cd83f731921 matched on both halves -- it failed, and the payload reported 33 rather than 3b, so the socket field followed the quartet. But the decision table I wrote for it was too strong and this file says so: a configuration restriction violated wherever that quartet sits predicts the same outcome as a defective member, so the crossover separates neither. The companions changed too, so the round did not isolate the socket at all -- the experimental unit for that comparison is the complete eight-module population. Eliminates the best alternative hypothesis: all modules are 16 GB, so Ampere's per-socket equal-capacity rule is satisfied and explains none of the failures. Retracts two narration errors: 0 W memory power does not distinguish early failure from timeout, and the three-outcome table was neither exhaustive nor equiprobable. Records what the decoder earned -- two controlled confirmations of ONE field -- and that stage, status and tail have no such support and may not name a DIMM. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Record what six configurations eliminated, and two retractions Written so the next session does not re-derive tonight's eliminations. Carries the seven tested populations with outcomes, what each ruled out, and the three hypotheses still standing. Two retractions recorded rather than quietly dropped: DDR4-2133 being unsupported on Altra (srv1/3/4 run 2133 Samsung parts and POST cleanly, so the SoC supports it), and any speed conclusion drawn from the eBay listing, which says 2Rx4 where the label says 2DRx4 -- a source wrong about one field is not evidence about a neighbouring one. Also carries the srv2 precedent: identical Samsung parts trained on three hosts and failed training on the fourth. Same class as tonight, already in the corpus, and recorded in the same module that carries the purchasing fail-open. Bounds the OEM decoder honestly: one field, two controlled confirmations, tail unchanged across the socket swap. May not name a DIMM. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Demote the socket-field reading from deduced to inferred Review 64195: 'the socket therefore lives in byte 3' exceeds the experiment. Correct -- and it is the same error the same document warns about four paragraphs lower, where it records that the companion modules moved with the quartet. If the companions changed too, the bit may be tracking any property that moved with the intervention: a restriction carried by the group, a channel-group index, a first-failing-controller identity. Both documents now separate what was OBSERVED (byte 3 changed between rounds, the tail did not) from what is INFERRED (that the bit encodes the socket), and say explicitly that two consistent crossovers support the reading without establishing it. DESIGN section 4d: do not assert as deduced what is only inferred. The reviewer's closing point is the one that matters -- this was on its way to becoming the next session's premise, which is how a hypothesis becomes a fact without anyone deciding to promote it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Preregister round 3: the 2Rx4 Micron group in socket 0 Directly comparable to round 2 -- same shape, same socket, only the substituted quartet differs. Prediction: fails. Confidence moderate-low, since no test has ever isolated this group and a falsification would be sharper than a confirmation. Records a fourth outcome the earlier tables missed: a DIFFERENT tail value would be the tail's first variation under a module-only change, since 1102 held across the all-spares round and both 2DRx4 positions. Worth watching for rather than discovering afterwards. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Score round 3: FALSIFIED -- the 2Rx4 group trains 6m13s no restart, memory power 10.4/9.6 W on both sockets, matching the one configuration that trained rather than the seven that failed. …

…carriers (collectors-before-actuation, silence-is-not-a-terminal, opaque-OEM-stays-opaque) (#11110) * The channel map is in the boot firmware, not in EDAC Mt. Collins unit 1 booted a Linux that ran ON the machine and its memory census is committed as bytes: nproc 160, dmidecode type 16/17 for all 32 connectors, the whole EDAC tree, and dmesg. The receipt states nothing the two artifacts do not contain. THE BRIEF EXPECTED EDAC TO CARRY THE CHANNEL MAP AND IT DOES NOT, which is the load-bearing result rather than a gap to chase again. This platform runs ACPI APEI firmware-first ("GHES: APEI firmware first mode is enabled by APEI bit"), so ghes_edac registers ONE synthetic controller and mirrors the SMBIOS device list purely so a GHES error record has a DIMM to name. It is an error-reporting shim, not a topology driver: `find /sys/devices/system/edac` returns no path containing "csrow" — a counted reading over an enumerated tree, not an inference from a driver name. No boot will change that, so the reason is recorded with the negative. The channel-resolved reading comes from the Altra boot firmware's DRAM training output instead, which is strictly richer than a csrow tree: it names socket, memory controller AND slot-within-channel. All sixteen modules sit at S0 of their channel, so the unit is uniformly 1DPC and the sixteen empty connectors are each channel's S1. Connector numbers are a JOIN and are declared as one — neither reading prints a J-number. What discriminates it: HMA82GR7CJR8N-VK occurs exactly ONCE in the machine; firmware puts it at SK0 MC5, SMBIOS at "DIMM 11", and the Getting Started Guide's pair table puts MCU5's 1DPC member at J11. No shift or reversal of the sequence reproduces that. SMBIOS's own Rank column reproduces the firmware's 1R/2R sequence independently, and the populated set is exactly the odd connectors, which upstream specifies. The upstream pair table is consumed from extdeps.ampere.mt_collins_product_brief.memory_population, not re-transcribed. EDAC is clean at capture: mc0 and all 32 per-DIMM counters read zero. That is recorded as clean AT CAPTURE on a host up ~20s — the memtest pass is the endurance evidence and this is the structural one; calling it more would be rung inflation. The witness test consumes the rows so they are not dangling, and its main check is adversarial: firmware and SMBIOS are two independent readings, so if either transcription drifts, the part number or rank at some connector stops agreeing and it goes red. The EDAC probe is enrolled as a control that is SUPPOSED to fail the day a native Altra driver exposes a real topology. Two modelling obligations are named and deliberately NOT satisfied here: HMA82GR7CJR8N-VK has no catalog row (minting one from our own boot log would render a local report as an upstream fact), and the same-channel rank-mixing rule is absent from extdeps.ocp.mt_jade, so the per-connector fill requirement is not authored as though it were derived. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * chip_width is BitWidth, and the failed attempt keeps its bytes Review 63222 is right: chip_width_bits: Nat was a second name for a concept std.measure already owns. dag/std/measure.dag defines BitWidth and bit_width, and the memory home already carries this exact fact as chip_width: BitWidth (extdeps.memory.types DramModuleCatalogRow, constructed with bit_width in extdeps.memory.sk_hynix). Minting a flat scalar beside it is the DESIGN section 3 nickname and the section 2 re-invention in one field. The field is now chip_width: BitWidth, built with bit_width(4) / bit_width(8), matching the catalog's spelling so the two join on a name as well as a meaning. ALSO PRESERVED: attempt 3, which failed. It was built to close the subject-binding gap and add a named memory workload with before/after EDAC counters. The kernel loaded from the virtual CD and panicked — "VFS: Unable to mount root fs on unknown-block(0,0)" — because the MegaRAC remote-media session dropped between kernel load and root mount; the controller read redirection_status 100 immediately before the reset and 1 after. Its bytes are committed anyway, because a failed probe is exactly as easy to lose as a successful one and this census exists to end that class. The pre-boot srv2-side observation stands on its own regardless: an ARP reading with a typed verdict against the expected MAC, plus the boot artifact's digest. AND A GAP IS NOW STATED RATHER THAN RELIED ON. The capture binds to the board MODEL (kernel DMI: FOXCONN Mt. Collins/Mt. Collins) and NOT to this physical unit — SMBIOS Type 1/2/3 was not captured, so board serial 02030A800TEXFT02L appears nowhere in the bytes. What ties the capture to unit 1 is the delivery path, which is author-held provenance rather than a fact a reader can check inside the artifact. Dissolved by one dmidecode --type 2 in a future attempt. There is no attempt 5: re-establishing the media degraded further (stop-media and start-media both HTTP 500, never returning to 100). That controller is the only out-of-band path to the M1 canary, so the run was stopped rather than driven harder, the boot override cleared to "No override", and the controller left verified healthy over IPMI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * The host was asked to legacy-boot a CD on aarch64, and the model called it success THE CENSUS IS COMPLETE. Both gaps this receipt declared open are closed by a second capture, artifacts/bmc/mtcollins1-host-capture.txt, 270880 bytes, sha256 a9b880c3ecd9ba611c1df9e7de1ab089839c5d8e92b743bf2e1bcd684100fd2a, whose nineteen sections each carry their argv and exit status so a missing reading is distinguishable from a zero one. All nineteen exited 0. THE UNIT BINDING IS NOW AN EQUALITY BETWEEN TWO INDEPENDENT READS, not a stronger assertion of one. The host reads board serial 02030A800TEXFT02L from its own SMBIOS Type 2 under Linux; mtcollins1_access_observation reads the same serial from the controller's IPMI FRU, different transport, different agent, days earlier. Either alone is an observation of a reading; the two agreeing is an observation of a unit. EDAC IS LOAD-BACKED RATHER THAN A SNAPSHOT. 64 GiB of tmpfs seeded from urandom, hashed twice and the passes compared, with the EDAC tree read on both sides: all 34 counters 0 before and 0 after. The digest comparison is there because EDAC counters are the memory controller's own account of itself -- if it fails to notice a fault its counters stay zero -- so hashing tests the DATA rather than the controller's opinion of it. It still is not a soak, and the row says so. AND THE REASON THIS TOOK FIVE ATTEMPTS IS A FIELD THE BOOT-HANDOFF MODEL DOES NOT CARRY. IPMI boot parameter 5 encodes two decisions: the device selector AND the BIOS boot type (byte 1 bit 5, 0 = legacy, 1 = EFI). oob_boot_handoff and mtcollins1_actuate model the selector alone -- efiboot, boot_type and legacy appear nowhere in that path -- so every handoff requests the default, which reads back "BIOS PC Compatible (legacy) boot". aarch64 has no legacy boot path, so the request is unsatisfiable and the firmware falls through to PXE and then the UEFI shell. Measured fix: options=efiboot,persistent reads back "BIOS EFI boot" and the next reset booted the image. THE DEEPER DEFECT IS THAT THE MODEL REPORTED SUCCESS THROUGHOUT. oob_boot_handoff mints BootHandoffCompleted once the override reads back as expected and the power action is accepted. Both held on every failed attempt -- the selector really did say "Force Boot from CD/DVD" and the reset really was accepted -- so a handoff that provably booted nothing is indistinguishable in the model from one that did. That is DESIGN section 5's specification-without-execution, and it is why a legacy/EFI mismatch could persist across an entire intake lane. Fixing the argv without fixing the postcondition would close this instance and leave the class, so both are recorded here and neither is fixed in this commit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * The 100 to 1 transition was the redirection succeeding, and I called it a drop A review on 68f91df caught two claims in this receipt that the evidence does not support. Both are corrected here rather than quietly edited, because the wrong text was load-bearing for an investigation that ran for hours. THE MEDIA-DROP MISCLASSIFICATION. The attempt-3 row said the remote-media session "dropped out from under casper between loading the kernel and mounting the squashfs root". The committed console refutes it directly: GNU GRUB / EFI stub: Booting Linux Kernel EFI stub: ERROR: Failed to load initrd: 0x8000000000000001 VFS: Unable to mount root fs on unknown-block(0,0) The firmware DID select the medium, GRUB DID run off it, the kernel DID start. What failed is the INITRD load, with EFI_LOAD_ERROR. A medium that had vanished could not have served GRUB and a kernel first. The row now states the initrd failure as what is established, and the partly-ready-medium reading as plausible and unproven -- the attempt reset while the redirection was still at 100. AND THE REASON THAT MISREADING WAS POSSIBLE now has its own row. redirection_status was treated as a health value where nonzero meant trouble. The controller's own served frontend says otherwise: 1 renders "Started - Connection Accepted" and is the healthy steady state, 100 is connecting, and 2 through 5 are Connection Denied, Login Failed, MAX Session Reached and Permission Denied. Measured against the live controller, attach goes 100 (session_index 255) -> 100 (session_index 0, +12s) -> 1 (+15s) and then HELD at 1 for 4m27s idle and through a full boot. 1 is the destination, not a decay. The consequence generalises past this unit and is why the row exists: a "nonzero means attached" predicate admits 100, which is merely CONNECTING, and admits 2-5, which are refusals. Only 1 may satisfy media-ready. A predicate that resets a host on 100 can expose a partly-ready medium to firmware reads, which is the plausible reading of the attempt-3 initrd failure above. This commit does not touch the boot-handoff or media modules. The typed producer, the IpmiBootSelection cut and the readiness predicate are being recut elsewhere; this only stops THIS receipt from asserting things its own artifacts contradict. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Two receipt-integrity defects: a timestamp the artifact contradicts, and one attempt identity for two attempts Both caught in review against 45ffaef, both verified against the committed bytes before being accepted, both mine. THE TIMESTAMP WAS WRONG BY NEARLY FOUR DAYS. mtcollins1_host_capture_observed_at read 1789428410000, which is 2026-09-14T23:26:50Z. The artifact's own first line says "attempt=3 begin 2026-09-11T01:26:50Z". The correct value is 1789090010000. This is the one error class this module cannot carry, because its entire claim is that it states nothing the artifact does not contain. A digest proves the bytes are unaltered; it proves nothing about whether the fields around it were read out of those bytes. A reader checking the digest would have found it correct and the timestamp still false, which is exactly the gap that makes a hand-transcribed receipt weaker than a generated one -- and is the argument for the modeled producer this lane has been asked for twice. AND "attempt=3" NAMES TWO DIFFERENT ATTEMPTS. The successful capture's header reads attempt=3; so does the FAILED run at mtcollins1_attempt3_failure, whose artifact is mtcollins1-attempt3-sol.log. One produced no host capture at all and one produced these bytes, minutes apart, under one identity. The cause is that the capture script hard-codes its attempt number, so a rerun re-uses the identity instead of minting a new one. The artifact FILE was correctly never overwritten -- the earlier directive's rule -- but the identity inside it was, which is the same failure one level down. An attempt identity a rerun can silently duplicate is not an identity, and any receipt join keyed on it would merge a failure with a success. THE BYTES ARE NOT EDITED. Rewriting a capture to correct its own label would destroy the property that makes it evidence. So the label is recorded as unreliable, the distinguishing facts are carried in the model instead -- different artifact, different digest, different wall-clock window, different outcome -- and the producer's literal is named as the thing to remove. Neither fix makes the producer reproducible; that is still the open item and it is being recut elsewhere. This only stops the receipt asserting what its own artifacts refute. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * The enum belongs to firmware 0.32, and efiboot,persistent proved one axis of two Three scoping corrections from the review amendment, all of them narrowing claims this receipt was making wider than its evidence. THE STATE MACHINE IS KEYED TO ONE FIRMWARE BUILD NOW. It was read from the frontend served by THIS controller at revision 0.32, and the row said only "the controller's own served frontend", which reads as a MegaRAC fact. It is not one. Nothing here establishes that any other release uses the same numbers, so the row names the build and says that an uncatalogued firmware identity must refuse rather than borrow the nearest profile. Inheriting a status enum across firmware would be the same failure that produced this row: a plausible-looking value read as its opposite. AND THE ROW NO LONGER IMPLIES A CLOSED RANGE. Carrying first_refusal 2 and last_refusal 5 invites a consumer to treat 2..5 as the refusals and everything else as fine. The vendor renders any value outside {0,1,100} as Stopped, so unknown codes are neither pending nor success. This row does not enumerate them and now says so: a consumer needs an explicit other-code arm, not a default. THE efiboot CONTROL PROVED THE EFI AXIS AND NOT PERSISTENCE. persistence was held constant across the failing and succeeding probes, so the varied term is the one implicated; options=efiboot,persistent is simply what executed. It is not the intake policy, because persistent changes ALL FUTURE BOOTS, and I used it for convenience on a machine that is not mine to leave reconfigured. ipmitool sets the valid bit itself, so the one-shot projection is options=efiboot alone. A one-shot EFI wet run is still owed, and if this firmware turns out to require persistence that must be an explicit persistent-until-restored fact with the clear and the readback in one transaction -- never a persistent write described as one-shot. None of this is the migration. The typed IpmiBootSelection, the readiness predicate over the decoded status, the serialized StartMedia body and the split of control issuance from image execution are being recut elsewhere and this commit deliberately does not anticipate them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Probe record: the census, the boot-delivery defect, and the errors that cost the night One document for the whole session, written because the operator asked to understand this path end to end and will run nineteen more of these machines. It carries the census result and both purchasing conclusions; the channel map and why EDAC cannot supply it on an APEI firmware-first platform; the J-slot join with the single-occurrence part that discriminates it; the unit binding as an equality between host SMBIOS and controller FRU; the load-backed EDAC reading and the explicit statement that it is not a soak. It carries the boot-delivery root cause -- IPMI boot parameter 5 encodes device AND boot type, the model carries only device, and legacy-on-aarch64 is unsatisfiable -- together with the deeper defect that let it hide: BootHandoffCompleted minted from an override readback and an accepted power command, never from evidence that anything booted. And it separates the two failure modes rather than letting the EFI axis explain an attempt that reached GRUB and died on its initrd. It carries the firmware 0.32 media state machine read from the controller's own frontend, keyed to that build, with the transient that a naive bounded poll would refuse, and the measured fact that HTTP 500 on media/general means both applied and not applied so only a readback is a verdict. AND IT CARRIES A NUMBERED LIST OF MY OWN ERRORS, which is most of why it exists. Reading redirection_status 1 as death when the vendor renders it Started, and escalating a decay clock that was really connect time. Reading a flag byte as a session count and reporting one-boot-per-reset as fleet knowledge. Overclaiming the root cause. A timestamp wrong by four days behind a correct digest. One attempt identity for two attempts. The password in argv. Persistent left on a machine that was not mine to reconfigure. And the framing one: I never built the modelled capture producer that was asked for in the first directive, which is the standing objection on #10965 and is fair. A probe record, not an authority. Every number was re-derived while writing rather than recalled, and inference is marked as inference throughout. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Recut to evidence only: the decoder, the policy and the prescription leave this receipt Acting on the strip-or-park ruling. #10965 becomes the evidence landing; the boot-path migration consumes it from a separate PR. One new commit on the existing branch -- the execution-history commits are NOT rewritten or rebased away, because the sequence of wrong turns is part of what the artifacts document. WHAT LEAVES, AND WHY EACH WAS NOT MINE TO HOLD: The media state machine is gone entirely, not refined. A mapping from vendor status codes to meanings plus a rule about which permits a reset is a firmware-keyed extdeps.bmc.megarac catalog and a caller policy on top of it -- neither is an observation of this unit, and holding them here would make a unit receipt a second authority the moment the migration lands. It also had prose provenance: it was read from a source.min.js that is NOT a committed artifact, and a sentence naming the file it came from is not a resolvable receipt. What survives is the measured transition alone, with no readiness conclusion drawn from it. The boot-delivery row keeps its observations and loses its prescription. It no longer tells a reader which argv to use, what the one-shot projection is, or what to do if the firmware demands persistence. It records what the flags read on the failing and succeeding attempts, that the control varied the boot-type bit alone, and that the model returned BootHandoffCompleted throughout. THREE RESIDUES FROM THE LAST ROUND, ALL CONFIRMED BEFORE FIXING: first_refusal and last_refusal were still declared and still set to 2 and 5. The previous commit changed the prose warning against that inference and left the fields that support it, which is worse than not having claimed the fix. Gone with the type. The "session never returned to redirection_status 100" reading survived in two places and is still backward. Replaced with the measured result: both calls answered 500 and the readback was unchanged, so neither transition was established as applied and the HTTP status decided nothing. The header claimed every field came from two files. That stopped being true when the module gained a second capture and later observations, and a global claim gone quietly false is worse than none -- a reader would verify both digests, find them correct, and still be reading fields those files never contained. Evidence now binds per section. AND THE ACQUISITION IS MARKED HONESTLY. HistoricalAdHocCapture with reusable_producer_absent. Every capture here was produced by hand; one successful manual capture is not evidence the intake system can take another. hw-first-host may read the observations, because its clause asks whether this unit passed named facts. Nothing may read them as proof of a reusable capability. THE WITNESS NOW READS WHAT IT USED TO IGNORE: subject binding, the workload, the before/after counters, their agreement with the topology row, and the acquisition standing -- the last as a control that SHOULD go red the day a producer exists. The earlier witness checked slot rows and nothing else, which is precisely how a four-day-wrong timestamp landed green. It still cannot recompute a digest, and says so: a pure witness has no file access, so a hand-transcribed digest stays unverifiable. That gap does not close with a better test. It closes when a producer GENERATES the receipt from the artifact. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Redact a published BMC credential, finish the strip in the probe doc, file the two failure modes CREDENTIAL FIRST, BECAUSE IT IS THE ONLY ITEM HERE THAT IS URGENT. Review found artifacts/bmc/mtcollins1-attempt3-srv2-side.txt recording the BMC password LITERALLY in ipmitool argv on two ----ARGV lines, in a PUBLIC repository. Verified: two occurrences, no others anywhere under artifacts/. Those bytes are redacted. Everywhere else this module insists captured bytes are never edited, because editing a capture destroys what makes it evidence -- this is the one exception and it is not a judgement call: a live credential in public outranks byte fidelity. The file carries a header saying it was redacted, nothing else is altered, and BOTH digests are declared in the receipt (e7673b74... -> 90e6f289..., 1669 -> 1989 bytes) so the edit is auditable rather than a silent disagreement with a receipt written earlier. THE REDACTION DOES NOT UNDO THE PUBLICATION, and the receipt says so. The unredacted bytes reached a public PR branch, so the credential is DISCLOSED. It is the factory default on a routable BMC; rotating it is the operator-attended BmcSecure step and is not this lane's to perform. The producer defect that caused it is that every ad-hoc ipmitool call in this session passed -P on the command line -- the modelled route already uses -f with a password file, and the migration's producer must too. THE STRIP WAS INCOMPLETE AND I HAD REPORTED IT DONE. The .dag carrier was observation-only, but docs/probes/ still reconstructed the whole MegaRAC state machine from an UNCOMMITTED source.min.js, derived the readiness rule, and closed with a normative operating procedure. A probe record whose header claims every number is artifact-backed cannot carry a table whose source was never preserved. Both are gone; the measured attach transition stays, with no readiness conclusion drawn from it, and the closing section now states what the record does NOT prescribe. The artifact table's stale digest for the redacted file is corrected and the redaction disclosed there too. FAILURE MODES, per the dispositions given. (a) ACCEPTED and filed: control_plane_acknowledgement_minted_as_effect. An accepted command, a desired-state readback or an actuator acknowledgement cannot construct a terminal effect on the acted-upon subject. The Mt. Collins instance is the receipt: BootHandoffCompleted minted from selector-readback plus accepted power action, both of which genuinely held on every failed attempt while the host booted nothing. The repair is a split -- BootControlIssued from control-plane facts, the subject-level terminal requiring host-originating observation -- not a stronger check. (b) NOT a new identity. subject_and_its_digest_as_independent_parameters already owns it: its scope is a value beside a summary with no structural join, its recognition rule already says proximity to a correct thing is not correctness, and its fabric-M0 specimen already covers a correct digest beside a lying provenance stamp. Minting integrity_mistaken_for_provenance would fork an owned meaning. The four-days-wrong timestamp behind a correct digest is appended as a SPECIMEN of that row, with the sharp form of the lesson: a correct SHA-256 authenticates those bytes, not adjacent metadata about those bytes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Revert the redaction: admin/admin is a published upstream fact, not this unit's secret Operator ruling, and it is correct. I redacted `-P admin` from a committed capture after review called it a credential published to a public repo. That was wrong. admin/admin is not a secret belonging to this unit. It is AMI's published MegaRAC factory default, and this repository already models it as an upstream fact: extdeps.bmc.megarac megarac_factory_login carries username "admin" and published_password "admin" -- the field is NAMED published_password because the value is public, and its comment says so explicitly. The artifact disclosed nothing the corpus does not already state by design. So the redaction protected nothing and cost the one property that makes a capture evidence. The file is restored byte-for-byte, 1669 bytes, digest e7673b74a9361453440364334d9223706284dc25d66c9f5bde1230c2ec5720ad -- verified identical to the pre-redaction bytes, not merely similar. The receipt and the probe document now carry the RETENTION BASIS instead of a redaction notice, which is also what the review asked for as the alternative: evidence policy explicitly permitting the retained value. THE RULE THIS SETTLES, because the next reviewer will ask the same question: a credential in a capture is redactable only when it is a SECRET. A value the corpus already publishes as an upstream fact is not made secret by appearing in argv, and an artifact is not improved by editing it into disagreement with extdeps. WHAT IS STILL A REAL DEFECT, and it is the producer rather than the bytes: every ad-hoc call in this session passed -P on the command line while the modelled route already uses -f with a password file. That belongs in the producer and is not a reason to rewrite captures after the fact. AND WHAT WOULD CHANGE THE ANSWER, recorded so this is not read as licence: if this unit's credential is ever rotated off the published default, the rotated value IS a secret, must never reach argv, and any capture containing it is genuinely unpublishable. That is the BmcSecure step. I should have checked extdeps before editing evidence. The whole argument I had been making all session is that captured bytes are not editable, and I made an exception without first verifying that the exception was needed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * The redaction paragraph survived its own removal, and Outstanding was specifying someone else's design Two residues in the probe document, one found in review and one found looking for the second one they said was probably there. THE CONTRADICTION. The document carried BOTH the new retention basis -- admin/admin is a published upstream fact, redaction reverted, bytes restored -- AND, immediately below it, the tail of the old redaction paragraph still saying the occurrences "are replaced with a marker" and that the credential "must be treated as disclosed". Both cannot describe the committed artifact. THE CAUSE IS WORTH RECORDING because it is a trap in the edit, not in the judgement: the removal searched for the next `---` delimiter, and the paragraph being removed contained the literal `----ARGV`. The search matched INSIDE that token, truncated the deletion, and left an orphan that begins mid-sentence. A textual edit that looks for a structural delimiter in a document whose content contains that delimiter will cut in the wrong place, and the surviving fragment reads as prose rather than as damage, which is why it passed my own check afterwards. AND `Outstanding` WAS THE SECOND COUPLING. It enumerated the migration lane's DESIGN -- the shape of the boot-intent product, how the readback should refuse, which terminal splits into which, how the request body should be serialized, how legacy-on-aarch64 should be made unconstructible. That is the same defect as the decoder stripped from section 8, one section further down: a probe record that specifies another lane's carriers becomes a second authority for them the moment they land. Agreeing with the design does not make it mine to write down. Replaced with a pointer that says what this record contributes -- the measured boot flags, that the model reported completed throughout, the two failure modes, the controller observations -- and states that the conclusions drawn from that evidence belong in the migration's carriers where they can be consumed rather than read. The genuinely open questions stay: they are facts about state, not designs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Strip decoded status semantics and generic credential policy from the unit receipt Review at cb5c1faa found residues that survived the earlier recut. The receipt asserted meanings for MegaRAC's `redirection_status` enum -- 1 as "Started", 100 as connect time -- decoded from `source.min.js`, which is not a committed artifact. The decoder was removed from the state machine for exactly that reason and then restated in prose beside it. The raw transition stays (mtcollins1_media_transition_observed); what a code MEANS is the status-code catalog's to say. The attempt-3 causal sentence is reduced to what the bytes establish: the failing reset happened at raw status 100, the succeeding boots at 1, and these artifacts do not establish that the difference caused the initrd failure. `mtcollins1_credential_retention_basis` stated reusable evidence-redaction policy ("redactable only when it is a SECRET") from a unit receipt, and was a prose-only String row with no importer anywhere in the corpus -- DESIGN 3c's dangling declaration and 4c's misplaced prose at once. The instance-specific basis survives as an annotation on the attempt it concerns; the general rule gets its own home if it earns one. Also cut the persistent/one-shot policy judgment from 7.1 and the generalized `image_redirection: 1` contract from 8, both of which prescribe for the boot-path migration, and the stale "remains the blocking objection" line, which the declared acquisition standing now answers. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Remove three probe residues the previous commit claimed to have removed Re-review at 4553c04 found the recut's three remaining leftovers, all in the probe. My verification grep missed them and I reported them cleared, which was wrong: "correctly held" wraps across a line break so a line-oriented pattern could not match it, and my patterns never covered "rule this settles" at all. - The header encoded a live review verdict ("draft, CHANGES_REQUESTED, correctly held") into a historical probe record. A probe should not carry a review's state; that state moves and the sentence rots in place. - Section 2 still promoted this instance into a general rule -- "redactable only when it is a SECRET" plus the future-rotation case -- which is reusable evidence-publication policy in a document whose own second line says it is not an authority. The instance basis survives; the rule does not. - Section 7.3 still wrote raw status 100 as "100 (connecting)" and hung a small-read/large-read mechanism off that decoding. Same unreceipted enum meaning the rest of the recut removed, and the same overreach: it now states the raw values and that no mechanism is established. Verified line-break-insensitively this time, over both carriers. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Carry the census quantities as std.measure values, not bare Int Review 63839 (dashboard-only) found the module applying carrier discipline selectively: it already imports std.measure and types chip_width as BitWidth, while every other quantity in the same file stayed a bare Int. Verified and correct -- each carrier it names already exists in dag/std/measure.dag, several authored for exactly these readings. mtcollins1_census_byte_count Int -> ByteSize mtcollins1_census_sol_byte_count Int -> ByteSize mtcollins1_host_capture_byte_count Int -> ByteSize MtCollins1MemoryWorkload.bytes_exercised Int -> ByteSize mtcollins1_nproc Int -> HardwareThreadCount mtcollins1_memtotal_kb Int -> Kibibyte mtcollins1_edac_uptime_at_capture_seconds Int -> Second MtCollins1SlotOccupancy.configured_mts Int -> MegatransfersPerSecond (16 rows) MegatransfersPerSecond's own comment names DDR MT/s as its case, and HardwareThreadCount sits on the Count axis for exactly an nproc reading. Bare Int re-mints quantity semantics std.measure already owns -- DESIGN section 2, net concepts must not grow by re-invention, and section 3, each fact lives in one place. memtotal keeps Kibibyte rather than normalizing: the kernel reported kB and the scale the reading was taken at is part of the reading. The witness reads through byte_size_count and hardware_thread_count_value. EXECUTED, not typechecked-and-assumed: built claim_executor and ran the witnesses lane locally. The corpus resolves and the claim fold evaluates; the only refusals are two self_host_logic wet witnesses that need a target/release/ gunbc this local run did not build, unrelated to this diff. Discriminating control: with nproc set to 161 the lane reports the_unit_presents_one_hundred_and_sixty_processors FAILED, and with 160 it does not -- so the assertion survived the carrier change live rather than going vacuous behind it. Note for the remote path: claim_executor refuses on BuildBuddy with HostBudgetUnreadable, because no cgroup memory limit binds the runner process. That is the fail-closed budget arm working as designed, not a defect here, but it means the lane cannot currently be executed by ctrl-build --remote. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Model the media transition, declare the digest frontier, drop the TODO rows Three reviews and an operator ruling, applied together. REVIEW 63839, second finding: mtcollins1_media_transition_observed packed a timestamped event sequence -- attach time, two raw controller fields, three offsets -- into one prose String. DESIGN section 2 calls a String leaf hiding named parts anemic modeling and section 4c puts an event in a typed carrier. It is now MtCollins1MediaRedirectionSample rows plus an attach timestamp. The status and index stay RAW and undecoded: what a value means is a megarac catalog keyed to firmware identity, not this receipt's to say. The witness folds them, and the checks are ones a String could not carry: that offsets strictly increase (a repeated or backwards offset is a transcription error, not a reading) and that the sequence actually CONTAINS a transition. If a later edit flattened these rows to one repeated status, the observation would have silently become a snapshot while still being cited as a transition. REVIEW 63839, third finding: the digests had no consumer. A digest's real consumer re-reads the bytes and compares, which is an effect; the witness is pure and the producer that would do it is what mtcollins1_acquisition_standing declares absent. So they are a DECLARED FRONTIER under section 3c, not a silent dangle -- and the witness folds the frontier rows themselves, refusing one that names no consumer or no trigger, because a frontier row with an empty trigger is a dangling declaration wearing a label. The trigger names a capability, per 4b(3): a capture producer sufficient for every artifact this module declares, not one verifier pointed at one file. OPERATOR RULING: the three modelling-obligation rows are gone. Nothing consumed them; a data row no fold reads is a prose TODO wearing a type, and giving a TODO a struct makes it look discharged while changing nothing. They are lanes now. REVIEW 63877: the probe hand-transcribed all five digests and the 16-row population table beside the rows that own them -- "digests verified at time of writing" being the rot admission in the header. Both tables cite the symbols now. This was one level up from the class this PR itself files at subject_and_its_digest_as_independent_parameters. AND THE PURCHASING CLAIM WAS WRONG TWICE. It first read "10 x 1Rx4 + 6 x 2Rx8", taking widths off the installed modules and presenting them as constraints on the ones to buy. Operator review caught that; I then corrected it to "width is unresolved, nothing closes it". OCP Mt. Jade Table 3 closes it -- same-channel x4/x8 mixing is No, and same-channel density too. So the first answer was right by accident and the second wrong by being cautious for the right reason; neither was DERIVED, which is why neither could be trusted. The probe records the sequence and cites extdeps.ocp.mt_jade rather than reprinting its cells. Recorded beside it: that table's different-channel row is Yes everywhere except RANK, which reads TBD -- and this unit mixes 1R and 2R across channels today. The specification declines to affirm the configuration the machine is already running. Escalated, because a ~320-module order premised on "different channels are fine" rests on the one cell that does not say so. NOT EXECUTED LOCALLY AT THIS EXACT HEAD, stated plainly: the run before this one parsed and passed the witness with no refusal, and the delta since is the obligation removal (no importers, verified by grep) plus markdown. A full floor run is a CI job, and mine was thrashing at the container memory cap, so CI adjudicates this head rather than my box. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Account for every declaration the census module adds Review 63909 found eleven data rows with no consumer and no frontier row -- DESIGN section 3c's dangling declaration. Verified whole-tree: outside the module, the witness imported ten symbols and nothing else read the rest. The fix splits two ways rather than labelling everything, because a frontier row is an admission and handing one to a row whose check was available all along is the label standing in for the work. CONSUMED BY EXECUTION -- three new checks, each discriminating: the clean-EDAC flag must AGREE with the counters it summarises and must have a non-zero observation window. A zero-counter reading taken at zero uptime says nothing; the window is part of the observation, so a flag that disagreed with either now goes red instead of sitting beside them. the capture windows must actually distinguish the two attempts. The attempt-label defect row claims the artifacts are told apart by wall-clock window rather than by the duplicated attempt=3 label -- this makes that claim checkable rather than merely stated, and it goes red if the windows ever collapse while the row goes on asserting them. the one-of-sixteen discriminator must still exist. The whole connector identification rests on a part occurring EXACTLY ONCE agreeing with the pair table at the single position carrying it, which no shift or reversal of the sequence reproduces. If a later edit duplicated that part the argument collapses while its prose keeps claiming it, so the property is asserted against the rows and the upstream citation is bound rather than left prose. DECLARED FRONTIER -- rows whose consumer is an effect a pure witness cannot perform, each with a capability trigger: the artifact identity rows grouped together (path, byte count, digest, kernel -- a digest authenticates bytes and says nothing about WHICH file or HOW MANY bytes were expected); the boot delivery observation and attempt-3 failure, whose consumer is gunbc#11001; memtotal_kb, whose capacity join needs a catalog row for every installed part, one of which was missing and is in flight as gunbc#11066; and the EDAC channel map reason, which resolves against the Linux carrier in gunbc#11071. DELETED: mtcollins1_media_redirection_held_through_boot. An unconsumed Bool restating what the final sample already carries is one more dangling row. AND THE FRONTIER TEST CAUGHT ITSELF. It asserted the list had exactly four entries; the frontier grew to fourteen and it failed for no reason but a stale number. The literal is gone rather than bumped -- DESIGN section 5 names that shape, a merge-blocking test comparing a live population to a literal measured from the same tree, which collapses to measure() == measure() the moment you automate the update. What is load-bearing is that every row EARNS its admission, a property of the rows and not of how many there are. EXECUTED: the local witnesses lane ran this module and reported exactly one failure, that stale count; the other four new tests passed and the log names only failures. The delta since is `== 4` becoming `> 0` on an Int in a function that had already compiled and run, so CI adjudicates this head rather than another thirty-minute local floor run at the container memory cap. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Consume the Ampere authority instead of hand-writing its mapping Review 63939, and it found the most serious defect in this PR. THE MODULE CLAIMED TO CONSUME extdeps.ampere.mt_collins_product_brief.memory_population AND IMPORTED NOTHING FROM IT. The "consume" was a DeclarationRef carrying the module path as a string. Meanwhile every firmware binding hand-wrote a `connector` for its (processor_socket, memory_controller) -- which is exactly connector_used_at_one_dpc on mt_collins_channel_population_roles, a mapping that authority already DERIVES from the guide's pair and population tables rather than transcribing. A second copy of one fact, beside its authority and free to drift (DESIGN section 3, section 2). This module's own basis row says the J-number "is a join, not a reading". Hand-writing the result of that join was the error the sentence describes. THE CONNECTOR COLUMN IS GONE. Firmware DRAM training reports socket, controller and slot-within-channel; SMBIOS reports a locator. Neither reports a J-number. The census now carries only what was observed, and the join to a connector happens where it can be checked. AND THE CHECK THAT WAS SUPPOSED TO BE DISCRIMINATING WAS COMPARING STRINGS. The previous test asserted the basis's DeclarationRef carried the expected module_path and decl_name spellings. That proves a sentence names the right authority and stays green while the mapping it describes drifts arbitrarily -- DESIGN section 5's specification-without-execution wearing a struct. I wrote it one commit earlier AS the fix for a dangling-declaration finding, which is exactly how this shape survives: it looks like a check. The witness now folds the upstream rows. It counts (role, slot) pairs where the role covers the observed channel and the slot sits at the connector that role assigns, and requires exactly one -- asserting three cardinalities at once: the authority covers this channel exactly once, and one SMBIOS slot carries the module firmware reported there. Delete the import and the file stops compiling, which is the difference between consuming an authority and citing one. The string comparison survives only as an explicitly labelled coherence guard, carrying a note saying what it is not. NO SENTINEL, after two attempts at one. Folding the roles down to a connector needed an "unresolved" value, and Nat has no value outside J1..J32 to reserve; an Int sentinel failed to typecheck against the Nat field, and 0 would have been a value a later reader could mistake for an answer. The pair fold has no hole: an uncovered channel contributes no pair, so its count is zero and the test refuses, with nothing standing for absence. FILED, as DESIGN section 4b requires of a newly discovered class: upstream_non_affirmation_consumed_as_permission. An upstream that answers over a richer vocabulary than yes/no -- OCP Mt. Jade Table 3 answers Yes / No / Not Preferred / TBD -- consumed into a Bool carrier makes every non-prohibition read as permission. Its receipt is this lane: the different-channel row is TBD on rank mixing, this unit mixes 1R and 2R across channels, and a proposed derivation would have emitted that as a fill REQUIREMENT with nothing carrying the decline. The machine's own clean EDAC is the corroborating trap -- evidence that this specimen executes, not that the authority affirms it. EXECUTED: witnesses lane run locally. The corpus compiles, the census module is judged, and no census test fails. The two remaining refusals are the self_host_logic wet witnesses needing binaries this run did not build, and a namespace-wave-admission stale-admission count that is an artifact of a local run against a moved base -- CI has adjudicated that phase green on every pushed head of this branch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Resolve the unit's observations against the authorities that now exist #11066 and #11068 merged, so the receipt stops naming gaps and consumes them. Review 63974 asked for exactly this, plus review 63987's stale-citation fix. CATALOG RESOLUTION, WHICH CLOSES A HOLE THE CROSS-JOIN LEFT OPEN. The firmware vs SMBIOS join proves two LOCAL transcriptions agree; edit the same part number in both lists and it stays green. Now every observed module must resolve to exactly one SK hynix catalog row whose rank and chip width equal what firmware reported, and the population is asserted by catalog IDENTITY -- ten AFR4N, five AFR8N, one CJR8N, summing to sixteen. A substitution now has to survive contact with the manufacturer's own datasheet figures. THE FILL CONSEQUENCE IS DERIVED FROM THE SPECIFICATION, NOT READ OFF THE SAMPLE. Each empty partner's rank, width and density are fixed by its channel peer BECAUSE OCP Mt. Jade prints same-channel rank, x4/x8 and density mixing as NotSupported. If a later revision relaxed a cell, the test goes red and the requirement stops being determined -- rather than a stale requirement quietly surviving the rule that justified it. THE FOUR STATES ARE CARRIED WHOLE, not collapsed to a Bool on the way through. mtcollins1_cross_channel_rank_mixing_standing records that the specification answers MixingUndetermined -- its TBD -- for the cross-channel rank mixing THIS UNIT ALREADY RUNS, and a control asserts it is still undetermined so a later revision resolving that cell goes red instead of being absorbed. That is the class filed at upstream_non_affirmation_consumed_as_permission. STALE CLAIMS CORRECTED: the receipt no longer says CJR8N is uncatalogued or the rank rule unmodelled, and review 63987 caught an annotation naming the_observed_channels_carry_the_connectors_ampere_assigns_them -- a symbol I renamed during the sentinel restructure, in the one comment whose job is to stop the weak check being mistaken for the strong one. It now names both real folds. I swept every long identifier in both files' comments against the declarations; no other citation is stale. FLEET CONCLUSIONS NARROWED TO UNIT SCOPE. This document may establish this machine's population and the compatibility consequences that follow from cited rules. It may not establish a twenty-unit roster, a ~320-module order, or a fleet-wide DDR rate for machines nobody has looked at. The reasoning was sound at unit scope and the scope was wrong, so it is narrowed rather than deleted. WHAT I COULD NOT EXECUTE LOCALLY, STATED PLAINLY BECAUSE IT CHANGES WHAT THIS COMMIT'S EVIDENCE IS WORTH. The module parses, typechecks and is judged, and two parse defects were found and fixed by running it -- a `data =` followed by a newline before `match`, and comma-separated match arms this language does not use. But the floor refuses before the claim-evaluation-fold on three modules this branch does not touch (vacuity_consumer_witness_long_test, fleet_posix_accounts, lens/enforcement/contract, all "missing required field"), so NO claim in this corpus evaluates locally, mine included. I proved that rather than assuming it: I broke the catalog-identity assertion to 11 and it did NOT go red, which is the signal that the check never ran. An earlier message in this session reported those tests green on the strength of no failure being NAMED -- that was wrong, and a module that never reaches the fold produces exactly the same silence as one that passes. CI reaches the fold and has been green on every pushed head of this branch, so CI is the executing evidence for these assertions, not my box. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Type the prose rows out of the receipt, and fix a real call-shape defect Review 64056, three findings, all the same class and all correct -- they cite this module's own argument against itself, since it deletes three rows one screen below for exactly this reason. mtcollins1_edac_channel_map_unavailable_reason: a six-hundred-character English paragraph in a String that no fold read, whose own frontier row conceded its home was elsewhere. DELETED. The rationale stays in the // channel, the typed readings it described were always carried separately by mtcollins1_edac_topology, and the mechanism lands as extdeps.linux.edac in gunbc#11071. Its frontier entry went with it -- a frontier naming a declaration that no longer exists is a stale citation, not an admission. mtcollins1_host_capture_attempt_label_defect: same shape, and its only consumer asserted the sentence was non-empty. That is DESIGN section 3c's own listed tell -- a witness that asserts a declaration exists rather than exercising it -- and I wrote it while addressing a dangling-declaration finding. DELETED, with the vacuous conjunct. The checkable content survives where it was already executed: the two captures carry different digests and different timestamps, and the_capture_windows_actually_distinguish_the_attempts asserts the ordering that makes the wall-clock window a real discriminator. MtCollins1BootDeliveryObservation: NOT deleted, because it records a real control, but its four prose fields were two observations and two CLAIMS written as paragraphs. The axes are typed now -- valid flag, EFI-versus-legacy on the failing and succeeding attempts, persistence held constant, model-reported- completed -- and two folds read them: one asserts the experiment had exactly one varied term, so flattening the two boot-type readings kills the control instead of leaving the prose standing; the other records that the model called every failed attempt complete, and is a control that SHOULD flip when gunbc#11001 lands. The device selector stays an exact quotation of the ipmitool rendering, which is evidence rather than commentary, and the SELECTION is deliberately not typed here because that carrier lands in #11001 and a second one would be the section 3 fork. AND A REAL DEFECT CI CAUGHT THAT I HAD NOT: bit_width_count takes `b`, and I called it with `w`, four times, in the catalog-agreement fold added by the previous commit. floor_class=structural, not infra -- my diff, my defect. Fixed, and I audited every other std.measure call site in the file against its declaration: byte_size_count(b:), second_count(s:), hardware_thread_count_value(t:) are all correct. That defect is the concrete cost of the gap reported in the previous commit: the local floor refuses before the claim fold on three modules this branch does not touch, so a call-shape error in a witness reaches CI before it reaches me. CI is the executing authority here and it did its job. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Derive the EDAC absence from the Linux authority now that it exists gunbc#11071 merged, so review 63974's deferred item comes due: the receipt stops describing the GHES/APEI mechanism and consumes extdeps.linux.edac. The observation contributes exactly one fact -- mtcollins1_edac_topology now carries driver_binding: GhesEdac, a typed binding rather than only the string /sys rendered -- and the authority supplies what follows. The string spelling stays beside it because a reader resolving this receipt against the committed capture needs the bytes they will actually find there. WHAT THAT BUYS, AND IT IS THE POINT RATHER THAN TIDINESS. This module used to assert in a String row that re-booting would not produce a channel map. That sentence was true and unfalsifiable where it sat. It is now DERIVED: edac_channel_topology_availability(GhesEdac) yields ChannelTopologyAbsent with cause FirmwareFirstErrorAttributionShim, whose absence standing is AbsentOnEveryBoot. The distinction between "no channel map here" and "no channel map, and another boot will not change that" is what justified recovering the map from firmware DRAM training instead -- so the justification for this census's central method is now a consequence of a cited kernel authority rather than of my confidence. A second fold requires the MEASURED tree to agree with what the authority predicts: zero csrow nodes is the EXPECTED reading under the shim, not an anomaly, and sixteen DIMM nodes is what it mirrors from SMBIOS Type 17. A future capture on this platform finding a populated csrow tree would put observation and authority in conflict and turn this red, which is the only way either of them gets to be wrong out loud. Call shapes checked against the declarations before pushing this time -- edac_channel_topology_availability(binding:) and edac_channel_topology_absence_standing(cause:) -- which is the check that would have caught the bit_width_count defect CI found in the previous commit. Also merges origin/main, which carries #11071's move of LinuxKernelRelease into extdeps.linux.kernel. Landing after that PR was the ordering deep-raven-831 and I agreed on, so the brand is authored in my base rather than met at the button. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Inhabit HostMemoryPopulation, and stop the receipt contradicting itself Review 64092, three findings, all correct. A FALSE FRONTIER. mtcollins1_memtotal_kb carried a declared frontier saying its capacity join needed a catalog row for every installed part and that CJR8N "had none", naming gunbc#11066 as in flight. That row is on main and this PR's own witness joins all three catalog identities. A frontier inventing an absent authority while the same change proves it present is a false wall -- DESIGN section 3c admits a frontier only with a trigger, and section 5 forbids fabricated plausible output. Removed, and DISCHARGED: the join it named is now written. THE SAME CONTRADICTION AS PROSE. One section derived same-channel rank, width and density from mt_jade_mixed_dimm_support; the next still asserted the OCP rule was "carried by no authority in this corpus" and that "chip width is not closed at all". Both were true when written and false once gunbc#11068 landed. A receipt that consumes a rule and denies it exists is a meaning fork. The paragraph now records what the authority settles, and says plainly how the contradiction got there: the model was fixed in layers and the prose around the edit was not re-read. The probe carried the same stale sentence and is corrected in the past tense rather than deleted, because the distinction it drew -- between what a machine HAS and what it NEEDS -- is the reason the census was worth doing. HostMemoryPopulation IS NOW INHABITED, which is what this census was for. mtcollins1 could not use the carrier every other fleet host uses while one of its three installed parts had no catalog row to point at. It now carries ten AFR4N, five AFR8N and one CJR8N as MemoryPopulationRows joined to catalog identities rather than to part-number spellings. AND THE CAPACITY JOIN THE FRONTIER NAMED IS THE CONSUMER. It respects the split gunbc.fleet.fleet_intent warns about rather than papering over it: the population states what is INSTALLED, MemTotal states what the kernel finds USABLE after reservations, and they are different facts. So the test asserts the RELATIONSHIP -- usable strictly below nominal, and within a few percent of it -- never equality. Measured here: 249.95 GiB usable against 256 GiB nominal, 97.64 percent. A population claiming eight sticks would put usable ABOVE nominal and go red; one far below would mean sticks are installed the firmware is not presenting. Both are real failure shapes for a census that decides a purchase. Call shapes checked against their declarations before pushing (host_memory_population_nominal_bytes(pop:), kibibyte_to_byte_size(k:)), and the arithmetic was evaluated rather than assumed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Preregister the spare-module screen; carry the Mt. Jade outcome whole TWO CHANGES IN ONE COMMIT, and the message says so because an earlier draft of it described only the first while `git add -A` had swept in the second. A commit message that does not describe its own contents is the same defect as a receipt that does not describe its own artifact. 1. THE PREREGISTERED PREDICTION, committed before the operator touches the hardware. Tonight's 32-DIMM adversarial test was predicted in conversation only, with no immutable pre-outcome receipt; proud-otter-590 correctly refused to let a row authored afterwards be called preregistration. This is the first one done properly -- configuration, basis, falsifier, and what each outcome earns. It also states the test's weakness in advance: sixteen modules change at once, so a failure localizes to nothing. A screen, not a diagnosis. 2. REVIEW 64125 -- THE MT. JADE LOOKUP OUTCOME IS NO LONGER COLLAPSED. This module is extdeps.ocp.mt_jade.memory_mixing's FIRST consumer and it performed exactly the substitution that module was built to prevent: mtcollins1_mixing_verdict mapped MixedDimmSupportUnmodelled and MixedDimmSupportAmbiguous onto MixingUndetermined. The upstream made its lookup total-with-refusal to stop that, and says in its own annotation that a manufactured MixingUndetermined is the worst of the three substitutions available -- the table really does print TBD, so a fabricated one is indistinguishable from a cited one. The harm was concrete. mtcollins1_cross_channel_rank_mixing_standing records the specification declining to affirm the cross-channel rank mix this unit runs, and its witness is a control documented as one that SHOULD flip. Collapsed, it could not flip: a row gone MISSING or turned AMBIGUOUS would arrive as MixingUndetermined and the test would stay green while its subject had disappeared. One spelling carrying both "the specification declines to state" and "this corpus has no row" is section 3's meaning fork and section 5's widening failure arm. Fixed by not folding. The outcome is carried whole; the witness handles the refusal arms as distinct constructors; the control now requires the lookup to RESOLVE and read MixingUndetermined, so a missing or duplicated row turns it red. It is also the class I filed today, one turn further in: upstream_non_affirmation_consumed_as_permission covers a non-affirmation read as permission, and here an ABSENCE was read as a non-affirmation. I wrote the row warning about the pattern and committed its next variant within hours. EXECUTED: parses and typechecks with no .dag errors; the only local failures are the self_host_logic wet witnesses needing binaries this run did not build. Claim evaluation does not happen locally on this checkout, so CI remains the executing authority for the assertions. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Pre-OS bring-up: collectors are a constructor input to actuation, console silence is not a terminal, an opaque OEM code stays opaque Model the pre-OS half of memory-reconfiguration admission as typed carriers with an executed regression corpus from Mt. Collins unit 1's 32-DIMM restart loop (2026-09-11). - extdeps.bmc.ipmi_sel: IPMI v2.0 §32 record types and the two §42.2 sensor offsets a bring-up reader consumes; OEM payloads carried as rendered bytes. - machine_intake_pre_os_observation_capabilities: per-platform profile of what can be seen before an OS; managed AC carries no outlet. - machine_intake_pre_os_bringup_attempt: sealed CollectorsReady with one refusing producer; PowerActuationRequest constructible only from it; four actuation kinds, AcPowerCycle a human-attended barrier; PowerActuationIssued is control-plane only (cites control_plane_acknowledgement_minted_as_effect); the effectful issuer is a declared frontier. - machine_intake_pre_os_bringup_verdict: stable terminal from standard SEL records only; PhysicalRemediationRequired { UnavailableFromExposedTelemetry } refuses further actuation; console reading typed by digest; OEM record as three facts with no fold to the verdict. - machine_intake_mtcollins1_32dimm_bringup_observation: the digest-bound corpus (SEL 0x3ea..0x44f, four byte-identical SOL captures, the web log's uniform `unknown`, the readiness fixture from 10-ac-meta.txt) and four checks. - 16 witnesses in test.claim.machine_intake.pre_os_bringup_witness_test, run green on BuildBuddy via claim_batch. - Two failure-mode rows filed, one receipt appended to absent_reads_identically_to_never_looked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HsYhty7z6f8KmVwreNbCGE * Preregister round 1 of the spare bisection: the 2DRx4 group Twelve known-good originals plus the four 2DRx4 spares -- the group whose part notation this corpus cannot identify. Prediction: FAILS. Confidence stated as low, because it is a guess among three roughly equal candidates and being wrong should cost something. Carries forward the standing disjunction proud-otter-590 insisted on: the prior falsification established that shape alone is not sufficient, NOT that supported shape is necessary, and NOT that a module is faulty rather than a combination untolerated. No round may name a bad module until one is isolated AND reproduces alone -- which matters physically, since the wrong framing gets a good stick binned. Records the operator's srvN prior for the 1Rx4 group as held-but-untested rather than assumed, so a later round falsifying it displaces something visible. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Preregister round 2: swap the 2DRx4 group to socket 0 Round 1 put the four 2DRx4 modules entirely in socket 1 and the OEM payload came back 0fde703b1102 -- the first 3b of the session against nineteen 33s. Under the candidate schema that is the socket bit, and it tracked a variable we controlled. This round exchanges the sides. The prediction is a CONJUNCTION -- that it fails, and that the payload reports 33 -- so both halves can fail independently, which is the point. A 3b result would falsify the module-following reading; a clean train would mean an interaction neither simple reading captures. States plainly what no outcome earns: four modules move together, so nothing here names one, and a module untolerated by this platform is indistinguishable from a broken one. The schema stays a hypothesis and may not name a DIMM. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Score the socket-swap prediction: matched, and record what it did not earn Prediction cd83f731921 matched on both halves -- it failed, and the payload reported 33 rather than 3b, so the socket field followed the quartet. But the decision table I wrote for it was too strong and this file says so: a configuration restriction violated wherever that quartet sits predicts the same outcome as a defective member, so the crossover separates neither. The companions changed too, so the round did not isolate the socket at all -- the experimental unit for that comparison is the complete eight-module population. Eliminates the best alternative hypothesis: all modules are 16 GB, so Ampere's per-socket equal-capacity rule is satisfied and explains none of the failures. Retracts two narration errors: 0 W memory power does not distinguish early failure from timeout, and the three-outcome table was neither exhaustive nor equiprobable. Records what the decoder earned -- two controlled confirmations of ONE field -- and that stage, status and tail have no such support and may not name a DIMM. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * The restart bound counts the trailing run since the last progress, so an early good boot cannot outvote a sustained failure sequence (review 64164) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HsYhty7z6f8KmVwreNbCGE * Record what six configurations eliminated, and two retractions Written so the next session does not re-derive tonight's eliminations. Carries the seven tested populations with outcomes, what each ruled out, and the three hypotheses still standing. Two retractions recorded rather than quietly dropped: DDR4-2133 being unsupported on Altra (srv1/3/4 run 2133 Samsung parts and POST cleanly, so the SoC supports it), and any speed conclusion drawn from the eBay listing, which says 2Rx4 where the label says 2DRx4 -- a source wrong about one field is not evidence about a neighbouring one. Also carries the srv2 precedent: identical Samsung parts trained on three hosts and failed training on the fourth. Same class a…

This was referenced Sep 11, 2026

Preserve mtcollins1 hardware-census and boot-path evidence #10965

Merged

Refuse unresolved and uncited Altra 2DPC operating rates #10954

Merged

briansrls approved these changes Sep 11, 2026

View reviewed changes

briansrls merged commit 6e2c8a9 into main Sep 11, 2026
6 of 8 checks passed

briansrls deleted the session/silent-koi-898 branch September 11, 2026 18:26

briansrls restored the session/silent-koi-898 branch September 11, 2026 18:41

Navigation Menu

Repository navigation

Mt. Jade Table 3: the same-channel mixing rule is a 2x7 matrix, and it closes width - #11068

Mt. Jade Table 3: the same-channel mixing rule is a 2x7 matrix, and it closes width#11068
briansrls merged 1 commit into
mainfrom
session/silent-koi-898

gunbai-bot Bot commented Sep 11, 2026

Uh oh!

briansrls left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

gunbai-bot Bot commented Sep 11, 2026

What the specification actually states

The two findings this was dispatched to settle

Modelling notes

Citation provenance

Evidence

Consumption (DESIGN section 3c)

Uh oh!

briansrls left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant