Student Data & Privacy Policy
Mission Control — mc.practomime.com
Last updated: 28 August 2026
The short version
- Students never create accounts. No student names, emails, passwords, birthdates, or photos are required. A student opens their work with a random code their teacher gives them.
- We collect coursework, not people. What Mission Control stores about a student is their Latin classwork — points earned, missions completed, notes they write in the game — plus whatever label their teacher chose to identify them by.
- This is not a gradebook. Latinity Points are game quantities, not grades. The Service computes no grade and holds no grading scale; how points relate to a student's actual mark is each teacher's own decision, kept in their own gradebook.
- No advertising, no tracking, no analytics, no AI training. There are no third-party trackers, ad networks, or analytics scripts anywhere on this site. Student work is never sold, rented, used for marketing, or used to train machine-learning models.
- Teachers stay in control. A teacher can delete a single student, a whole class, or their entire account — along with all of its data — at any time, from inside the app.
- The school owns the records. Under FERPA we act as a school official holding student records on the school's behalf, and we do not use them for anything except running this service.
The sections below give the full detail. If anything here is unclear, write to lapis@practomime.com.
1. Who we are
Mission Control (the "Service") is operated by The Pericles Group Foundation, publisher of the Operation LAPIS and Operation FALX Latin curricula. In this policy, "we" and "us" mean The Pericles Group Foundation.
Privacy contact: lapis@practomime.com
2. What Mission Control is
Mission Control is the online character sheet and progress tracker for a roleplaying Latin curriculum. It replaces what used to be kept in a shared spreadsheet. Teachers ("Agents") set up a class ("cohort"), create a record for each student ("operative") and each team ("character"), and record the Latinity Points, Puncta Virtūtis, denariī, and equipment students earn as they work through the missions. Students open their own dossier or their team's character sheet to see where they stand, write their Memorātiō entries, spend points, and collect Carta Collēctiōnis grammar cards.
Everything it stores exists because a teacher put it there or a student did classwork in it.
What Latinity Points are — and are not
Mission Control is not a gradebook, and the numbers in it are not grades. Latinity Points, Puncta Virtūtis, and denariī are in-game quantities in a roleplaying curriculum: they drive a student's level, what their character can do, and what they can buy in the Forum. The Service does not compute a course grade, does not hold a grading scale, does not weight or average anything into a mark, and has no field for a letter grade or a percentage.
How — or whether — Latinity Points relate to a student's actual grade is entirely the individual teacher's decision, made in their own gradebook, under their own school's policies. Some Agents convert LP totals to a grade, some use them only as formative feedback, and some keep the two completely separate. Nothing in this Service assumes or requires any of those choices, and the numbers here should not be read as a record of academic standing.
We describe it this way because it matters for what follows: the information in Mission Control is a record of classwork done inside a game, and we protect it as a student record regardless (see §8), but it is not an assessment record and should not be treated as one.
3. What information the Service holds
3.1 About teachers
When a teacher signs up for an Agent account, we store:
- the name they type in (any name they like);
- their email address, used only to send them their Agent code, to tell them their account was approved, and to reach them about the Service;
- a randomly generated Agent code, which is their login credential;
- the date the account was created and a coarse last-active timestamp (updated at most once every ten minutes), so we can tell active teachers from abandoned accounts.
There is no password. The Agent code is the credential, which is why teachers are told to keep it private.
3.2 About students
Students do not have accounts and do not sign up. Everything the Service holds about a student is either entered by their teacher or produced by the student doing classwork. Specifically:
- An identifying label chosen by the teacher. The "operative name" is a free-text field. Most teachers type a student's real first name, or first name and last initial, because they need to recognize the row. A teacher is free to use a nickname, a Roman persona name, or a student ID instead — the Service does not require, verify, or care about a real name. See §13.
- A section or class-period label, if the teacher uses one (e.g. "Period 3").
- A random access code (e.g.
OP-XXXX-XXXX) generated by the Service. - Coursework and progress: Latinity Points per mission and episode; attunement and key-text completion marks; scores on teacher-created Extra-Operational Awards; Puncta Virtūtis, denariī, gradus, trait ranks, and equipment owned or equipped; the timestamped log of awards a teacher has granted.
- Writing the student does in the app: Memorātiō entries (short narrative log entries, one per mission slot) and the optional free-text addition to a character's background.
- Carta Collēctiōnis submissions: the Latin word forms a student submits to collect grammar cards, the surrounding context they paste in, and which cards they have collected.
- Feedback from the teacher: the short "transmission" message a teacher can post to a student's dossier.
- Shared mission-board state for cohort activities such as the Villa of M. Maecenās board (token positions, not per-student data).
Because the Memorātiō, background, and Carta context boxes accept free text, a student could in principle type personal information into them. Teachers should tell students these are for in-character Latin coursework, and teachers can read and edit every one of those fields.
3.3 Technical information
- Failed-access records. When someone enters a wrong code, fails an Agent login, or submits a signup or code-recovery request, we store the requesting IP address with a timestamp so we can rate-limit brute-force attempts. These rows are short-lived: they age out on their own within minutes to an hour depending on the type, and they are pruned automatically. They are not linked to any student.
- Web server logs. Our hosting provider keeps standard web server logs (IP address, time, URL requested, browser user-agent) for operational and security purposes, as every web server does. Note that a student's access code appears in the URL of their dossier and therefore in those logs; the logs are not public and are not used for any analytical purpose.
3.4 What we do not collect
The Service does not ask for, and has no field to store: student email addresses, passwords, usernames, dates of birth, addresses, phone numbers, photographs or video, biometric data, geolocation, disability or health information, disciplinary records, free-and-reduced-lunch status, race or ethnicity, religion, government identifiers, or any financial or payment information. There is no chat, no messaging between students, no file upload, and no public profile.
4. How students get in
Access is by unguessable code rather than by login. A student who has their code can open their dossier; anyone who does not have it cannot. This is a deliberate trade: it means no student has to hand over an email address or remember a password, and it means the code should be treated like a key. Teachers should distribute codes privately (the roster has a copy-link button for this) and can issue a fresh code by deleting and recreating a student's record if one is shared too widely.
Students cannot see each other's dossiers. The one cross-student figure shown is a cohort average, which is not attributed to any individual. Teachers can see only their own cohorts; the Service checks ownership on every request.
5. How the information is used
We use it to run the Service and nothing else: to show a student their own progress, to let a teacher record and review their class's work, to send teachers their Agent code and account notices, and to keep the site secure and working.
We do not use student data for advertising or marketing of any kind, do not build advertising or behavioral profiles, do not sell or rent it, do not disclose it to data brokers, and do not use it to train machine-learning or AI models. We do not use student data to develop or improve products other than this Service.
6. Cookies and tracking
There are no analytics, advertising, social-media, or tracking scripts on this site, and no third-party fonts, scripts, or resources are loaded into the pages students use.
The Service sets exactly one cookie, and only for logged-in teachers and administrators: a session cookie that remembers you are signed in. It is marked HttpOnly, Secure, and SameSite=Lax, and it expires when the browser closes. Students are not given a cookie at all. We do not respond to Do Not Track signals because we do not track.
7. Who else touches the data
We do not sell, rent, trade, or disclose personal information. We share it only with the small number of service providers required to run the site, and only to the extent listed here:
| Provider | What reaches them | Why |
|---|---|---|
| Our web hosting provider | Everything stored by the Service, as the operator of the server it runs on, plus standard server logs | Hosting the site and its database. All data is stored on servers located in the United States. |
| Resend (email delivery) | Teacher names, email addresses, and Agent codes — only for the specific message being sent | Delivering Agent code-recovery and account-approval emails. No student data is ever emailed. |
| Alpheios / Whitaker morphology service (Tufts University) | A single Latin word, with no name, code, or identifier attached | Checking whether a word a student submitted for a Carta Collēctiōnis card is the grammatical form the card asks for. Results are cached locally, so each distinct word is looked up at most once, ever. |
We may also disclose information if we are legally required to, or where necessary to protect the safety of a student or the security of the Service. If we are ever served with a legal demand for student records, we will notify the school that controls those records unless the law forbids it.
If the Service were ever transferred to another operator, student data would transfer only to a successor bound by commitments at least as protective as these, and schools would be notified with an opportunity to delete their data first.
8. FERPA
Student records in Mission Control belong to the school or district, not to us. Where a school or teacher uses the Service to hold information from student education records, we act as a school official with a legitimate educational interest under the Family Educational Rights and Privacy Act (34 C.F.R. § 99.31(a)(1)(i)(B)). That means:
- the school retains direct control over the records;
- we use them only to perform the service the school engaged us for;
- we do not re-disclose them to anyone else except as described in §7 or as the school directs;
- we will correct or delete records at the school's or teacher's direction; and
- we make the records available to the school on request.
Requests from parents or eligible students to inspect, correct, or delete records should go to the school or teacher first, since the school is the custodian. We will support the school in fulfilling any such request. Schools that require a signed data-privacy agreement should contact us.
9. Students under 13 (COPPA)
Mission Control is offered to schools and teachers for classroom use. It is not directed to children as consumers, is not advertised to children, and children cannot sign up for it — only a teacher can create a student record.
Consistent with the FTC's guidance on the Children's Online Privacy Protection Act in schools, where students under 13 use the Service as part of their coursework, the school or district may provide consent on behalf of parents, for educational purposes only. We collect from students only what is reasonably necessary to run the classroom activity (see §3), use it for no commercial purpose, and delete it on request.
Teachers and schools are responsible for making sure they have whatever parental notice or consent their own policies require before adding students, and for deciding what identifying label to use (see §13).
10. How long data is kept, and how to delete it
We do not delete data on a timer. Student records stay in place until a teacher or the school removes them, so that a class's history survives across a school year. Deletion is available at all times, from inside the app:
- One student — the operative's manage page removes that student and all of their points, marks, entries, cards, and feedback.
- One team character — removes the character with its traits, gear, Memorātiō, and award history.
- A whole cohort — the Danger Zone on the cohort page removes every student and character in the class along with all their data.
- An entire Agent account — deletes the teacher record and cascades through every cohort, character, and student they created.
These deletions are immediate and permanent in the live database. Encrypted backups of the server may retain a copy for a short period before rotating out. A teacher or school may also email lapis@practomime.com to ask us to delete a cohort or account for them; we will action such requests within 30 days.
Rate-limiting records expire within minutes to an hour. Server logs are retained by our host on their standard operational schedule. The Latin morphology cache stores dictionary lookups of Latin words only, with no link to any student, and is kept indefinitely.
11. How the data is protected
- All traffic is served over HTTPS.
- Access codes are long and randomly generated, and repeated wrong guesses lock out the requesting address.
- Teacher and admin sessions use hardened, HttpOnly, Secure cookies.
- Every teacher request is checked against record ownership, so one teacher cannot reach another teacher's cohorts by guessing an identifier.
- New Agent accounts are either approved by hand or created with a signup code shared directly with colleagues, so the teacher area cannot simply be opened by anyone who finds the URL.
- The database is not reachable from the public internet, and no student data is stored in the project's source code repository.
No system is perfectly secure. If we discover a breach affecting personal information, we will notify affected teachers and schools without undue delay and provide what we know about the scope and our response, so that schools can meet their own notification obligations.
12. Questions and requests
Parents and students: contact the teacher or school first — they hold the records and can view, correct, or delete anything in them directly. If you would rather write to us, we will help the school act on your request.
Teachers and schools: you can export a cohort's data as CSV from the roster pages, and delete anything at any time. For a copy of everything we hold, a signed privacy agreement, or a deletion you would rather we perform, write to lapis@practomime.com.
13. A note for teachers on minimizing data
The single most effective privacy measure available to you costs nothing: the Service never needs a student's real name. The operative name is only a label so you can find the right row. If your school's policy prefers it, use first name and last initial, a student number, or a Roman persona name, and keep the mapping in your own gradebook. Everything in the app works identically either way.
14. Changes to this policy
This section is about changes to how student data is handled — for example, collecting a new kind of information, using it for a new purpose, adding a service provider that receives it, or changing how long it is kept.
Ordinary work on the app is not a change to this policy and will not appear here: new missions or curricula, new features, redesigns, performance work, and bug fixes all leave the commitments above untouched. If a new feature ever does change what is collected or who sees it, that is a material change and it gets an entry below.
When a material change happens, we update the date at the top of this page and add a dated note to the revision history below saying what changed, so that a teacher or school can see at a glance whether anything has moved since they last looked. Schools that object to a change may delete their data at any time as described in §10.
Revision history
- 28 August 2026 — Initial publication.
15. Contact
The Pericles Group Foundation
Operation LAPIS — Mission Control
lapis@practomime.com