I am the control policy. I chose Approach B from the free verb library (retrieve-then-evaluate-fit against known failure conditions), running verbs as needed and stopping once the gate decided it.

## Working (verbs run)

**match (retrieve).** I queried the semantic engine with the domain-stripped meta-model — "a critical capability that depends entirely on one component whose failure is catastrophic; build an independent backup path or harden the single element." Top structural hits: Functional Redundancy (Degeneracy), Redundancy, Fault Tolerance, Systemic Risk, Margin of Safety, Refinement.

**match / search_by_facets (oblique decomposition).** The problem instantiates several structures at once (a single-point failure, a duplicate-vs-harden choice, possible correlated failure, a fixed budget). I retrieved per-facet:
- "a single point whose failure takes down the whole system" -> systemic_risk, FMEA, threshold_and_criticality, fail_safe
- "redundancy and diversity so no one failure is catastrophic" -> redundancy, fault_tolerance, diversity, robustness, antifragility
- "improving the reliability of one element versus duplicating it" -> redundancy, refinement, reproducibility
- "correlated failure modes shared across components" -> FMEA, systemic_risk, redundancy, correlation, fault_tolerance
- "allocating a fixed budget for maximum risk reduction" -> risk_pooling, margin_of_safety, opportunity_cost, prioritization, linear_programming
- Fused ranking: redundancy, systemic_risk, FMEA, fault_tolerance, synergy_and_antagonism.

**salience-rank / prune.** I kept the three load-bearing patterns — duplicate-an-alternate-path (the diversity pattern), the continue-service-despite-component-failure property, and the maximize-one-component's-reliability pattern (refinement / margin). I pruned tipping-points, decay, and adaptive-capacity as off-axis for a one-shot funding choice.

**lift (abstraction).** Stepping back to the underlying structure: a function currently realizable by exactly one mechanism has function-loss probability equal to that mechanism's failure probability p. The defining property of the duplicate-path pattern is that combined failure probability of N independent mechanisms collapses toward p^N — an exponential reliability gain — *but only under independence*. Hardening the single mechanism can only push its p downward toward, but never to, zero; the function still has exactly one mechanism, so a single failure still ends it.

**compose (typed relational model).**
- Capability --realized_by--> Component(single) ; failure(Component) => failure(Capability). [the current state: a lone critical node]
- Approach B: invest(budget) -> reduce p(Component). Topology unchanged: still one node, still single-point. Residual p > 0 always.
- Approach A: add Component2 (independent/diverse path); failure(Capability) requires failure(Component1) AND failure(Component2). Topology changed: no node is individually catastrophic.

**evaluate-fit (gate against known failure conditions).** I checked each approach against the two stated success criteria and the catalog's documented failure modes of the diversity pattern.
- Criterion 1 — "no single failure may take down the critical capability." Approach B fails this categorically: improving one component's reliability does not remove the fact that its failure (however unlikely) still takes everything down. It is still a single point of failure. Approach A is the only one whose topology can satisfy this — *conditional* on the second path being genuinely independent.
- Known failure condition of Approach A: correlated / common-mode failure. The catalog is emphatic that duplicate paths sharing a hidden dependency (same power, same code, same upstream service, same operating procedure) do not deliver the reliability math — "independence is the load-bearing property, not the copy count." So A is correct *only if* the budget is spent on a path that is diverse in its failure modes, not a near-clone.
- Criterion 2 — "budget used effectively." Under independence, the second path buys an exponential drop in joint-failure probability for a finite cost, whereas hardening hits diminishing returns against an asymptote it can never cross. So A also dominates on effectiveness once independence is secured.

**reconcile.** B has one genuine virtue: it is simpler and avoids the coordination/detection failure modes that a second path introduces (failover logic, split-brain, a detection step that can itself fail). But that virtue cannot rescue B against Criterion 1 — simplicity of a single point does not stop it being a single point. The reconciliation is to choose A *and* spend the gate's warning forward: earmark the design effort on making the second path's failure modes uncorrelated with the first, and on the failover/detection path, since those are exactly where a nominally-redundant design silently reverts to single-point behavior.

**STOP.** The gate is decisive: only A can meet the hard "no single failure" criterion, and under enforced independence it also wins on budget effectiveness.

===DECISION_BEGIN===
DECISIVE_FACTOR: Hardening the lone component leaves it a single point of failure no matter how reliable it becomes, so only an independent second path can satisfy the hard requirement that no single failure takes down the capability.
CHOICE: A
JUSTIFICATION: Making the one component more reliable lowers the odds of failure but never removes the fact that its failure still ends everything — it stays the single point of failure the success criteria forbid. A second, independent path means the capability survives any one failure, and the chance of both failing at once is far smaller than either failing alone, so a fixed budget buys far more resilience this way. The decisive condition is that the second path must fail for genuinely different reasons than the first — not share its power, code, or upstream dependencies — and the budget should also cover reliable detection and switchover, or the duplication quietly collapses back into a single point of failure.
===DECISION_END===
