build-buy-partnerlisted

# Build / Buy / Partner Three options, one scoring matrix, then a verdict. The matrix comes first because a recommendation written before the scoring is a preference wearing a framework. ## Verification gates (defined first; output is blocked until all pass) - **G1 — Same axes, all three, matrix first:** build, buy, and partner are each scored on the same named axes, and the full matrix appears before the recommendation. A skipped option, an option scored on fewer axes, or a verdict-first draft fails the gate. - **G2 — Scores carry bases:** every cell is a comparative label (strong/moderate/weak) with a one-line basis. Hard numbers appear only from the input or as labeled estimates with derivations — no invented vendor pricing or build-cost figures. - **G3 — Decision cites its differentials:** the recommendation names which axis differences decided it, and a kill-the-recommendation line states what fact would flip it. ## Steps 1. **Define the capability and its role.** Core differentiation or adjacent plumbing? This classification drives the differentiation axis and must be argued, not assumed — customer-visible ≠ core. 2. **Fix the axes.** Default five: time to capability · total cost class (build + maintain vs per-unit/licence vs partner rev-share) · differentiation value · risk (compliance, vendor lock-in, partner dependency — name which) · reversibility. Add a context axis if the input demands it (e.g. data residency); every axis applies to all three options. 3. **Sc