Glossary

The vocabulary that recurs across the product and these docs, defined in one place. Where a term is explained in more depth elsewhere, the definition links out to it, so this page can stay short while still pointing you to the full story.

Cohort

One run of the first six weeks for one group of students, usually an intake. Each cohort has its own content, its own roster, and its own insights. Staff switch between cohorts; data never bleeds across them. The cohort is the unit almost everything else hangs off. Content is authored for a cohort, the pulse is read per cohort, and a staff member's view is always of one cohort at a time.

Week

A numbered step in the six-week arc. Content (events, briefings, to-dos, the check-in) is authored per week, and a cohort's weeks are marked as complete, current, or coming up. The arc is deliberate: each week's content is meant to match what tends to be hard at that point in the first six weeks.

Check-in

The weekly wellbeing question a student answers. A single response per week, rolled up into a cohort-level signal that staff read by default. Individual answers are also visible to the support staff responsible for a cohort, so they can follow up. And that access is audit-logged. Who sees my check-ins walks through exactly where the line sits.

Signal / Pulse

The aggregated read on how a cohort is travelling, derived from check-ins. Pulse is the view staff see: a distribution across the cohort, not a list of individuals. It is built to answer "how is this group doing?" without ever answering "how is this one person doing?". See pulse for how staff read it.

Help request

A message a student raises through the help flow. Carries a priority (normal, urgent, or crisis) and routes to staff in the inbox, where it is triaged and answered. The priority is what decides how loudly, and how fast, it reaches staff.

Crisis

The danger threshold for a help request: the message tripped the crisis signal list (self-harm, suicide, or threats to others). Detected on the client and again on the server, and the only level that pages staff in real time. The full path, from typing to staff response, is in respond to a help request.

Actor

An identity within an institution: a student or a staff record. A signed-in person (auth_user_id) maps to exactly one actor per institution, which is how the same human can be a student at one institution without that identity leaking anywhere else. See the two apps.

Institution / tenant

One customer of First Six. Every row of data is scoped to an institution, and that scoping is the tenant boundary: the line that separates one customer's data from another's. It is enforced by RLS, below.

RLS (row-level security)

The database mechanism that enforces the tenant boundary. Policies attached to each table decide which rows a given caller can see, so isolation lives in the database rather than in application code. The practical upshot: a bug in the app cannot quietly read across tenants, because the rule sits a layer below the app. See security posture.

Audit log

The immutable record of staff writes and sensitive reads. It is what makes activity reviewable after the fact, and it is the basis of an institution's evidence pack. See the audit log.

Audience tags

The campus, program, and role labels used both to target content at the right students and to scope which content a staff member is allowed to author. The same tags do double duty: they decide who sees a piece of content and who is allowed to write it.

MIN_N

The small-cell suppression floor (five). A breakdown stays hidden until at least five students sit behind it, so no individual can be identified from an aggregate. It is the numeric expression of the same rule as the check-in privacy line: aggregates may be shown, individuals may not.