Skip to content

Wizard Of Oz Prototyping

Prime #
1276
Origin domain
Human Computer Interaction
Subdomain
design research → Human Computer Interaction
Aliases
Woz Prototyping, Oz Testing

Core Idea

Wizard of Oz prototyping is the structural move of decoupling what a system appears to do from the outside from how it actually does it on the inside, by replacing some or all of the planned interior mechanism with a hidden human operator (or an off-the-shelf shim, or hand-rolled scripts) during user-facing trials. The user interacts with what looks like the target system; behind the curtain a person — or a kludge — supplies the behaviour the planned mechanism is meant to produce later. The defining commitment is that the validation question is about the experience, the demand profile, and the interaction design — not about whether the interior can be built. The team buys information cheaply by skipping the expensive build, the user supplies honest interaction data because the surface is convincing, and the team learns whether the planned system is worth building before the build cost has been incurred.

Three structural facts give the pattern its shape. First, interior–exterior decoupling: any system has a surface (interaction, interface, promised function) and an interior (the mechanism that delivers the function), and the move exploits the fact that the surface can be made convincingly present while the interior is deliberately absent. Second, the substitute must behave like the planned interior within a bounded envelope: whatever a user could plausibly observe from the surface must come from the substitute, so a planned mechanism that would be slow on long inputs requires the operator to delay on long inputs, and one that would refuse out-of-scope requests requires the operator to refuse. The fidelity of the substitute determines exactly what the trial validates. Third, concealment is load-bearing: if the user knows a human is behind the curtain, the data changes — users become collaborators rather than test subjects — so concealment is what produces honest demand data and also what raises the ethical and disclosure questions the protocol must handle.

The pattern is not unique to the named technique. Every substrate where a planned system can be partially simulated by a cheaper stand-in to test demand, interaction, or experience before commitment instantiates the same move: a hidden simulator stands in for a not-yet-built mechanism, the surface is kept convincing, and the validation question is aimed at the experience rather than at buildability.

How would you explain it like I'm…

The Pretend Robot

Imagine a 'magic' robot that answers your questions, but really there's a person hiding behind a curtain typing the answers. You think you're talking to the robot, so you act for real — and that helps the builders learn if people would even want the robot before they build it. The hiding part is what makes you act naturally.

Fake Robot, Real Person

Wizard of Oz prototyping means making something look finished on the outside while a hidden person (or a quick cheat) does the work on the inside that the real machine would do later. Users interact with what seems like the real thing, so they behave honestly, and the team finds out whether people want it without paying to actually build the hard part. The fake has to act like the real machine would — if the real one would be slow on big jobs, the hidden person has to be slow too — because that's what decides what the test actually proves. And the hiding matters: if users knew a person was behind the curtain, they'd act differently, so the secrecy is what makes the data real (and also raises questions about being honest with people).

Fake the Inside, Test the Outside

Wizard of Oz prototyping is the move of decoupling what a system appears to do from the outside from how it actually does it on the inside, by replacing some or all of the planned interior mechanism with a hidden human operator (or an off-the-shelf shim, or hand-rolled scripts) during user-facing trials. The user interacts with what looks like the target system while, behind the curtain, a person or a kludge supplies the behaviour the real mechanism is meant to produce later. The defining commitment is that the validation question is about the experience, the demand, and the interaction design — not about whether the interior can be built. Three facts give it shape: interior–exterior decoupling (the surface can be made convincingly present while the interior is deliberately absent); the substitute must behave like the planned interior within a bounded envelope (anything a user could observe must come from the substitute, so a mechanism that would be slow on long inputs requires the operator to delay on long inputs), and that fidelity determines exactly what the trial validates; and concealment is load-bearing (if the user knows a human is behind the curtain, they become a collaborator rather than a test subject, changing the data — which is also what raises the ethical and disclosure questions).

 

