The current Simulation Configuration form lives inside a SCORM. Admins fill in persona, scenario, and instruction fields manually — many already use external AI tools and copy-paste the results. The goal of this redesign is to streamline configuration, introduce AI-assisted drafting, support content references, and bridge the config experience with Exercise creation.
The SCORM is built on top of two vendor APIs (Tavus and Anam) which are abstracted away from the admin — the config fields map through a backend template system to the relevant API payloads.
Structural fields (avatar, voice, language, patience, interruptibility, toggles) go in Settings. The six text fields that define the scenario (persona, scenario, opening line, instructions, objections, background) go in Content. AI generation targets the Content zone only.
Admins select an avatar by name. Provider (Tavus or Anam) is inferred from the avatar's definition and set silently. Provider-specific IDs move into the avatar catalog, not the config form. Voice picker filters to voices compatible with the selected avatar's provider.
Matches the current UI pattern. A compact trigger shows the selected avatar thumbnail and name; clicking opens a searchable photo grid. Scales to any number of avatars.
These define conversation dynamic (the kind of person the avatar is behaving as), not difficulty. They are not collapsed into a single difficulty dial. Future: AI generation could infer appropriate values from the scenario description.
A "Starting point" chip row sits above the prompt text box. Today it holds scenario-type shortcuts (Cold call, Discovery, Objection handling, Demo) that pre-fill the prompt. A Templates chip opens a curated template picker that pre-fills all six content fields directly. Selecting a template exposes "Use as-is" alongside "Regenerate." This is the extensibility pattern — new entry points slot into the chip row without changing the panel's shape.
When admins reference existing Allego content (videos with transcripts, documents), intent is carried by the prompt text and inferred by the AI from content names and types. Per-item role tags (e.g. "Use for: Objections / Persona / Scenario context") are the right future pattern but only worth adding if evidence shows the AI is misusing content.
The SCORM is not replaced — it handles the learner's conversation experience, Tavus/Anam SDK, and score reporting. But it becomes an implementation detail. Customer admins configure the scenario as part of Exercise creation; the system auto-creates and manages the SCORM behind the scenes.
A Scenario object (config + runtime) replaces the SCORM as the portable artifact CS and SEs use to build and distribute pre-built setups to client orgs. Scenarios published internally by Allego become the Templates chip options for customer admins. This replaces the current "copy SCORM to client org" workflow.
Admins test from within the config form (in Exercise Properties or the Scenario editor) via a "Test this scenario" button. Test runs against current in-memory config — no save required. A transcript is surfaced after the test session to support iteration. This replaces the workflow of opening the SCORM content item directly.
The raw JSON editing escape hatch (currently via direct SCORM key manipulation) moves to a collapsible Advanced panel within the config form, showing the actual Tavus/Anam API request payload. Available to internal roles (PM, SE). The form and JSON panel stay in sync. This is more direct than editing SCORM keys and less brittle.
CS/SE build scenarios independently of Exercises today. A Scenario library UI may be needed for them to create, test, and publish scenarios before wiring them to customer orgs. Scope and priority TBD.
Customer orgs with existing role play SCORMs need a migration or compatibility path. Options: auto-migrate config into the new Scenario model; leave existing as-is and only new ones use the new flow. TBD.
Generation needs an endpoint that takes a prompt + content IDs, fetches extracted text, and returns structured JSON matching the six field names. Whether this is a net-new service or an extension of an existing API is unresolved.
AI generation could set these values based on the scenario description. Deferred to keep v1 scope focused on the six content text fields.
The content picker infrastructure built for scenario generation is the same foundation needed to draft a Scorecard Template. Worth noting for future planning; out of scope for this feature.
Role tags on each referenced content item (e.g. "Use for: Objections") add specificity when multiple documents serve different purposes. Deferred until there is evidence the AI is misusing content without them.
1
Decide phase: Write a feature document capturing the decisions above as formal product choices, including the Scenario object model and Exercise integration approach.
2
Prototype v3: Illustrate the Exercise Properties integration — how the scenario config section sits within the Exercise creation flow.
3
Scenario object design: Define the Scenario data model, library UI for CS/SE, and the cross-org distribution mechanism before specifying stories.
4
Specify: Write Jira stories for the config form changes (Settings/Content split, AI generation panel, avatar picker) as a separable first increment that delivers value before the Exercise integration lands.