Model the 64 GiB DIMM upgrade: an OEM offering, a stacking axis, and the fleet's first measured MemTotal

dag/extdeps/memory/cisco_ucs.dag

@@ -0,0 +1,60 @@
+module extdeps.memory.cisco_ucs
+
+import std.decl_ref { DeclarationRef, WholeDeclaration }
+import extdeps.memory.types { OemModuleOffering, OemModuleLinkEvidence, OemLinkPhysicalLabelObserved }
+import extdeps.memory.samsung { m393a8g40d40_crb0q_catalog }
+import extdeps.vendor.cisco { cisco }
+import extdeps.external_authority { ExternalAuthority, ExternalModelScope, ExternalSubjectRef }
+import extdeps.uri { Uri, Https }
+
+data extdeps_external_authority_anchor: ExternalAuthority = ExternalAuthority {
+  uri: Uri {
+    scheme: Https
+    locator: "www.cisco.com/c/en/us/products/servers-unified-computing/ucs-c-series-rack-servers/datasheet-listing.html"
+  }
+}
+
+data extdeps_model_scope: ExternalModelScope = ExternalModelScope {
+  subject: ExternalSubjectRef {
+    declaration: DeclarationRef {
+      module_path: "extdeps.memory.cisco_ucs",
+      decl_name: "ucs_mr_1x648ru_a",
+      field: WholeDeclaration
+    }
+  },
+  first_citation: extdeps_external_authority_anchor,
+  further_citations: []
+}
+
+// WHY THIS MODULE EXISTS SEPARATELY FROM extdeps.memory.samsung (DESIGN 3).
+// Cisco resells a Samsung module under its own PID and part number, with its own lifecycle and
+// its own published description. That is a second independently governed entity inhabiting the
+// same shape, not a second name for the Samsung row -- so it gets its own module authority and
+// REFERENCES the module rather than restating its organization axes. A second OEM reselling the
+// same part would be another row here and no edit to Samsung at all.
+//
+// CITATION STANDING, STATED HONESTLY BECAUSE IT IS WEAKER THAN THE ANCHOR SUGGESTS.
+// The anchor above is Cisco's C-Series datasheet index, not a document carrying this PID. The
+// per-PID spec sheets under cisco.com/c/dam refuse automated retrieval (HTTP 403, checked
+// 2026-08-22), and the M4-era memory guide that would carry a 2133 TSV-RDIMM was not reachable.
+// What established the description below was agreement across independent distributor listings
+// -- 64 GB, DDR4-2133 / PC4-17000, TSV-RDIMM, octal rank, x4, 1.2 V, CL15 -- corroborated by the
+// operator's physical label. That is a real basis and it is NOT a first-party reading, which is
+// exactly the distinction OemModuleLinkEvidence's two arms exist to keep visible.
+// Dissolve-on: a reachable Cisco memory guide or spec sheet listing this PID, at which point the
+// anchor names that document and this paragraph shrinks to a citation.
+//
+// WHAT THE LABEL SETTLED THAT NOTHING ELSE COULD. The label reads
+// "M393A8G40D40-CRB0Q S", which is what links this Cisco PID to that specific Samsung part
+// number -- no reachable Cisco document names the underlying manufacturer part at all. The link
+// is therefore an observation of the part in hand, recorded as such.
+data ucs_mr_1x648ru_a: OemModuleOffering = OemModuleOffering {
+  oem: cisco,
+  oem_product_id: "UCS-MR-1X648RU-A",
+  oem_part_number: "15-102952-01",
+  underlying_module: m393a8g40d40_crb0q_catalog,
+  link_evidence: OemLinkPhysicalLabelObserved {
+    label_text: "M393A8G40D40-CRB0Q S",
+    observer: "operator, physical label on the module in hand, 2026-08-22",
+  },
+}

dag/extdeps/memory/samsung.dag

@@ -1,7 +1,7 @@
 module extdeps.memory.samsung
 
 import std.measure { ByteSize, byte_size, bit_width }
