Repository navigation
GHES/APEI firmware-first is a Linux fact: ghes_edac gets its own upstream carrier - #11071
Merged
Merged
Conversation
…ream carrier Under ACPI APEI firmware-first mode the firmware handles memory errors and hands the OS finished error records; the OS never enumerates the memory controller. ghes_edac exists so one of those records has a DIMM to name -- it registers ONE synthetic controller and mirrors the SMBIOS Type 17 device list into it. It is an error-attribution shim, not a memory-controller topology authority, so no csrow or channel node exists to read on ANY boot absent a native driver. That sentence was living as prose inside one unit's observation (gunbc#10965's mtcollins1_edac_channel_map_unavailable_reason), where it is a fact about a Linux/firmware arrangement wearing a receipt's clothes. DESIGN 3's external upstream decomposition puts it in extdeps.linux.edac, keyed to the kernel release it was read against, and leaves the receipt its readings. What the carrier makes decidable rather than restatable: - EdacDriverBinding is a trichotomy, not an enum of drivers. The native-driver roster is genuinely open upstream (one per memory controller), so the closed part is the only part that is closed: a controller-enumerating driver is bound, ghes_edac is, or nothing is. - The two absences are separate causes with separate standings. FirmwareFirstErrorAttributionShim is AbsentOnEveryBoot -- the errand is over; NoMemoryControllerDriverBound is AbsentUntilDriverBound -- there is something to try. Collapsing them into one "unavailable" is exactly what books the next pointless boot. - edac_dimm_node_source asks both drivers the same question and gets different answers, which IS the shim: a controller's enumeration carries channel position, an SMBIOS Type 17 mirror names slots and never locates a part in the topology. - apei_firmware_first_from_dmesg matches the kernel's own line rather than a paraphrase. LinuxKernelRelease moves to a new extdeps.linux.kernel with it. It was declared inside gunbc.served_surface_browser_observation, a downstream receipt; an extdeps module cannot import a gunbc one, so keying an upstream fact to a kernel release would have had to re-coin the brand -- the fork. Its one consumer imports it from the new home. Consumption (DESIGN 3c): test.claim.linux_edac_topology_authority_witness exercises every arm of every fold, with a discriminating red on the dmesg detector whose fixture mentions GHES, EDAC, APEI and firmware and is still not the marker. Both controls were executed red by mutation before landing. The named later consumer is #10965's receipt, trigger stated in the module: that PR merging, after which it keeps driver ghes_edac, apei_firmware_first true, csrow_node_count 0 and the dmesg line, and resolves the WHY here. Observations this repo produces are receipts in the observing layer, never facts owned by the observed upstream. edac.dag leaves the frozen legacy scope manifest and joins scope_carrier_paths, with the extdeps_model_scope it owed; kernel.dag lands as a carrier. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JGu7gNotcNwnQLyddmmkXs
This was referenced Sep 11, 2026
briansrls
approved these changes
Sep 11, 2026
briansrls
left a comment
briansrls
left a comment
Contributor
There was a problem hiding this comment.
Approved at this head. The GHES/APEI mechanism belongs in the Linux authority and cleanly separates topology absence on every boot from the still-open native-driver condition. #10965 should consume this typed result after it lands. Merge only after the current required witness run is green.
#10956's consumed row The required floor refused with `3 unadjudicated delta(s), 0 stale admission(s), 1 consumed admission(s)`, and both halves are this change's to pay. The three deltas are the brand move itself: `LinuxKernelRelease` is authored on both sides inside ContainerVisibleHostKernel, the playwright run row, and the witness's execution-identity law, and what changed is which declaration the spelling admits -- base gunbc.served_surface_browser_observation, head extdeps.linux.kernel. That is exactly the motion the wall exists to make an author say out loud, so it gets three rows and the adjudication beside them: the moved declaration is byte-identical including the brand STRING (a changed brand would have altered what every `as LinuxKernelRelease` ascription means, which is a semantic change wearing a relocation's name), and the two consumers are the complete population -- both edited here, no third site left resolving through a module that no longer authors the name. The consumed row is #10956's, which merged this morning; the wall computed its transition as already satisfied at the base and printed it. This file is the roster, so this touch is the toucher the rule charges and the deletion is paid here rather than deferred to a follow-up nobody owes. Empty was the resting state and empty is not permissive: authoring different rows back into it is the ordinary motion, not a regression of that dissolution. Floor itself was clean on the refused run -- verdict=FloorClean, claims_failed=0, and all 12 of the new EDAC witnesses reported standing=planned-and-passed as changed witnesses. Only the namespace phase refused. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JGu7gNotcNwnQLyddmmkXs
briansrls
requested changes
Sep 11, 2026
briansrls
left a comment
briansrls
left a comment
Contributor
There was a problem hiding this comment.
The Linux/GHES subject model is sound, but this head is not mergeable because its required namespace-wave-admission phase failed structurally.
The log identifies the three unadjudicated deltas precisely: the LinuxKernelRelease binding target moved from gunbc.served_surface_browser_observation to extdeps.linux.kernel in:
gunbc.served_surface_browser_observation::ContainerVisibleHostKernelgunbc.served_surface_browser_observation::playwright_chromium_151_linux_arm64_headless_navigation_runtest.claim.served_surface_browser_observation_witness::witness_run_owns_one_execution_identity
It also reports one consumed admission that is owed deletion on this roster touch: gunbc#10956 runner provider roster rehome.
Please admit the three target changes by identity, remove the consumed #10956 admission, and rerun required CI on the resulting head. My earlier semantic approval still describes the subject review; this change request records the actual merge gate.
Contributor
Author
|
The change request is satisfied on the current head, and the wall says so rather than this comment. That review was submitted against Zero unadjudicated deltas, zero stale admissions, zero consumed admissions. The floor on that run then refused for an unrelated reason, and it is not a verdict about the diff — the job itself classified it that way: The runner (srv1-17) refaulted its own evicted pages at 325295 major faults/minute while computing for 10% of the wall, and refused rather than holding. I have re-run the failed jobs; nothing in the diff changes for it. — sent from deep-raven-831 |
… with a real other arm `ghes_edac_registers_exactly_one_controller_holds` read `ghes_edac_registered_controller_count == 1` against a data row declared as 1. That is statically decided: it can only go red if someone edits the row, which makes it a change detector rather than a check -- DESIGN §5's own tell, that automating the literal's update collapses the assertion to measure() == measure(). eager-owl-205 hit the same shape from the other direction today (a witness comparing DeclarationRef strings to literals, green and proving nothing) and flagged it; this is that shape. The repair is not to delete the row but to notice the fact it was standing in for. How many controllers are registered is TWO different kinds of fact depending on who is bound. Under the shim it is ONE regardless of what the hardware has, because it is a property of ghes_edac rather than of the platform -- which is exactly why one memory controller beside sixteen DIMMs is the expected reading and not an anomaly. Under a native driver it is whatever the machine actually has, which this module cannot know: that is a per-platform reading for the observing layer. So the count becomes an arm of a fold, and the discriminating half is the other arm -- a native driver must NOT come back as a driver-fixed number, because answering one here would be the fabricated-plausible-output failure with a Nat on it. Executed red by mutation: pointing the native arm at ControllerCountFixedByDriver reds native_driver_controller_count_is_not_fixed_by_the_driver_holds while the ghes arm stays green, so the two arms are independently discriminating rather than one law wearing two names. 14 witnesses, all passing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JGu7gNotcNwnQLyddmmkXs
… its siblings in std.measure
review 63971, and it is right. `ghes_edac_registered_controller_count: Nat = 1` and the
`ControllerCountFixedByDriver { count: Nat }` payload carried a domain count on a bare
scalar, in a module whose entire point is that ONE controller beside sixteen DIMMs
means something specific. Nothing in that type distinguished the 1 from a DIMM count, a
channel count, or a slot number -- which is the §2 test failing one step earlier than a
fork: not a second name for the axis, but no name at all.
std.measure already owns the axis and the corpus has refused this exact move twice by
name. MergeQueueEntryCount sits there rather than in the module decoding GitHub's
merge_queue rule because "an extdeps module minting its own alias for it would fork that
axis once per upstream that happens to count something"; PowerCordCount was put there so
a product module "consumes it rather than re-minting a local alias for the same axis".
An extdeps module counting memory controllers is the same shape, so MemoryControllerCount
lands beside them with its constructor and accessor, and edac.dag consumes it. The
witness's oracle becomes memory_controller_count_value(c: n) == 1 rather than n == 1.
The stage0 mirror is regenerated by its own producer rather than hand-edited: one
`--required-regen` round emitted the three additions to std_measure.rs, applied as hunks,
and the second round reports first_generation_equal=true with no drift line. clippy
--all-targets clean, 14 witnesses passing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JGu7gNotcNwnQLyddmmkXs
review 63982, and it is right: `git grep edac_topology_model_read_at_release` returned
one line, its own declaration. No fold read it, it was not carried on the scope, and my
own §3c block claimed consumption for "every arm of every fold" — which that row was
not. DESIGN §3c names this exact tell ("a data row no fold reads") and says it is red
regardless of how well modeled the dangling piece is.
The fix is not to drop it. The brief asked for the fact to be keyed to the relevant
kernel, and the reason is load-bearing rather than decorative: this module's whole claim
is that an absent channel map is STRUCTURAL and not a missing driver, and that claim is
falsifiable only against a stated release — a mainline that grew a native Altra
memory-controller driver would answer ChannelTopologyEnumerated for the same question.
A provenance a consumer can quote the answer without is a provenance that will be
dropped.
So the release travels WITH the reading, in the same value:
edac_channel_topology_availability now returns EdacChannelTopologyReading
{ availability, read_at_release }. Deliberately ONE fold — a release-free route beside
it would be the path every caller takes, and the row would be dangling again one caller
later.
The reviewer's other suggestion, carrying it on the citation row, I did not take: the
`?h=v6.8` source URL in further_citations is reachable but it is a citation, not a value
any consumer can join on, so the receipt in #10965 still could not say which kernel its
answer was keyed to.
Executed red by mutation: pointing read_at_release at a literal "9.9.9" reds
every_reading_carries_the_release_it_was_read_at_holds, which checks all three arms and
not only the interesting one. 15 witnesses passing. Also merged current main (the branch
had picked up a main-integration merge) and re-ran the regen against it:
first_generation_equal=true, no drift.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JGu7gNotcNwnQLyddmmkXs
Carry public main through 02eee95. Preserve the GHES/APEI authority, release-bound topology reading, typed MemoryControllerCount, LinuxKernelRelease transition admissions, and generated mirror. Main's intervening paths are disjoint from the PR.
Contributor
Author
|
Both change requests are addressed on the current head; recording the evidence so the blocking review can be resolved. review 63971 (domain count on a bare review 63982 (dangling I did not take the alternative of carrying it on the citation row. The Both repairs were executed red by mutation, not argued: pointing the native arm at — sent from deep-raven-831 |
gunbai-bot Bot
pushed a commit
that referenced
this pull request
Sep 11, 2026
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>
Closed
6 tasks
gunbai-bot Bot
pushed a commit
that referenced
this pull request
Sep 11, 2026
…solution is recorded once main took 9243870, which edits the same NAMESPACE_TRANSITION_ADMISSIONS roster this branch appends to. namespace_wave_admission.rs is HAND-WRITTEN (//! header, no generated banner), so a regen cannot resolve it and the hunks are authored text. Git interleaved the two appends mid-literal, so the sides could not be concatenated: the conflict boundaries cut through TransitionAdmission structs. Resolved by reconstructing the roster from each side's complete file and taking the union -- main's 3 gunbc#11071 LinuxKernelRelease rows first, then this branch's 175 v2-native-route module-split rows. 178 total, none dropped, and neither side's #10956 rows return (both had already deleted them as consumed). THE DISSOLUTION IS RECORDED ONCE. Both sides wrote a TWENTY-FIRST DISSOLUTION paragraph for the same #10956 event -- recording one dissolution twice is a rostered failure mode in this repo, and two accounts of one event is the fork DESIGN section 3 forbids. Main's account survives: it landed first and it cites the receipt (required floor run 34627055157 reporting the row CONSUMED), where this branch's cited only the merge sha. The duplicate is deleted rather than merged into a third wording. Main's narrative says "the rows below are a DIFFERENT relocation", which was true when its rows were the only ones. After the union it would read as covering this branch's rows too, so a bridge paragraph states that the roster now carries two independent relocations with different dissolve-on triggers and that neither narrative covers the other's rows. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013aZDLk2CxsCDznqn49Xhe8
gunbai-bot Bot
pushed a commit
that referenced
this pull request
Sep 11, 2026
… from its own blob The freeze is lifted by the trigger review named for it -- a CONCRETE CONFLICT, not elapsed commits. This branch sat at 265a92d through 9, 13 and 28 commits of drift without merging, because absorbing main on a schedule buys nothing while nobody can execute the missing acceptance receipt and every absorption moves the subject SHA. GitHub reported the branch unmergeable at 55 behind, so the condition is met and the merge happens now. FIFTH CONFLICT IN THIS FILE, AND THE FIRST QUALITATIVELY DIFFERENT ONE. Both sides appended rows, so git interleaved the two arrays and produced THREE hunks across one list: 40 SCM rows here, 3 for gunbc#11071 from main. Patching interleaved hunks is exactly how a row gets silently dropped in the middle of a list nobody re-counts, and a dropped row here is an unadjudicated delta the wall exists to refuse. So the resolution does not touch the hunks at all: each side's array is reconstructed from its OWN staged blob (`git show :2:` and `git show :3:`) and the two are concatenated. UNION, for the reason that decided the second and fourth conflicts: taking either side whole deletes obligations the other still owes. 43 rows, verified by label census -- 31 SCM_MERGE_BASE_COHOME, 9 SCM_SOURCE_RECOVERY_REHOME, 3 gunbc#11071 -- rather than by trusting the patch applied cleanly. Main's #11071 TRIGGER paragraph is kept verbatim. It records when those rows come due and this branch is not the authority that retires them; the same receipt rule that deleted #10945 and #10956 from this roster will delete these when the wall says so, and not before. cargo check -p v1-compiler --lib finished clean on the working tree. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ4iThiZ1B9LPB9ePr8qa9
Closed
6 tasks
gunbai-bot Bot
pushed a commit
that referenced
this pull request
Sep 11, 2026
…t main's new witnesses hit Two blockers on 761f9af, and only one of them was the roster. 1. THE RECEIPT. Required floor run 34651932681 reported all three gunbc#11071 rows as CONSUMED ADMISSION ... already satisfied at the base, and refused with 3 consumed admission(s) due for deletion on this roster-touching change. Deleted. Third time this branch has carried another lane's fresh rows through a merge and had the wall order their deletion, and the union was right all three times: what deletes a row is the receipt, never the expectation, however reliable the expectation has become. Main's TRIGGER paragraph stays -- it records when they came due. 2. A SEMANTIC MERGE CONFLICT I CAUSED. The floor also refused with fabric_m0_commit_witness_test.dag:194: type mismatch: expected 'Coproduct(CasStoreFailure)', got 'Coproduct(CasUnreadableSlot)' This branch changed `CasStoreRefused` to carry a `CasStoreFailure` rather than a `CasUnreadableSlot` directly, because a conditional write can reach the store, satisfy its precondition, and still fail to PUBLISH -- reporting that as a malformed head was the conflation the widening removed. Main then landed fabric-M0 witnesses written against the old shape. NEITHER SIDE IS WRONG ALONE; the defect exists only in their composition, which is exactly the stranded-caller shape that took main down earlier this week with #10923 and #10925. The difference is that this time the type change is mine, so the repair is mine: I am the one composing them. THE FLOOR NAMED TWO SITES AND THERE WERE FOUR, across three files -- it stopped early. Repairing only the cited lines would have left two more to surface on the next run, which is the same fix-the-quoted-instance-rather-than-retire-the-claim pattern this branch recorded two commits ago when a narrowed word survived forty lines below its own correction. All four now wrap as `CasSlotObservationRefused { cause: ... }`, and the constructor is imported where it was missing. Verified by sweeping for the old shape corpus-wide rather than by re-reading the error: 0 remain. Roster census after deletion: 40 rows, 31 SCM_MERGE_BASE_COHOME + 9 SCM_SOURCE_RECOVERY_REHOME. All three fabric modules resolve clean; cargo check -p v1-compiler --lib finished clean; section 4c: 0 violations. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ4iThiZ1B9LPB9ePr8qa9
gunbai-bot Bot
pushed a commit
that referenced
this pull request
Sep 11, 2026
…ent its own trigger named The floor at 8b9c886 refused: "namespace-wave-admission (0 unadjudicated delta(s), 0 stale admission(s), 3 consumed admission(s) due for deletion on this roster-touching change)". The three rows are main's gunbc#11071 LinuxKernelRelease rehome, and they are genuinely consumed, verified at the base rather than assumed: origin/main authors LinuxKernelRelease in dag/extdeps/linux/kernel.dag and no longer authors it in gunbc.served_surface_browser_observation, so the delta those rows admit is not producible any more. MY MERGE RESOLUTION WAS WRONG AND THIS IS THE CORRECTION. Resolving the roster conflict, I took the union of both sides' rows on the reasoning that an append conflict must not drop anyone's work. That is right for rows still admitting a delta and wrong for these: #11071's own TRIGGER sentence says "these rows go when #11071 merges", and the commit I merged (9243870) IS #11071 merging. So the union preserved rows that the very act of merging consumed. The rule charges the roster's toucher, and this change touches it. The narrative goes with the rows. Main's four #11071 paragraphs -- the rehome argument, the TargetChanged classification, the safety adjudication and the trigger -- described rows that no longer exist, so they are replaced by one TWENTY-SECOND DISSOLUTION record in the form the twenty-first uses, citing the floor run that named the rows as due. The bridge paragraph I added for "two independent relocations" goes too: there is one relocation on this roster again. 175 rows remain, all v2-native-route module splits, dissolving on this PR. Each dissolution is recorded exactly once. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013aZDLk2CxsCDznqn49Xhe8
gunbai-bot Bot
pushed a commit
that referenced
this pull request
Sep 11, 2026
The floor reported all three gunbc#11071 LinuxKernelRelease rows CONSUMED -- already satisfied at the base -- and refused adjudication, because a roster-touching change owes the deletion. This is the toucher, so the rows and main's account of their subject go here rather than being deferred. Second time today on this file; that is what a shared append-only roster costs while two lanes are both moving. The preceding dissolution paragraph asserted 'the rows below are a DIFFERENT relocation' -- true when written, false once those rows are gone -- so that clause is dropped rather than left standing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YT3CM7TgQNeyBp1REtuxWE
briansrls
pushed a commit
that referenced
this pull request
Sep 11, 2026
The loader (previous commits) could produce another revision's
`ParseEnvironment`, but nothing consumed it: `parse_census_fill_sources`
pinned `dag_parse_environment`, `base_records` took no environment, and the
baseline was reconstructed from untouched head records regardless of whether
the two revisions spoke the same language. This is the consumption.
AUTHORITY SIDE. `parse_census_fill_sources_with_environment` takes the
environment and threads it into both `tokenize_artifact` and
`parse_with_table_in_occurrence_scope`; the old name survives as a thin
head-grammar wrapper, which is now the ONLY place that names
`dag_parse_environment` on the census path. `parse_with_table_in_occurrence_scope`
requires its `env` for the same reason `parse_with_table_at` does: a default
would be the head's grammar, and the forgetful base caller would answer
confidently under the wrong rules.
THE PARTITION, which is the correctness core. Carrying untouched head records
assumes an untouched FILE has an untouched PARSE. That holds while both
revisions speak one grammar and fails exactly when they do not -- a keyword,
literal, operator or item-form change gives an untouched file a different
parse, so its head records are not its base records. So:
environments identical -> changed-file reconstruction, as before
environments differ -> carry nothing; read every base-side file in sweep
scope under the base's own environment
THE CHEAP CHECK DECIDES. `environment_agreement` asks the RESOLVER for the
files declaring the environment (13 today; that number appears nowhere) and
compares git object ids. Equal ids are equal content, so agreement is
established by construction, and the ordinary pull request -- which changes no
grammar -- pays a handful of `rev-parse` calls and never materializes
anything. Only a real grammar change pays for the base corpus.
KERNEL HALF, GUARDED NARROWLY. `declaring_candidates` consults this binary's
own `kernel_type_set`, a head fact. Equal blobs for `dag/std/types.dag` mean
both revisions name the same kernel and one map serves; different blobs leave
the question open, and an open question is `NotEvaluated`. Threading distinct
base and head kernel maps is the general repair and is not this change's
subject.
AND FAILING TO ESTABLISH THE BASE ENVIRONMENT REFUSES. Not knowing which
grammar the base speaks makes every base-side declaration unreadable; falling
back to the head's would fail open on exactly the changes this exists for.
CONSUMED ADMISSIONS PAID. #11071 merged, so all three `LinuxKernelRelease
rehome` rows report CONSUMED -- the base now authors the name in
`extdeps.linux.kernel` and their delta has stopped being producible. The
obligation comes due on the roster's next touch and this change touches the
roster, exactly as those rows predicted in writing. Deleted, with the
twenty-second dissolution recorded. An empty roster admits nothing: any delta
no row names still refuses as UNADJUDICATED.
Verified: clippy --all-targets -D warnings clean; 51 wave-admission tests and
3 loader tests pass, including the probe that fails if the loader reads the
worktree instead of the revision.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YZZi3QsDvibJqy8k8PwzZ9
gunbai-bot Bot
pushed a commit
that referenced
this pull request
Sep 12, 2026
… rows. Required floor run 34661122479 refused namespace-wave-admission on two NewPoolCoincidenceResolution bindings; touching the roster also pays the three consumed LinuxKernelRelease admissions. Co-authored-by: Cursor <cursoragent@cursor.com>
gunbai-bot Bot
pushed a commit
that referenced
this pull request
Sep 12, 2026
The required floor on this branch is CLEAN -- `verdict=FloorClean
unexpected_failures=0` over planned=3757 executed=3757 claims_failed=0 --
and the census moved exactly as the change intended:
`read_name_module_pairs` 105 -> 82, `qualified_name_module_pairs`
305 -> 334, with all 23 `[floor-bare-name-ambiguity-bound]` rows naming
the authority this PR chose (10 `String` -> std.string_type, 12 `Unit` ->
std.types, 1 `Filesystem` -> extdeps.filesystem.filesystem_io).
What blocked the lane was a different phase: `FAILED PHASE
namespace-wave-admission (1 unadjudicated delta)`.
THE DELTA, AND IT IS A REAL ONE -- a side effect on a name this PR never
set out to touch:
TargetChanged binding
extdeps.tools.sha256sum::extdeps_external_authority_anchor
base {extdeps.filesystem.filesystem_io, extdeps.shell,
extdeps.tools.sha256sum}
head {extdeps.shell, extdeps.tools.sha256sum}
`extdeps.tools.sha256sum` imported `extdeps.filesystem.filesystem_io`
BARE. A bare module import drags the whole module into the candidate set
for every name it declares, so filesystem_io's copy of
`extdeps_external_authority_anchor` -- the per-module convention row some
315 modules each author -- was a candidate at this site. Naming
`{ Filesystem }` binds the one declaration the author meant and drops the
rest, which narrows the candidate set for that unrelated spelling too.
NO RESOLUTION CHANGES: sha256sum authors its own
`extdeps_external_authority_anchor`, and a module's own declaration wins
inside the authored region, so the site resolved to sha256sum's row
before and resolves to sha256sum's row after. The removed candidate could
not have won either way. What moved is the SET, three modules to two --
the resolution stopped depending on a module the author never named,
which is the qualification's whole purpose. That is admitted, not
silenced: the row states it out loud, which is what this wall exists for.
The ten `extdeps.tools.* -> std.string_type` membership additions needed
no row: the phase classified each `ExplicitlyEvaluatedZeroDelta ...
reached by a name this module authors`.
ALSO PAID HERE: the three `gunbc#11071 LinuxKernelRelease rehome` rows are
deleted. #11071 merged, so the base already binds those spellings to
`extdeps.linux.kernel` and the floor reported all three CONSUMED. A
consumed row's deletion comes due on this roster's OWN next touch; this
change is that touch, so the debt is paid rather than inherited by an
unrelated lane.
NOTE FOR THE LATER BATCHES: the Filesystem/Clock batch converts fourteen
more bare imports to named ones, so it should be expected to produce this
same class of delta per module rather than treated as a surprise.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
briansrls
pushed a commit
that referenced
this pull request
Sep 12, 2026
* 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.
…
briansrls
pushed a commit
that referenced
this pull request
Sep 12, 2026
…11137) * Qualify the extdeps.tools bare-name reads by their declaring module 23 of the 105 value-position reads the bare-name-ambiguity census names (`[floor-bare-name-ambiguity-read]`, landed #11078) sit under `extdeps.tools`. Each was resolved by whichever claimant scope precedence happened to rank first; this binds each to the authority its own module means, through the file's own import, so the read no longer falls through the shared name slot. Three names, three declaring authorities, each named rather than inherited: - `String` is declared by `std.string_type`, NOT by `std.types`. Ten of these files carried `import std.types { String }`, which answers nothing -- `std.types` neither declares `String` nor imports it, so the name was travelling through the shared slot while the import line implied otherwise. The bogus name is dropped from the `std.types` list and `import std.string_type { String }` added, so the citation now names the declaration (§3: cite the symbol, not a re-exporter). - `Unit` IS declared by `std.types` (`type Unit`), so it joins the existing list. This is the form the proof site landed in #11078 already demonstrates: `extdeps.tools.hostname` reads `[floor-bare-name-ambiguity-bound] name=Unit resolves_to=std.types`. - `Filesystem` at `extdeps.tools.sha256sum` is the one judgment site in this batch and it is not close: the call is `Filesystem.Write(path:, content:)`, matching `service Filesystem { operation Write }` in `extdeps.filesystem.filesystem_io`. The other claimant, `std.resources`, declares a `resource Filesystem` whose capability is lowercase `write` and which has no `Write` operation at all. The file already imported `extdeps.filesystem.filesystem_io` bare; it now names `{ Filesystem }`, which is the form 82 other files in the corpus already use. No renames, and neither declaring side is touched -- this is the qualification mechanism 305 sites corpus-wide already resolve through, applied to the residue that never got it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT * Admit the one namespace delta the sha256sum qualification produces The required floor on this branch is CLEAN -- `verdict=FloorClean unexpected_failures=0` over planned=3757 executed=3757 claims_failed=0 -- and the census moved exactly as the change intended: `read_name_module_pairs` 105 -> 82, `qualified_name_module_pairs` 305 -> 334, with all 23 `[floor-bare-name-ambiguity-bound]` rows naming the authority this PR chose (10 `String` -> std.string_type, 12 `Unit` -> std.types, 1 `Filesystem` -> extdeps.filesystem.filesystem_io). What blocked the lane was a different phase: `FAILED PHASE namespace-wave-admission (1 unadjudicated delta)`. THE DELTA, AND IT IS A REAL ONE -- a side effect on a name this PR never set out to touch: TargetChanged binding extdeps.tools.sha256sum::extdeps_external_authority_anchor base {extdeps.filesystem.filesystem_io, extdeps.shell, extdeps.tools.sha256sum} head {extdeps.shell, extdeps.tools.sha256sum} `extdeps.tools.sha256sum` imported `extdeps.filesystem.filesystem_io` BARE. A bare module import drags the whole module into the candidate set for every name it declares, so filesystem_io's copy of `extdeps_external_authority_anchor` -- the per-module convention row some 315 modules each author -- was a candidate at this site. Naming `{ Filesystem }` binds the one declaration the author meant and drops the rest, which narrows the candidate set for that unrelated spelling too. NO RESOLUTION CHANGES: sha256sum authors its own `extdeps_external_authority_anchor`, and a module's own declaration wins inside the authored region, so the site resolved to sha256sum's row before and resolves to sha256sum's row after. The removed candidate could not have won either way. What moved is the SET, three modules to two -- the resolution stopped depending on a module the author never named, which is the qualification's whole purpose. That is admitted, not silenced: the row states it out loud, which is what this wall exists for. The ten `extdeps.tools.* -> std.string_type` membership additions needed no row: the phase classified each `ExplicitlyEvaluatedZeroDelta ... reached by a name this module authors`. ALSO PAID HERE: the three `gunbc#11071 LinuxKernelRelease rehome` rows are deleted. #11071 merged, so the base already binds those spellings to `extdeps.linux.kernel` and the floor reported all three CONSUMED. A consumed row's deletion comes due on this roster's OWN next touch; this change is that touch, so the debt is paid rather than inherited by an unrelated lane. NOTE FOR THE LATER BATCHES: the Filesystem/Clock batch converts fourteen more bare imports to named ones, so it should be expected to produce this same class of delta per module rather than treated as a surprise. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT * Address review 64326: consistent String citation, and name the instrument Three of the four findings were right and are fixed here. TRANSCRIBED INSTRUMENT OUTPUT (valid). The roster doc carried `verdict=FloorClean unexpected_failures=0` and the planned/executed/ claims_failed counts as prose. DESIGN §6 is explicit that a measurement is cited by naming the producer that re-derives it, never by copying its numbers, because a transcribed number rots without anyone touching either end. The counts are gone; the claim now names the `claim_executor` invocation and the verdict line to read it off. TWO FILES LEFT ON THE OTHER SPELLING (valid). `extdeps.tools.jq` and `extdeps.tools.sha512sum` were edited on exactly the line that carries `String` and kept it on `std.types`, which left them inconsistent with their nine siblings after a change whose stated purpose is to qualify reads by their declaring module. They were excluded because the census does not list them -- their reads are settled inside the authored region -- but "not in the measured population" is a reason to not CHASE a site, not a reason to leave a wrong citation on a line already being edited. Both now name `std.string_type`. All thirteen touched files are consistent: none carries `String` on a `std.types` import. THE ROSTER DID NOT SPEAK TO THE `String` REQUALIFICATION (valid as a gap in the writing). The doc said "NO RESOLUTION CHANGES" about the sha256sum anchor and a reader could take it as covering the whole diff. It now states why `String` needs no row, and states it as the wave phase's measurement rather than as this author's assertion. THE FOURTH FINDING IS NOT ACCURATE and nothing is changed for it. It reads the `String` requalification as retargeting the spelling to "a second authority" and forking it across nine modules. `std.types` declares no `String` -- the finding says so itself -- so it was never an authority for that name, and `import std.types { String }` bound nothing. The two real claimants are `std.string_type` and `v2.std.text`, which the census names as the self-host migration double and explicitly scopes out. Naming one of the two existing declarations creates no third. That it is measured rather than argued is the part that matters: the wave phase compares the binding table on both sides, and on this head it reported exactly ONE `TargetChanged binding` delta over 814,621 binding rows compared -- the sha256sum anchor -- and NONE for `String`. The ten `String` sites are reported as `ExplicitlyEvaluatedZeroDelta membership ... reached by a name this module authors`: evaluated, zero. So the read resolved to `std.string_type` before and after; what changed is its authorization, from an accident of scope precedence to something the author wrote. The finding's live observation -- that ~1951 modules carry `import std.types { String }` -- is real and is a corpus-wide defect this campaign does not fix: those lines name a module that does not declare the name they list. They are harmless only while those modules' reads are not ambiguous. Correcting them is its own change with its own adjudication, not a drive-by in a PR scoped to 23 measured reads. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT --------- Co-authored-by: Brian Searls <briansearls1@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
gunbai-bot Bot
pushed a commit
that referenced
this pull request
Sep 12, 2026
Both sides deleted the three #11071 rows -- main as its thirty-fifth dissolution (#11137), this branch independently -- so main's text is taken, including its numbering, which is the authority's count rather than my local one. Main's #11137 row is then dissolved here, because its own trigger has fired: "this row goes when #11137 merges", and #11137 is in origin/main with `import extdeps.filesystem.filesystem_io { Filesystem }` at the base. The delta it admitted has stopped being producible, so it is CONSUMED, and a consumed row's deletion comes due on the roster's next touch. This change is that touch. Verified rather than reasoned: the merge commit and the import line were both read off origin/main before deleting. The roster is empty again, which admits nothing: any delta no row names still refuses as UNADJUDICATED. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NQnvBvFGNu9tNL544NJe2j
briansrls
pushed a commit
that referenced
this pull request
Sep 12, 2026
DELETES gunbc#11137's admission row, DELIBERATELY, and records it. Two conflicts needing opposite treatment. src/v1/stage0/src/namespace_wave_admission.rs is hand-maintained despite living in the emitted stage0 tree -- .gitattributes line 70 carries an explicit "!merge" against the line-53 glob, and git check-attr reports "unspecified" where a control in the same directory reports "generated-artifact". So it is hand-resolved, and it was resolved by PROVENANCE rather than by rule. The rule I nearly applied -- "rows arriving from main are consumed at my base by construction" -- is a belief about main's content, not a measurement, and applying it here would have silently reverted a landed PR's adjudication narrative with no marker and no gate complaint. What main's side actually is: exactly one commit, #11137 (34d2a8d), which REPLACED #11071's record with its own. Measured, the row IS consumed: #11137 landed after this branch's base, so the base now authors the qualified import and the TargetChanged delta the row admits is no longer producible. A consumed row's deletion comes due on this roster's own next touch, and this merge is that touch -- the same rule the thirty-fifth dissolution applied to #11071's rows, applied to the change that applied it. So the row goes, and the deletion is recorded as a THIRTY-SIXTH DISSOLUTION naming #11137 rather than left silent. The block accumulates records (eighteenth through thirty-sixth all coexist) while per-row accounts die with their rows, so main's thirty-fifth record is kept verbatim. docs/design-rung-drops.md is merge=generated-artifact and the driver REFUSED, leaving ours-side bytes unmerged with no markers. Per its own declared repair route the BASE side is taken verbatim and NOT regenerated locally: heal-generated-artifacts derives it from the merged authorities and the gate must agree with THAT derivation, which locally-produced bytes would not be. Verified by set difference, not by count and not by marker count: no row main carries went dark. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YT3CM7TgQNeyBp1REtuxWE
gunbai-bot Bot
pushed a commit
that referenced
this pull request
Sep 12, 2026
MERGE. origin/main merged with a merge commit (no rebase). One conflict, in src/v1/stage0/src/namespace_wave_admission.rs, resolved to main's table with none of this branch's 181 rows dropped. THE #11137 ROW IS DELETED AND ITS TRIGGER FIRED. The row's trigger was authored as "this row goes when #11137 merges"; #11137 merged as 34d2a8d, verified by identity rather than inferred, so the base carries the named import, the delta stopped being producible, and the row is CONSUMED. A consumed row's deletion comes due on this roster's own next touch, and this is that touch. Recorded as the THIRTY-SIXTH DISSOLUTION, which also writes down why the disposition was nearly the wrong one: the row matched no delta on any open PR and the floor refused namespace-wave-admission on every branch carrying it, so deleting it for a green wall and calling that a trigger firing would have laundered an unpaid debt into a discharged one (DESIGN 4b(3): a declared row is retired by its trigger and by nothing else). DUPLICATE DISSOLUTION DROPPED. This branch's TWENTY-SECOND DISSOLUTION and main's THIRTY-FIFTH describe the same #11071 event. Main's landed ordinal is kept and this branch's copy is deleted rather than both being carried. REVIEW 64431 FINDING 1: source_root_eval_driver_seed_growth_justification was authored but never enrolled in seed_growth_justification_roster, which is an explicit enumeration -- so the row sat in exactly the state its own header argues against, readable by people and by nothing else (DESIGN 3c). One import, one roster line. REVIEW 64431 FINDING 2: a_missing_terminal_marker_refuses had stopped testing its subject. Its fixture carried an identity with no verdict, so after the unrecognized-line refusal added earlier on this branch (48bf101) it hit that NEW arm and returned before the missing-marker check was ever reached -- the test greened identically with the missing-marker refusal deleted. The fixture is now a well-formed population row, so the absent terminal marker is the only remaining cause. Evidence is the pair, not a green: with the missing-marker refusal replaced by a default the test goes RED (panic at native_lane_runner.rs in the assert), and with it restored the test and its sibling pass. Both arms executed locally on this head. RECURRING FAILURE MODE: a_long_phase_prints_nothing_until_it_ends. The SourceRootEvalDriver announces "adjudicating through the emitted compiler" and then emits nothing until the phase terminates, so a live run and a hung run have byte-identical output for the whole span. Found tonight on this branch's own route run, where liveness could only be established out of band from /proc CPU accounting -- an instrument the log does not carry and a CI reader does not have. Rung 1, ceiling 2 (no type makes a process emit a line); the trigger names the capability -- a long-phase carrier declaring the progress grain it reports at -- not "add a progress line to this driver", which would fix one specimen and leave every other long phase with the same surface. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013aZDLk2CxsCDznqn49Xhe8
briansrls
added a commit
that referenced
this pull request
Sep 13, 2026
…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 file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Under ACPI APEI firmware-first mode the firmware handles memory errors and hands
the OS finished error records; the OS never enumerates the memory controller.
ghes_edac exists so one of those records has a DIMM to name -- it registers ONE
synthetic controller and mirrors the SMBIOS Type 17 device list into it. It is an
error-attribution shim, not a memory-controller topology authority, so no csrow or
channel node exists to read on ANY boot absent a native driver.
That sentence was living as prose inside one unit's observation
(gunbc#10965's mtcollins1_edac_channel_map_unavailable_reason), where it is a fact
about a Linux/firmware arrangement wearing a receipt's clothes. DESIGN 3's external
upstream decomposition puts it in extdeps.linux.edac, keyed to the kernel release it
was read against, and leaves the receipt its readings.
What the carrier makes decidable rather than restatable:
is genuinely open upstream (one per memory controller), so the closed part is the
only part that is closed: a controller-enumerating driver is bound, ghes_edac is, or
nothing is.
FirmwareFirstErrorAttributionShim is AbsentOnEveryBoot -- the errand is over;
NoMemoryControllerDriverBound is AbsentUntilDriverBound -- there is something to try.
Collapsing them into one "unavailable" is exactly what books the next pointless boot.
which IS the shim: a controller's enumeration carries channel position, an SMBIOS
Type 17 mirror names slots and never locates a part in the topology.
LinuxKernelRelease moves to a new extdeps.linux.kernel with it. It was declared inside
gunbc.served_surface_browser_observation, a downstream receipt; an extdeps module cannot
import a gunbc one, so keying an upstream fact to a kernel release would have had to
re-coin the brand -- the fork. Its one consumer imports it from the new home.
Consumption (DESIGN 3c): test.claim.linux_edac_topology_authority_witness exercises
every arm of every fold, with a discriminating red on the dmesg detector whose fixture
mentions GHES, EDAC, APEI and firmware and is still not the marker. Both controls were
executed red by mutation before landing. The named later consumer is #10965's receipt,
trigger stated in the module: that PR merging, after which it keeps driver ghes_edac,
apei_firmware_first true, csrow_node_count 0 and the dmesg line, and resolves the WHY
here. Observations this repo produces are receipts in the observing layer, never facts
owned by the observed upstream.
edac.dag leaves the frozen legacy scope manifest and joins scope_carrier_paths, with the
extdeps_model_scope it owed; kernel.dag lands as a carrier.
🤖 Generated with Claude Code
https://claude.ai/code/session_01JGu7gNotcNwnQLyddmmkXs