Skip to Content
Role-play designPublication and governance

Publication and governance

The current backend exposes active role-plays for use but does not provide create, edit, approve, publish, or retire endpoints. New catalog records and their content files are maintained through the manual storage process described in Create and provision a role-play. The deployment seed process initializes an environment only when its tables are empty; it is not the normal workflow for adding a later Role Play. A dedicated catalog service and authoring workflow are planned, not implemented.

Current activation model

A catalog lookup returns a role-play only when:

  • Its catalog record exists and is marked active.
  • Its referenced SCAI agent exists and is marked active.

An inactive or unknown role-play, or one linked to an inactive or missing SCAI agent, is returned as unavailable.

Content files are loaded separately and do not all control catalog availability:

  • Invalid session JSON fails the role-play request because the timing contract cannot be built.
  • Missing or invalid briefing JSON is returned as empty content; the current briefing page then remains in its loading state.
  • Missing or invalid help JSON produces no contextual-help sections.
  • Missing evaluation criteria do not block the initial briefing, but leave the later evaluation without its role-play-specific assessment instructions.

Voice, credentials, and AI Factory availability are exercised later in the journey. A successful catalog read therefore does not prove that practice and evaluation will succeed.

Release checklist

Learning experience

  • Target learners, objective, and real-world use case are approved.
  • Scenario, objectives, challenges, tips, skills, competency, and profile tell one coherent story.
  • Strict/flexible timing, warning, and overtime rules match the intended behaviour.
  • Contextual help supports the learner without revealing the answer.
  • Every published locale has been reviewed by a competent language owner.

Conversation and evaluation

  • The design-team handoff includes the simulated-customer specification, localized roleplayinfo, and evaluation criteria; optional help is explicitly included or omitted.
  • The SCAI team created the agent specifically for Role Play use and disabled the default customer-service macro-prompt.
  • The SCAI character is active and behaves consistently with the briefing.
  • The browser voice channel, DNIS, approved ElevenLabs voice, and all supported language settings are verified.
  • Every important indicator has a realistic opportunity to occur in the conversation.
  • Evaluation criteria define evidence, 1–5 scoring, weights, status expectations, and rounding.
  • Evaluation weights total 100% and any elapsed-time target is consistent with SessionInfo.
  • Speaker attribution has been verified: Customer is the learner and Agent is the AI character.
  • Strong, average, weak, incomplete, and timing-boundary transcripts have been tested.
  • Feedback language, evidence, indicators, and action plan have been reviewed by a learning owner.

Integration and governance

  • The approved host can launch the role-play and refresh learner tokens.
  • Microphone, WebSocket, WebRTC, and evaluation work end to end in the target environment.
  • Target-platform completion is tested when the role-play uses it.
  • Analytics start, end, unload, evaluated, and failed paths are tested when analytics is enabled.
  • Privacy, consent, retention, and support responsibilities are documented.
  • Content owner, SCAI owner, evaluation owner, approver, and support contact are recorded.

Release record

Role-play ID:
Release version:
Active from:
Learning owner and approver:
SCAI agent reference/version:
Briefing and help content versions:
Evaluation criteria version:
Supported locales:
Session rules:
Target platform, if any:
Analytics tenant, if any:
Test evidence:
Known limitations:
Rollback owner and procedure:

Change and rollback

Treat briefing content, character behaviour, and evaluation criteria as one functional release even when they live in separate systems. A change to one can invalidate the others.

Before activation, retain the previous approved records and content references. If quality or safety regresses, deactivate the role-play or restore the previous coherent set. The current product does not provide built-in version history, approvals, staged publication, or automatic rollback, so those controls must be supplied by the operating process.

Create and provision a role-playArchitecture