docs(r3): Q-MachineConstraint-Carrier RATIFIED — universal substrate + 5 PM defaults

docs/r3-design-schedule-2026-05-06.md

@@ -45,10 +45,19 @@
 
 Prior `AbelianGroup<Nat>` references in r3-structure.md, r3-program-plan.md, this doc are **DEFERRED-shorthand** until design selection lands. **T-Numeric-Construction further dispatch HELD** (Brian directive 2026-05-06) until algebra-side selection ratified. S3 (`MachineConstraint<C>`) interaction modeling proceeds in parallel — once algebra-side resolves, the interaction `Int<N> = Int × MachineWidth<N>` semantics carries through identically under either option (Int participates as AbelianGroup carrier in both).
 
-Carriers needed: `MachineConstraint<C>` + `MachineWidth<bits>` + interaction-lookup substrate. May require additional axes (`RegisterClass<R>`, `EndianMode<E>`, alignment) per use cases.
+**Q-MachineConstraint-Carrier scope RATIFIED 2026-05-06** (Brian directive: "universal substrate, ratify defaults" + clarifying inline 2026-05-06 on sub-decisions 1, 2, 5, 6). Per `r3-program-plan.md` §10.3 Q-MachineConstraint-Carrier row, the 6 sub-decisions are:
+
+1. **Axes in R3 scope**: `MachineWidth<bits>` only. `RegisterClass<R>` / `EndianMode<E>` / alignment / signedness-as-axis deferred post-R3 absent a closure-gate forcing them. **Discipline note (Brian directive)**: this is a separation-of-facts/concerns exercise — algebra is one axis of fact, machine constraint is another, target lowering (e.g., Rust emission) is a *projection / coercion* over both. Integer modeling is the canonical exercise for this discipline; getting comfortable with the separation is the broader R3 modeling work.
+2. **Interaction substrate shape**: **REST-API-style typed-contract interactions between models** (Brian directive 2026-05-06: *"these models interact a la rest apis interacting — scalable / no dual representations (.dag generated)"*). Each model (algebra, machine-constraint) declares its interface in `.dag`; the interaction substrate (composition, projection, coercion) is **`.dag`-generated**, not hand-coded. **Hard constraint: no dual representations** — any Rust counterpart must be generated from `.dag`, never hand-maintained (per `feedback_isomorphism_or_generation_for_mirrors` + `feedback_no_generated_code_on_disk`). Closed-enumeration lookup-maps and parallel Rust mirrors are both rejected (bridges).
+3. **Type-level spelling**: `Int<64>` parses/elaborates as `Compose<AbelianGroup, MachineWidth<64>>` parametrically. Surface intuition is the literal product `Int × MachineWidth<64>`; substrate spelling is parametric. Equivalent under both algebra-side options per PR #1815. **Distinction (per claude review observation)**: the *elaboration* of a particular `Compose<AbelianGroup, MachineWidth<64>>` term is parser/elaborator behavior; the **interaction substrate** (composition/projection/coercion machinery operating *on* such Compose terms) is what's `.dag`-generated per sub-decision 2 — not the `Compose<...>` *type itself*. S3 worker brief should preserve this distinction.
+4. **Approximate-algebra layering**: algebra-side approximation (`ApproximateField<Rational>`) and machine-side approximation (`MachineWidth<64>`) stay as independent axes that compose. `Real<64>` = `Compose<ApproximateField<Rational>, MachineWidth<64>>` carries both layers explicitly per S8's named-axiom-relaxation discipline.
+5. **Demonstration breadth — NOT a target** (Brian directive 2026-05-06: *"3 is not a target, we shouldn't be 'targeting' modeling, we are just doing our best job to faithfully represent the concepts"*). The 3-pair demonstration (`Int<64>` / `Real<64>` / `Nat<8>`) is the **minimum existence proof** that the substrate carries the concept faithfully. **Faithful representation of the concept is the closure criterion**; pair-counting is not. Once the parser handles generic interaction syntax + the substrate carries the algebra+machine separation, all valid pairs work by construction. Closure-gate predicate phrasing should reflect "concept is faithfully modeled" not "≥3 pairs land".
+6. **Target-specificity — universal substrate, faithful target lowering** (Brian directive 2026-05-06 elaborated): `MachineConstraint<C>` is **universal substrate** — every target carries machine-constraint facts as substrate. Targets lacking native machine-width semantics handle lowering by **faithfully representing the concept in a target-available primitive**, NOT by omission. For Python u8: lower to `numpy.uint8` / `ctypes.c_uint8` / explicit literal-bits via `int & 0xFF` discipline — pick whichever Python idiom faithfully carries the 8-bit-natural-number concept. The substrate stays universal; Grounding handles per-target faithful-lowering selection. *Brian framing: "if python lacks — we would have to actually represent the struct using something that python faithfully provides — i.e. either literal bits or otherwise."* Faithful representation > target-conditioned omission.
+
+**S3 dispatch unblocked on machine-constraint side** (independent of T-Numeric-Construction algebra-side Option A vs B selection per PR #1815 — interaction semantics carries through under either). **Sub-decision 2's `.dag`-generated discipline** means S3 worker brief must specify the interaction substrate as `.dag`-declared with any Rust counterpart generated, not hand-authored.
 
 **Dispatch trigger**: now (foundational; gates Class 1 closure).
-**Closure predicate**: §1.8 gate #60 `substrate_gap_parser_grammar_closed` (Class 1 5-criteria Pass: substrate carriers + parser handles generic interaction syntax + ≥3 algebra×constraint pairs emit to target primitives + target primitives NOT primary substrate entities).
+**Closure predicate**: §1.8 gate #60 `substrate_gap_parser_grammar_closed`. **Pass = concept faithfully modeled** (per sub-decision 5 above): substrate carries algebra and machine-constraint as independent axes; interaction substrate is `.dag`-generated; parser handles generic `Compose<...>` interaction syntax; concrete types are derived consequences (not primary entities). The 3-pair set (`Int<64>` / `Real<64>` / `Nat<8>`) lowering without v2-fallback is **minimum existence-proof evidence**, NOT the closure target — once the substrate carries the separation faithfully, all valid pairs work by construction. **§1.4 conjunctive-closure rule still binds** (per claude review observation): "concept faithfully modeled" replaces pair-counting as the success criterion but does NOT relax the conjunctive form (representative gap-test executes AND class-bridge enumeration = 0); see `r3-structure.md` §"Acceptance" + `r3-program-plan.md` §1.4 for the conjunctive rule. Sub-decision 5 narrows the *what counts as Pass*, not *how many things must hold*.
 **Cross-lane**: T-Numeric-Construction provides algebra side (in flight); MachineConstraint<C> is new substrate.
 
 ### S4 — Workflow* family carriers (Class 4)