Reliability: not a single class session gets lost¶

ControlAI processes hundreds of class sessions a day — thousands a week — automatically. And one firm promise holds here: no class session disappears unnoticed. If something goes wrong — a camera goes offline, audio fails to record, processing fails — it is always visible and flagged, never silently lost. A class session that quietly vanishes means a missing report and eroded trust; that's why the system is built to surface problems honestly rather than pretend everything is fine.

Every class session is always at a clear stage¶

Every class session in the system is always at one of a defined set of stages, so at any moment you know exactly where it stands:

Scheduled → Recorded → Processing → Ready
                       │
                       ├─→ Not held    (no one showed up)
                       └─→ Failed      (something went wrong)

"Ready," "Not held," and "Failed" are final states. A session can never be left hanging without a status: it either makes it all the way to a report, or is explicitly marked as not held or as having a problem.

What can go wrong — and what the system does¶

Camera unreachable¶

If the system fails to pull a recording (camera powered off, no network, misconfiguration), it detects this and opens a "camera offline" task flagging exactly which classroom is affected. The session is not lost — it stays in the "Scheduled" stage waiting for a recording, while the university's responsible service sees that the equipment needs to be checked. If the recording still cannot be retrieved (for example, the archive on the video recorder has already been overwritten), the session is marked "Failed" with a reason — but it never sits in that state forever.

No audio or a poor microphone¶

If a camera's microphone is weak or not working, the system flags the classroom as "microphone needed." That's the signal to add an external microphone to the camera's audio input — before report quality actually suffers.

A separate, honest note on large lecture halls: monitoring whether the class was held, timing, and the instructor's talk share all work in any room, but transcript completeness in a large hall depends on acoustics — so that's confirmed by an audio audit at onboarding, and wherever the built-in microphone fails the test, an external microphone is added to the camera's audio input. Nothing extra is installed in the room itself — the cameras already hanging there are what's used.

Class session not held¶

If no one shows up or the room is empty, ControlAI marks the session "not held": it doesn't spend resources analyzing it, and such a session is not included in the billed volume. The system distinguishes a genuine "not held" (an empty room, confirmed on video) from "the microphone died but the class actually happened" — the latter counts as our defect and is likewise excluded from the billed volume.

Processing failure¶

If a step in the analysis fails, the system retries (several times, with pauses) — most transient failures fix themselves this way. If it still doesn't succeed after retries, the session is marked "failed" with a reason, and a task is opened for the team. The session stays visible and can be re-run — it never disappears.

Self-checks: retries and duplicate protection¶

Retries. Every processing step has automatic retries — if a failure is transient, the system recovers without human involvement.
No duplicates. Even with retries, the same class session is never processed twice and never counted twice in the billed volume. This guards against both double billing and confusion in reports.

Everything visible: the Operations section and coverage¶

The system's entire state is gathered right in the panel — the quality-control office (ichki ta'lim sifati nazorati bo'limi), the dean's office, and the team responsible for equipment see it immediately:

Operations section — a single list of every problem: camera offline, microphone needed, processing failure, consent pending, session not held — each with a clear action; equipment-related tasks (camera offline, microphone needed) go straight to the university's IT service.
Coverage summary — how many of the day's scheduled class sessions were recorded and processed on time, plus a list of "gaps" with a reason (for example, "08:30, room 214 — camera offline").
Connection health — when a recording was last successfully pulled, whether the building is reachable, and whether the video recorder's archive is being overwritten before its time.
The "Needs attention" feed on the dashboard surfaces what matters most.

Why this matters¶

For a university, ControlAI is only as valuable as it is trustworthy. If class sessions occasionally vanished without a trace, the rectorate could never be sure it had the full picture — and the entire analytics layer, from individual instructor statistics to department comparisons, would lose its value. That's why reliability here isn't a "nice-to-have" — it's the foundation: better to surface a problem openly than to lose a session silently.

Key takeaway: every class session is always at a clear stage and can never quietly disappear. The system catches failures, offline cameras, and sessions that weren't held, flags them with a reason, and surfaces them in the Operations section and the coverage summary; retries fix transient failures, and duplicate protection rules out double counting. Reliability is the foundation of trust in the analytics.

→ Next: 08. Inside the admin panel — a tour of the panel and a breakdown by role: who sees and can do what.