Live & virtual classes.

The module's tagline promises "YESS Live / Zoom / Teams," and it is important to be straight about what that means in the shipped product. The real, production live provider is YESS Live — a self-hosted LiveKit backend that YESS drives directly: it issues the room tokens, streams the video, runs the whiteboard and the polls, and records the session. That is the classroom this handbook documents, because that is the one that is built.

Zoom and Microsoft Teams exist today only as a choice in a dropdown and a place in the schema to store an external meeting link — there is no Zoom or Teams sign-in, no meeting creation, no launch flow behind them yet. Pick one and YESS records your choice but cannot open the meeting. They are on the roadmap at the end of this book. Everywhere else, "virtual class" means YESS Live.

Under the hood the whole feature is a family of tables prefixed yess_live_ — sessions, viewers, chat, engagement, poll results, recordings — plus a per-school settings row and a registry of LiveKit endpoints. You never touch those names; the teacher sees "classes," the student sees "join," and YESS does the plumbing.

A live class is a physical class that happens to be online — same roster, same attendance, same logbook.

Follow one lesson end to end and the rest is detail.

08:50. A teacher opens /dashboard/virtual-classes, clicks Schedule class, and fills the dialog: title "Photosynthesis," class JSS-2 Blue, subject Biology, platform YESS Live, chat and reactions on, record off. A session row is written in status scheduled.

09:00. The teacher clicks Go live. The session flips to live, and the page swaps in place into the classroom — no new tab. The teacher's camera and microphone publish; a tldraw whiteboard fills the centre of the room.

09:01. The students of JSS-2 Blue see the class under "Live now" at /portal/live-classes and tap Join. Each join writes a viewer row that starts counting watch time. Their cameras and mics are off unless the school allows them; the board is read-only for them; a notebook panel sits beside the video so they can take notes that save straight into their subject notebook.

09:20. The teacher drops a diagram onto the board, annotates it, runs a two-option poll ("Which reaction needs light?"), and clears three raised hands from the queue.

09:40. The teacher clicks End session. The session flips to ended — and a database trigger does the quiet, important work: every student who watched at least half the class is marked present for that period, and a logbook entry is written for the lesson, tagged as a live-classroom delivery. The teacher wrote nothing down.

Every school gets a live-classroom settings row automatically, and an administrator tunes it at /dashboard/settings/live-classroom. There are thirteen knobs, and they decide what a live class is allowed to be at your school.

The teacher console is /dashboard/virtual-classes (re-exported at /teacher/virtual-classes for teacher chrome). It lists a teacher's upcoming, live, and past sessions, and its Schedule dialog writes the session row.

The one field that matters most is the class / section— and it is required. It is not decoration: the section is what scopes who may join the room, and it is the key the end-of-class automation uses to find the right timetable period and the right roster. A subject is optional but recommended (it links the session to a course and a logbook line). The platform picker offers YESS Live, Zoom, Teams, or "recorded"; the toggles set whether chat, reactions, questions, and recording are allowed for this session.

A session moves through four statuses — scheduled, live, ended, cancelled. Going live and ending are teacher actions backed by database functions that verify the caller is the session's teacher before they change anything.

When a teacher goes live, the page mounts the classroom in place. The engine is LiveKit: a real-time room the teacher and students publish audio and video into, with every interactive signal — chat, reactions, poll votes, hand-raises, board updates, mode changes — travelling over the room's data channel rather than the database. That is what keeps it feeling instant.

What the teacher can do

The teacher switches between three modes — face (camera front and centre), board (a collaborative tldraw whiteboard), and screen (screen share). The whiteboard is presenter-authoritative: the teacher draws, and the board state is snapshotted to the students over the data channel, so everyone sees the same page (students watch, they don't draw). The teacher can drop an image or a PDF onto the board and annotate it live — PDFs are rasterised page by page and placed as image shapes, so a worksheet becomes something to mark up in front of the class. Chat, reactions, polls, a hand-raise queue, and an award-a-star gesture round out the controls.

What the student sees

A student joins from /portal/live-classes; joining writes a viewer row and mints a student-scoped room token that only permits the devices the school's settings allow. The board is read-only. Beside the video sits a notebook panel that autosaves the student's notes into the same per-subject notebook documented in the Study handbook, linked to this session — so in-class notes aren't a throwaway scratchpad, they land in the notebook the student revises from later.

Ending a class is where YESS earns its keep. The moment a session flips to ended, a database trigger runs the fan-out — once, guarded so it can never run twice for the same session.

Attendance. YESS matches the session's section to a timetable period, then marks every viewer who watched at least half the class (and no less than a minute) as present for that period, writing into the same attendance store the daily register uses. A student who dropped after two minutes is not marked present — watch time is real.

Logbook. YESS writes a logbook entry for the lesson, tagged with a live-classroom teaching method, so the syllabus-coverage record shows the lesson was actually delivered — the same logbook the coverage reports read from.

Both halves respect the school's auto-log toggles from chapter two. A school that keeps a separate register can turn attendance off; a school that logs coverage elsewhere can turn the logbook off. On the defaults, both happen and the teacher does nothing.

If the school allows recording and the teacher turns it on for a session, the record button dials LiveKit's Egress service, which composites the room and uploads the file to the school's cloud storage. A recording row tracks the capture through three states — processing, then ready (a webhook confirms the file, its size, and its duration), or failed. Every capture is checked against the school's storage quota before it starts.

Finished recordings play back at the session report, /dashboard/virtual-classes/[sessionId]/report, where YESS mints a short-lived signed URL per recording and streams it inline. Past-session cards on the console deep-link straight here.

A genuinely built LiveKit classroom has scaffolding around it for features not yet finished. Here is the honest state, so you know what to rely on and what to wait for.

A live class touches the roster, the register, the logbook, and the notebook. Here is what plugs into what.