Worked examples

Two engagements end-to-end, run with this methodology. Read one once to see the phases land on a real problem — but read it for recognition, not for rules. No rule lives here. Every move you see is owned by another file; this file points at the owner each time, so the example stays a demonstration and never quietly becomes a second, drifting copy of the doctrine. The structure is in model.md, the per-phase why/how-it-fails in process.md, the schema in contract.md, the cost method in pricing-tco.md, the front-end in cockpit.md.

The two are deliberately a pair:

• EFI — the classic selection. A near-monolithic stack where each solution was essentially “which tool per category.” The four axes are present but Cost/Risk stay light. This is the shape the methodology was born for, and it is enough on its own to see the funnel, the loop, and the verdict.
• Skischule — the composed / buy-vs-build engagement, where the deliverable stopped being a tool and became a solution (a composition). It is the reference instance for the whole solution model in model.md: six solutions on one Scenario, scored on all four axes, with a re-weightable authored verdict.

Run a classic single-category pick and EFI is your model; run anything with a build option, a sidecar, or integration glue and Skischule is.

---

EFI — classic selection (3-category tool stack)

EFI (European Forum for Innovation) is a 7-person Vienna-based pan-European policy NGO running 24 events/year across 18 cities. It needed a stack across three categories — Collaborative Work, CRM/Newsletter, Event Management — connected via middleware. What makes it a good first model is that nothing here is exotic: it is the funnel run straight, and the discipline shows mostly in what got named out loud.

Phase 1 — Mission

The mission was framed tool-neutrally before any product entered the room (the Phase-1 discipline — process.md § Phase 1; the use-case spine — model.md). What shaped everything downstream:

• Stakeholders as a constraint, not a preference. Two non-technical lead users, Monika and Margit, plus Francesco driving the flexibility need. Their comfort was not a nice-to-have — lead-user approachability became a critical criterion later (see Phase 2), which is the “stakeholder comfort is decisive” principle (process.md § Principles) entering at Phase 1 as a fact about who must operate the thing daily.
• One stress-test use case. The 18-city European tour — the concrete, near-future, high-stakes scenario every later candidate was walked through. This is the single forcing scenario process.md § Phase 1 demands; it is not yet the costed Scenario of model.md (EFI’s Cost stayed light), but it played the same role of making every evaluation answer the same hard question.

Phase 2 — Requirements

The mission became 49 criteria across the four weight tiers — 6 hard filters, 10 critical, 16 standard, 17 nice-to-have — shared criteria first, then per-category (the tiered weighting model — contract.md four-tier weight table; the elicitation discipline — requirements-interview.md). Two moves are worth copying:

• Approachability scored ×5 (critical), alongside power features, not below them. This is the single-placement rule (model.md § four axes) doing its job: lead-user comfort is a capability the use cases need → it lives on Fit, weighted as heavily as the power-user features, rather than being relegated to a footnote.
• “EU data residency” named as a non-requirement. GDPR compliance was deemed sufficient, so EU residency was stated out loud as not a criterion. Naming the non-requirement killed a whole class of false disqualifications before the survey ran — the “name what is not a requirement” check (requirements-interview.md pre-finish checks). Note it is an absence, not a smuggled affordability clause on a gate (model.md § four axes warns against exactly that contamination).

Phase 3 — Architecture

A confirmed market gap — no single tool does contacts + events + newsletters + WordPress well — settled the architecture as multi-tool early. That is the coupling/landscape finding ruling out an architecture class, not just a tool (process.md § Phase 3). The candidate architectures enumerated were:

• Single-platform (one tool does everything) — kept as an anchor candidate, expected to fail, to verify the market-gap finding actually held (anchor candidates — process.md § Phase 3). It fell in the first loop iteration; how it fell was the evidence.
• Two-tool with middleware.
• Three-tool best-of-breed connected via middleware.

Each architecture entered the loop as a branch (architecture-is-not-solution — model.md; the architectures→solutions fill happens in Phase 4).

Phase 4 — Solutions (the loop)

