GTPCNZ
  • Home
  • Public report
  • Dashboard
  • Model card
  • Claim boundaries
  • Evidence tracker
  • Calibration readiness
  • Dashboard contract
  • Post crosswalk
  • Repository guide

On this page

  • Streamlit dashboard content and presentation contract v1.8.1
    • Purpose
    • Audience
    • Required first-screen content
    • Required sections
    • Required current-state information
    • Required visual and tabular material
    • Post-to-dashboard crosswalk
    • Wording constraints
    • Deployment contract

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 source-informed model scaffold, not a calibrated simulator.

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 source-informed parameterised scaffold and educational explainer. It is not a real-data calibrated forecast and 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 toy 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 toy incentive simulation.
  • Toy explainer: educational sliders and dynamic toy-output chart.
  • Toy 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, scaffold, toy 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;
    • toy 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 Toy explainer Funding comparison toy module
03 marginal supply Microeconomics lab Marginal supply simulation
04 formulas do not solve games Game theory lab Toy incentive game or best-response simulation
05 current reform pathway Current state; Reference scenarios F0/current reform comparator selector
06 uncapping primary care funding Toy 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”, “source-informed scaffold”, “reference scenario”, “toy 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 toy sliders do not rerun the full parameterised model;
  • state that toy sliders are qualitative teaching levers, not estimated structural parameters;
  • define the toy 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 dashboard must be deployable from Streamlit Community Cloud using:

  • repository: edithatogo/gtpcnz;
  • branch: main;
  • entrypoint: streamlit_app.py.

The public URL is:

https://gtpcnz.streamlit.app/

GTPCNZ

 

Source-informed scaffold; not a real-data calibrated forecast