Product concepts

Functional model

What makes up a role-play

A usable role-play combines four functional areas:

1. Learning design: name, scenario, objectives, challenges, tips, skills, competency, interaction context, and simulated-customer profile.
2. Session rules: planned duration, strict or flexible mode, warning threshold, and allowed overtime.
3. Runtime connection: an active SCAI agent with its voice destination and environment.
4. Assessment: evaluation criteria that define the indicators, scoring rules, evidence expectations, and weighting.

Localized briefing and help content are stored by locale. Catalog lookup requires both an active role-play and an active associated SCAI agent. Missing content has more specific effects: unusable briefing content prevents the briefing from rendering, missing help leaves no contextual help, and invalid session JSON makes the role-play request fail.

Attempt lifecycle

The timer and analytics session begin when the voice call becomes active, not while credentials or microphone permission are being requested. A cancelled attempt is not evaluated. Its temporary transcript can remain in browser sessionStorage until practice is opened again or the browser session ends; opening a new practice clears it and creates a fresh analytics session when analytics is enabled.

Timing modes

• Strict: SCL warns before the configured deadline and locks the practice at the planned duration.
• Flexible: SCL lets the conversation continue beyond the planned duration and stops it at the overtime limit. The browser uses a five-minute fallback when no overtime value is supplied.

Timing controls the learner experience. The evaluation criteria may independently score conversation duration by using the elapsed seconds supplied with the transcript.

Transcript and speaker model

SCL builds the transcript from allow-listed SCAI metadata messages. The learner-facing interface labels the two speakers as the person and the bot. In the evaluation API contract, the mapping is less intuitive:

• Customer is the human learner and is the participant being evaluated.
• Agent is the AI simulated customer and must not be credited as learner behaviour.

The transcript is temporary browser-session data. A new attempt clears it, and the current backend does not store durable transcript or evaluation history.

Evaluation model

The Evaluation API programmatically validates only:

• An integer overall score from 1 to 5.
• A non-empty description.
• At least one performance indicator.

The active AI Factory prompt additionally instructs the model to return 1–5 integer indicator scores, preserve criterion order, use achieved for 4–5 and improvable for 1–3, write in the requested locale, use transcript evidence, provide at least two strengths and two improvements, and include at least one action item. Those prompt rules are not all revalidated by backend code. Summary items and recommended courses exist in the response contract but may be empty; the current core prompt does not request them.

Completion and analytics are separate outcomes

A successful evaluation can trigger two background effects:

• Learning-platform completion is queued only when the role-play has a target platform and the learner token provides both user and course-module identifiers.
• Analytics is emitted only when a tenant and analytics runtime are configured. Frontend events describe starts and end reasons; backend events describe evaluation success or failure.

Completion failures are isolated from a valid evaluation result, and analytics is implemented as best effort. Consequently, feedback availability, host-platform completion, and analytics delivery should be treated as related but distinct outcomes.

Language and preferences

The interface supports English, Spanish, and French. Language and theme preferences persist in the browser. Briefing content uses the best available locale match; the evaluation language is captured when feedback begins and changing the interface language afterwards does not evaluate the same attempt again.