Student data

We do not collect anything about a student.

That is a short sentence with a lot resting on it, so the rest of this page is what it means exactly, where it stops being true, and what would change if we ever built the version that saves anything.

What exists today

There is no account, no login, no roster, and no database record of any student. A student can use every part of this site without telling us who they are, because there is nowhere for us to put it.

The interest questions, the scoring, and the match against 923 occupations all run in the student’s own browser. Their answers are never transmitted. This is not a retention policy — there is no transmission to have a policy about.

You can verify this in about fifteen seconds. Open the developer tools network tab, complete the questions, and watch. Beyond the page and its own files loading, the only request is the job search described below, and only if the student presses the button that asks for it. No request carries an answer, and no cookie is ever sent.

The one request this site makes

When a student asks to see openings for an occupation, the browser sends two values to our server and nothing else:

A search term: Derived from the occupation title, for example Registered Nurse.
A two-letter state: The state the student chose from a list, for example MT.

That is the whole request. It carries no answers, no interest scores, no name, no email address, no school and no identifier of any kind. It is a public job search with a state filter, and it is indistinguishable from any other visitor’s.

Our server logs are the ordinary web-server logs of the hosting provider. We do not run analytics, we set no cookies, and there is no third-party script on any page of this site — which is now enforced by a Content-Security-Policy rather than only being true, so a reviewer can check it from a response header.

Everything is served over TLS with HSTS; there is no unencrypted path to any page. We are not making a data-residency claim: this site is served by a commercial CDN and queries a hosted database, and we have not yet established and cannot yet evidence which regions either of them uses. If residency is a requirement for you, ask us and we will get it in writing rather than guess on this page.

On PPRA (20 U.S.C. §1232h): all sixty questions ask whether a student would enjoy a kind of work. None of them touches the eight protected categories — political affiliations, mental or psychological problems, sexual behavior or attitudes, illegal or self-incriminating behavior, critical appraisals of family, privileged relationships, religious practices, or income. The item wording is O*NET’s and is published, so this is checkable rather than asserted.

What stays in the browser, and the shared-computer problem

Answers are held in the page while it is open and are never written to the computer. On a shared computer that is the whole point, so it is worth being precise about what the code actually does.

Nothing is written to browser storage, to a cookie, or to a file. A student can confirm this with the browser's own developer tools: session storage, local storage and cookies are all empty while the questions are being answered.
The answers live in the page's memory. Moving around the site and coming back keeps them, because it is the same page.
Reloading the page, or closing the tab, ends them. There is nothing left behind to recover, and nothing for the next person to find.
Nothing is transmitted. The scoring, the interest profile and the occupation matching all run on the student's own machine, which is visible as an absence of network requests.

Surviving a refresh and protecting a shared computer turned out to be the same feature pointing in opposite directions. Anything durable enough to outlive a reload is also copied into a duplicated tab, and from inside the page a refresh of your own tab and a duplicate of somebody else's are indistinguishable. On a cart-based fleet the machine is the identifier, not the person, so we chose the side that cannot leak one student's answers to the next, and we tell the student plainly that a reload loses their work.

There is no draft recovery, no autosave and no expiry window, because there is no stored draft to expire.
This protects the answers, not the screen. Anyone who can see the monitor can see the questions, and no software choice changes that.

We have written this section wrong twice, both times by changing the code and updating one page out of three. It now reads from the same single file the other pages read from, and the build refuses a page that describes this in its own words, because keeping three prose descriptions in agreement by intention does not work and we have the evidence.

When you leave this site

A job listing links out. Most of those links go to a job board rather than to the employer, and those sites have their own cookies, their own analytics and their own privacy policies, over which we have none of the control we have here.

Two things we do about that:

We strip our own referral tag from every outbound link. The postings reach us through a jobs API that attaches an attribution parameter, and we remove it. Nothing on this site earns us anything when a student clicks, and nobody can ask whether we steer young people toward the listings that pay.
We name the destination before the click. Each opening says which site it opens, so a student is not handed to a company they have never heard of without being told.

What we will never do

Each of these is enforced by something in the build, not by a promise in a document.

