Privacy & data · Helpme.software
The short version: the column does not exist.
Most privacy pages describe a set of controls. This one mostly describes an absence, because the strongest thing we can tell you about student data on a support ticket is that the table has nowhere to put it.
This page describes helpme.software and speaks for no other product. Every other product in the Stanley Studios family publishes its own policy on its own site; if a sentence about photographs or face matching would be relevant to you, you want that product’s page, not this one.
What a support ticket actually holds
Five kinds of data, and that is the list.
✓An adult contact, and only an adult contact
The person on a ticket is the adult who wrote in: their session identity as the owner and their own email address, both read on the server from the session rather than accepted from the request. An optional reply-to override is permitted; it is still an adult address the requester supplies for themselves.
✓Opaque incident context
A request correlation id, a screen LABEL with the query string stripped at the boundary so a stray identifier cannot ride in on a URL, the actor’s role, and the tenant identifiers used for routing and row-level security. These are handles, not descriptions of a person.
✓The words the requester chose to write
A summary and a detail, both adult-authored prose. A content-safety pass runs over them on the server. We will not claim more than that: a text box accepts what a human types into it, and the honest statement is that the SCHEMA does not invite subject data in, not that free text is impossible.
✓Lifecycle, tier and assignment, with an append-only trail
The status, the escalation tier, the assigned owner handle, and an append-only event log carrying every status change, tier change and reassignment with a from-and-to pair and an actor. The trail inherits the same tenant wall as the ticket, so an audit stream never crosses a tenant boundary.
✓Two opaque references, when a ticket is about a thing
A ticket raised from an editor or a checkout may carry an opaque reference to the page or the order it concerns. Tenant-scoped uuids with no foreign key declared, so the reference cannot become a join into anything else. Never a student id, never a roster row.
What this product is not — said plainly
A help desk is not a student information system, a camera, or an advertising surface.
✓No student record, and the schema is the reason
First name, last name, student id, subject id and date of birth are not representable as columns on the ticket table, and a database check forbids a parent or student surface from coupling a subject at all. There is no roster join available to make. This is a property of the migration, not a setting an administrator maintains.
✓No facial recognition, no photo store, no image library
This product answers questions. It holds no photographs, runs no face matching, and sells nothing to a family. If you arrived from a picture-day ordering question, this is the wrong page, and we would rather say so than hand you something that looks like an answer.
✓No advertising profile, and support data is not a product
We do not build a behavioural or advertising profile from a ticket and we do not sell or rent support data. There is no third-party analytics or advertising script on this site.
✓No model trained on your tickets
The AI triage module in the codebase is not wired, and every ticket the live route creates reports that fact with a machine reason. No model is trained on your support data and no third-party generation service is called from these surfaces. The family portal generates nothing at all — its suggestions are retrieval over published articles.
✓No enumeration oracle
A requester asking for another person’s ticket in the same tenant gets the same plain 404 a made-up identifier gets. Not a 403 — a 403 confirms the row exists. For a requester, cross-tenant rows are invisible one layer lower, at the database. The staff per-ticket read is the documented exception — it opens a system-lane transaction that the select policy admits unconditionally — and it is written up as a defect above, not counted here as a wall.
✓No count small enough to identify someone
Every aggregate count in the operator queue passes through small-cell suppression before it leaves the server. A cell below five renders as “<5” and the raw number is not in the payload at all.
Minors
Minors’ data is consent-gated and never public. Here is what carries that.
The table cannot hold it. The migration that creates the support ticket was written so the student-shaped column names are unrepresentable, and a database CHECK forbids a parent or student surface from coupling a subject. A support row cannot become a back-door student record because there is no door. The two columns added since are an adult owner handle and two opaque uuids with no foreign key.
The family surface generates nothing. A student or guardian using the request portal sees suggestions retrieved from PUBLISHED knowledge-base articles, filtered for their audience on the server. No text generation runs on that surface. An unprovisioned or empty knowledge base yields an honest “no suggestions”, never an invented article.
Their own request, and nothing else. A requester’s list is resolved from an owner-scoped read and filtered a second time by the engine. Another person’s ticket returns the same plain 404 a nonexistent one does, so the surface cannot be walked to discover who else has written in.
Counts cannot re-identify. Aggregate queue counts below five are suppressed to “<5” on the server. In a small school with a single counsellor, a count of two in a sensitive tier is not an anonymous statistic, and treating it as one is the mistake this closes.
What we do NOT claim: that free text is impossible. The summary and detail are adult-authored prose and a person can type anything into a text box; a content-safety pass runs server-side over that prose. The schema does not invite subject data in. It cannot stop a human from typing it, and we are not going to pretend otherwise.
Money, automation and messages — what is on and what is off
Three places a product like this usually overreaches. All three are off.
✓No live checkout, and no payment surface in the product
There is no checkout on this site and no card is captured. There is also no payment code in the help desk itself — a search of the operations route for payment, checkout, price, invoice or billing returns nothing, and the family portal client says in its own header that it handles no money. Pricing published here is the planned launch tier, not a price you can be billed at.
✓No AI running, and every ticket says so
An AI triage module with an explicit grounding gate exists in the codebase and is not wired. Every ticket the live route creates reports AI triage as disabled, with a machine reason. The queue’s sort order is deterministic and its at-risk flag is an age-and-priority heuristic, not a learned score. Canned replies are four templates a human wrote.
✓Notifications are key-gated and reported honestly
Where an email would be sent, the absence of a configured mail key means it is reported as queued-not-sent rather than faked as sent. The corridor up-routing surface that would carry those notifications is itself gated behind a flag that defaults off, so every write returns 503 today. No SMS channel exists at all.
✓These marketing pages set no cookie and run no client script
The page you are reading is a stateless server render. It sets no cookie, ships no client-side JavaScript, and calls no third-party analytics or advertising endpoint. That covers this marketing site; the product application behind a login is a separate surface with its own session, and we will not blur the two to make a nicer sentence.
Asking us about data
A person answers, and the answer is specific.
If you are a school, a district, a studio or a family and you want to know what is held about a particular request — or you want something corrected or removed — write to [email protected]. Say which surface it concerns (the request portal, the agent workspace, the operator queue) and we will answer about that surface rather than in generalities.
A school or district running Helpme.software under its own agreement is the controller of its own data; where the agreement and this page disagree, the agreement governs. If you are a family, your school is the right first stop — but if you would rather ask us directly, that address reaches a person.