The through-thread
One example, end to end

A deliberately tiny decision — Keep the cats off the counter — runs through the whole methodology once. Each phase shows two things: the methodical move (how the decision is made) and the layer underneath (where it lands in the data and the architecture). You can try the same decision yourself in the demo cockpit ↗.

The stress test
Three hours home alone, thawed chicken on the counter, two motivated cats. Whatever survives that evening will hold.

Five phases, five layers. 6 requirements, 5 solution types, 5 concrete candidates — one of which fails at the gate. That’s enough to touch every mechanism once.

  1. 1

    Mission

    The brief

    What the system must do — tool-neutral.

  2. 2

    Requirements

    Requirements

    Each requirement on exactly one axis.

  3. 3

    Architecture

    Solution space

    A structural finding splits the space into types.

  4. 4

    Solutions

    Candidates

    Concrete solutions, scored on four axes.

  5. 5

    Decision

    Verdict

    The ranked result under one weighting.

Phase 1 · Mission

The brief — tool-neutral

Before any device is named, the methodology pins down what the system must do. Three use cases, the people involved, one stress test — nothing else.

  • Keep them away

    The cats shouldn't get onto the countertop in the first place — not "shoo them down when you catch them."

  • Every route up

    The direct leap from the floor AND the detour via a chair, stool, or windowsill — both routes count.

  • Even unsupervised

    Works when no one is home for hours — not just while someone is watching.

RoleWho
Decides & paysMe — one household, no budget drama, but not play money either.
AffectedTwo cats and the housemates who use the kitchen every day.
The skepticThe cats themselves — they test every gap, relentlessly and with plenty of time.

Data requirements.jsonuseCases · stakeholders · stressTest  ·  Method → The phase process  ·  Live Station 1 in the cockpit ↗

Phase 2 · Requirements

Requirements — each on exactly one axis

The requirements are the criteria. Each sits on exactly one of the four axes — Gate, Fit, Risk or Cost — which prevents double-counting. The methodology always treats cost separately (4-bucket TCO), never as part of a blended number.

RequirementAxisTierWeight
Humane & safe
Must not physically harm the cat or create a kitchen hazard (e.g. water near a power socket). Binary: a solution that violates this is out — no matter how well it works.
GatehardK.O.
Effectiveness
Actually keeps the cat off the countertop. 5 = the cat never gets up there in the first place; 1 = it ignores the measure after a short while.
Fitcritical5
Holds unsupervised
Works for hours with no one present — the stress test. 5 = runs reliably on its own all evening; 1 = only works while someone is watching.
Fitcritical5
Kitchen stays pleasant
No constant noise, no clutter or devices on the surface, no smell for the people. 5 = you barely notice it; 1 = the kitchen becomes unpleasant.
Fitstandard3
Unobtrusive
Ideally near-invisible, no eyesore on the countertop. A pure plus, not a deal-breaker.
Fitnice-to-have1
Robustness / habituation
Does it stay effective, or do clever cats learn to work around it while batteries die unnoticed? 5 = robust, no habituation effect; 1 = quickly outsmarted or silently fails.
Riskstandard3
The fourth axisCost isn’t in this table. It’s its own axis, as a 4-bucket TCO across setup, maintenance, license and usage — computed per solution, in Phase 4.

Data requirements.jsoncriteria[] (axis · tier · weight)  ·  Reference → The requirements schema  ·  Method → The four axes

Phase 3 · Architecture

The solution space — a structural finding splits it

Phase 3 partitions the space into a few solution types (architectures) — still tool-neutral. They emerge from forks: some are already closed, one stays open and sharpens the space live.

The structural finding — One spot or every route up?
Structural finding: there are multiple routes up (direct leap + via chair/stool) — a single spot leaks.
Solution typeWhat
Buy an off-the-shelf deviceBuy a ready-made deterrent — a motion-triggered air blast, ultrasonic emitter, or a textured mat. One-time hardware, possibly refill cartridges.
Smart device on subscriptionAn app-controlled camera/deterrent device on subscription — a recurring monthly fee plus the purchase. The only rental option.
In-house build anchorBuild it yourself: a motion sensor + buzzer, or a self-made physical barrier. Costs mostly my time.
Catwood (open-core build hub)The open build path: one deterrent hub (Catwood), composed per job from modules — buy or build — on your own box (self-host) or in the cloud. Between an off-the-shelf gadget and a full in-house build. Configure it live in the Konfigurator.
Change the environment anchorReshape the environment instead of using a device: remove the incentives, physically block the routes up, train. Nearly free, but my time + discipline.

These four types emerge from a single fork — “Buy something off-the-shelf — or solve it yourself?” Pull it in the cockpit and the rail narrows from four to two: buy ready-made keeps the bought types, solve it yourself the built ones. That prune is exactly what the kernel does.

Data architectures.json + decisions.jsonforks[].prune  ·  Method → Forks & narrowing  ·  Live Pull the fork ↗

Phase 4 · Solutions

The candidates — scored on four axes

Only now are the types filled with concrete products and scored on Gate · Fit · Cost · Risk. One solution is configurable (the ready-made device fans out into three variants), and one fails the gate on purpose — to show what the gate does.

SolutionKindSolution typeStatus
Off-the-shelf deterrent device 3 variants
Buy it ready-made, set it up once, done. Air blast is the most effective but hisses; the mat is unobtrusive but weaker.
buy Buy an off-the-shelf device live
Smart camera + subscription
Camera + monthly subscription. Dependent on the app, Wi-Fi, and the vendor — when the subscription lapses, the device is dead.
rent Smart device on subscription live
In-house build (Arduino + buzzer)
Anchor — the maximal bespoke variant. Shows where the DIY ceiling lies; rarely the winner.
build In-house build live
Change the environment (clear out + block)
Anchor — the passive variant. Maximally pleasant + unobtrusive, but weaker than an active device when unsupervised.
build Change the environment live
Electric shock mat
Eliminated by the humane gate. Stays in the comparison only to show what the gate does.
buy Buy an off-the-shelf device Gate ✗
The gate eliminates, it doesn’t score
The electric-shock mat is effective — but it violates the humane gate and is eliminated, however good its Fit numbers are. Eliminated solutions can never overtake a live one: the kernel gives them no verdict, and the ranking sorts them to the bottom.

Data solutions.json (scores · variants · costInputs) + the instance cost() hook  ·  Reference → The solutions schema  ·  Live The matrix ↗

Phase 5 · Decision

The verdict — ranked, but not automatic

The kernel rolls Fit, cost and Risk up under one scenario (€200/day, 3 years amortization) into a verdict — and re-ranks live as you turn the weighting. The cockpit ships presets for this:

  • Balanced

    Fit ×1 · Cost ×1 · Risk ×1

  • Money matters

    Fit ×1 · Cost ×2 · Risk ×1

  • Just make it work

    Fit ×2 · Cost ×1 · Risk ×1

  • Robust + safe

    Fit ×1 · Cost ×1 · Risk ×2

The consultant writes the verdict — the instrument informs, the knobs are transparent. The recommendation may diverge from it, with reasons. The cockpit doesn’t win a decision, it makes it defensible.

Data config.jsonscenario · presets + kernel ranking()  ·  Method → From space to verdict  ·  Live Turn the verdict ↗

One decision, five layers

What you just touched

This one small decision touched every one of the five architecture layers — the methodology phases and the build plan are two views on the same system.

LayerIn this example
ContractThe schema that demo/*.json validates against — four axes, one shape-truth.
KernelThe pure math: gate elimination, Fit weighting, TCO roll-up, ranking.
ShellThe cockpit you clicked through — stations, forks, matrix, verdict.
TemplateThe copy-me scaffold such a cockpit is born from.
Instancedemo/ itself — the filled data of this cats decision.

→ The five layers in detail  ·  → The methodology in detail

← Back to the overview