# Control-policy run — FC6 (condition C)

Acting as the CONTROL POLICY. Verbs run in order below; each reads/writes the shared STATE. Condition C enforces the checkable post-conditions (compose → referential integrity; lift-L1 → witness-check; lift-L2 → coverage map with no `missing`; evaluate-fit → every anti-signature evaluated) before any final recommendation.

---

## STATE.problem
- **statement:** A critical capability depends entirely on one component. Fixed budget. Pick exactly one: (A) build a second, independent path; (B) spend the whole budget hardening the one existing component.
- **constraints:** fixed budget (the spend is mutually exclusive across A/B); exactly one approach funded.
- **success_criteria:** No single failure may take down the critical capability AND the budget is used effectively.
- **failure_criteria:** A single failure can still take down the capability; or budget spent on something that cannot meet the success criterion.

## Verb: match (retrieve)
Meta-model query (domain-stripped): *a critical function depends on a single point whose failure is catastrophic; resilience via an independent parallel path vs. hardening the one path.* Also ran facet decomposition (single-point-of-failure / independent-parallel-path / hardening-cannot-eliminate-SPOF / correlated-common-cause failure / fixed budget across competing strategies).

Candidates (with source-prime overlap recorded):
- `redundancy` — **load_bearing.** Facet "redundancy through an independent diverse parallel path" → 0.77 (top hit). The operative pattern.
- `systemic_risk` — context/anti-signature carrier. Surfaces on the common-cause facet (correlated failure when paths share a cause).
- archetype `common_mode_failure_analysis` (source primes: redundancy, functional_redundancy, coupling) — carries the anti-signatures that gate Approach A.
- archetype `diverse_functional_redundancy` — the design form of Approach A; supplies the diversity/independence requirement.
- context-only: `threshold_and_criticality`, `fail_safe`, `fault_tolerance` (neighborhood; not load-bearing for the A-vs-B choice).

