What Is a Verified Interactive Explainer? Ledger-Checked Prose, Browser-Exercised Panels

A verified interactive explainer is a generated instructional page — prose plus interactive panels — that a system refuses to publish until two machine checks pass: claim-by-claim verification of the prose against an evidence ledger, and browser exercise of every panel. The format matters to anyone shipping generated interactive instructional content, because it draws a hard line between what verification can guarantee and what still requires a human. All facts here trace to Learning Explained at Five Levels, an implementation report with a public MIT-licensed reference implementation.

What is a verified interactive explainer?

The format separates three concerns that generated content usually fuses:

• The shell is code. Page chrome, tabs, sanitizer, and iframe messaging are owned by the system, not the model.
• The levels are content. The model writes prose plus panel markup and panel JavaScript for each of five fixed audience rungs — child, teenager, undergraduate, PhD student, peer — with one running example rebuilt at every level. This fixed structure is the audience ladder; per the paper, "the rungs never move: that is what makes the format a format."
• Publication is a gate. Claims are verified against an append-only evidence ledger, panels are exercised in headless Chrome, and release is blocked if either step failed or never ran.

One sentence: a verified interactive explainer is generated teaching content where "verified" means machine-checked prose and machine-exercised panels standing between the model's output and the reader.

How does it work?

The pipeline runs in seven stages:

1. Research. A question is researched into an append-only evidence ledger, shared unchanged with the agent's paper format.
2. Design. One structured call produces a running example "a child can hold and an expert can still argue about," a palette, a shared data model every panel uses "so the child's toy and the expert's model are the same objects," and five level plans with evidence ids.
3. Write five levels in parallel. Each writer returns prose citing [E:id] tokens plus panel markup and JS. A writer that raises is stubbed and routed to repair — one level cannot kill the page.
4. Assemble. Levels drop into the fixed HTML shell; a sanitizer strips active markup from model output; the page ships under a strict CSP with no network access at runtime. Note the paper's own caveat: a sandbox bounds what a panel can reach, not what it can claim.
5. Validate panels. A node --check syntax pre-check runs per level, then headless Chrome clicks each tab, requires a rendered SVG or canvas in each stage, operates up to 10 controls per level under timeouts, and flags static controls. Failing levels return to their writer for at most two repair rounds.
6. Verify prose. All five levels are flattened into one document and each claim gets a verdict against the ledger's quotes. Levels 3–5 must cite the ledger for every material claim; levels 1–2 need not.
7. Publish gate. The gate blocks if verification did not run, extracted no claims, judged any claim unsupported or contradicted, if citations reference ids not in the ledger, or if panel validation did not run, was unavailable, or failed. A blocked gate opens the pull request as a draft and prints "Publication blocked pending human review."

Empirics from the report: three published pages, produced in 293.4 to 576.2 seconds of wall clock each, two of them with zero repair rounds. Across the three runs the verifier checked 60 claims — 52 supported, 8 partial, none unsupported or contradicted — and the browser exercised 90 controls across 15 panels with no failures. A partial verdict deliberately does not block: it is "a wording problem for the reviewer to see, not an unsupported assertion."

Why does it matter?

The paper's framing for the learning pillar is blunt: "Knowledge that nobody consumes is wasted." A passage the reader can interrogate by changing an input is consumed. But "decoration is not interaction," and a dead button is a defect. Without gates, three failure classes ship directly to learners:

Unverified prose ships confident errors at five expertise levels at once. A single wrong claim in the design propagates into the child's version, the undergraduate's version, and the peer's version simultaneously.

Unexercised panels ship dead interactives. Model-written panel code can fail to parse, throw at run time, render an empty stage, or wire a control to nothing — and none of that is visible in the prose. A page can read perfectly and do nothing.

A prompt that describes a subject instead of a format corrupts the running example the whole pedagogy hangs on. The running example, the palette, and the visual idiom are the pedagogy; if they are inherited from whatever page the format was modeled on rather than derived from the topic at hand, every subject gets nudged toward one vocabulary and one picture.

