Skip to content

Booth Demo Guide

Use this page when you need a clean live story for a Zoom call, jury table, sponsor walkthrough, or fair booth.

The demo bundle creates:

  • three simulation runs
  • a jury-friendly poster
  • a written talk track
  • optional AI-ready artifacts for the safety case

The Story It Tells

The booth demo tells one clean story in three panels:

  1. Normal Run A moderate day where the controller keeps glucose in range.
  2. Meal Stress Test A harder day with larger meals and exercise.
  3. Supervisor Override A deliberately unsafe AI request that gets blocked by the safety supervisor.

The public message stays simple:

  • it simulates
  • it stresses
  • it protects

Fastest Way To Run It

From the repository root, for the cleanest live on-stage flow:

./scripts/run_live_stage_demo.sh

That script is backed by examples/demos/07_live_stage_demo.py, which is the best file to show first because the top of the file clearly exposes the patient profile, output directory, duration, and deterministic seed.

It also visibly demonstrates these SDK features in code:

  • run_full(...)
  • generate_results_poster(...)
  • prepare_ai_ready_artifacts(...)

You can also run the full booth bundle script directly:

./scripts/run_booth_demo.sh

Or with the CLI:

iints demo-booth

Or from source:

PYTHONPATH=src python3 examples/demos/06_booth_demo.py

Main Outputs

By default the outputs go to results/booth_demo/.

Key files:

  • results/booth_demo/booth_demo_poster.png
  • results/booth_demo/booth_demo_poster.json
  • results/booth_demo/JURY_TALK_TRACK.md
  • results/booth_demo/BEURS_LIVE_DEMO_SCRIPT.txt
  • results/booth_demo/run_commands.md
  • results/booth_demo/demo_summary.json
  • results/booth_demo/showcase_study/showcase_study_summary.json
  • results/booth_demo/showcase_study/showcase_study_poster.png
  • results/booth_demo/showcase_study/SHOWCASE_RESEARCH_SYNC.md
  • results/booth_demo/showcase_study/SHOWCASE_EXPLANATION_PANEL.md

For the larger public story, you can also build:

iints demo-expo --output-dir results/expo_demo

That adds:

  • results/expo_demo/study_summary.json
  • results/expo_demo/study_summary.md
  • results/expo_demo/evidence_table.csv
  • results/expo_demo/evidence_table.md
  • results/expo_demo/study_poster.png

Each scenario also gets its own full run bundle with:

  • results.csv
  • audit/
  • baseline/
  • clinical_report.pdf
  • run_manifest.json

The showcase_study/ subfolder is the research-sync layer for fairs and jury tables. It mirrors the benchmark language used by iints run-study:

  • baseline vs candidate
  • safety-on vs safety-off
  • the same TIR, hypo, intervention, uncertainty, and calibration vocabulary used in study bundles
  • a plain-language explanation panel you can read out on the stand without changing the scientific terminology

Best Live Flow

Use the smallest readable source file as your starting point:

examples/demos/07_live_stage_demo.py

What to point at first:

  • PATIENT_CONFIG - show that a patient can be swapped
  • OUTPUT_DIR - show that all artifacts land in one bundle
  • DURATION_MINUTES and TIME_STEP_MINUTES - show simulation control
  • SEED - show reproducibility

For a Zoom call or jury meeting, the easiest all-in-one command is:

iints demo --output-dir results/live_demo --audience jury

That now starts with an audience-aware opening explanation, writes PRESENTER_GUIDE.md, DEMO_STORY.md, DEMO_CUE_CARD.md, DEMO_ARTIFACTS.md, and RUN_LIVE_DEMO.sh, runs the exported demo script in clean stage mode, saves noisy execution details to DEMO_RUN_LOG.txt, and ends with a terminal table of the poster, talk track, summary JSON, and scenario folders.

For live conversations, use the story shortcut that matches the room:

iints demo doctor --output-dir results/demo_doctor
iints demo eucys --output-dir results/demo_eucys
iints demo booth --output-dir results/demo_booth
  • doctor opens as a clinical safety discussion: virtual patient, risk context, supervisor decision, and questions for medical feedback.
  • eucys opens as one controlled experiment: research question, hypothesis, normal run, stress run, risk run, and evidence.
  • booth opens as a public digital-patient story: scenario change, algorithm suggestion, safety check, and visual proof.

It also builds a public research evidence folder by default:

results/live_demo/evidence_bundle/
  README.md
  MODEL_CARD.md
  evidence_summary.json
  run_index.csv
  runs/

Use --no-evidence only for a quick rehearsal. For doctors, engineers, juries, and booth visitors, keep the evidence bundle enabled so you can show that the poster comes from reproducible run folders.

