The first Simulation Learning Lab milestone was intentionally infrastructure-first.
Before expanding the authoring experience, I wanted a stable browser-to-Python boundary, a clear experiment lifecycle, containerised local execution and a runtime that could stream experiment state back to the workspace. That milestone answered an infrastructure question: can the product reliably create, run and observe a simulation experiment through the architecture I want to build on?
The next milestone answers a different question: what structure helps a learner turn evidence into an experiment they can reason about, change and evaluate?
That is where Evidence, Plan, Author and Preview come in.
The experiment is the organising unit
A useful learning environment should help the learner make the reasoning around a simulation explicit:
- What am I trying to understand?
- What evidence or assumptions am I starting from?
- What variable am I changing?
- What should stay fixed?
- What should I observe during the run?
- How does the result compare with the expectation or previous run?
The simulation runtime is essential, but it is not the whole learning model. The product needs to preserve the question, the setup and the comparison around the execution.
Evidence, Plan, Author, Preview
I am structuring the authoring flow around four stages.
Evidence holds the source material, observations or system context that motivate the experiment.
Plan turns that context into a testable scenario with explicit variables, constraints and expected observations.
Author configures the actual simulation behaviour and the parameters that are allowed to change.
Preview makes the experiment inspectable before execution and gives the learner a clear view of what will run.
This keeps the simulation engine inside a learning sequence rather than forcing the interface to reconstruct the purpose of a run after the fact.
Why the runtime came first
Staging the work this way gives the learning layer a dependable execution contract.
The authoring model can evolve without also changing the basic rules for starting experiments, streaming state or managing the local runtime. The runtime can be tested as infrastructure, while the learning model can be evaluated against a different standard: whether a learner can form a useful experiment and understand the result.
Those are related problems, but they are not the same problem.
Counterfactuals make simulation useful
The strongest simulations are not only demonstrations of what happened. They let the learner ask what changes when one meaningful condition is different.
That is why scenario controls and comparison matter to the project. A learner should be able to alter an assumption, rerun the experiment and inspect the difference without losing the context of the original run.
The public evidence gate
Simulation Learning Lab remains in the portfolio build log until the case study has visual evidence for the product behaviour I want to claim:
- the workspace and lab library;
- the Evidence to Plan to Author to Preview flow;
- one representative simulation runtime;
- the evaluation or learning evidence that demonstrates the experiment loop.
The point of that gate is simple: the public case study should follow demonstrated behaviour. The implementation can move through deliberate milestones without the portfolio pretending a later milestone was already complete.