No student is scored or ranked. There is no readiness score, no employability index, and no percentile against classmates. We rank occupations and show no number at all. A build gate fails the deploy when an identifier naming such a value appears — that is a source check, not a proof, and it would not catch a percentage assembled inline at render time. The architecture is the real control: there is nowhere to store a score even if one were computed.
No employer or recruiter can see a student. This product has no employer console, no recruiter surface, and no code path that writes a student anywhere. A second build gate fails the deploy if such a route is created.
No advertising, ever. No targeted advertising, no behavioral profile for a non-educational purpose, and no sale or licensing of student information. This is what California’s SOPIPA (Bus. & Prof. Code §§22584–22585) requires and what we would do without it.
No text messages. Prior express written consent is required and a minor cannot give it, so the capability is not built.
No engagement mechanics. No streaks, no loss-framed notifications, no manufactured urgency, no leaderboards.

If a saved version is built

Nothing in this section exists. It is written in the conditional deliberately, and it describes what we would commit to if a district ever asked us to build a version that keeps a record. If you are evaluating this product today, this section is not part of it.

It would be opt-in at the district level, under a signed agreement, and the anonymous version on this site would keep working exactly as it does now.

It would hold: A display name and a school-issued email address supplied by the district, the student’s own answers, and which steps they completed. Not a Social Security number, a home address, a photograph, a disciplinary record, an IEP or 504 record, a grade point average, disability status, free-and-reduced-lunch status, or immigration status.
It would be governed by: FERPA’s school-official exception under the district’s direct control; school consent under COPPA for students under 13, which is available precisely because we take no commercial benefit from a child’s data; SOPIPA’s prohibitions; and an agreement carrying the AB 1584 terms.
It would be signed on: The SDPC National Data Privacy Agreement, your state alliance’s version, or your own. We would not require you to use ours.
It would be exportable and deletable: Export by a district administrator without asking us; deletion on written request with written confirmation; deletion on termination rather than retention “for analytics”.

Would student data reach an AI vendor?

There is no AI in this product today — no model client, no API key, no inference of any kind. If language features were ever added they would run under commercial terms prohibiting training on submitted data, would never carry a student’s identity, would never make a decision about a student, and a district would be able to switch them off with the rest of the product still working.

Accessibility

We target WCAG 2.1 Level AA. Build gates reject on every deploy the specific failures that recur: removed focus indicators, images without alternative text, invalid ARIA on links, focusable content hidden from assistive technology, and any attempt to disable zoom. An automated accessibility engine is run against the live site by hand, at phone, tablet, Chromebook and desktop widths, before a release — it is not yet wired into the build, and saying “every deploy is checked” would have overstated that by exactly the margin this page exists not to overstate.

We do not publish a completed VPAT. It is in progress and we would rather say that than send you one that has not been earned.

What we do not have

No signed data privacy agreement with any district, because there is no district yet. We will sign yours.
No SOC 2 report. We can answer a security questionnaire in full detail and we can be audited, but we will not claim a certification we do not hold.
No completed VPAT.
No outcome data. No placement rates, no completion statistics, no impact study. We have not been in a school long enough to have earned any.
No rostering, no single sign-on, no LMS integration.

If any of that is a hard requirement for your district this year, we would rather you knew it on this page than three weeks into an evaluation.

Document details

Effective: 31 August 2026. This is version 2; version 1 was withdrawn the same day because it described capabilities this product does not have.
Service: Futureful for Schools, at student.futureful.app (served today at futureful-student.netlify.app while DNS is set up).
Operator: TwinFlame Group. Futureful is its product; SMI is a partner, not the operator of this service.
Privacy and security contact: david@reddenda.com — a single named human today rather than an alias that nobody reads. When there is a team it becomes a role address, and this line will say so.
Security disclosure: /.well-known/security.txt
Breach notification: There is no student data to breach today. If a saved version ships, we would commit in the agreement to notify the district without unreasonable delay and within the window your state requires — New York Ed. Law §2-d and Texas SB 820 both set one, and a DPA term is the right place for it rather than a web page.