The CRM track ran four loop iterations before a clear winner emerged — the honest case of the re-entrant loop, where most engagements need one (process.md § Phase 4). Each iteration was the palette of moves, not a fixed pipeline (model.md § Narrowing): survey → deep dive → red team, ordered by leverage.

Two findings are the lesson:

• The red team, not the deep dive, made the decisive cuts. A finalist’s support paywalled at $499/mo; deliverability volatility on another. The deep dive picks the paper-winner; the red team decides whether it survives contact with reality (research-briefs.md red-team template; process.md § Phase 4). Each cut was recorded as a hard-filter 0, never a row-deletion — the struck candidate is where the next round looks first (process.md § Regression; model.md § Narrowing).
• Broadening unstuck the CRM track. Iterations kept producing the same disqualifying flaw, so the architectural assumption was wrong, not the candidates — the trigger to broaden (process.md § Phase 4, the broadening / within-Phase-4 regression). The broadening move that worked was inverting which tool holds the contacts (“Mode 2”: the planning tool, not the CRM, as the contact home). That is a fork surfaced mid-loop and placed by its resolution, exactly as model.md § the fork describes — discovery is continuous, placement is by what closes it.

Phase 5 — Decisions

The close was the multi-scenario shape: not one answer but a recommended path, a compromise, and a minimal-change path, each with its stack, the pricing total, and what it trades off (process.md § Phase 5). The recommendation was framed against EFI’s stated values — the verbatim Phase-2 quotes — and authored by the consultant, not read off the top of the matrix (P1, the verdict doctrine — model.md § verdict).

What EFI is the model of

A defensible selection where the structural findings — the market gap, the four-round CRM stuckness, the red-team disqualifiers — carried the engagement, and the four axes were present but Cost and Risk stayed light because the solutions were near-monolithic. EFI’s engagement folder (its criteria.json, the per-category matrices, the explorer) is the shape the bundled tool-level explorer generalizes (cockpit.md § explorer).

---

Skischule — composed / buy-vs-build (six solutions, one Scenario)

Die Skischule (Nassfeld) is a tiny seasonal ski school that needed email triage, AI drafts, summaries, and a website chatbot. It is the engagement where the methodology outgrew tool selection — where the deliverable became a solution, a composition, and the unit of comparison moved up a layer. It is the live reference for everything in model.md; the cockpit (now built on the shared kernel + shell + template/ — cockpit.md) was the proto-engine since harvested. What it added beyond EFI:

Solutions, not tools, were the unit

Six candidate solutions stood on one footing across the buy↔build spectrum (tools-≠-solutions — model.md § Tools are not solutions):

• four whole-platform SaaS — Zendesk, Intercom/Fin, HubSpot, Freshdesk (each a trivial composition: one tool is the solution);
• one composed stack — Chatwoot + a custom AI sidecar + the integration glue;
• one full Eigenbau (bespoke build).

The last two have no vendor pricing page and only exist because the comparison happens at the solution layer — which is precisely the failure a flat tool list hides (build disappears; integration cost is invisible — model.md § the failure it prevents). A single ranked list of tools cannot express “Chatwoot + a sidecar we build” against “Zendesk alone”; those are two solutions composed from overlapping tools, and the customer chooses between the solutions.

One shared Scenario drove everything

Seats, season length, email/chat volumes, deflection rate, a 10× Fasching peak, and the day-rate — one demand vector, every solution costed against it (the shared Scenario as forcing function — model.md § the shared Scenario; the cost method — pricing-tco.md; its schema fields — contract.md). Turn any knob (seats 4→6, peak 5×→10×) and all six solutions’ Cost — and the load-sensitive Fit/Risk — recompute together, so the ranking’s sensitivity is visible, not just its point value.

This is what let a SaaS subscription and a self-built stack be compared at all. The earlier proto-version had disconnected cost tabs and no shared Scenario, so they never could be — the concrete failure the Scenario forcing-function fixes.

Four axes with the single-placement rule