-import extdeps.memory.types { DramModuleCatalogRow, DimmBuffering, dram_generation_ddr4 }
+import extdeps.memory.types { DramModuleCatalogRow, DimmBuffering, dram_generation_ddr4, MonolithicDie, ThreeDimensionalStacked }
 import extdeps.vendor.samsung { samsung }
 import extdeps.external_authority { ExternalAuthority, ExternalModelScope, ExternalSubjectRef }
 import std.decl_ref { DeclarationRef, WholeDeclaration }
@@ -59,7 +59,49 @@ data m386a4g40dm0_cpb_catalog: DramModuleCatalogRow = DramModuleCatalogRow {
   data_rate_mts: 2133,
   ecc: true,
   buffering: LoadReduced,
+  die_stacking: MonolithicDie,
   chip_width: bit_width(4),
 
   rank_count: 4,
 }
+
+data stick_capacity_bytes_64g: ByteSize = byte_size(68719476736)
+
+// PROVENANCE, AND IT IS THE SAME STANDING AS THE ROW ABOVE RATHER THAN A STRONGER ONE.
+// No first-party Samsung datasheet for M393A8G40D40-CRB0Q was reachable (checked 2026-08-22):
+// the per-part paths under semiconductor.samsung.com serve a generic DDR overview, as they do
+// for the EOL SKU above. What IS reachable is the Cisco OEM offering that resells this module
+// (extdeps.memory.cisco_ucs), whose published description carries capacity, data rate, module
+// type, rank organization, chip width and voltage. Those third-party distributor listings agree
+// with each other and with the operator's physical label; none of them is Samsung.
+//
+// So this row's figures are the OEM description plus the label, NOT a manufacturer datasheet
+// reading, and the module anchor cites DDR4 only. Dissolve-on: a Samsung product-selection guide
+// or module datasheet carrying this part, at which point these become cited facts.
+//
+// THE ORGANIZATION AXES ARE THE POINT OF THIS ROW AND THEY DISAGREE WITH ONE OBSERVATION.
+// Cisco describes the offering as OCTAL RANK, x4, 3DS/TSV. The BMCs on srv3 and srv4 report
+// RankCount=2 for the installed modules. These are NOT competing answers to one field: a 3DS
+// module presents stacked dies behind one package load, and a management controller reporting
+// what the memory subsystem enumerates is a per-host observation, not a property of the part.
+// rank_count here carries the module's LOGICAL rank organization, which is what both consumers
+// of this field need -- see the field's own note in extdeps.memory.types. The Redfish figure
+// lives with the host observation that produced it and is not authored back into this row.
+//
+// COROLLARY THE REALIZABILITY CHECK CANNOT CATCH, stated so nobody reads a green as proof:
+// dram_module_required_die_density passes at BOTH 8 (4 Gbit/die) and 2 (16 Gbit/die, exactly
+// the DDR4 monolithic ceiling), so a wrong rank_count here lands silently. The value is settled
+// by the OEM description, not by the wall.
+data m393a8g40d40_crb0q_catalog: DramModuleCatalogRow = DramModuleCatalogRow {
+  part_number: "M393A8G40D40-CRB0Q",
+  manufacturer: samsung,
+  generation: dram_generation_ddr4,
+  capacity_bytes: stick_capacity_bytes_64g,
+  data_rate_mts: 2133,
+  ecc: true,
+  buffering: Registered,
+  die_stacking: ThreeDimensionalStacked,
+  chip_width: bit_width(4),
+
+  rank_count: 8,
+}

dag/extdeps/memory/sk_hynix.dag

@@ -1,7 +1,7 @@
 module extdeps.memory.sk_hynix
 
 import std.measure { ByteSize, byte_size, bit_width }
