Checkpoint: The Course Is an Executable Conversation
OpenMAIC is now visible as more than a generator, a data contract, or a playback feature. This checkpoint connects those established mechanisms around one practical question: what, exactly, is happening when a request or source material becomes a classroom that can speak and respond? The useful judgment is to classify each step as generated content, contract-enforced structure, runtime playback, or learner/session state. That classification shows both why the pieces form one loop and why a playable classroom still needs a durable, trusted building environment.
One request, four kinds of state
Consider a learner who brings a topic and a source document and asks OpenMAIC to make it teachable. The first result is not yet a classroom conversation. The model helps produce an ordered outline and then scene content: perhaps a visual explanation, a question, an interactive surface, or a project. This is generated content. Its quality depends on the supplied context, the model, the prompt, and the material. The system can parse, normalize, and reject parts of the response, but it cannot make a model's explanation true simply by accepting it.
The generated result then crosses a contract boundary. Each scene has a declared content kind, and the course DSL binds that type to the payload that belongs with it. Actions are likewise typed: speech, visual focus, whiteboard work, discussion, and widget operations are not arbitrary strings hidden inside a blob. Validation checks the shape, normalization supplies producer-independent defaults or derived geometry, and migration moves persisted data between known document versions. This is contract-enforced structure. It makes the output legible to the renderer, editor, storage layer, and playback engine, but it does not turn structural validity into instructional validity.
The same scene then crosses into runtime playback. The action sequence gives time and order to what was previously data. Speech may wait for audio or a reading fallback. A spotlight may fire without blocking. A discussion action may pause ordinary progression while the learner decides whether to join. The director may route a bounded agent turn, and the playback engine may move between playing and live modes. These are executed behaviors, not new versions of the source document. They interpret the course; they do not silently rewrite its meaning every time an action runs.
Finally, the learner and session produce state. A playback cursor records where the learner is. A discussion can become consumed so it does not trigger again on replay. A conversation can add a follow-up request. A future edit can change a scene while the learner's runtime facts remain a separate concern. This is learner/session state. It belongs in the loop because it tells the system what happened, but it should not be confused with the authoring document or with the model's original output.
A concrete request can pass through all four categories without changing its identity. Suppose the user supplies a paper and asks for a classroom explanation. The paper and request are input context. The outline and generated page copy are model proposals.