Run the event
Start the environment
Configure OPERATOR_TOKEN with at least 16 characters. Launch the application and PostgreSQL with the repository's Compose configuration. Keep the operator token with organisers.
Before participants arrive, run:
pnpm verify -- doctor
pnpm smoke
pnpm verify -- journey
The smoke test creates a team world, reads each advertised adapter, transfers a legacy document, and checks a delayed test result.
Prepare teams
Ask participants to create or join a team from the map. Names are lowercased with all whitespace removed; entering the same name returns the same world and reusable API key. Test the expected number of concurrent worlds before the event. PostgreSQL stores patient records, resources, events, and receipts as separate rows. Teams share the published population baseline and keep their changes in separate worlds.
See what teams are doing
Open Organiser controls and connect with this deployment's operator token. A participant key cannot unlock this screen. The local Compose default is local-operator-change-me; the hosted deployment has its own token. You can paste the token alone or with a Bearer prefix.
Search the team directory and select a team by name. Review its API requests, affected patients and recorded changes. API requests show the method, path, status and duration. A request that reads a patient is distinct from a recorded change to that patient.
Request logging starts when this feature is deployed; older API calls cannot be reconstructed. Recorded changes use existing provenance, so earlier attributed work can still appear. Request history retains up to 2,000 calls per world for seven days. It omits credentials, query strings and request bodies. The console refreshes while open.
Choose Explore as this team to open the team's existing world using its participant permissions. This switches the shared participant connection across tabs in this browser. Changes you make there are real changes in that synthetic world and carry its team attribution. The exploration banner identifies the active team in each tab. Use Return to organiser to restore your previous team connection and return to the console.
Operator access is remembered in this browser tab for navigation to CIS2 and the clinical apps. Disconnect operator access when finished. Operator credentials are separate from the participant key saved in localStorage.
Delete an unused team
Select a team and choose Delete team, or use the directory checkboxes to select several teams. Select all matching selects the teams in the current search. Review the selected names and world IDs, then confirm permanent deletion once. You do not need to type team names. Cancel leaves every team unchanged.
Deletion revokes all keys for that world and removes its records, events, pending work and API request history. It frees a team slot. Other teams and shared synthetic population baselines remain intact. Anyone entering the deleted name later creates a new world; they cannot recover the old records that way.
Use the activity history to decide which teams to remove. No requests yet can mean the team predates request logging, so it is not proof that the team is unused. Teams are never deleted automatically.
Introduce a failure
In Organiser controls, select the team before changing incidents, agents or simulation time. The selected team's name identifies which world each control affects. Leave deterministic agents enabled for the initial run, then introduce one incident for the team's second demonstration.
World agents are scripted simulation workers, not participants' AI models. They process work as simulation time advances. Turning off an incident removes the fault condition but does not undo requests or arrivals it already created.
Use All-team incidents to introduce the same disruption across every current team, or restore that service across all teams. Choose the incident and review the number of teams before confirming. The default seed world is excluded, and teams created later do not inherit the disruption. If the team list changes before you confirm, refresh and review the new count before trying again.
Operator API endpoints accept ?world=.... Team clock requests always affect the key's own world.
Exercise staff sign-in
Open Staff Identity organiser controls from the console. The same tab reuses your validated operator token. You can also enter it directly in the CIS2 token form. The workbench provides operator controls for client registration, token lifetime, denial, session expiry and service unavailability, alongside the fictional staff sign-in.
Identity settings affect the whole running application. Changing them revokes current interactions, codes and access tokens. Restore the normal scenario before another team tries to sign in. Restarting the application resets identity settings to their defaults.
Team worlds and API keys are separate from these identity sessions. A successful staff sign-in does not create or unlock a team world.
Evaluate the result
Ask for the initial state, the action sequence, and the final records. Distinguish accepted requests from completed work. Keep model APIs optional so teams can run the default deterministic agents without a paid model account.