For the actual call or booth moment, use the normal live command above. Use iints demo --dry-run only as a rehearsal/preflight before people are watching. If you need raw subprocess output while debugging, add --technical.

Use the generated files like this:

  • DEMO_STORY.md - the audience-first explanation, including the first 30 seconds, core sentence, safety boundary, and proof order.
  • DEMO_CUE_CARD.md - one-page script for a Zoom call or booth explanation.
  • DEMO_ARTIFACTS.md - exact files to open and what each artifact proves.
  • RUN_LIVE_DEMO.sh - rerun the exported demo without remembering arguments.
  • PRESENTER_GUIDE.md - longer audience-specific explanation and fallback plan.
  • DEMO_RUN_LOG.txt - raw execution output, kept out of the live terminal unless needed.

The presenter guide also points you to two ready-made physiology handouts:

  • research/eucys_pack/pdf/EUCYS_05_PHYSIOLOGY_REFERENCE_BROCHURE.pdf
  • research/eucys_pack/pdf/EUCYS_06_JURY_PHYSIOLOGY_BRIEF.pdf

Use the audience mode that matches the room:

iints demo doctor --output-dir results/live_demo_clinical
iints demo eucys --output-dir results/live_demo_jury
iints demo booth --output-dir results/live_demo_booth
iints demo --output-dir results/live_demo_clinical --audience clinical
iints demo --output-dir results/live_demo_engineering --audience engineering
iints demo --output-dir results/live_demo_jury --audience jury

The story shortcuts decide what you say first. The audience option still tunes wording inside the guide. For example, iints demo doctor keeps code and folders as proof artifacts instead of the opening screen.

iints demo-live remains available as an explicit alias, but for live calls and booth work the intended command is simply iints demo.

If you specifically want to drive the repository script yourself, then run:

./scripts/run_live_stage_demo.sh

That wrapper script resolves the repository root automatically, so you do not have to manually cd into the right place first if you launch it via its full path.

Then open:

  • results/booth_demo_live/booth_demo_poster.png
  • results/booth_demo_live/JURY_TALK_TRACK.md
  • results/booth_demo_live/BEURS_LIVE_DEMO_SCRIPT.txt

If you are on a machine that only has the installed SDK and not the repository checkout, first export the same showable demo code with:

iints demo-export --output-dir iints_demo
cd iints_demo
python 07_live_stage_demo.py

If someone wants proof that the poster is real, open one of the scenario folders and show:

  • results.csv
  • clinical_report.pdf
  • run_manifest.json

Optional Local AI Step

If Ollama and a local Ministral model are ready, the booth demo also prepares the Supervisor Override run for AI explanation.

Recommended live check:

iints ai local-check --model ministral-3:3b
iints ai report results/booth_demo/03_supervisor_override --model ministral-3:3b
iints ai review results/booth_demo/03_supervisor_override --model ministral-3:3b
iints ai explain results/booth_demo/03_supervisor_override --model ministral-3:3b

Jury Framing

Suggested one-line pitch:

IINTS-AF is a safety-first SDK for testing insulin-delivery algorithms before they ever touch a real patient.

Suggested walkthrough:

  1. Open examples/demos/07_live_stage_demo.py and point at PATIENT_CONFIG, OUTPUT_DIR, DURATION_MINUTES, and SEED.
  2. Say that a different patient can be tested by swapping the patient profile name or pointing to another YAML config.
  3. Run ./scripts/run_live_stage_demo.sh.
  4. Open the left panel first: normal control.
  5. Move to the middle panel: stress handling under meals and exercise.
  6. Finish on the right panel: the supervisor blocks unsafe insulin.
  7. Point out that each panel comes from a full reproducible run bundle, not a hand-drawn mockup.
  8. If time allows, show the local AI explanation on the safety case.

Why This Is Good For A Fair

  • one command to run
  • one poster to show
  • one markdown talk track to read from
  • one safety story that non-technical people can understand

Alternative: Live Raspberry Pi Demo

If you want a more "alive" booth setup, use the new persistent patient runtime instead of the three-panel booth bundle:

iints quickstart --project-name iints_pi_demo
cd iints_pi_demo
iints patient scenarios
iints patient start \
  --algo algorithms/example_algorithm.py \
  --workspace patient_runtime \
  --scenario-profile normal_day \
  --mode demo-time \
  --speed 60x

Then present:

  • the dashboard at http://127.0.0.1:8765/dashboard
  • iints patient inject-meal --carbs 60 --workspace patient_runtime
  • iints patient expo-reset --workspace patient_runtime
  • iints patient export-service --workspace patient_runtime
  • optionally iints patient review --workspace patient_runtime --model ministral-3:3b

That path is documented in: