The questions a school asks once it takes this seriously: what exactly do we get, where does it live, how does it change, and what do you do with our data. Published rather than answered one email at a time.
The instruments are the collection format. They are not the deliverable. Each phase produces named artefacts with a defined shape.
| Artefact | Phase | Form | Typical length |
|---|---|---|---|
| Baseline report | 1 | Document + PDF | 10–15 pp |
| Risk register | 1 | Spreadsheet (CSV) | 20–40 rows |
| Opportunity register | 1 | Spreadsheet (CSV) | 8–15 rows |
| Values / fear map | 1 | Document | 4–6 pp |
| Policy Pack v1.0 | 2 | Document set | 5 documents |
| Training completions log | 3 | Spreadsheet | by name |
| Activity map + facilitator guides | 3 | Document set | 4 age bands |
| Pilot report | 4 | Document | 6–10 pp |
| Operating cadence pack | 5 | Document + calendar | 4–6 pp |
| Governance site | 1–5 | Static site bundle, bilingual | 12–14 pages |
Every artefact above also lands in a working, bilingual site — home, statement of work, policy, baseline, risk register, governance model, operating cadence, communications templates, downloads. It is built through the engagement rather than at the end, so your school watches its governance take shape instead of receiving a folder in Week 12. Governance that nobody can find does not survive contact with the next term; a URL you can send someone does.
It runs on your own server, inside your network, in a sandbox account you provide. We build and maintain it there. Nothing is hosted by us, and your material never leaves your infrastructure — we are never the custodian of your risk register, and there is no supplier-held copy of it anywhere.
Access control is whatever you already use. No new vendor, no new account, and no authentication layer of ours that can fail on a Tuesday and lock you out of your own governance.
Exit is one action, and it is total. You close the account. Everything keeps running, on your server, because it was always yours. No migration, no export, no negotiation, no invoice. That is the part suppliers usually settle in their own favour, and it costs nothing to arrange at the start.
Nothing is delivered in a format that needs our tooling to read or maintain. Documents come as editable source and PDF; registers as CSV, so they open in whatever you already use. You must be able to keep every artefact alive after we leave, without us. Ask and we will show you the empty templates before you commit.
This is a governance decision, not an IT one. The defaults below are ours; you can override any line, and the decision gets recorded.
| Artefact | Default | Why |
|---|---|---|
| Baseline report | Restricted | An honest account of institutional weakness |
| Risk register | Restricted | A public register is a published map of where you are vulnerable |
| Opportunity register | Internal — all staff | Sharing strengths is the point of it |
| Values / fear map | Internal, aggregated only | Trust depends on people seeing what was heard |
| AI policy | Public | A policy nobody can read does not protect anybody |
| Parent communications | Public | Same |
| Incident register | Restricted | Contains safeguarding material |
| Training log | Internal — leadership, HR | Names individuals |
Three rules hold regardless of platform. You host and own everything — your site, your intranet, your tenancy; we do not run a portal you depend on. Restricted means a named list, not an unlisted URL, which is public with extra steps. And publish the policy where a parent can actually find it — buried in a staff intranet will not help in a complaint.
Not everything has the same lifecycle, and treating them alike is the usual mistake. Some artefacts are frozen evidence; some are living controls.
| Artefact | Lifecycle | Who may change it |
|---|---|---|
| Baseline report | Frozen, dated | Nobody, after acceptance |
| Risk register | Living, reviewed monthly | Named owners |
| AI policy | Versioned v1.0 → v1.x | Policy owner, via the governance model |
| Incident register | Living, append-only | DSL and named leads |
Why the baseline is frozen. A baseline that keeps being edited is not a baseline. Its value is that it records what was true on a date, so improvement can be evidenced later. If it turns out to be wrong, we issue a dated correction alongside it rather than editing the original — that is what makes it usable in front of a board or an insurer.
Why the register is living. A register nobody has touched in three months is a document, not a control. Entries are closed with a reason and a date. They are not deleted.
Red-flag confirmation happens before the draft, never after. You should never learn a finding about your own school by reading it in a finished document.
We would rather absorb your existing work than make you redo it. A school that has already run a self-assessment or assembled evidence is further ahead, and treating that as worthless is both wasteful and insulting. Send it before scoring and we will do one of three things, and tell you which: map it onto the dimension framework so you never answer the same question twice; merge it as the primary source where your evidence is stronger than what we would have gathered; or keep it separate and cross-reference, because not everything should be merged.
What we will not do is silently reformat your work into our template and hand it back as ours. If your file becomes an input, the report says so and names it.
One caution, said early rather than late. A self-assessment completed by the people responsible for what is being assessed carries a known optimism bias — it is the same reason we score leadership and staff separately and compare them. Your work is genuinely useful. It will be weighted as self-reported evidence rather than verified evidence, and the report will be explicit about which is which.
The most common failure in this work is not a bad policy. It is a good one that nobody updated. Governance decays quietly: the policy keeps its version number, the register stops being opened, the site still says what was true in March.
The optional maintained tier exists for exactly that. Four scheduled releases a year — calendar-driven, not request-driven, because a site that only changes when somebody asks will go quiet, and quiet is how this dies. Plus a release whenever it actually matters: your policy changes version, your registers move, AI tool signatures decay, a regulatory change touches a published clause, or you finish training, a pilot or a re-baseline. Twelve change requests a year on top of that.
Every release is signed by a named person before it goes live. Changes are prepared as a reviewable diff and checked automatically — nothing restricted on a public path, every link resolving, the scale right, the suppression and validation statements present, both languages moved together — and then read and approved by a human. Approval triggers the deploy, so nothing waits on a ticket at your end.
We use AI assistance to prepare releases. We do not let it publish. That is the same standard we ask of you, and it would be indefensible to apply it to your school and not to your own website. The approval record — who signed, what changed, when — is retained and handed to you. It is itself a governance artefact, and it is the kind of evidence this programme exists to teach you to keep.
We ask schools whether their data retention periods are defined and enforced. It would be indefensible not to answer the same question ourselves.
Not legal advice. These instruments have not been externally validated or psychometrically tested. They support a structured management conversation and a defensible register; they are not a compliance certification. Data-protection questions belong with your DPO or counsel.
Questions this page does not answer: ask us — and we will add the answer here.