The worst plausible outcome is the one the paper names itself. The verifier checks prose, never panel code or its outputs, so "a level-4 simulation can converge to the wrong value, and the page will render, pass validation, score full marks on its claims, and be wrong. This is the gap most likely to publish a confidently incorrect interactive."

How do you build for it?

Six design patterns from the paper, each with its cost and its coverage limit. None of them is sufficient alone; the point is what each does not cover.

1. Evidence ledger plus claim verification as a publish gate. Every material claim at expert levels must cite the ledger; unsupported or contradicted claims block release outright. Cost: a full research phase and verifier-lane model calls per page. Does not cover: panel computations, the numbers a simulation produces, or claims at the two lowest levels.

2. Syntax pre-check before browser time. node --check per level, with line numbers renumbered to match the panel code. Cost: trivial. Does not cover: runtime errors, dead controls, or wrong output — only parse failures.

3. Fault isolation per level. One script block per level, so a failed level reports in its own stage and routes to repair while the others ship. Cost: shell complexity. Does not cover: shared-data-model errors that poison all levels at once.

4. Browser exercise of every control. Headless Chrome clicks tabs, requires a rendered SVG or canvas, operates controls under a per-level 35-second budget, flags static controls, and screenshots each level. Cost: roughly 15–19 seconds per passing page, a Chrome dependency in CI, and a 240-second ceiling. Does not cover: pedagogical quality — "a button whose handler changes nothing passes, and an empty axis satisfies the stage check."

5. Topic-neutral prompt regression tests. The prompts describe only the format, carrying worked examples that span unrelated fields so no discipline reads as the default, and test_prompts_are_topic_neutral and its companions fail the build if that stops being true. Cost: maintaining the word list the tests scan for. Does not cover: vocabulary not on the list. Tests, not a run that happens to come out clean, are what hold this line.

6. Bounded repair, then human review. At most two in-graph repair rounds fix code failures only. The pull request — draft if gated — carries per-level screenshots, and that review is where a human catches dull panels or drifted examples. Cost: human time per page. Does not cover: nothing automated sends a level back "because its panel is dull or its running example drifted." This is the same lesson that shows up in pedagogical safety: gates protect learning, not just correctness, and the last gate is a person.

Related concepts and tools

• Learning Explained at Five Levels — the source paper; every factual claim above traces to it.
• Audience ladder — the fixed five-rung structure that makes the format a format.
• What is a generative AI tutor? — an adjacent generated-instruction architecture with its own failure-mode framing.
• AI tutoring and adaptive learning — the pillar topic hub; see also the generative AI tutor design checklist for adjacent design decisions.

FAQ

How is a verified interactive explainer different from an AI-generated tutorial?

Two machine gates stand between generation and publication. Prose claims are verified against an append-only evidence ledger, and every interactive panel is exercised in a headless browser. A typical generated tutorial has neither. The other difference is enforcement: failure blocks publication rather than flagging it. A blocked gate opens the pull request as a draft and prints "Publication blocked pending human review" — the page cannot quietly ship anyway.

Can verification catch an interactive panel that computes the wrong answer?

No. The verifier sees only the flattened prose of all five levels, never panel code or the numbers a panel computes. The paper is explicit: a level-4 simulation can converge to the wrong value and the page will render, pass validation, score full marks on its claims, and be wrong. This is the format's named open problem, and the reason human review before merge remains required.

What does browser validation actually prove?

Absence of failure, not presence of function. Each panel must render an SVG or canvas, every control must be clickable without throwing or timing out, and static controls get flagged for the reviewer. But a button whose handler changes nothing still passes, and an empty axis satisfies the stage check. Browser validation proves the panels are alive; whether they teach anything is a question the machine gates do not answer.

The useful takeaway for anyone building similar systems: "verified" is a precise claim about prose and liveness, and the honest version of the format states out loud what its gates do not check.