# w_FC6 — Resilience approach decision (free verb library, Approach B path)

## Working (verbs run)

**lift** — Step back from the surface (vendor, budget, "component") to the underlying structure: a critical capability whose continuity hangs on one element, with two rival ways to spend a fixed resilience budget — duplicate the path vs. perfect the single path. The deep question is whether the success criterion ("no single failure may take down the critical capability") is achievable by improving one element at all.

**match (retrieve)** — Queried `search_prime` with the domain-stripped meta-model ("a critical function depends entirely on a single element whose failure is catastrophic; resilience through an independent backup path versus hardening the one element"). Top distinctive hit: **Resilience**; also **Functional Redundancy (Degeneracy)**, **Systemic Risk**, **Margin of Safety**.

**match (oblique → search_by_facets)** — Decomposed into structural facets. Per-facet results:
- "single point whose failure takes down the whole system" → systemic_risk, fmea, **fail_safe**
- "an independent redundant path so no one failure is catastrophic" → **redundancy (0.72)**, fail_safe, **fault_tolerance**, robustness
- "hardening one element to reduce its probability of failure" → gradual_deterioration, stress_rupture, margin_of_safety
- "a trusted incumbent advocating a self-interested option" → **trust**, mechanism_design_and_incentive_structure, authority
- "correlated failure when diversity is absent" → **correlation**, redundancy, fmea

**salience-rank** — Load-bearing primes: **redundancy** (the A-path's logic), **systemic_risk** (why the single point is the hazard), and the **trust/incentive** facet (how to weight the vendor's advocacy). The "hardening one element" facet retrieved only *degradation/margin* patterns — none of which remove a single point of failure; that is diagnostic on its own.

**prune** — Dropped tipping_points, scaling, critical_juncture, fading: surface-similar (failure/threshold vocabulary) but not about the redundancy-vs-hardening allocation. Kept the failure-architecture cluster.

**compose (typed relational model)** —
- *Element* E: sole carrier of capability C. P(E fails) = p > 0, irreducibly.
- *Approach B*: lower p → p′ (smaller, never zero). Topology unchanged: one node, one path.
- *Approach A*: add independent path E₂. P(C lost) ≈ p·p₂ **iff failures are independent**; the single-point-of-failure node is eliminated.
- *Vendor V*: trusted, but incentive aligns with B (B routes the whole budget to V's own product). Advocacy is information, but it is **interested** information about its own component.

**evaluate-fit (gate against known failure conditions)** —
- Against the success criterion "no single failure may take down the capability": **B structurally cannot satisfy it.** Hardening lowers the *probability* of the single failure but the single point of failure still exists — p′ > 0, and one failure of E still takes down C. A satisfies it by construction (alternate pathway maintains function through the failure).
- Gate on A's load-bearing precondition: redundancy only pays off if the second path fails **independently** — no shared power, network, code, or, critically here, **no shared vendor/dependency**. So A must be built as a genuinely *diverse* path, not a second copy of the same component from the same supplier. This is the real engineering work and the place the budget must be spent carefully.
- Gate on the vendor facet: the trusted-incumbent's recommendation (B) maximizes dependence on a single supplier — itself a correlated-failure / single-point exposure. Individually prudent hardening of one node does not aggregate to system safety; concentrating on one well-managed component is exactly the configuration that fails all at once. The trust is real but does not change the topology.

**reconcile** — B's only advantage (a hardened single path is cheaper and the partner is reliable) cannot clear the hard success constraint: a single failure must not be able to take down the capability, and a single path — however reliable — always leaves that possibility open. A clears it, provided the budget buys *independence* (a different implementation/supplier), which also dissolves the single-vendor concentration the incumbent's proposal would deepen. The vendor's reliability is best used *inside* a diverse architecture, not as a substitute for one.

**STOP** — Decision is sound. Choose **A**, with the explicit condition that the second path be independent in its failure modes (different supplier/implementation), or the spend is wasted.

===DECISION_BEGIN===
DECISIVE_FACTOR: A single path, no matter how reliable it is made, still leaves one failure able to take down the whole capability — only an independent second path removes that single point of failure.
CHOICE: A
JUSTIFICATION: The stated goal is that no single failure can take down the critical capability, and spending the whole budget to make the one existing component more reliable only lowers the odds of that failure without ever removing it — the single point of failure remains. Building a second, independent path is the only option that actually meets the goal, because the capability survives even when the original component fails. The budget must go toward making that second path genuinely independent — a different design and supplier — since duplicating the same component from the same partner would fail at the same time and defeat the purpose. The incumbent's reliability is valuable but is best used as one leg of a diverse setup rather than as the sole thing everything depends on.
===DECISION_END===
