# Demo runbook

## Starting the demo

Open the configured deployment URL, for example `https://fleetops.example.com`, or `http://localhost:1228` for local development. The login screen names the fictional organisation, states that all data is synthetic and offers:

- **Start begeleide demo** — logs in as Operations Manager and opens the Demo Guide at step 1;
- **Verken als Operations Manager** / **Verken als Rental Employee** — free exploration without the guide.

No password is shown or required for either synthetic-demo path.

## Five-minute demo

1. Click **Start begeleide demo**.
2. Follow steps 1–3: dashboard, booking needing attention, and the pre-filled odometer-anomaly return.
3. Resolve the data-quality issue created by the return. “Retain canonical” is the fastest demonstration path.
4. Ask a suggested knowledge question and show the cited source.
5. Show the automation/audit-trail link-through.
6. Close with the About page’s real/synthetic/not-connected breakdown.

## Ten-minute demo

Complete the five-minute path, then use `/scenarios`:

- scenario 2: duplicate customer merge;
- scenario 3: booking overlap, resolved through `/data-quality`;
- scenario 4: failed automation retry through `/automation`.

All scenarios are deterministic and independent after a reset.

## Resetting the environment

An Operations Manager can reset from the sidebar, Demo Guide or About page. Reset requires confirmation, rebuilds only the deterministic MobilityOps dataset, runs a server-side integrity check and invalidates the acting session. It never mutates shared n8n, RAGcore, MCP data, unrelated containers or volumes. Disable reset entirely with `DEMO_ALLOW_RESET=false` where required.

## Deployment contract

Create a source archive from the exact reviewed commit, record its SHA-256 and full Git SHA, transfer it through the operator-approved channel, and invoke `deploy/unraid/deploy-release.sh` with those immutable identifiers.

Keep the following values in operator-local configuration rather than repository documentation:

- deployment host or SSH alias;
- SSH key selection;
- persistent appdata directory;
- public application URL;
- n8n and RAGcore endpoints;
- tokens and callback secrets.

An Unraid installation commonly uses a path such as `/mnt/user/appdata/mobilityops`, but that is an example only. See `deploy/unraid/README.md` for the parameterized deployment layout.

The deployer verifies the archive checksum, extracts into a commit-named release directory, builds revision-labelled immutable images, promotes without reseeding and checks application, backup and observability health. Reset demo data only as a separate deliberate action.

## Rollback

`.deploy/source-revision` and `.deploy/release-history.log` record the live commit and image tags. A failed readiness check restores the previous image IDs. Database rollback remains a separate explicitly guarded restore operation.

## Server safety

Only touch the `mobilityops` Compose project’s own `api` and `web` services, and interact with `db` only through migrations or the guarded backup/restore flow. Never stop unrelated containers, run broad Docker pruning, delete unrecognised resources, overwrite the server `.env`, print secrets, start a second permanent n8n instance or activate guessed integration URLs. PostgreSQL must remain unexposed.

## Troubleshooting

- **Scenario unavailable:** it was already resolved since the last reset; reset the synthetic dataset.
- **Knowledge question returns insufficient evidence:** use a suggested question and inspect provider health/citations; the adapter refuses ungrounded answers.
- **Unexpected failed n8n delivery:** use the automation view and bounded retry path; inspect operator-side n8n logs without committing them.