Pilotable Solution¶
Bounded validation — instantiates Minimum Sufficient Solution
Runs the scoped-down solution in one bounded setting to prove it actually satisfies the requirement before committing to a full build.
A Pilotable Solution takes a minimum that has already been scoped and runs it for real in one deliberately bounded setting — one store, one clinic, one region — to find out whether it truly satisfies the requirement before it is committed everywhere. Its defining move is that it is a validation harness, not a scope decision: it does not decide what the minimum should contain; it subjects an existing minimum to live conditions and reads back whether the reduced solution actually works when real people use it. The pilot exists because sufficiency claimed on paper and sufficiency proven under real load are different things, and the cheapest place to discover the difference is a corner of the world small enough to fail safely.
Example¶
A grocery chain has scoped a leaner returns process — no receipt required under $25, a single scan step, no manager sign-off — and believes it is sufficient. Rather than roll it to all 240 stores, it makes the solution pilotable: it runs the new process in three stores for a month with real customers and real cashiers. The pilot is built to answer one question — does the leaner process still handle returns correctly without inviting abuse or stranding hard cases? Two things are wired in from the start. A review trigger: if fraudulent-return rate climbs past a set threshold or cashiers escalate more than expected, the pilot pauses for redesign rather than pressing on. And an exception rule: the odd case the lean process can't handle — a clearly defective high-value item, a dispute — routes to a named fallback instead of jamming the line. After the month, the pilot doesn't just say "it felt fine"; it shows where the minimum held and where a single missing step let losses through, and that evidence decides whether the process ships chain-wide.
How it works¶
- Bound the setting. Choose a slice — a site, a cohort, a region — large enough to exercise real conditions and small enough that failure is cheap and reversible.
- Run the actual minimum, live. Put the already-scoped solution in front of real users under real load; the point is proof, not rehearsal.
- Wire a stop condition before starting. Define in advance the signal — harm, failure rate, escalation volume — that pauses the pilot for redesign rather than pushing to scale on momentum.
- Give hard cases a fallback. Route the situations the minimum cannot handle to a named exception path, so the pilot tests the common case without stranding the rare one.
Tuning parameters¶
- Boundary size — how much of the world the pilot covers. Larger boundaries surface more real-world variety but raise the cost and blast radius of failure.
- Realism — live operation versus a shadow run beside the current process. Live is the truer test but carries real risk; shadow is safer but softer evidence.
- Stop-trigger sensitivity — how quickly a bad signal halts the pilot. Twitchy triggers protect against harm but abort on noise; slack ones let a genuine failure run too long.
- Exception-path capacity — how much fallback the pilot provides for hard cases. Generous fallback keeps the pilot safe but can mask how often the minimum truly fails.
When it helps, and when it misleads¶
Its strength is that it replaces "we think this is enough" with evidence from real use, caught in a setting small enough to fail safely and stop cheaply. Its central failure mode is a threat to external validity: a pilot in one hand-picked, well-staffed, unusually motivated site can succeed for reasons that will not travel, so the clean pilot result does not survive the full rollout.[n1] The classic misuse is the rigged pilot — run where it is sure to look good, with the stop trigger quietly ignored — so it manufactures a green light rather than testing for one. The guarding discipline is to pick a representative setting, honor the stop condition, and treat a pilot's success as conditional evidence, not proof of universal sufficiency.
How it implements the components¶
sufficiency_test— the bounded live run is the test: it checks whether the scoped-down solution actually satisfies the requirement under real conditions.review_trigger— a stop condition defined in advance pauses the pilot for redesign when harm, failure, or escalation crosses a set threshold.exception_rule— hard cases the minimum cannot handle are routed to a named fallback, so the pilot tests the common case without stranding the rare one.
It tests a solution someone else has already scoped; it does not draw the boundary via core_requirement and expansion_path or hold the preserved_invariant_set inside version one — that scoping is MVP-like Scoping, its nearest twin — nor does it compose the bundle's active ingredients via nonessential_feature_filter traced to a stakeholder_need_trace, which is Simple Intervention Package's.
Related¶
- Instantiates: Minimum Sufficient Solution — the pilotable solution is the validation step that proves a scoped minimum sufficient before scale.
- Consumes: MVP-like Scoping supplies the scoped solution the pilot puts to the test.
- Sibling mechanisms: Essential Feature Set · Must/Should/Could Filter · Lean Policy Design · Minimum Viable Documentation · MVP-like Scoping · Simple Intervention Package · Minimum Viable Process
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Pilotable Solution operates as an active test, trial, simulation, drill, or rehearsal that generates evidence through a deliberate attempt or perturbation because it runs the scoped-down solution in one bounded setting to prove it actually satisfies the requirement before committing to a full build.
Independent corroboration: The frozen evidence defines Pilotable Solution as 'Runs the scoped-down solution in one bounded setting to prove it actually satisfies the requirement before committing to a full build', so its operative form is Experiment, Test & Rehearsal.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Pilotable Solution is rooted in engineering and design: Design validation proves a scoped solution against requirements in a bounded real setting before full build.
Related originating lineages:
- Innovation & Entrepreneurship — Innovation and entrepreneurship materially shaped Pilotable Solution through pilots, product gates, ventures, and market entry. Minimum viable product practice supplied aggressive scoping for early learning.
- Organizational & Management Science — Project gating supplied the commitment decision after the trial.
- Statistics & Experimental Design — Experimental design and statistics materially shaped Pilotable Solution through randomization, inference, sensitivity analysis, and validation.
Review resolution: Both blind reviewers agree that engineering design and systems assurance is the primary origin. Reconciliation resolves alternate_origin_disagreement. Formative alternate lineages are retained as innovation_entrepreneurship, statistics_experimental_design, organizational_management; later breadth of use is recorded separately as domain_reach=multi_domain, while origin_mode=cross_disciplinary_synthesis describes the relationship among origin lineages.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
A pilot here tests sufficiency — does the scoped solution satisfy a known requirement? — which is a different question from the learning-release pilot of Minimum Viable Process, whose bounded run exists to discover how work flows. Same bounded-run shape, opposite success test: one confirms an answer, the other seeks a question's shape.
[n1] External validity is the degree to which a result observed in one setting generalizes to others. A pilot that succeeds because of its site's unusual staff, motivation, or conditions is a classic external-validity failure — which is why representative site selection and honest stop conditions matter more than a flattering pilot number. ↩