How AI254 LIVE Works

Lecturers create sessions with a course code, subject, introduction and summary. Each session gets a six-character join code and a QR code, and moves through Scheduled → Live → Paused → Ended.

The lecturer's browser captures audio with the standard MediaRecorder API, applying echo cancellation and noise suppression where the device supports them. Chunks are forwarded server-side to the speech service; the web application does not keep audio files.

Provided by the AI254 speech recognition service through a single adapter module. The interface does not depend on any particular recognition engine, so it can be improved or replaced without rebuilding the application.

Provided by the AI254 translation pipeline. Each request includes the subject and the relevant glossary entries; the response is stored with the English statement and the processing time reported by the service.

A managed glossary of English terms, Kiswahili terms, definitions in both languages and usage notes. Each entry carries a review status (Draft, In review, Reviewed), so it is clear which terms have been approved.

Students join with their admission number, without creating an account. They can read recent statements, open terminology explanations, write notes kept on their own device and download them, ask questions by voice in English or Kiswahili, and leave or rejoin.

Sign-in, session creation for any STEM subject, start/pause/end, microphone capture on/off, permission for students to ask spoken questions, a live view of transcription and translation, connected-student count and incoming questions.

Administrators can see every session and its activity, manage lecturer accounts, maintain terminology, review demonstration requests and contact messages, and read system and error logs.

Processing time for recognition and translation is recorded for every statement and shown in the administration logs. These measurements are used to guide improvements. We do not publish latency or accuracy guarantees.

Staff passwords are stored as salted hashes, sign-in sessions use signed, HTTP-only cookies, and administration endpoints check the user's role. Students are identified only by admission number. IP addresses are stored only as salted hashes for spam and rate-limit checks. Credentials are kept in server environment variables and never sent to the browser.