Analytics & intelligence.

Analytics in YESS is not one screen — it is a stack tuned to who is asking. The analyst (a data-minded admin) wants to slice everything by campus, year, term, and class; they live in the workbench. The leader (the principal or proprietor) wants a verdict and a short list of things that need them; they read the briefing. The board wants a pack of chapters they can trust; they open the owner reports.

A single truth runs under all three: most analytics are computed live. The owner briefing, the financial chapter, the academic pass-rate story — they query the operational tables (invoices, student_scores, student_attendance, the payroll runs) at the moment you open the page, so the number a leader sees on Friday afternoon is the same number the bursar worked with on Friday morning. Only a few heavier models are pre-computed on a schedule — early-warning risk scores and subject-pair correlations — and the handbook says clearly where those are.

The whole school, as numbers a leader can act on — live, in plain words, with the decision attached.

The proprietor opens /owner on her phone at 07:40. What loads is not a dashboard of charts — it is a briefing, written like a letter, top to bottom.

The masthead greets her by school and date. Below it, today's pulse — what is happening right now. Then the verdict: a plain-language health line and a single ring scored out of 100 with a letter band, so she knows in one glance whether the week starts green or red.

"Needs you" is the part she reads first on a busy day: the few things that need the owner personally — invoices past 90 days, contracts expiring, a settlement owed, margin under target, collection slipping. Each is a glyph and a deep link straight to the chapter that explains it. Then the numbers, in plain words — a rail of headline figures, each with a sparkline and two clauses: how it moved versus last period, and how it sits against her own target.

She taps the collection figure; it carries her to /owner/financials, where the same number opens into the full money story. Two minutes, one screen, and she knows exactly which conversation Monday needs.

The workbench at /dashboard/analytics is the analyst's home. A global filter bar across the top — campus, academic year, term, class — narrows everything below it at once, and ten tabs cover the school cluster by cluster:

Every tab renders from live hooks and supports export to CSV, PDF, or Excel. Nothing here is a stored snapshot waiting to go stale — change a score or record a payment and the relevant tab reflects it on the next load.

Where the workbench reports what happened, the intelligence hub at /dashboard/intelligence looks for patterns. It is deliberately heuristic — statistical signals a head of department can read, not a black-box AI verdict. Three artefacts:

Subject-pair correlations — a Pearson correlation between every pair of subjects within a term (computed in the subject_pair_correlations materialized view), surfacing where a struggle in one subject tends to travel with another, and how many students are jointly at risk in both. Teacher impact — each class average set against the programme baseline (the teacher_impact_metrics view), expressed as a delta and a percentile, so "effective" means measured against peers teaching the same level. Cognitive load — a check of how much heavy work lands on one section on one date, so a coordinator can spot the day three big assignments collide.

One stored model deserves its own chapter because it drives intervention, not just reporting. The student_overall_risk_scores table holds, for each student in a term, a single risk score and a level — low, medium, high, or critical — built from four weighted factors: attendance, grades, behaviour, and lateness. The weights are fixed and visible: grades carry the most, attendance next, then behaviour and lateness.

A database function (compute_student_overall_risk, and its bulk sibling) reads the operational tables and writes the score; the permissions that gate it — at_risk.view, at_risk.evaluate, at_risk.manage — decide who can run an evaluation and who can acknowledge a flag. The acknowledgement is recorded on the row with a note, so a high-risk student is not just detected but owned: a name, a time, and a plan attached.

The briefing at /owner reads against the owner's own targets, which is what turns a number into a judgement. Those targets — a revenue goal, a margin floor, a collection-rate floor, a payroll-to-fees ceiling, an enrolment goal — are set once and stored under the owner_targets key in the school settings, then read on every briefing.

So the collection figure does not just say "74%" — it says 74% against a 90% target, down from last period, and it routes that verdict into the "needs you" list when it breaches. The whole briefing is the same idea repeated: every headline number carries its movement and its distance from the line the owner drew. First paint loads on the financial and enrolment figures; the heavier HR and academic numbers fill in behind them, so the page is useful in under a second.

Each headline in the briefing opens into a full chapter. Together they are the board pack — but as live pages, not a PDF that was true last Tuesday. The owner reports index at /owner/reports lists them and links straight through:

The report center at /dashboard/reports has two tabs: a set of pre-built operational reports, and a custom builder. The builder also lives as a tab inside the workbench. A custom report is a saved definition — you name it, pick a data source, toggle the fields you want, set grouping, sorting, and a chart type, and save. That record lands in the saved_reports table and re-runs live whenever you open it.

On a saved report you can attach a schedule: a row in scheduled_reports with a frequency of weekly, monthly, or term-end, a day-of-week or day-of-month, a recipient list, and an enabled flag. The definition and the schedule both persist today. The delivery worker that actually mails a scheduled report on its next_run_at is the part still being rolled out — so treat the schedule as set-and-stored, with delivery arriving in a near release.

The one piece of analytics that comes to the owner rather than waiting to be opened is the digest, configured from a card on the briefing itself. The owner picks the sections to include — what needs a decision, the health verdict, today's pulse, the key numbers, the year-over-year — chooses a frequency (daily or weekly) and a time, and sets a recipient email (their login by default). Every change auto-saves under the owner_digest key in school settings, and a live preview renders the exact email in place.

"Send me one now" delivers the digest to the owner's inbox immediately via the platform email provider. The scheduled path runs as an hourly job that reads the saved preferences, builds the same HTML, and hands it to the notification pipeline as a newsletter.

The analytics surfaces, the briefing, the chapters, the risk model, and the digest are live. The honest gaps below are the parts still being finished, listed here so you can plan around them.

Analytics is the downstream reader of almost every module — it computes on the data the rest of the platform produces.