## Verb: salience-rank (verified by ablation)
- `redundancy` — **load_bearing.** Remove it and the choice has no principled basis: its load-bearing mathematical property (probability of simultaneous *independent* failure shrinks exponentially in copy count; a single component's failure probability is nonzero and irreducible to zero) is what decides A vs. B.
- common-mode / independence requirement — **load_bearing.** It is the one thing that can disqualify Approach A as actually built, so it must be checked, not assumed.
- `systemic_risk` — context. Frames *why* hardening can't reach the goal but doesn't itself pick the approach.

## Verb: prune
Operative subset retained: {`redundancy`, independence/common-mode requirement, `systemic_risk` (context)}. Cut the threshold/criticality and fail-safe neighbors — they describe failure *dynamics*, not the redundancy-vs-hardening allocation question.

## Verb: compose (Post: referential integrity — every edge references declared nodes; every operative prime appears as an annotation)
nodes:
- n1 = critical_capability {kind: function}
- n2 = existing_component {kind: component}
- n3 = proposed_second_path {kind: component}
- n4 = shared_environment / common_cause {kind: dependency}
- n5 = budget {kind: resource}

edges:
- e1: n2 → n1, relation `solely_provides` [annot: SINGLE_POINT_OF_FAILURE — n1 fails iff n2 fails]
- e2: n3 → n1, relation `alternately_provides` [annot: redundancy — n1 survives if either n2 or n3 works]
- e3: n4 → {n2,n3}, relation `could_disable_together` [annot: redundancy.independence_requirement / systemic_risk — correlated failure defeats e2]
- e4: n5 → {n2 OR n3}, relation `funds_exactly_one` [annot: budget constraint]

Referential integrity: all edges reference declared nodes (n1–n5); operative primes `redundancy` (e2, e3) and `systemic_risk` (e3) both appear as annotations. PASS.

## Verb: lift — L1 (model → meta_model). (Post: every role/relation has a witness; no domain terms remain)
meta_model:
- **roles:** WHOLE (a function that must persist); SOLE-PROVIDER (one element the whole currently depends on entirely); ALT-PROVIDER (a candidate second element discharging the same function); SHARED-CAUSE (a condition that could disable providers together); FIXED-RESOURCE (a one-shot allocation, split A-or-B).
- **relations:** WHOLE-persists-iff-(SOLE OR ALT); RESOURCE funds exactly one of {harden-SOLE, build-ALT}.
- **invariants:** (i) any single element has nonzero, non-eliminable failure probability; (ii) whole survives a single element's failure ⇔ ≥2 elements can each discharge the function AND they do not fail together; (iii) reducing one element's failure probability never makes it zero, so a lone provider always remains a single point whose failure is total.
- witness-check: WHOLE↦critical_capability(n1); SOLE-PROVIDER↦existing_component(n2); ALT-PROVIDER↦proposed_second_path(n3); SHARED-CAUSE↦n4; FIXED-RESOURCE↦budget(n5); relations witnessed by e1,e2,e4; invariant (iii) witnessed by e1. No domain terms remain in the role/relation/invariant names. PASS.

## Verb: reconcile (apply candidate logic to model and meta_model separately)
- **Concrete model reading:** Hardening n2 lowers P(n2 fails) but leaves e1 intact — n1 still fails *iff* n2 fails. The single point persists. Building n3 replaces e1's "iff" with e2's "either/or" — n1 now survives n2's failure.
- **Meta-model reading:** By invariant (iii), a lone SOLE-PROVIDER, however hardened, is still a single point whose failure is total — so success_criterion #1 ("no single failure may take down the capability") is *structurally* unreachable by hardening. Only adding an ALT-PROVIDER (invariant ii) can satisfy it, conditional on the no-common-cause clause.
- **Divergence resolved:** The two views agree on direction (A) but the meta-model adds the decisive sharpening the concrete view alone could miss — that B's failure is *categorical* (criterion #1 can never be met), not merely *quantitative* (B is "less good"). The meta-model is not decorative: it converts "A is better" into "B is disqualified by the success criterion as written." Reading consistent with both: **A**, provided independence holds.

## Verb: lift — L2: SCOPED COVERAGE CHECK on the single operative pattern the chosen approach (A) relies on
Pattern in hand: **independent parallel path / redundancy** (design form: diverse functional redundancy). Components named from the pattern; each posed as a candidate requirement and coverage-checked against the Approach-A design. (Statuses: instantiated | homolog | correctly_declined | missing — none may be `missing` at STOP.)

```
coverage_map:
  pattern: redundancy (independent-parallel-path; diverse functional redundancy)
  components:
    - name: Protected function (what must continue)
      status: instantiated
      witness: the critical capability (n1) — explicitly the thing that must survive a single failure.
    - name: Alternative pathway (a second element that discharges the same function)
      status: instantiated
      witness: Approach A = "a second, independent path so the capability survives if the existing component fails" (n3, edge e2).
    - name: Functional-equivalence check (the alt actually delivers the function)
      status: instantiated
      witness: A is specified as a path for the SAME capability; equivalence is the premise of "the capability survives."
    - name: Failure-mode INDEPENDENCE / no-common-cause (the load-bearing property)
      status: instantiated
      witness: A is named "a second, INDEPENDENT path ... no single point whose failure is catastrophic." This is the property that makes the exponential reliability gain real; it is the single thing that, if violated, collapses A back toward B. Must be actively verified (separate power/supply/lineage/operator), not assumed — flagged as the binding design risk in the post-conditions below.
    - name: Activation / selection rule (how the alt carries the function on failure)
      status: homolog
      witness: discharged by the "survives if the existing component fails" clause — a failover/either-suffices selection; concrete mode (active-active vs standby) is a downstream design choice, structurally covered.
    - name: Coverage/capacity profile (alt carries enough of the function)
      status: homolog
      witness: implied by "the capability survives" — alt must carry at least the critical load; sizing is downstream but the requirement is captured.
    - name: Voting / N-of-M arbitration
      status: correctly_declined
      decline_reason: over-build. The problem is single-component → make-it-survive-one-failure (a 1→2 path step). Majority-voting among ≥3 copies adds machinery the success criterion ("no SINGLE failure") does not require; the abstract voting frame would distort a sub-structure the simple second-path handles naturally. (over-lift guard)
    - name: Common-mode mitigation governance / residual-risk register
      status: correctly_declined
      decline_reason: over-build at the FUND/CHOOSE decision granularity. Naming the independence requirement (above) is necessary to choose A; standing up an ongoing residual-risk governance program is an implementation artifact, not part of the A-vs-B funding decision. Declined to avoid distorting the scoped choice.
```
Post (CHECKABLE): every component carries a status; instantiated/homolog carry witnesses; correctly_declined carry reasons; **no component is `missing`** → the design is eligible to STOP. PASS.

## Verb: evaluate-fit (gate) — walk Approach A's anti-signatures (from common_mode_failure_analysis & diverse_functional_redundancy)
- **"No backup exists yet; this is just provisioning, not the choice"** — tripped? **No.** The decision IS whether to fund a second path; provisioning is exactly the chosen act.
- **"Alternatives differ in name only / nominal (false) redundancy — share power, credentials, vendor, location, code lineage"** — tripped? **Not necessarily, but it is the live risk.** A is specified as *independent*; the gate keeps A only on condition the independence is engineered and tested (separate power/supply/operator/lineage), per the load-bearing component above. Conditional KEEP.
- **"Different but not functionally equivalent (alt can't meet timing/scale/quality)"** — tripped? **No** on the framing; A is a path for the same capability. Equivalence-sizing is a downstream requirement, already posed.
- **"Shared cause already known and accepted; no decision rides on independence"** — tripped? **No.** A decision rides on it and independence is achievable within scope.
- **"Over-diversification / unnecessary complexity"** — tripped? **No.** A 1→2 independent-path step is the minimum that meets criterion #1; voting/N-of-M were declined above.

Verdict on A: **KEEP**, conditioned on engineering genuine failure-mode independence between the two paths (the only way A's value is real rather than cosmetic).

Symmetric check on B against the success criterion: B reduces P(failure) of n2 but cannot change edge e1 — n1 still fails iff n2 fails. By meta-model invariant (iii), B leaves a single point whose failure is total. B therefore **cannot satisfy success_criterion #1 ("no single failure may take down the critical capability") at any reliability level**, so "effective use of budget" is moot — the budget is spent on a target that is structurally incapable of meeting the stated bar. DROP B.

## STOP — recommendation
Fund Approach A (the second, independent path), and spend the design effort on making the two paths genuinely independent (no shared power, supply, location, operator, or design lineage), because only an alternate path — not a more-reliable single component — can satisfy "no single failure may take down the capability."

===DECISION_BEGIN===
DECISIVE_FACTOR: The stated bar — no single failure may take down the capability — is structurally unreachable while everything rides on one component, because that component's failure probability can be lowered but never driven to zero, so only a genuinely independent second path can meet it.
CHOICE: A
JUSTIFICATION: Making the one component more reliable lowers the odds of failure but leaves it as the sole thing the capability depends on, so a single failure can still take everything down — which is exactly what the requirement forbids. A second, independent path means the capability keeps running when either side fails, which is the only way to meet the no-single-failure bar. The budget only works if the two paths are truly independent — not sharing the same power, supplier, location, or operators — otherwise one event takes down both and the spend buys nothing. Given that condition, the second path is the effective use of the money.
===DECISION_END===
