Skip to content

Concepts

Retention and getting a copy

What a school's records are kept as, what is not an automated feature in this release, and what a deployment can hand over.

A school's records belong to the school. This page says what that means for keeping them, and it is deliberately careful about what it does not promise, because retention is the topic where a documentation page is most likely to invent a policy the product does not have.

What is kept

The year, its terms, the classes and subjects, the placements, the marks, the corrections with their reasons and approvals, and the published results as snapshots. Nothing in that record is pruned as a term ends: the point of a dated correction and an immutable snapshot is that the history stays readable.

What is not an automated feature

This release does not ship an export button, a scheduled backup you can download, or a migration path to another system. A page claiming otherwise would be the most expensive kind of documentation error, so it says so plainly.

What a school can rely on instead:

  • every screen reads from the school's own record, and nothing is held only in a browser;
  • a school's deployment is a copy of that school's database, so the school's operator can take a copy the way any database is copied;
  • the school owns the data, and leaving does not require permission from the product.

What is a deployment's decision

How long a deleted school's copy is kept, and where backups live, are properties of a deployment rather than of the product. A school asking for a retention period should ask the organisation that operates its deployment, and how one school stays its own describes the boundary that makes the answer a short one.