Roadmap: consequence standing, extension law, scenario evaluation, customer CI failover

dag/gunbc/roadmap/roadmap_authority.dag

@@ -2160,6 +2160,70 @@ fn declared_roadmap_nodes() -> List<RoadmapNode> {
       )),
       parent: in_project(project: "fabric-bringup", contribution: "Fabric decisions follow the declared objective of the work they serve, so one fabric serves both cost-sensitive batch work and latency-sensitive work without being re-tuned for each."),
     ),
+    roadmap_node(
+      identity: "rn_FABRIC0CONSEQUENCE0STAND0A",
+      id: "fabric-consequence-standing",
+      owner: "fleet",
+      carriers: carrier(path: "dag/std/decision.dag"),
+      line: ticket(t: fields(
+        headline: "Every option carries a standing for every consequence its decision requires, and an unknown never becomes zero",
+        boundary: "A decision subject declares the consequence dimensions it requires (supplier spend, accepted work, setup and reconstruction, outstanding liability, and later others). Every candidate carries exactly one disposition per required dimension: observed, estimated (with its conditioning facts and model version), conservatively bounded, proven irrelevant to this candidate, or unestablished. Unestablished asks for evidence or refuses the candidate; it is never read as zero. Keeping a running card is NoSetupRequired; renting one carries an estimated or bounded setup; moving work carries reconstruction. The disposition reuses std.decision axis readings and extdeps.external_authority CitedFigureStanding rather than a new evidence vocabulary.",
+        displaced_cost: "Setup, interruption and reconstruction overhead are real but not fixed, and today they enter a comparison only when the author remembers them. A missing one silently counts as free, which is how a cheaper card looks better than it is and how a migration looks costless.",
+        first_slice: "Add the required-dimension declaration and the per-candidate disposition, and make the flex wait-versus-move decision (fabric-demand-objective) consume it for setup and reconstruction.",
+        red_control: "A candidate with no setup disposition refuses or needs evidence and is never selected as if setup were free; RED is the current path, which treats an absent setup as zero. A bounded setup admits against the cap only through its bound. An irrelevant disposition leaves the decision unchanged.",
+        out_of_scope: "How the estimates are produced (fabric-scenario-evaluation). New valuation semantics (fabric-demand-objective).",
+        handback: "The disposition carrier, its consumer in the wait-versus-move decision, and the missing, bounded and irrelevant controls."
+      )),
+      parent: in_project(project: "fabric-bringup", contribution: "Fabric decisions stop treating unmodelled overhead as free, so cheap and expensive supply are compared on what they actually cost."),
+    ),
+    roadmap_node(
+      identity: "rn_FABRIC0DIMENSION0EXTEND0A",
+      id: "fabric-dimension-extension-law",
+      owner: "fleet",
+      carriers: carrier(path: "dag/std/decision.dag"),
+      line: ticket(t: fields(
+        headline: "Adding a dimension to a decision changes it only through the shared evaluation, and leaves it unchanged where the dimension is irrelevant",
+        boundary: "A new dimension (urgency, cache state, market response, failure domain) enters a decision as a required consequence, a constraint or a valuation of the existing decision subject. It never enters as a new controller or an unconditional rule beside selection. Every extension ships with two executed controls through the real consuming decision path: a case it must change, and a case it must preserve.",
+        displaced_cost: "Each new concern has historically arrived as its own rule (keep running cards, equalise sessions, raise after losing) that competes with the selector. Thirty dimensions become thirty controllers whose combined decisions waste money while each one looks correct.",
+        first_slice: "State the law as a witness pattern and apply it to the first added dimension after fabric-consequence-standing: reconstruction cost changes a move decision in one case and leaves an unrelated decision byte-identical in another.",
+        red_control: "An extension implemented as a side rule (an unconditional keep-incumbent beside selection) passes its own change case but fails the preserve case, or changes decisions where its dimension is irrelevant. The control must go red on that implementation.",
+        out_of_scope: "Choosing which dimensions to add. Monte Carlo estimation.",
+        handback: "The witness pattern, its first application, and the side-rule RED."
+      )),
+      parent: in_project(project: "fabric-bringup", contribution: "The fabric can absorb new dimensions without each one becoming a competing controller."),
+    ),
+    roadmap_node(
+      identity: "rn_FABRIC0SCENARIO0EVALUATE0A",
+      id: "fabric-scenario-evaluation",
+      owner: "fleet",
+      carriers: carrier(path: "dag/std/decision.dag"),
+      line: ticket(t: fields(
+        headline: "Uncertain consequences are estimated over seeded joint scenarios, and a new model revision must do no worse than the old one under the same decision authority",
+        boundary: "A scenario is one coherent possible world: market floors, setup duration and charges, lifetime, throughput, demand arrivals, interruptions, release completion. Coupled facts (cheap cards with slower setup and more interruptions) are drawn together, never as independent axes. Each candidate produces one distribution per outcome dimension; nothing is summed during simulation, and the selector still applies constraints, Pareto and the demand policy. Evaluation keeps a seeded corpus of historical traces and synthetic sweeps, and compares an old and a new MODEL OR IMPLEMENTATION revision on identical seeds while holding the decision authority fixed: decision subject, objective and valuations, hard constraints, candidate-field authority, horizon and outcome interpretation. A changed demand objective is a different decision judged under its own authority, never a regression against another. Gates: no added budget or correctness violation, no dominated choice, the preservation control owned by fabric-dimension-extension-law, and regret no worse than the old revision beyond a declared threshold. This runner is the implementation that law's preservation control consumes.",
+        displaced_cost: "Bidder and balancer changes are judged by anecdote after deployment; the ownership-limit and failed-release overspends were found by hand-built repros after merge. A policy change has no pre-merge evidence that it makes fewer costly mistakes across plausible markets.",
+        first_slice: "A deterministic seeded scenario runner for the flex keep, release, rent, release-then-rent and wait candidates over the four first dimensions, plus one paired old-versus-new comparison on a small fixed corpus.",
+        red_control: "Structural failures, not profitability claims: (a) a revision whose only response to a loss is a higher bid with no declared update law crosses the budget or ceiling invariant in a named scenario; (b) a revision in which changing ONLY prior ownership changes the selection among otherwise equivalent present offers is refused. The same seed always gives the same outcome vectors; an independent-axis sampler is refused where a coupling is declared; comparing two different objectives under one regret is refused.",
+        out_of_scope: "Learning market response. Random sampling in the required CI path: the corpus is seeded and deterministic.",
+        handback: "The runner, the seeded corpus, the paired gate, and the two historical-defect REDs."
+      )),
+      parent: in_project(project: "fabric-bringup", contribution: "Fabric policy changes carry pre-merge evidence that they make fewer costly mistakes, rather than being judged after deployment."),
+    ),
+    roadmap_node(
+      identity: "rn_FABRIC0CI0FAILOVER0SELECT0A",
+      id: "fabric-customer-ci-failover",
+      owner: "fleet",
+      carriers: carrier(path: "dag/gunbc/ci/ci_runner_target.dag"),
+      line: ticket(t: fields(
+        headline: "Customer CI failover, balancing, cloud burst and return-to-owned-capacity are one policy-bound allocation over uncertain supply",
+        boundary: "Customer CI hosting onboards to the shared decision interface (conformance-decision) as a named consumer. Demand is a job or job DAG with the customer's declared objective; supply is owned bare metal plus stable cloud (OCI, AWS, GCP), each described by observed facts (failure and recovery distributions, failure domains, startup, quota, price, storage reachability), never by a reliable or unreliable label. A candidate is the current allocation plus a transition sequence to a target, so the cost and feasibility of getting there is chosen too. Customer disruption stays decomposed: time to next accepted result, repeated work, interrupted jobs, SLO-miss probability. When capacity is scarce across N failed customers, the allocation is selected over the complete candidate field under the affected demands' declared objectives and constraints; delay relative to each customer's own allowance is carried as an axis reading or a contract constraint, not as the universal deciding rule, and a contract may select minimax normalized disruption as its own policy. Durable execution authority (job, attempt, fence, receipts) survives every host; portable state rides network storage, which is itself supply and a failure domain. Spare capacity is a selected operating point, not a constant.",
+        displaced_cost: "Without this, customer CI failover becomes a separate system with its own priority rules, re-solving the selection, fencing and budget problems the fabric already owns, and inferring customer priority from whoever complained last.",
+        first_slice: "One CI workload class, one customer profile, the owned runner pool, one cloud fallback and one durable storage path; candidates stay, move to another owned host, burst to cloud, wait; consequences spend, time to accepted result, repeated work, liability; one executed cutover with fencing and readback. Add customer CI failover to the conformance-decision named consumers.",
+        red_control: "(1) Batch work: owned host fails; waiting or another owned host beats cloud. (2) Latency-sensitive PR: the same failure bursts to cloud. (3) A dominating destination is chosen by both profiles. (4) Storage unavailable: a healthy cloud runner is not a feasible destination. (5) Destination startup fails: old capacity is not released and no false cutover is published. (6) A late old runner cannot publish a second result. (7) N-customer outage: capacity goes where the affected demands' declared objectives and contracts select, and changing one customer's contract changes the outcome through that authority only. (8) Changing only the customer objective changes the winner in a real tradeoff.",
+        out_of_scope: "Multi-provider procurement beyond one fallback. Selling CI capacity. Changing the repository's own runner target (gunbc.ci.ci_runner_target selected_ci_runner_target) until this consumer is green.",
+        handback: "The CI consumer on the shared interface, the executed cutover with fencing, and the eight-case receipt."
+      )),
+      parent: in_project(project: "fabric-bringup", contribution: "Customer CI hosting rides the same fabric decision as inference serving, so failover and bursting are allocation choices rather than a second scheduler."),
+    ),
     roadmap_node(
       identity: "rn_HARNESS0RECURSIVE0ALIGN0A",
       id: "harness-recursive-alignment",
@@ -4514,6 +4578,12 @@ fn declared_roadmap_edges() -> List<RoadmapEdge> {
     edge(child: "2-scm-mercurial-upstream-model", parent: "fabric-bringup"),
     edge(child: "2-scm-pijul-upstream-model", parent: "fabric-bringup"),
     edge(child: "2-claim-indexed-evidence", parent: "fabric-bringup"),
+    edge(child: "fabric-consequence-standing", parent: "fabric-demand-objective"),
+    edge(child: "fabric-dimension-extension-law", parent: "fabric-consequence-standing"),
+    edge(child: "fabric-scenario-evaluation", parent: "fabric-consequence-standing"),
+    edge(child: "fabric-scenario-evaluation", parent: "fabric-dimension-extension-law"),
+    edge(child: "fabric-customer-ci-failover", parent: "fabric-consequence-standing"),
+    edge(child: "fabric-customer-ci-failover", parent: "fabric-demand-objective"),
     edge(child: "2-scm-compatibility-shape", parent: "2-scm-git-upstream-model"),
     edge(child: "2-scm-compatibility-shape", parent: "2-scm-mercurial-upstream-model"),
     edge(child: "2-scm-compatibility-shape", parent: "2-scm-pijul-upstream-model"),