Privacy Policy

The institution whose staff upload a document decides what is collected and why — it is the data controller (or, under India's DPDP Act, the data fiduciary). RadiusX operates the platform on that institution's instructions as a processor. If you are a student or applicant asking about your own records, the institution you applied to is the first place to ask; we will act on a request they pass to us, and we will also act on one you send us directly.

When a member of staff selects a transcript or letter in the extension, the file is read in the browser and a SHA-256 fingerprint of it is computed there. The fingerprint is the one thing derived from the file without the file being sent anywhere.

The file itself is then sent over TLS to our server, which does two things with it. It reads the document's own PDF metadata — the producer and creator tags, the creation and modification dates, the revision count — for signs that the file was edited after it was issued. And it passes the document to Google's Gemini API, which reads it and returns the contents as structured fields. Those are the only purposes the file is sent for.

We do not keep the file. After extraction, the uploaded bytes are discarded, and so are the metadata values read from them: they are used to compute the risk score shown to the reviewer, and are not stored. What persists is the extracted fields, the fingerprint, and that score. Google processes the request under our Google Cloud data processing terms with zero-data-retention enabled, which means the request is not retained by Google and is not used to train models.

• Details read off the document: student name, student ID, date of birth, issuing board or institution, city, state and country, academic year, results and grades for each period, overall result and percentage, and English test scores where present.
• A summary of the extraction, and any notes a reviewer adds or corrects.
• The SHA-256 fingerprint of the file, which lets the same document be recognised if it is submitted again.
• A risk score and band computed from the integrity signals.
• Which staff account created the record, which institution it belongs to, and when.

Every insert, edit, and deletion of a record is appended to an audit trail holding the full before-and-after values, including the personal details above. The audit trail cannot be edited or erased by the application — that is what makes it an accountability record — and only RadiusX staff can read it.

• Email address, role, and institution. Passwords are held by Google Firebase Authentication and are never visible to us or stored in our database.
• Invitations issued to colleagues: the email address invited, the role offered, who issued it, and when it was used or withdrawn. The invitation token is stored only as a hash.
• Per-account request counters used to rate-limit expensive operations.

• __session — an HttpOnly sign-in cookie for the dashboard, valid for five days. Signing out, changing your password, or using “sign out other devices” ends it.
• rx_tz — your browser's time zone, so dates render and filter in your local time rather than UTC.
• The extension keeps your sign-in token in the browser’s local IndexedDB so you are not asked to sign in for every document.

There are no advertising cookies, no analytics trackers, and no third-party scripts on these pages.

• The officer who created it.
• Administrators at the same institution, for records created by their own staff.
• RadiusX staff administrators, who can reach records across institutions in order to operate and support the platform. This access is the reason the audit trail exists.

Records are not shared between institutions, and we do not sell personal data or use it for advertising.

• Google Cloud Platform — application hosting (Cloud Run), the database (Cloud SQL for PostgreSQL), and sign-in (Firebase Authentication).
• Google Gemini API — reading uploaded documents, and generating plain-language explanations of a risk score from de-identified snippets.

Data is stored in Google Cloud and may be processed in the regions where those services run. No other third party receives personal data from this platform.

Records are kept until they are deleted. Staff at the institution that created a record can delete it from the dashboard, and a deletion removes the row. There is no automatic expiry today; if your institution needs a fixed retention period, contact us and we will apply it.

The audit trail outlives the record it describes, by design — otherwise a deletion would erase the evidence that it happened. Audit entries can be pruned by RadiusX staff on request.

Depending on where you live, you may have the right to ask what personal data we hold about you, to have it corrected, to have it erased, to object to how it is used, and to complain to a supervisory authority — the Data Protection Board of India under the DPDP Act, or your national data protection authority under the GDPR.

Write to rsbuttar@radiusx.com. Tell us the institution you applied to and enough detail to find the record. We will respond within 30 days. Where we act as a processor we may need to confirm the request with that institution first, and we will tell you if so.

All traffic is served over TLS. The dashboard sign-in cookie is HttpOnly, so no script on the page can read it. Access to records is enforced in the database by row-level security as well as in the application, so a bug in one layer does not by itself expose another institution's data. Sign-out, password changes, and account deactivation revoke existing sessions rather than waiting for them to expire.

No system is immune. If we discover a breach affecting personal data, we will notify the affected institutions and the relevant authority as the law requires.

We update this page when the data flow changes, and the date at the top moves with it. Material changes are communicated to the institutions using the platform.