Wizard of Oz prototyping is the structural move of decoupling what a system appears to do from the outside from how it actually does it on the inside, by replacing some or all of the planned interior mechanism with a hidden human operator (or an off-the-shelf shim, or hand-rolled scripts) during user-facing trials. The user interacts with what looks like the target system; behind the curtain a person — or a kludge — supplies the behaviour the planned mechanism is meant to produce later. The defining commitment is that the validation question is about the experience, the demand profile, and the interaction design — not about whether the interior can be built. The team buys information cheaply by skipping the expensive build, the user supplies honest interaction data because the surface is convincing, and the team learns whether the planned system is worth building before incurring the build cost. Three structural facts give the pattern its shape. First, interior–exterior decoupling: any system has a surface (interaction, interface, promised function) and an interior (the mechanism that delivers it), and the move exploits that the surface can be made convincingly present while the interior is deliberately absent. Second, the substitute must behave like the planned interior within a bounded envelope: whatever a user could plausibly observe from the surface must come from the substitute, so a mechanism that would be slow on long inputs requires the operator to delay on long inputs, and one that would refuse out-of-scope requests requires the operator to refuse — the fidelity of the substitute determines exactly what the trial validates. Third, concealment is load-bearing: if the user knows a human is behind the curtain, the data changes — users become collaborators rather than test subjects — so concealment is what produces honest demand data and also what raises the ethical and disclosure questions the protocol must handle.

Structural Signature

the convincing surface — the absent planned interior — the concealed substitute standing in for it — the bounded behavioural envelope the substitute must match — the validation question aimed at experience, not buildability — the staged-commitment ladder gating the build decision

A system instantiates the pattern when each of the following holds:

  1. A surface and an interior that can be decoupled. The system divides into an externally observable surface (interaction, interface, promised function) and an interior mechanism that delivers it, and the two can be varied independently — the surface made present while the interior is absent.

  2. A concealed substitute. Some cheaper stand-in — a hidden operator, a shim, a script — supplies the behaviour the planned interior would produce, occupying the interior's place during a trial.

  3. A bounded behavioural envelope. Whatever the participant could observe from the surface must come from the substitute, so the substitute's permissible actions must match the planned mechanism's envelope; the fidelity of that match fixes exactly what the trial validates.

  4. Load-bearing concealment. The participant does not know the interior is substituted; concealment is what makes the interaction data honest, and is also the source of the disclosure and consent obligations the protocol must discharge.

  5. An experience-directed validation question. The trial asks whether the experience produces the demanded behaviour and interaction — not whether the interior can be built — so build-feasibility is explicitly out of scope.

  6. A staged-commitment ladder. Surface-only gives way to surface-plus-substitute, then to a hybrid, then to the full system, each rung carrying a smaller cost-and-risk profile and gating entry to the next.

These compose into a method for learning what to build before paying the build cost: the decoupling licenses the substitute, the envelope bounds what is learned, concealment secures the data, and the ladder converts an all-or-nothing build into a sequence of cheap evidence-producing stages.

