Generative UI: how to validate simulations for learning

Generative UI suggests a product that turns a learning need into an experience people can manipulate. Yet a moving control does not establish that its effects are correct. For a product team, the important decision is what may vary between generations and what must remain verifiable. Without that boundary, an appealing demonstration can become a false explanation that users absorb through trial and error.

On September 17, 2026, Google Research announced a public library of more than thirty English-language educational interactives, generated with AI and reviewed by teachers. It provides a concrete release through which to examine the problem. This article proposes five engineering decisions for evaluating similar initiatives; these are editorial recommendations, not a Wasyra-tested integration or a claim of educational effectiveness.

Google’s technical report, dated September 16, describes planning, level objectives, interface generation and guidance. Iteration evaluates visual, mechanical, solution and telemetry aspects using code and execution in Chrome. Its evaluation includes teacher studies and ratings; these alone do not establish a causal improvement in student learning.

The architectural implication we propose is to treat every output as versioned software. The prompt is an input; the deliverable includes rules, controls, states and explanations. If a correction changes a formula but retains a hint written for the previous version, the product becomes internally contradictory. Review and publish the whole artifact as one unit, with evidence that can reconstruct exactly what each participant received.

Start with an observable action: compare two scenarios, predict an outcome or explain a decision. Then specify allowed variables, their units, ranges and relationships that must remain true. Include success conditions and impossible states. A request such as “teach service capacity” leaves too many decisions open; a contract requiring users to identify when demand exceeds capacity offers a testable criterion.

For the first pilot, separate the calculation core from the generated presentation. Keep essential rules in reviewed functions and let AI propose layout, context and exercise sequence within explicit limits. This constraint reduces generator freedom but makes errors easier to locate: you can distinguish a wrong calculation from a wrong label or an interaction that poorly communicates a correct result.

Hypothetical example: a company wants to train support leads using a simplified simulator. Twelve requests arrive each hour and each person can resolve five. With two people, aggregate capacity is ten; under those assumptions, unfinished work grows. With three, capacity is fifteen. The exercise asks users to predict the trend before moving the control. It does not represent real waiting times: variability, breaks and differences between requests are excluded.

The evaluator should calculate those results outside the generated code. It should also check that the chart, explanatory text and success signal refer to the same state. If the interface celebrates an answer because the user clicked the right button even though the prediction is wrong, the activity fails. Store input and output examples alongside the artifact; an attractive screenshot cannot replace that comparison.

Organize three reviews with separate criteria. The first checks domain relationships using known cases and boundaries. The second exercises the product: keyboard, narrow screens, reset, rapid changes, hints and persistence. The third observes whether a person can explain the relationship they just explored without copying the interface. No aggregate score should conceal an essential failure in either of the other dimensions.

In our example, test zero demand, zero capacity and the exact balance point. Repeat after changing levels and after resetting. Human review should ask which assumptions the simplified model omits and whether hints encourage a prediction or immediately reveal the answer. To measure learning, design a separate evaluation with a new task; completing the activity and liking its appearance are different signals.

I suggest generating during preparation and serving approved versions during the session. This separates review time from the latency participants experience. Track requests, rejected attempts, specialist time and the cost of maintaining each version. The useful indicator for a pilot decision is cost per accepted activity, not the cost of the model’s first response.

Set an attempt limit and an explicit outcome when minimum quality is not reached: return the request to its author or use a previously reviewed activity. Do not weaken the rubric to turn an exhausted budget into a release. If the model, instructions or calculation core changes, rerun stored cases. A variant that fixes mobile layout can accidentally alter control state.

Attach objectives, assumptions, version and review ownership to the activity. Provide a simple way to report inconsistencies. Isolate executable content from the rest of the application and restrict its capabilities to what practice requires. In a pilot, avoid personal data that does not support the objective; use synthetic scenarios and decide which events you need to observe before instrumenting everything.

Define who can withdraw a version and how a valid activity is restored. If you discover an incorrect explanation, identify affected sessions before replacing the file. Preserve the evidence needed to review the failure without storing full conversations by default. Traceability supports correcting both product and content; it does not justify assuming an approved activity remains correct after any change.

Google’s release raises a useful question for education and training products: how much value does adapting an experience provide when its behavior also needs review? I would start with one narrow concept, a domain owner and a reference activity. I would retain generation only if it enables useful adaptation without making users responsible for discovering conceptual errors.

If you are evaluating a custom AI experience, turn these five decisions into acceptance criteria before choosing the model. Use our implementation roadmap and discuss the scope of a pilot with Wasyra. A reasonable next step is to define what users should learn or decide and what evidence will justify approving the experience.