The Subject Is a Delivery Task, Not a Tutorial
On September 23, 2026, Simon Willison recorded a prompt aimed at Fable 5.1 Medium: “Build an artifact to explain shadow roots in CSS with interactive examples.” On the surface, the subject is CSS shadow roots. In practice, the prompt asks the model to build an artifact and place the explanation inside an interactive experience with live examples. The required output is therefore not a definition or a collection of isolated code fragments. It is a frontend deliverable that a user can open, operate, and learn from.
That distinction determines how the record should be read. The source provides the task prompt and its topic, but it does not show what Fable 5.1 Medium generated. It does not say whether the page ran successfully, and it supplies no interaction tests, browser-compatibility findings, or assessment of explanatory quality. The record demonstrates that a capability test was proposed, not that the test was passed. Even if an artifact existed, this material would not justify claiming that Fable 5.1 Medium is better than other models at frontend development, browser debugging, or interaction design.
Interaction Changes the Unit of Evaluation
A conventional conceptual question usually treats the correctness of the explanation as the main acceptance criterion. If a model defines the term and produces code that looks plausible, a reader can judge the answer from the text. An interactive artifact changes that standard. The explanation must be organized inside an interface, the code must perform a real role on the page, and the user must be able to observe a change that corresponds to the concept. The evaluation target becomes a loop from knowledge to behavior rather than an answer alone.
That loop contains at least three dependent parts. The first is the mechanism explanation, which must represent the CSS behavior accurately. The second is the example implementation, where the code and controls must correspond to the concepts described. The third is the feedback, where user actions should produce a change that helps the user understand what happened. If any part is missing, the artifact may be only a visually complete demo. Accurate prose with broken code, a runnable page whose controls are unrelated to the lesson, or changes that provide no interpretable feedback all represent failures of the original delivery task.
Why Frontend Teaching Makes a Low-Risk Capability Test
This kind of task works well as an end-to-end capability test because it compresses abstract knowledge into a relatively bounded deliverable. A CSS mechanism can be divided into examples, the examples can be placed in a page, and the page must respond to user actions. The model must understand what is being explained, plan the information structure and interaction model, generate the code, and connect the parts. A short prompt therefore covers content organization, interface construction, runtime delivery, and user feedback.
Compared with giving a model direct control over a production system, a frontend teaching task has a more manageable failure cost. An incomplete page may not directly affect business data or an online service, yet it can still expose the model’s integrated weaknesses. A model may be good at writing a conceptual explanation but unable to turn it into a runnable page. It may also generate a complete-looking interface without establishing a clear relationship among the controls, the examples, and the lesson. Treating the teaching artifact as the acceptance target separates something that merely looks finished from something users can actually use to verify an idea.
That is why this record is more instructive than an ordinary model demo. Frontend teaching is not valuable because it is trivial. It is valuable because it places several model outputs inside one observable object. A technical leader can inspect whether a page exists, whether the code works, whether the interaction serves the explanation, and whether the user can form the intended understandin
Do Not Confuse the Prompt, the Model Name, and the Result
The page also lists other model information, including Claude Opus 5.5, GPT-6 Sol, and GPT-6 Luna, but those names do not form a set of evaluation results for this task. There are no parallel artifacts, no shared acceptance criteria, and no comparison showing who performed better. Fable 5.1 Medium therefore should not be placed in a completed model competition, and the other names should not be used as evidence for its capabilities. Connections in the knowledge graph involving Claude Fable 5 and other models can describe an ecosystem relationship, but they cannot replace the experiments missing from this record.
The boundary of the product itself also requires caution. The supplied material does not identify who publishes Fable 5.1 Medium, and it does not answer how it differs from Claude Artifacts. A technical leader evaluating tools cannot infer the deployment model, execution environment, permission model, cost, or maintenance responsibility from this record. The prompt reveals an interface to a task. It does not reveal a complete product architecture.
Turning a Prompt Record into an Actionable Acceptance Benchmark
If a team wants to use a task like this for internal evaluation, the prompt must be only the starting point. First, the team should preserve the artifact that the model actually delivered rather than keeping only the chat transcript or generation process. Second, each live example should have a named concept and an expected behavior, so that the code, controls, and explanation can be checked for correspondence. Third, the interaction should be tested to confirm that a user action produces the expected change and that the change is sufficient to support the intended explanation.
The evaluation should also record where failure occurs. A page that cannot start represents a runtime delivery problem. An example that conflicts with its explanation represents a broken connection between knowledge and implementation. An interaction that works but gives confusing feedback represents a teaching-design problem. Separating these failures reveals whether the model lacks code generation, mechanism understanding, interaction planning, or verification discipline. Without that separation, teams may use “the page opens” as an overly weak standard and mistake a presentable shell for a completed deliverable.
The lasting conclusion from this record is not that Fable 5.1 Medium has mastered shadow roots. It is a more useful engineering criterion. Whether a model can explain a concept shows that it can generate content. Whether it can deliver an artifact that runs, responds to users, and allows the explanation to be verified is much closer to the integrated capability that technical teams need.