The model specification has been confirmed. Coding builds the model from it and tests it. No language model writes model code, and the generated code is never edited by hand.
The specification files from the previous step are uploaded. The platform sets up the model, builds the structure, the R model and the Excel workbook, then runs the tests and writes its review.
Building takes seconds. Most of the time goes into testing.
The scorecard shows how many tests apply to the model and how many passed, failed or errored. Tests that were skipped are listed with their reasons, and a skip is never counted as a pass.
In the film, 38 tests apply to the model: 35 passed, 2 failed and none errored, and 11 were skipped. This was the quick set of checks, and the full checks were not run.
The review reads like a reviewer's note: what the model is, what the tests found, and where to look first. The model synopsis, the parameters and the results, with costs, outcomes and the cohort trace for each arm, are on the same screen.
You can ask why a test failed. In the film, the two failures concern one input, a relative risk that does not change any result. The answer separates what the test material establishes from what it cannot see, and concludes that the input is wired incorrectly and that no value is missing.
A change to how the model computes a transition is a change to its structure. Coding refuses it, explains why, and keeps it on the plan, because structure is decided in Model Specification.
A change of value is queued as a revision. Nothing changes until the plan is applied.
Applying the plan rebuilds the model from the specification and runs the tests again, rather than patching the old build. The revision plan then shows what was applied and what was refused.
On the Results tab, the change moves one cost class in the film, and the other cost classes and the QALYs are unchanged.
Everything downloads: the R project, the Excel workbook, the session record, the testing report and the parameters.
The R project carries the inputs, the engine, the analysis, the sensitivity analysis and a Shiny app. The workbook holds the same model for those who review cell by cell.
The Excel workbook opens on a cover. It lists the engine and build, the time horizon, which cells are editable, and a contents list with one sheet for each part of the model.
The Results sheet shows the totals for each strategy and the ICER. A value edited in the review is marked as user edited on its sheet, so the workbook carries the revision.
The sensitivity analysis control panel sets the number of simulations and the willingness to pay. It runs through a macro, which is imported once, following the instructions shipped with the file.
In R, one script runs both strategies and prints the league table. The totals and the ICER are the same as in the workbook.
The cost-effectiveness plane places one strategy against the other, and the Markov trace shows the share of the cohort in each state, for each arm, over the cycles.
In the generated Shiny app, the Results page runs the model. It shows the incremental cost, the incremental QALYs and the ICER, with the plane, the Markov trace and a table of totals for each strategy.
The input pages carry a note: edits are a what-if for the session and do not change the compiled model.
The one-way analysis re-runs the model in the app. Where the source gave no range, each parameter is varied by ten percent either way, which is a convention and not published uncertainty.
The probabilistic analysis runs 1,000 draws in the app, then draws the acceptability curves and the cost-effectiveness scatter.
In the testing report, the workbook was recalculated and its headline totals matched the R model on all 12 compared quantities. The report also lists the tests that did not pass.