Current limitations and decisions

This page describes the product evidenced by the current frontend and backend repositories. Planned services and governance processes are not listed as delivered capabilities.

Learner experience

SCL depends on a host platform for normal launch and identity; manual token entry is a technical fallback.
The interface supports English, Spanish, and French. Role-play, voice, and feedback language coverage depends on external content and services.
There is no text-only alternative to microphone practice.
The live transcript is derived from SCAI metadata and may not be verbatim.
An interrupted attempt cannot be resumed.
Feedback export uses browser printing rather than a generated document.
The role-play contract includes a description, but the current briefing page does not render it.
demoMode returns mock feedback and is not an authorization or production assessment mechanism.

Content and administration

There is no authoring or administration interface.
Active catalog records and content files are managed through backend storage/deployment processes.
The implemented catalog list endpoint is bearer-protected but does not yet enforce the planned role-play-administrator policy.
Built-in draft, approval, version history, staged publication, audit, and rollback workflows do not exist.
The Catalog API is a placeholder, not a current service.

Evaluation and learning records

The current backend validates a 1–5 score, description, and non-empty performance indicators, but cross-role-play score comparability is not established.
Summary items and recommended courses exist in the response contract but are not required by the active core evaluation output schema.
No durable learner transcript, evaluation history, trend view, or reporting dashboard is implemented.
The Sessions API described in the backend repository is a placeholder.
The feedback UI cannot confirm whether asynchronous learning-platform completion was eventually delivered.
Evaluation requests have no documented idempotency key; automatic client retry could create duplicate downstream effects.

Analytics and operations

Analytics is best effort and disabled for an attempt if its technical token or server session cannot be created.
Analytics delivery does not provide durable evaluation history.
Browser-side telemetry failures are logged but not shown to the learner.
Exact supported browsers, devices, proxy/firewall conditions, SCAI SLA, and WebRTC/TURN topology are not defined in the inspected repositories.

Security and privacy

The first accepted iframe token message establishes the parent origin; there is no client-side allow-list before that message.
Evaluation API local JWT validation is intentionally non-authoritative and depends on the external edge.
Browser-visible APIM keys are not secrets.
The unload beacon carries the learner bearer token in its JSON body for technical-token exchange.
Authoritative audio/transcript consent, retention, deletion, residency, AI-processing, and learner-access policies are not defined in the repositories.
No completed formal accessibility, penetration, AI fairness, or production end-to-end audit is evidenced.

Product decisions still required

Which use cases, learner populations, languages, browsers, and networks are officially supported?
Which roles may view results, operate the catalog, approve criteria, or access analytics?
How should scores be interpreted and compared across attempts or role-plays?
Should transcripts and evaluations become durable learner records, and under which retention policy?
How should the host receive reliable completion status and prevent duplicate evaluation/completion?
What is the approved embedding-origin, JWT-validation, and tenant-isolation model?
What service levels, support ownership, monitoring, and incident process apply to each dependency?

Until owners decide otherwise, this documentation uses Syntphony Conversational Learning, learner, simulated customer, and role-play as the public terminology.