Skip to content
Open the app

Handover

What First Six has done before handing the platform over, and what each role on your side needs to do to get it ready for students.

When First Six hands the platform over to your institution, the boundary between our work and yours needs to be obvious — otherwise the launch stalls in the gap. This category sets the boundary in plain terms.

What First Six has already done before handover

Before you see the console for the first time, we've taken care of the ground floor so your team can focus on the institution-shaped work that only you can do. The pre-handover pack covers:

  • Identity protocol implementation. A standards-based OIDC sign-in flow is built, hardened (PKCE, nonce, state, issuer + audience checks), and ready to wire to your IdP. You connect it; we don't ask you to invent it.
  • Data residency. Your tenant lives in our Sydney (AWS ap-southeast-2) Supabase project from day one. Nothing crosses the border for primary storage.
  • The product itself. Every console feature — inbox, weekly briefings, events, library, writing assistant, guides, students, audiences, campus maps, insights, audit, settings — exists and is wired up. We don't build features against a customer commitment.
  • The safety net plumbing. The crisis pathway (server-side re-detection, parallel email/Slack/SMS fanout, audit) is shipped. You point it at your institution's actual on-call response.
  • The evidence pack. HECVAT-Lite (docs/HECVAT.md) plus a full internal self-audit, subprocessor list, breach-response runbook, data-residency note, and an immutable audit log of staff actions are all in place for your cyber team to review.
  • Operational guardrails. Row-Level Security on every app-owned table, a daily security-checks workflow (RLS regressions, anon-grant regressions, schema drift, anon-callable RPC drift), an append-only audit log, secrets rotation runbook, an incident-response plan, and a public uptime page at status.firstsix.com.au.

What you need to do, by role

Pick the doc that matches your role on the project. Each is a tracked checklist — tick items off and your progress survives reload. None of the four is huge; the long pole is the platform owner's content work, not anything technical.

If you are…Read
The day-to-day admin who will run First Six (typically a student-success, engagement, or wellbeing lead)Platform owner
Drafting and publishing the weekly briefings, library answers, and student-facing copyContent editor
On the institutional IT team (identity, network, integrations)IT and SSO
In cybersecurity, risk, or the data protection officeCybersecurity and privacy
The executive sponsor accountable for the rolloutLeadership and sponsor
One responsible person per doc

These checklists assume one named owner per role. Two people sharing a checklist tends to mean nobody owns it. If a role is shared on your side, pick one person to drive the list and one to back them up — both can use the same checkboxes, but only one closes them.

Edit this page on GitHub