• Gates eliminated — DSGVO + valid transfer mechanism, multilingual, German UI (model.md § four axes; gate phrasing — contract.md). Eliminations were recorded as a hard-filter 0, never row-deletions (model.md § Narrowing).
• Fit scored capability only.
• Cost was the 4-bucket TCO, separate from Fit — pricing ran after scoring so it never contaminated the Fit number (cost-not-in-Fit — model.md § four axes; the 4-bucket rollup — pricing-tco.md).
• Risk became a scored axis on four dimensions — Datensicherheit, Resilienz, Abhängigkeit, Termin-Sicherheit — not a paragraph of prose (model.md § Risk as a scored axis; the riskScores schema — contract.md).

The instructive move: several criteria were deliberately moved from Fit to Risk — graceful degradation, SLA uptime — to kill double-counting. That is the Fit↔Risk test applied (model.md § four axes): a downside that emerges over time lands on Risk, not Fit, even though it reads like a capability.

Build as a scored row, via coverage and work packages

The Eigenbau and the Chatwoot sidecar were sized in work packages with optimistic / expected / pessimistic effort bands — and that spread is the Termin-Sicherheit signal (build sized in bands, count-each-package-once — model.md § Composition; the method — pricing-tco.md; workPackages schema — contract.md). The integration glue carried its own Resilienz / Abhängigkeit risk: more fillers → more glue → more dependency, which is how the single-core-plus-sidecars vs. fragmented best-of-breed difference becomes visible (coverage codes + fillers — model.md § Coverage). Per use case, each solution’s coverage reads as in / part / aug:<filler> / build / proj, rendered beside its Fit score so a mismatch (build claimed at Fit 5 with no work package) gets questioned (the coverage→Fit bridge — model.md § Coverage).

Verdict = the consultant’s, expressed as a turnable instrument

No hardcoded winner. Named weighting presets — “Ausgewogen”, “Sicherheit”, “Günstig”, “Meine Empfehlung” — re-rank the solutions live, and the recommendation is authored: “here’s how I weight it and what that gives; turn the knobs and see if it holds.” That is the verdict doctrine in its full form (model.md § the verdict; P1 — the consultant authors, the agent presents). Gate-eliminated solutions never appear on the ranking no matter the weighting (gate carries through to the verdict — model.md § the verdict). Survivors that differed only on a handful of forks collapsed to “one family + the open decision” — the briefing shape of 2–3 solutions + 2–3 open forks (fork-position collapse — model.md § Collapsing to the brief; process.md § Phase 5).

Two surfaces, one model

A dense analyst cockpit (all knobs) and a linear ?präsentation client walkthrough (presets as the only lever) render the same scored data — built once, skinned twice (the two-surface rule + the three registers, client copy as a shell layer not the data — model.md § Two surfaces / § Three registers; the front-end mechanism — cockpit.md). The data file carries model + analyst rationale; the polished client-addressed strings live in the shell override layer, never in the data.

What Skischule is the model of

The work EFI did in prose — architecture shape, risk register, pricing totals — Skischule made computable and re-weightable: one Scenario, four scored axes, build as a first-class row, an authored-but-turnable verdict. That machinery is exactly what the shared kernel + shell now generalize (cockpit.md), and Skischule remains the reference instance the solution model in model.md was abstracted from. (A new solution cockpit is built by copying template/, never by forking Skischule — cockpit.md § copy-template-never-fork.)

Caveat — resolve an AI-assist fork’s use-boundary before its buy/build axis

A worked-example caveat (not a new fork coordinate): some forks — especially AI assists — carry a hidden use-boundary (internal-only vs customer-facing) that sets the liability bar, and it should be resolved before the buy-vs-build axis, because it can collapse the fork entirely. In Ehimare the AVB-knowledge assist first read as “buy vs build” (F-2b); once the real axis surfaced — internal team helper (a draft a human checks) vs customer-facing oracle (which carries legal-RAG hallucination liability) — the customer-facing branch was ruled out, and “buy vs build” only mattered for the surviving internal use. Ask “who reads the output, and what’s the liability if it’s wrong?” first; the buy/build options you then weigh may be a much smaller set. (First sighting — Ehimare R2; held as a caveat, not yet a model coordinate, pending a second engagement.)