Streamlit dashboard content and presentation contract v1.8.1
Purpose
The Streamlit dashboard must be readable by a general audience and safe for policy, research and public communication. It is an explainer for a public-data anchored benchmark, not a calibrated simulator.
Migration note
This v1.8.1 contract remains binding for the Streamlit compatibility surface while the future interactive dashboard moves to a Plotly Dash app on Hugging Face Spaces. The same claim boundary, wording constraints, required visuals, table fallbacks and public-data limitations apply to the Dash surface unless a later Dash-specific contract supersedes this document.
The canonical public topology is:
- GitHub Pages: public front door, narrative report, static documentation and release links.
- Hugging Face Space: future interactive Dash simulation lab.
- Streamlit: compatibility/reference surface during migration.
Audience
The primary audience is an interested public reader, journalist, policy stakeholder, clinician, public servant or reviewer who has not read the full project.
The dashboard should not assume that the reader already understands capitation, fee-for-service, PHOs, NPCD, OIA, calibration or model indices.
Required first-screen content
The first screen needs:
- A plain-English title identifying the dashboard as a funding architecture explainer.
- The full model caveat:
This is a public-data anchored benchmark and educational explainer. It is not linked-data calibrated and not a patient-level forecast. It should not be used to claim precise fiscal savings, hospital-demand reductions, workforce effects, or implementation impacts.
- A short reader guide explaining the difference between reference scenarios and educational slider settings.
- A short guide to reading the dashboard.
Required sections
The dashboard needs these sections or tabs:
- Start here: thesis, claim boundary, model status and interpretation rules.
- Post guide / reading map: each public post mapped to the corresponding Quarto section, Streamlit module, GitHub Pages card, static visual and dynamic visual.
- Current state: current New Zealand reform pathway, public project status, static table and static diagram.
- Reference scenarios: precomputed model-generated indices and dynamic charts.
- Microeconomics lab: marginal supply, capitation budget constraint, scheduled activity payment and co-payment barrier modules.
- Game theory lab: formulas-do-not-solve-games module, payoff/best-response explanation, controls/gaming-risk module and guided educational incentive simulation.
- Educational explainer: educational sliders and dynamic educational-output chart.
- Educational parameter dictionary: plain-English definitions for every slider, including what 0, 100 and a high value mean.
- Evidence and OIA: public evidence tracker table.
- Calibration readiness: table of data required before real calibration.
- Glossary: plain-English definitions of core terms.
Required current-state information
The current-state section must explain that the current reform pathway is the comparator, not a straw man. It should cover:
- capitation reweighting;
- primary care access target;
- National Primary Care Dataset;
- digital access and telehealth;
- urgent and after-hours care;
- PHO accountability and commissioning.
Required visual and tabular material
The dashboard must mix static and dynamic material:
- Static tables:
- current reform pathway table;
- public project status table;
- evidence/OIA tracker table;
- calibration-readiness table.
- Static diagram:
- public explainer architecture diagram showing current reform pathway, tested gap, benchmark, educational explainer, evidence tracker and calibration readiness.
- Dynamic figures:
- reference scenario viability chart;
- reference scenario supply-generation versus hospital-pressure scatter plot;
- scenario score heatmap;
- selected scenario radar/profile chart;
- educational explainer output chart;
- project readiness chart.
- marginal supply simulation;
- co-payment/access barrier simulation;
- game-theory payoff or best-response simulation;
- gaming-risk frontier or controls-stack simulation.
Post-to-dashboard crosswalk
The dashboard must implement the public reading map defined in:
docs/public-site/post-surface-crosswalk-contract-v1.8.2.md
Minimum mappings:
| Post | Streamlit destination | Required dynamic component |
|---|---|---|
| 01 upstream rationing and hospital growth | Start here; Current state; Reference scenarios | Supply versus hospital-pressure plot |
| 02 FFS/capitation/blended funding | Funding models or Educational explainer | Funding comparison educational module |
| 03 marginal supply | Microeconomics lab | Marginal supply simulation |
| 04 formulas do not solve games | Game theory lab | Educational incentive game or best-response simulation |
| 05 current reform pathway | Current state; Reference scenarios | F0/current reform comparator selector |
| 06 uncapping primary care funding | Educational explainer; Microeconomics lab | Activity/payment/control simulation |
Later game-theory posts and appendices that are referenced by the public surfaces must have a corresponding dashboard module or guided explainer. They must not remain only as off-dashboard background.
Wording constraints
The dashboard must:
- use “explainer”, “public-data anchored benchmark”, “reference scenario”, “educational explainer” and “model-generated index”;
- describe outputs as model-generated indices, not observed New Zealand outcomes;
- state that F0/current reform is the comparator;
- state that educational sliders do not rerun the full parameterised model;
- state that educational sliders are qualitative teaching levers, not estimated structural parameters;
- define the educational scale as 0 = absent/weak and 100 = strong/reliably implemented;
- use public slider labels that explain the policy lever rather than exposing only internal implementation names;
- state that index differences must not be converted into dollars saved, beds avoided, workforce numbers, ED reductions or implementation impacts.
The dashboard must not:
- describe itself as a calibrated simulator;
- describe slider output as a forecast;
- imply precise fiscal savings, hospital-demand reductions, workforce effects or implementation impacts;
- imply government endorsement.
Deployment contract
The Streamlit compatibility dashboard must remain deployable from Streamlit Community Cloud using:
- repository:
edithatogo/gtpcnz; - branch:
main; - entrypoint:
streamlit_app.py.
The Streamlit compatibility URL is:
The future interactive Dash lab is: