Student interventions.

An intervention in YESS is one flat record — a single support plan for one student. It names the student, an optional subject, the type of support, a title and description, who assigned it, a due date, and a status that moves from assigned to done. It is not a multi-step case file with a dozen logged actions and a review board; it is the plan itself, held cleanly so nothing a school decides to do for a struggling student is forgotten.

Two screens work with these records. The interventions register at /dashboard/interventions is the full list — every plan, filterable by status, with the stats on top. The at-risk desk at /dashboard/at-risk-students is where a student surfaces as needing help and an intervention is assigned on the spot. This book walks both, and is candid throughout about what is automatic and what is a human's call.

When a student starts to slip, the plan that catches them — with an owner, a due date, and an honest read on whether it worked.

The at-risk desk at /dashboard/at-risk-students is where a plan usually begins. On the left is a roster of students flagged at risk, each with a risk level — low, medium, high, or critical — and a score, sorted worst-first. Selecting a student opens their intervention panel on the right: the plans already assigned to them, and a button to assign a new one. From here you can also jump to the student's conduct profile to see the fuller picture.

A Generate alerts button turns the flagged students into alerts staff can act on. Two honest points about this desk. First, it produces alerts, not interventions — nothing here auto-creates an intervention; an alert is a prompt, and a human still decides to assign the plan. Second, an intervention is always created by a person. There is no automatic route that turns a risk score into a support plan; the risk model surfaces the student, and a teacher, tutor, or head decides what to do.

Whether from the at-risk desk or the register's New Intervention button, assigning a plan means choosing a type, naming it, and setting a due date. Assigning requires the manage interventions permission — enforced at the database, so a view-only user cannot create one. The six types are a fixed vocabulary, so the whole school talks about support in the same terms:

A plan carries a title and description, an optional subject (or "all subjects" when the concern is general), an assigned date (today by default), and a due date. It is stamped with who assigned it and opens at status assigned. The action is written to the audit log, and the plan appears in the register and on the student's panel.

The register at /dashboard/interventions is where a plan is tracked to done. It opens with six stats — total, assigned, in progress, completed, completion rate, and average effectiveness — a status filter, and a table of every plan showing the student, the title, the type, the subject, the assigned and due dates, the status, and any effectiveness rating. A per-row status control moves a plan along its lifecycle:

• Assigned — the plan is set but not yet under way.
• In progress — the support is happening.
• Completed — the plan is done, closed with an effectiveness rating (1 to 5) and optional notes on whether it worked.
• Cancelled — the plan was called off.

That effectiveness rating is the point of the loop — it is what turns a pile of good intentions into a school that learns which support actually helps. The platform insists on it: a plan cannot be marked completed without a rating, enforced by a database rule that also stamps the completion date for you.

The assign-and-track core works, and the intent to measure effectiveness is baked in. But the follow-up loop is thin, the risk link is manual, and one close-out field is missing from the UI. The straight list:

Interventions sit downstream of the signals that flag a student — grades, attendance, conduct — and upstream of the wellbeing and family conversations a plan can trigger.