-import extdeps.memory.types { DramModuleCatalogRow, DimmBuffering, dram_generation_ddr4 }
+import extdeps.memory.types { DramModuleCatalogRow, DimmBuffering, dram_generation_ddr4, MonolithicDie }
 import extdeps.vendor.sk_hynix { sk_hynix }
 import extdeps.external_authority { ExternalAuthority }
 import extdeps.uri { Uri, Https }
@@ -23,6 +23,7 @@ data hma82gr7afr4n_vk_catalog: DramModuleCatalogRow = DramModuleCatalogRow {
   data_rate_mts: 2666,
   ecc: true,
   buffering: Registered,
+  die_stacking: MonolithicDie,
   chip_width: bit_width(4),
 
   rank_count: 1,
@@ -36,6 +37,7 @@ data hma82gr7afr8n_vk_catalog: DramModuleCatalogRow = DramModuleCatalogRow {
   data_rate_mts: 2666,
   ecc: true,
   buffering: Registered,
+  die_stacking: MonolithicDie,
   chip_width: bit_width(8),
 
   rank_count: 2,

dag/extdeps/memory/training.dag

@@ -11,6 +11,7 @@ import extdeps.memory.types {
   DramModuleCatalogRow,
   JedecDdrGenerationCatalogRow,
   LoadReduced,
+  MonolithicDie,
   Registered,
   Unbuffered,
   dram_data_chips_per_rank,
@@ -118,6 +119,11 @@ fn module_executes_step(module: DramModuleCatalogRow, step: MemoryTrainingStep)
 // load-reduced ones. The buyer's intuition that a lower speed grade is simply
 // a discount is therefore wrong at capacities near the density ceiling: the
 // older part is not the same module clocked slower, it is a different topology.
+// MonolithicDie in the constructed row below is load-bearing, not a default carried over from
+// the input. This builds the COUNTERFACTUAL plain module -- the one that would exist if the
+// capacity were reachable without the two escapes the comment above names, extra ranks and
+// stacking. Propagating module.die_stacking would ask "is this capacity reachable given that it
+// is already stacked", which is trivially yes and answers nothing.
 fn hypothetical_module_at_rank_count(
   module: DramModuleCatalogRow,
   rank_count: Int,
@@ -130,6 +136,7 @@ fn hypothetical_module_at_rank_count(
     data_rate_mts: module.data_rate_mts,
     ecc: module.ecc,
     buffering: Registered,
+    die_stacking: MonolithicDie,
     chip_width: module.chip_width,
     rank_count: rank_count,
   }

dag/extdeps/memory/types.dag

@@ -98,6 +98,29 @@ fn dram_module_class_eq(a: DramModuleClass, b: DramModuleClass) -> Bool {
     })
 }
 
+// WHY die_stacking IS A REQUIRED FIELD ON THE ROW AND NOT AN OPTION (2026-08-22).
+// DramDieStacking already existed as an axis, declared above for the controller-admission
+// question, but the catalog row could not say which value a module carried -- so a 3DS RDIMM
+// and a monolithic RDIMM were indistinguishable in the only carrier a consumer reads. That is
+// the fused-axis defect the DramModuleClass comment above repairs for the CONTROLLER, left
+// standing in the MODULE. The two must agree or the admission check answers about a class no
+// row can claim membership in.
+//
+// It is required rather than optional because the state it excludes is exactly the one that
+// caused this: a stacked module authored by someone who did not know the axis existed, landing
+// as a monolithic-looking row that the Altra admission check then grades against the wrong
+// class. An Option would have made forgetting it representable and re-opened that door
+// (DESIGN 5 -- prefer the shape in which the bad state cannot be written).
+//
+// rank_count STAYS ONE FIELD, and that is a deliberate finding rather than an omission. Both
+// of its consumers are correct for a stacked part when it carries the module's LOGICAL rank
+// organization: dram_module_required_die_density divides capacity by (data chips x ranks) to
+// get PER-DIE density, which is the figure JEDEC's monolithic ceiling actually bounds, and
+// devices_per_stick multiplies chips-per-rank by ranks to get a DIE count, which is what a
+// stacked package contains. Neither wanted a package count. A management controller's own
+// reported rank number is a DIFFERENT fact -- an observation of one host's slot, not a
+// property of the part -- and belongs in the observing layer, never authored back here
+// (DESIGN 3, external upstream decomposition).
 type DramModuleCatalogRow {
   part_number: NonEmptyStr
   manufacturer: Vendor<Hardware>
@@ -109,6 +132,7 @@ type DramModuleCatalogRow {
   ecc: Bool
 
   buffering: DimmBuffering
+  die_stacking: DramDieStacking
 
   chip_width: BitWidth
 
@@ -138,6 +162,35 @@ fn dram_module_is_realizable(module: DramModuleCatalogRow, jedec: JedecDdrGenera
   }
 }
 
+// --- OEM RESALE IDENTITY -------------------------------------------------------------------------
+//
+// AN OEM OFFERING AND THE MODULE INSIDE IT ARE TWO INDEPENDENTLY GOVERNED FACTS (DESIGN 3,
+// external upstream decomposition). Cisco assigns a PID and a Cisco part number, publishes its
+// own specification, and controls that offering's lifecycle; Samsung manufactures a module with
+// its own part number and its own organization. Flattening them into one catalog row -- an
+// "OEM part_number" field, or a Cisco row duplicating the Samsung organization axes -- makes one
+// authority answer for the other, and the duplicate drifts the moment either side revises.
+//
+// So the offering REFERENCES the module rather than restating it. Adding a second OEM that
+// resells the same Samsung part is then a new offering row and no edit at all to the module.
+type OemModuleOffering {
+  oem: Vendor<Hardware>
+  oem_product_id: NonEmptyStr
+  oem_part_number: NonEmptyStr
+  underlying_module: DramModuleCatalogRow
+  link_evidence: OemModuleLinkEvidence
+}
+
+// HOW WE KNOW THE OFFERING CONTAINS THAT MODULE, and the arms are not interchangeable.
+// A supplier document is an upstream claim we can cite and re-read. A physical label read off
+// the part in hand is an OBSERVATION this repository produced -- a receipt in the observing
+// layer, admissible and often the only thing available for an EOL SKU, but never citable as
+// though the OEM had documented it. Recording which one we have is the difference between a
+// grounded row and one that merely looks grounded (DESIGN 4b, rung honesty).
+type OemModuleLinkEvidence
+  = OemLinkDocumentedBySupplier { citation: ExternalAuthority }
+  | OemLinkPhysicalLabelObserved { label_text: NonEmptyStr, observer: NonEmptyStr }
+
 type MemoryPopulationRow {
   module: DramModuleCatalogRow
   stick_count: Int

dag/extdeps/vendor/cisco.dag

@@ -0,0 +1,30 @@
+module extdeps.vendor.cisco
+
+import std.decl_ref { DeclarationRef, WholeDeclaration }
+import extdeps.vendor { Vendor }
+import extdeps.hardware { Hardware }
+
+import extdeps.external_authority { ExternalAuthority, ExternalModelScope, ExternalSubjectRef }
+import extdeps.uri { Uri, Https }
+
+data extdeps_external_authority_anchor: ExternalAuthority = ExternalAuthority {
+  uri: Uri {
+    scheme: Https
+    locator: "en.wikipedia.org/wiki/Cisco"
+  }
+}
+
+data extdeps_model_scope: ExternalModelScope = ExternalModelScope {
+  subject: ExternalSubjectRef {
+    declaration: DeclarationRef {
+      module_path: "extdeps.vendor.cisco",
+      decl_name: "cisco",
+      field: WholeDeclaration
+    }
+  },
+  first_citation: extdeps_external_authority_anchor,
+  further_citations: []
+}
+
+
+data cisco: Vendor<Hardware> = Vendor { legal_name: "Cisco Systems, Inc." }