What It Is Not

  • Not design_prototyping in general. Most prototyping builds a real but partial version of the interior to test feasibility or refine a mechanism. This prime specifically fakes the interior with a concealed substitute and aims the validation at experience, not at whether the interior can be built.
  • Not minimum_viable_product_mvp. An MVP is a genuinely-built, shippable minimal product whose interior really works at small scope; the Wizard of Oz interior is deliberately not built — a human or kludge stands in behind a convincing surface that only looks like a product.
  • Not signaling. Signaling conveys a quality through costly-to-fake action; here the concealment exists to elicit honest demand data from a participant who is not the intended audience of a signal, and disclosure obligations attach precisely because the participant is misled, not courted.
  • Not affordance. An affordance is what a surface invites a user to do; the Wizard of Oz move is about who supplies the behaviour behind the surface, not about the surface's perceived action possibilities.
  • Not simulated_annealing or any search procedure. This is not an optimisation algorithm over a solution space; it is a one-shot-or-staged evidence-gathering method that defers a build decision, with no objective function being descended.
  • Common misclassification. Reading a successful trial as evidence the system is buildable. The tell: a human operator faked exactly the capability the machine cannot yet deliver, so any conclusion about the interior mechanism (rather than the user's experience of the surface) is outside what the method validated.

Broad Use

  • Human-computer interaction — the origin: a hidden operator types responses while a user converses with what appears to be an automated interface; the workhorse method for conversational, voice, and intelligent-feature design.
  • Intelligent-system and product development — feature prototypes begin with a human in the loop producing the "model's" output, so the team learns desired behaviour, failure modes that matter, and latency tolerance before building the real interior.
  • Service and customer-experience design — a new service is run with manual labour behind the counter while the operational machinery is still in planning, validating the customer journey before the operational build-out.
  • Organisational pilots and process design — a new internal process is run with manual handoffs and spreadsheets before the system that will automate it is specified.
  • Robotics and physical systems — a planned autonomous machine is tested with a hidden teleoperator, validating social interaction and demand before the autonomy stack is finished.
  • Venture and product-market-fit discovery — the "concierge" and "Wizard of Oz" patterns: an apparent automated product with a manual back end, used to validate demand before building.

Clarity

Naming a trial a Wizard of Oz prototype disciplines the team to be explicit about which interior mechanisms are faked and which are real, what the operator is allowed to do (the operating envelope of the stand-in must match the planned mechanism's envelope, or the validation is invalid), what observable behaviour the user is seeing (so the validation question is correctly scoped), and what disclosure regime applies. Each of these is easy to leave implicit, and each, left implicit, silently invalidates the trial.

The label also separates two questions that are routinely conflated: prototyping as build-validation ("does the team know how to build this?") and prototyping as experience-validation ("does this experience produce the demand and behaviour the team needs?"). Wizard of Oz is unambiguously the second; a team that uses it to claim build-feasibility is misusing the method. A further clarity benefit is that the frame surfaces the question of what the substitute cannot fake. A human stand-in can fake generated text but not the latency profile of a distributed system under load; it can fake a machine's turn-taking but not its sensor failure modes. The validation is bounded by what the substitute can mimic, and naming that boundary prevents over-reading the result.

Manages Complexity

The pattern compresses an expensive integrated build-and-test cycle into a much cheaper experience-test, deferring the build until the experience question is resolved. The complexity-management win is direct: the team avoids paying interior-build cost for systems that will fail the experience-test, and learns which interior properties are worth optimising on the basis of evidence rather than guess. A question that would otherwise require a full system to answer is answered with a curtain and an operator.

The pattern also produces a staged-commitment schedule. Surface only (paper or sketches) gives way to surface-plus-substitute (a low-fidelity interior simulator), which gives way to surface-plus-partial-real-interior with a substitute covering the unimplemented parts (a hybrid), which finally gives way to the full system. Each stage carries a smaller information-cost-and-risk profile than the next, and each stage's findings inform whether the next stage is worth entering. This staged ladder is the structural backbone of disciplined design research and the build-measure-learn discipline of lean product development; it is the part of the pattern that transfers most cleanly and that gives the method its claim to be a structural design of how to learn what to build before paying the build cost, rather than merely a clever interface trick.

Abstract Reasoning

The pattern licenses inferences the unitary "build and test" framing does not. Demand-test before build-test: if the experience-test fails, the build is wasted regardless of how good the interior would have been, so the validation order should be inverted to put experience first. Substitute-envelope must match planned-envelope: the operator's permissible actions must match what the planned mechanism will be able to do, or the trial validates a different system than the one being planned — an operator with unrealistic capability produces inflated expectations the real system will later disappoint.

Fidelity is a control variable: increasing substitute fidelity costs money (more skilled operators, more rehearsal, better tooling) and reduces information loss, so the team chooses fidelity against the validation question being asked rather than maximising it by reflex. Concealment carries ethical obligations: the team must plan disclosure — timing, content, consent — or the protocol fails research-ethics review and yields data of compromised legitimacy. And the substitute's behaviour becomes the spec: whatever the operator is allowed to do becomes the specification the engineering team builds against, so an over-permissive operator produces an unrealistic spec and an over-constrained one produces an uninspiring one. Each of these is a structural consequence of the interior–exterior decoupling, and each is invisible to a framing that treats prototyping as a single undifferentiated activity.

Knowledge Transfer

The pattern's transferable cargo is an intervention catalogue that travels cleanly across substrates: stage the build; substitute the interior; control the surface; control the substitute's envelope; collect demand and interaction data; disclose appropriately; decide build / refine / kill on the data. This sequence is substrate-independent, and it is the sequence that moves rather than any single domain's vocabulary. From interface design it carries into intelligent-feature development, where the same protocol used for conversational-interface trials applies to perception-pipeline trials and recommendation-feedback trials. From interface design it carries into service design, where the staged-commitment ladder becomes service-blueprint validation with a manual back-of-house standing in for the planned operational system.

From service design it carries into organisational pilots, where spreadsheet-and-meeting pilots validate workflows before any system is specified, letting business operations learn before engineering commits. From lean product practice it carries into the named "concierge" and "Wizard of Oz" venture patterns, which inherit both the structural move and the staged-commitment ladder. From robotics it carries into autonomous-systems development, where a hidden teleoperator behind apparent autonomy lets the team learn social-interaction requirements before the autonomy stack is complete. In each transfer the load-bearing contribution is the staged-commitment ladder — surface only, then surface-plus-substitute, then hybrid, then full system — because that ladder is what converts an all-or-nothing build decision into a sequence of cheap, evidence-producing stages. The pattern survives the strip-the-jargon test: stripped of its origin vocabulary, the residue is "stand in for a not-yet-built mechanism during a user trial, keep the surface convincing, and aim the validation at experience rather than buildability," a move with independent presence in every substrate where systems are built around user interaction. Its provenance — a named technique from a single design discipline, carrying that discipline's vocabulary and disclosure norms — is why it reads as framed rather than structural even as the underlying decoupling transfers.

Examples

Formal/abstract

The original 1980s conversational-interface study is the canonical worked case, and it instantiates every slot of the signature exactly. The convincing surface is a screen on which the participant types natural-language requests and reads back fluent, apparently-automated responses. The absent planned interior is a natural-language understanding engine that, at the time, did not exist at the required quality. The concealed substitute is a skilled human operator in another room, reading the participant's typed input and composing the system's replies in real time. The bounded behavioural envelope is the load-bearing constraint: the operator is instructed to behave only as the planned system could — to use a restricted vocabulary, to "fail" on inputs the real engine would not parse, and to delay in proportion to input length, so that the trial validates the planned system rather than a superhuman one. The validation question aimed at experience asks how users phrase requests, what they expect the system to understand, and where the interaction frustrates them — not whether the engine can be built. Load-bearing concealment secures honest data: were participants told a human was answering, they would converse collaboratively rather than testing the system's limits. The staged-commitment ladder then converts the finding into a build plan: the observed vocabulary and failure-tolerance become the specification the engineering team builds against. The intervention this enables is precise — the team learns the required envelope of the engine empirically, before paying to build it.

Mapped back: The typed interface is the convincing surface, the hidden operator is the concealed substitute, the restricted-vocabulary instruction is the bounded envelope, and the dialogue transcripts answer the experience question — exactly the Wizard of Oz structure that names the technique.

Applied/industry

A startup validating demand for an automated meal-planning service runs the "concierge" form of the pattern. The convincing surface is a polished web app where a subscriber enters dietary preferences and receives a personalised weekly plan; from the outside it looks like an algorithm. The absent planned interior is the recommendation engine, deliberately not built. The concealed substitute is the founders themselves, hand-assembling each plan from a spreadsheet. The bounded behavioural envelope matters: the founders must produce plans the eventual algorithm could plausibly produce — drawn from a finite recipe database, respecting the same constraints — or the trial validates a service the software can never match. The experience-directed validation question is whether subscribers value the plans enough to pay and renew, not whether the engine is feasible. Concealment keeps the demand signal honest: subscribers behave as paying customers, not as beta-testers indulging the founders. The staged-commitment ladder is explicit — manual concierge first, then a partial engine with humans covering the gaps (a hybrid), then full automation — each rung cheaper to abandon than the next, and each gating entry to the next on the demand evidence. The same ladder governs a robotics team testing a delivery robot with a hidden teleoperator behind apparent autonomy, validating pedestrian interaction and demand before the autonomy stack exists; and an internal-operations team running a new approval workflow with manual spreadsheet handoffs before any system is specified.

Mapped back: The app is the surface, the hand-assembled plans (or the teleoperator, or the spreadsheet) are the concealed substitute, the database-and-constraint limits are the envelope, and renewal rates answer the experience question — with the surface-then-substitute-then-hybrid-then-full ladder converting an all-or-nothing build into staged, cheap evidence.

Structural Tensions

T1 — Experience-Validation versus Build-Validation (scopal). The prime answers "does this experience produce the demanded behaviour?" and is silent on "can the interior be built?" — that question belongs to design_prototyping and engineering feasibility work. The boundary is routinely violated: a successful Wizard of Oz trial is read as evidence the system is buildable, when a human operator faked exactly the capability the machine cannot yet deliver. The failure mode is greenlighting a build on demand evidence while the hardest interior problem remains unsolved. Diagnostic: does any conclusion drawn from the trial concern the interior mechanism rather than the user's experience of the surface?

T2 — Substitute Envelope versus Planned Envelope (coupling). The substitute must act only as the planned interior could; the trial validates whatever the operator was permitted to do, not whatever was intended. The coupling is load-bearing and fragile: an over-capable operator (a human who understands any phrasing) validates a superhuman system the engineering team can never match, inflating expectations into later disappointment. The failure is letting the operator's natural competence exceed the machine's envelope. Diagnostic: for every operator action, ask whether the planned mechanism could plausibly produce it — and instrument the operator's latency, vocabulary, and failure behaviour against the machine's projected limits.

T3 — Concealment versus Disclosure (sign/direction). Concealment is what makes the interaction data honest, yet it is also the source of consent and research-ethics obligations that pull the opposite way. The two cannot both be maximised: full disclosure turns subjects into collaborators and corrupts the demand signal; full concealment yields clean data but fails ethics review and produces evidence of compromised legitimacy. The failure mode is treating disclosure as an afterthought, so the trial's data is either gamed or ethically void. Diagnostic: is there a planned debrief — timing, content, consent — that preserves data validity while discharging the disclosure duty?

T4 — Snapshot Demand versus Sustained Demand (temporal). The trial measures demand under a faked interior at one moment; it cannot observe how demand responds once the real interior's true latency, error rate, and edge-case behaviour arrive. A concierge founder hand-crafting perfect plans validates demand for perfection the algorithm will degrade. The failure is reading first-window enthusiasm as durable product-market fit when the experience that produced it was unsustainable by the real system. Diagnostic: which observed demand drivers depend on substitute properties (human judgment, zero latency) that the built interior will not reproduce at scale?

T5 — Fidelity Cost versus Information Gained (measurement). Higher substitute fidelity costs money and reduces information loss, but the two do not scale together — past a point, extra fidelity buys evidence the validation question never needed. The failure mode is reflexively maximising fidelity (skilled operators, elaborate tooling) when a low-fidelity stand-in would have answered the question, spending the build savings the method was meant to capture. Diagnostic: for the specific decision the trial gates, what is the coarsest fidelity at which the answer would not change — and is the team paying for more than that?

T6 — Spec-Discovery versus Spec-Distortion (scopal). Whatever the operator is allowed to do becomes the specification engineering builds against — a genuine benefit, but it inverts into a hazard. An over-permissive operator produces an unbuildable or bloated spec; an over-constrained one produces an uninspiring spec that under-sells the concept. The failure is letting the operator's improvised behaviour silently define requirements no one consciously chose. Diagnostic: is the operator working from an explicit, bounded script that the team intends as the spec, or are post-hoc transcripts being mined into requirements the operator never knew they were setting?

Structural–Framed Character

Wizard of Oz Prototyping sits firmly on the framed end of the structural–framed spectrum, with an aggregate of 0.8 — four of the five diagnostics reading at the maximum. There is a structural kernel here, the interior–exterior decoupling that lets a convincing surface stand in front of an absent mechanism, and that kernel is what gives the prime any cross-substrate reach it has. But almost everything around the kernel is human design practice, and the diagnostics record that decisively.

Vocab_travels is 1.0: the very name is a literary-film allusion (the man behind the curtain), and the working terms — concealed operator, disclosure regime, build-validation versus experience-validation, the staged-commitment ladder — are HCI-research vocabulary that must be carried wholesale into any new setting; the pattern does not let each domain tell it in its own words. Institutional_origin is 1.0 because the technique has a precise human provenance: a 1980s human-computer-interaction study (Kelley), named for a 1939 film, a method invented within a design discipline rather than a regularity discovered in nature. Human_practice_bound is 1.0 because the pattern cannot exist without the human practices of building products, running user trials, and discharging research-ethics disclosure obligations — there is no physical or biological substrate in which a "concealed substitute behind a convincing surface validating experience before a build decision" runs indifferently; every instance is a designer learning what to build. Import_vs_recognize is 1.0 because invoking the prime imports a whole methodological frame — stage the build, conceal the interior, aim validation at experience not buildability, plan the debrief — rather than recognising a pattern already present in some medium. Only evaluative_weight reads 0.0: the method is value-neutral, neither approving nor disapproving until you say what it is used for. That single structural diagnostic, plus the genuine decoupling kernel, is why the aggregate lands at 0.8 rather than a perfect 1.0 — but the prime is unmistakably a framed, human-practice-bound design method, and the prose and the frontmatter agree on that placement.

Substrate Independence

Wizard of Oz Prototyping is a weakly substrate-independent prime — composite 2 / 5 on the substrate-independence scale. The structural kernel that does travel is the interior–exterior decoupling: a convincing surface can be made present while a concealed substitute supplies the absent interior, and that decoupling is recognisable across HCI conversational-interface trials, intelligent-product feature prototypes, service-design blueprints, organisational process pilots, robotics teleoperation, and venture "concierge" MVPs, which gives it some genuine domain breadth and a documented but largely intra-disciplinary transfer record. What holds the composite low is that every one of those substrates is a human design-and-product substrate: the pattern cannot exist without the practices of building products, running concealed user trials, and discharging disclosure obligations, so there is no physical or biological medium in which it runs, and its working vocabulary (concealed operator, staged-commitment ladder, build-versus-experience validation) must be carried wholesale into any new setting rather than recognised natively. The structural abstraction is correspondingly thin — the kernel is real but wrapped in method-specific commitments — which is exactly why domain breadth and structural abstraction sit at 2 and the transfer, though real, stays modest.

  • Composite substrate independence — 2 / 5
  • Domain breadth — 2 / 5
  • Structural abstraction — 2 / 5
  • Transfer evidence — 3 / 5

Relationships to Other Primes

One-hop neighborhood: parents above, mutual partners to the right, children below.Wizard Of OzPrototypingsubsumption: Design PrototypingDesignPrototyping

Parents (1) — more general patterns this builds on

  • Wizard Of Oz Prototyping is a kind of, typical Design Prototyping

    The file: ordinary design_prototyping builds a REAL but partial interior; wizard_of_oz specifically FAKES the interior with a concealed substitute and aims validation at experience not buildability. A specialized species (concealment + interior-absence) of design_prototyping (the 0.88 nearest, the correct parent).

Path to root: Wizard Of Oz Prototyping → Design Prototyping → Iteration

Neighborhood in Abstraction Space

Wizard Of Oz Prototyping sits in a sparse region of abstraction space (72nd percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely rather than landing on a neighbor.

Family — Adaptation Under Adversarial Pressure (14 primes)

Nearest neighbors

Computed from structural-signature embeddings · 2026-06-14

Not to Be Confused With

The nearest and most consequential confusion is with design_prototyping, the embedding-nearest prime. Both produce a cheap stand-in for a planned system and use it to learn before full commitment, but they answer different questions and fake different things. Ordinary prototyping builds a real, partial interior — a clickable mockup with stubbed logic, a structural model, a breadboard — to test feasibility, refine a mechanism, or de-risk the build; the question is largely "can we build this, and how should the mechanism work?" The Wizard of Oz move deliberately does not build the interior at all: it conceals a human or kludge behind a convincing surface and aims the validation strictly at experience and demand, with build-feasibility explicitly out of scope. The structural marker is concealment plus interior-absence. A prototype that exposes its partial interior and invites the user to evaluate the mechanism is doing design prototyping; one that hides the absence of the interior to elicit honest interaction data is doing Wizard of Oz. The boundary matters because the two validate opposite things, and reading a Wizard of Oz result as a feasibility verdict is the prime's signature failure (its T1).

A second genuine confusion is with minimum_viable_product_mvp. An MVP and a Wizard of Oz prototype can look identical from the outside — a polished, apparently-automated product offered to real users — but they differ at the interior and in their commitment posture. An MVP's interior genuinely works at minimal scope: it is a shippable product, however thin, and the value it delivers is real and sustainable by the system as built. The Wizard of Oz interior is faked and unsustainable by the real system — founders hand-assembling plans from a spreadsheet, an operator typing replies a machine cannot yet generate — so the demand it measures may evaporate once the real, degraded interior arrives (the prime's snapshot-versus-sustained-demand tension). The practical test: if the back end stopped being human, would the product still deliver what users experienced? If yes, it was an MVP; if the experience depended on the concealed substitute's human judgment or zero-latency perfection, it was Wizard of Oz, and the demand signal must be discounted accordingly.

For a practitioner the distinctions govern what conclusion the trial licenses. Treating Wizard of Oz as design_prototyping invites a greenlight on a build whose hardest interior problem is still unsolved; treating it as a genuine minimum_viable_product_mvp invites mistaking unsustainable first-window enthusiasm for durable product-market fit. Naming the prime correctly keeps the validation aimed where it belongs — at the experience the convincing surface produced — and keeps the team honest about everything the concealed substitute faked.

Solution Archetypes

No catalogued solution archetypes reference this prime yet.