Privacy Policy

Effective date: June 3, 2026

Last updated: August 31, 2026

1. Information We Collect

Information you provide to us

Account information. When you create an account, we collect:

• Your email address (required).
• A display name, populated from your identity-provider metadata where you sign in through your institution’s system, or otherwise derived from the part of your email before the “@”.
• Your role in a given course (instructor, teaching assistant, or grader), stored per course.
• Your plan tier, recorded on your profile for billing purposes.

We authenticate accounts using a password (managed by our authentication provider, Supabase, and never stored by us in plaintext); through Sign in with Google(Google OAuth), where Google verifies your identity and returns your email address, a Google-issued user identifier, and basic profile information (such as your name and profile picture) to Supabase; or, where you launch the Service from your institution’s Canvas learning management system (LMS), via that LMS.

Content you upload. To use the Service, you upload grading materials, which may include:

• Answer keys and rubrics (files, images, or text).
• Exam and course metadata (course name, code, term, exam name, due dates).
• Student submissions (images, PDFs, or text; for example, scanned handwritten work).
• Student names or identifiers that you attach to submissions.

Payment information. If you purchase page credits or a subscription, our payment processor (Stripe) collects and processes your payment details directly through Stripe’s embedded checkout component. We do notreceive or store full card numbers or security codes. We retain only Stripe-issued references: a customer ID, payment-method ID, subscription ID, subscription status, period-end date, page-credit ledger entries, and (if you cancel a subscription) any cancellation reason code and free-text comment you provide in Stripe’s cancellation flow.

Communications. If you email us or submit our contact form, we receive the name, email address, and message you provide. Contact-form messages are relayed to our support inbox via Resend and are not stored in our application database.

Information we collect automatically

Diagnostic, error, and session-replay data (Sentry). We use Sentry to detect, diagnose, and fix problems and to monitor performance. This includes error messages, stack traces, the page or action involved, browser/device characteristics, performance traces, backend profiling data, forwarded application log lines, and client-side Session Replay. We configure Sentry not to attach personally identifying user fields automatically (sendDefaultPii: false). Because that setting alone does not govern on-screen or logged content, we apply the following additional controls and disclose the residual limits plainly:

• Session Replay records a reconstruction of what is rendered in your browser for approximately 10% of sessions (sampled at random) and for 100% of sessions in which a browser error occurs. Replay is configured to mask all text and all form inputs, and to block all media, so student names, scores, and submission transcriptions displayed on grading-review and history pages are replaced with placeholders rather than recorded. We also do not enable Sentry’s canvas-recording integration, so rendered PDF or image pages of student work are not captured, and we do not capture network request or response bodies.
• Application logsforwarded to Sentry identify a submission by a random per-run correlation tag (for example, sub-1a2b3c4d) rather than by student name, and only WARNING-level and above are forwarded to Sentry’s log stream. Captured errors are configured not to include local-variable snapshots, which would otherwise carry submission text, transcriptions, and page images from the stack frame. Residual limitation (disclosed): the instructor email address is written to an application log line when a grading-completion email is sent, and can therefore reach Sentry attached as context to an error report from the same request. This concerns instructor account data, not student education records.

Limited usage logs. We keep a limited in-app audit log of certain actions (for example, viewing the dashboard, submitting work through the Canvas integration, and administrator access). Server-recorded entries record the action type, related resource identifiers, and limited contextual metadata such as a file count or Canvas user ID; they do not record IP address or user-agent. A separate set of browser-recorded diagnostic entries(used to investigate upload failures) additionally records your browser’s user-agent string and coarse connection-quality readings (connection type, estimated bandwidth, and round-trip time). Neither log records student submission content.

Operational metrics. We record per-API-call token counts, cost, and latency linked to internal account/course/exam/submission identifiers, used to calculate page-credit consumption and to operate and monitor the Service.

IP address. Our backend reads your IP address to apply rate limits and protect the Service from abuse. We do not store your IP address in a persistent user profile or transmit it to any advertising or analytics third party.

Cookies. We use only strictly necessary, first-party cookies (a Supabase session-authentication cookie to keep you signed in). See Section 12 (Cookies and Tracking Technologies).

Information we do NOT collect

To be clear about what we don’t do:

• We do not collect precise geolocation or GPS data.
• We do not extract or store student email addresses from the Canvas LTI launch (only name and Canvas user ID are received).
• We do not pull Canvas course rosters, sections, or enrollment lists (the Names and Roles Provisioning Service is not implemented).
• We do not use advertising trackers, third-party analytics pixels, beacons, or marketing tags. We do not use Google Analytics, Google Tag Manager, Meta Pixel, PostHog, Amplitude, Mixpanel, Segment, Hotjar, FullStory, LogRocket, Intercom, or HubSpot.
• We do not set advertising or cross-site tracking cookies.
• We do not sell personal information, and we do not share it for cross-context behavioral advertising.
• We do not collect Social Security numbers, government-ID numbers, biometric identifiers, financial-account numbers, or health/medical, racial, religious, or sexual-orientation data.

2. How We Use Information

We use the information above to:

• Create and authenticate your account and keep it working;
• Provide and continuously improve the core Service: analyzing your answer keys and rubrics and grading student submissions to return scores and feedback, and (where the Canvas integration is enabled) writing approved grades back to the gradebook. Improvements to our grading models are developed from de-identified and aggregated data only, never from identifiable student coursework (see Section 3);
• Process payments, manage your page-credit balance, and send billing-related messages;
• Send you transactional notifications (for example, an email letting you know a grading run has finished);
• Monitor, debug, secure, and operate the Service;
• Create de-identified and aggregated data and use it to analyze, develop, and improve the Service, including our grading models (see Section 3);
• Detect and prevent fraud and abuse; and
• Comply with legal obligations.

We do not use your content to send you marketing or promotional campaigns. The only emails we send are service- and account-related. Apart from the grading-model improvement described in Section 3 — which uses data with direct identifiers removed, and which for records still linkable to a submission is limited to courses whose institution has authorized research use — we do not use student education records for any purpose beyond performing the grading function for the institution or instructor that uploaded them.

3. How AI Processing Works

Grading and related AI features are performed using third-party AI models. xAI (models in the Grok family) is our primary grading model: it performs answer-key analysis, rubric generation, and the grading and scoring of student submissions, and is used to evaluate our own model quality. Google (models in the Gemini family) performs document extraction and handwriting transcription, and generates draft answer keys in the questions-first flow (where an instructor uploads a blank exam and reviews AI-proposed answers before any grading). OpenAI(models in the GPT-5 family) runs two narrow checks throughout — notation disambiguation and answer-key conformance — and remains configured as our fallback grading model, performing answer-key analysis, rubric generation, and grading/scoring whenever the Service is configured or falls back to it. It therefore still receives the same categories of content as the primary grading model, and we continue to name it as a grading subprocessor. Open-weight models(defined below) generate draft answer keys in the questions-first flow. To provide these functions we transmit content to these providers’ APIs: answer-key images/text and rubric data; student submission images (sent as base64-encoded data inline in the request); and the AI-generated transcription text of the student’s work. We do not include any student name, email address, or institutional identifier in the prompt text sent to any provider.

The models we use, and how those roles can change.The Service runs on a fleet of models rather than a single one, and which model performs a given function is a configuration choice we may change — per stage, per request, or as an automatic fallback when a provider is slow or unavailable. The roles described above are our current default configuration, not a fixed commitment: any of the model families listed below may be used for any of the AI functions described in this Policy — answer-key analysis, rubric generation, document extraction and handwriting transcription, grading and scoring, and the narrow checks that run throughout. The families we use, or may use, are:

• xAI — models in the Grok family
• OpenAI— models in the GPT family, including smaller “mini” variants
• Google — models in the Gemini family
• Meta— models in the Muse Spark family (open-weight, served by Meta’s hosted API)
• Anthropic — models in the Claude family
• DeepSeek — models in the DeepSeek family
• Moonshot AI — models in the Kimi family
• Open-weight models we run ourselves, including models we have fine-tuned (Qwen- and Ornith-family), on the infrastructure named in Section 4

Changing which model performs a function does not change what we send, or what we promise about it. The categories of content described above are the same for every provider, we never include a student name, email address, or institutional identifier in prompt text, and we do not route your content to any provider that is not named in the subprocessor table in Section 4. If we begin using a provider that is not listed there, we add it to that table and update this Policy before your content is sent to it. The provider-specific disclosures below — including the contractual gaps we disclose for xAI and Meta — state what protections are, and are not, in place for each provider we currently use.

• We do not use your content, student submissions, or grading results in identifiable form to train any AI or machine-learning model that we operate or control. As described under De-identified and aggregated data below, we may use de-identified and aggregated data derived from this content to improve our grading models.
• We access OpenAI exclusively through its commercial API. Under OpenAI’s API data-usage policy, inputs and outputs submitted through the API are not used to train OpenAI’s models.
• We access Google’s Gemini models through Google Cloud’s Vertex AI API under the Google Cloud Data Processing Addendum. Under those terms, inputs and outputs are not used to train Google’s models and are not subject to human review; processing is transient and content is not stored at rest by Google. Region (disclosed):Google does not currently offer US-region serving for the Gemini model we use, so these requests are served from Google’s global endpoint and may be processed outside the United States. We re-check regional availability and will pin this processing to a US region when Google offers it. Institutions with strict residency requirements should contact us before deploying.
• Retention controls and remaining gap (disclosed):We set OpenAI’s store=false flag on every grading request, so that OpenAI does not persist the request or response for retrieval. This does not by itself eliminate OpenAI’s abuse-monitoring retention:absent an approved organization-level Zero Data Retention (ZDR) arrangement, OpenAI’s policy permits it to retain API content for a limited period for abuse monitoring before deletion. We have not yet completed a ZDR arrangement, so that limited window still applies to submission content we send, and we cannot compel OpenAI to return or delete an individual record on instruction. Institutions with heightened requirements may contact us about contractual safeguards. Grading requests are sent synchronously and no submission content is uploaded to OpenAI’s Files API.
• xAI (Grok) — disclosed contractual gap.We access xAI’s Grok models through xAI’s commercial API to perform answer-key analysis, rubric generation, and the grading and scoring of student submissions. xAI therefore receives the same categories of student content as our other grading providers, including student submission images and the AI-generated transcription of a student’s work, alongside answer-key and rubric data. We have not completed a data processing addendum with xAI. We therefore cannot represent — and do not represent — that content sent to xAI is excluded from model training, exempt from human review, or subject to a defined retention or deletion window; content we send may be retained and used by xAI under the API terms in force at the time of the call, and we cannot compel the return or deletion of an individual record. This is a materially narrower set of contractual protections than we hold with OpenAI and Google, and it applies to student work rather than to metadata alone. Because xAI now serves as our primary grading model, this gap applies to most grading runs rather than to an occasional one. We are pursuing a written agreement with xAI and will update this Policy when it is executed. An institution that prefers its data not reach xAI should contact us before deploying (Section 19).
• Meta (Muse Spark) — disclosed contractual gap.We access Meta’s Muse Spark, an open-weight model, through Meta’s Model API, where it generates draft answer keys in the questions-first flow. This model is text-only in our pipeline: it does not receive student submission page images. It does receive instructor-supplied question, answer-key, and rubric text, and — where the questions-first flow has surveyed student work — short prose descriptions of observed student approaches derived from submissions. We have not completed a data processing addendum with Meta, and the same limits stated above for xAI apply: we cannot represent that this content is excluded from training, exempt from human review, or subject to a defined retention window, and we cannot compel deletion of an individual record. We are pursuing a written agreement with Meta and will update this Policy when it is executed.
• We do not send your content to any AI provider other than those named in this section and in the subprocessor table in Section 4, and only to provide the Service.

A separate, brief LLM call (the notation disambiguator) may run on a small fraction of questions when a student’s written math contains convention-ambiguous notation; it sends the student’s expression and a truncated transcription excerpt to a lightweight OpenAI model and contains no student identifiers.

Open-weight models. Some models we use are open-weight: their trained parameters are published under a license that lets anyone run them. A model’s license does not by itself tell you what happens to your data — what matters is where the model runs — so we treat two cases differently and disclose both.

• Open-weight models served by a third party.When we call an open-weight model through someone else’s hosted API — for example Meta’s Model API — your content leaves our systems and is processed by that host, exactly as it would be with any other provider. That host is a subprocessor, is named in the table in Section 4, and is subject to everything this Policy says about subprocessors. The fact that the model’s weights are public changes nothing about this: it does not reduce what that host receives, and it is not a basis on which we would omit them from disclosure.
• Open-weight models we run ourselves. When we run an open-weight model on infrastructure we already control and disclose (our backend hosting, named in Section 4), no additional third party receives your content— it stays inside the boundary this Policy describes. We do not send that content to the party that published the model’s weights, and self-hosted inference does not expose your content to any outside provider’s training, logging, or human review.

De-identified and aggregated data. We may create de-identified or aggregated information from data processed through the Service (including from student submissions, transcriptions, and grading results) and use it to develop, evaluate, and improve our grading models, rubric generation, and other features. Before any such use, we remove direct identifiers such as student names, email addresses, and Canvas user IDs; our research-data schema rejects records containing them. We commit not to attempt to re-identify this data; we require any recipient to do the same; and we do not transfer it to anyone who has not agreed both not to attempt re-identification and not to transfer it onward except under the same restriction. Current limitation (disclosed): some research records retain an internal random record identifier that, within our own systems, can be traced back to the originating submission. Until that linkage is severed, such records are pseudonymised rather than fully de-identified; we hold the link under access controls, never disclose it, and treat those records as education records still subject to the FERPA protections in Section 7, not as de-identified data. We do not sell de-identified data, and we never place student names or other direct identifiers in model-training data.

4. How We Share Information

We do not sell your information and do not share it for cross-context behavioral advertising. We share it only with the service providers (“subprocessors”) below, who process it on our behalf under contractual confidentiality and data-protection obligations, and as described under “Other disclosures.”

Subprocessors

Google Fonts (Google LLC).Our public marketing landing page loads a webfont directly from Google’s font CDN (fonts.googleapis.com), which causes your browser to send your IP address and user-agent to Google when you visit that page. This does not occur on the authenticated application, where fonts are self-hosted. We disclose this so it cannot be read as covering authenticated, student-data pages.

Other disclosures

Learning management systems. When you or your institution connect RavenGrader to Canvas via LTI 1.3, we exchange data with Canvas as described above only while the integration is enabled.

Legal and safety. We may disclose information if required by law, regulation, legal process, or governmental request, or to protect the rights, property, or safety of RavenGrader, our users, or others. For legal demands seeking student education records we hold on behalf of an institution, see Section 7.

Business transfers. If we are involved in a merger, acquisition, or sale of assets, information may be transferred as part of that transaction, and we will notify affected users of any resulting change in ownership or use of their information. Student education records are treated differently.FERPA contains no exception for business transfers, so we will not transfer education records to a successor unless that successor assumes, in writing and as a condition of the transfer, this Policy’s Section 7 obligations and every institutional agreement covering those records. We will give each affected institution advance written notice and an opportunity to terminate and require return or deletion of its records before any such transfer takes effect. We do not disclose education records to prospective investors, lenders, or acquirers for diligence purposes; where diligence requires data, we provide aggregate or de-identified information only.

5. Data Retention

We retain information for as long as your account is active or as needed to provide the Service, and we are transparent about the current limits of our deletion tooling.

• Account, course, exam, submission, and grading dataare retained while your account is active. Deleting a course, exam, or submission first removes it from your active workspace by marking it deleted in our database (a “soft delete”), which allows an accidental deletion to be reversed on request. Records that have been in that state for more than 90 days are then permanently destroyed by an automatic daily process, both the database rows and the corresponding uploaded files in our storage service.
• Billing data: Stripe billing references and the page-credit ledger are retained while your account is active. Certain operational records (per-call cost/token events) and some billing-event records are retained in de-identified form (with the user link removed) after account deletion for accounting and fraud-prevention purposes; other billing records (the credit balance and credit ledger) are deleted together with the account.
• Diagnostic data and session replaysare retained according to Sentry’s then-current retention settings for our plan.

Account deletion. When you delete your account, it is permanently destroyed, effective immediately: your subscription is canceled, database rows are deleted (except the de-identified billing records described above), and the associated uploaded files are removed from our storage service. Deletion cannot be undone.

Known deletion limitations (disclosed). As of the date of this Policy:

• We do not provide a self-service data-export interface; access, correction, and export requests are fulfilled manually by our staff (see Section 8).
• Deletion of a course, exam, or submission is not immediate: the record leaves your workspace at once, but the underlying rows and stored files persist for the 90-day recovery window described above before automatic destruction. A request to destroy specific records ahead of that window is fulfilled manually on request (see Sections 7 and 8).
• As noted in Section 3, content sent to xAI or Meta is not covered by an executed retention or deletion commitment, and content sent to OpenAI remains subject to OpenAI’s limited abuse-monitoring retention, which we cannot currently waive on a per-record basis.
• Our transcription cache stores derived text on ephemeral server disk keyed by content hash rather than by student or submission, and is not addressable for targeted deletion; entries rotate out automatically within a short period.

We are actively building automated export tooling and will update this section as those capabilities ship. Institutions may request manual deletion or return of their student records at any time (see Sections 7 and 8).

6. How We Protect Information

We use reasonable technical and organizational safeguards, and we describe both what we do and where we are still hardening.

Encryption in transit. Traffic between your browser and the Service is served over HTTPS/TLS by our hosting providers (Vercel for the frontend, Railway for the backend). Non-localhost CORS origins are restricted to https:// endpoints.

Encryption at rest.Data stored in our database and file-storage buckets is encrypted at rest using AES-256, implemented at the infrastructure layer by Supabase (on AWS US-East-1) under its SOC 2 Type II–certified controls. We do not add a separate application-level encryption layer on top of this infrastructure encryption, and our database connection relies on Supabase’s server-side TLS requirement rather than an application-enforced ssl=require parameter.

Access controls.Database tables holding account, course, submission, grading, audit, and billing data are protected by Postgres row-level security so authenticated users can access only their own data and courses they belong to. Storage buckets holding uploaded coursework and grading files are private and accessed only through short-lived, pre-signed URLs; three narrow buckets that hold no student coursework (profile avatars, instructor-authored exam-builder diagram images, and marketing videos) are public-read so pages can load them directly. Account authentication uses Supabase ES256 JWTs verified against Supabase’s published JWKS endpoint. Administrative access is restricted to a named email allowlist. Critical grading endpoints are rate-limited. Stripe webhook payloads are signature-verified.

Security posture and known gaps (disclosed).In the spirit of transparency with institutional customers. The gap list previously published here was written in early June 2026; each item has since been remediated and verified against the current codebase (July 31, 2026): LTI integration tables now have row-level security applied; LTI launch tokens are cryptographically verified against the platform’s JWKS, including audience, issuer, and expiry; LTI student endpoints derive identity from the server-side launch session and never trust a client-supplied user ID; submission endpoints enforce per-record owner-or-instructor authorization; and administrative endpoints enforce a second factor for any administrator who has enrolled one (see the current limitation below).

A further review was completed on August 3, 2026. Its critical and high-severity findings have been remediated and independently verified: the LTI signing key described below was rotated and the new key confirmed live; row-level security was extended to four tables that previously lacked it, and the underlying table grants to anonymous and authenticated roles were revoked as well, so those tables are unreachable from the browser rather than merely filtered; Canvas/LTI authorization is now scoped to the specific course a session was launched from, rather than to the institution as a whole; per-client rate limits, request-size limits, and page-count limits were corrected or added; the application container no longer runs as root; and automated secret scanning now runs on every change.

Remaining, stated plainly: (a) administrative multi-factor authentication is enforced but not yet mandatory. Where an administrator has enrolled a second factor, our administrative endpoints require it, and a failure to verify enrollment denies access rather than granting it. An administrator who has not enrolled a factor is currently admitted with a single factor. Enrollment and mandatory enforcement are being completed; we will update this statement when that is done rather than before; (b) we have not yet obtained SOC 2 Type II certification of our own program: our Type II observation window opened in June 2026 and no report has been issued; our core subprocessors independently hold SOC 2 Type II reports; (c) database backups are daily rather than continuous, so our worst-case data-loss window is up to 24 hours (see our security page). We will update this section as these items close.

No method of transmission or storage is 100% secure, and we cannot guarantee absolute security. You are responsible for keeping your credentials confidential.

7. Student Data & FERPA

RavenGrader is designed for educational use, and most student data we process constitutes “education records” under the Family Educational Rights and Privacy Act (FERPA).

7.1 RavenGrader as a “school official”

When a FERPA-covered educational institution uses RavenGrader to grade student coursework, RavenGrader, Inc. acts as a “school official” with a “legitimate educational interest” within the meaning of FERPA, 34 CFR § 99.31(a)(1)(i)(B). Grading (evaluating student work, producing scores, generating feedback, and returning results to the instructor or gradebook) is a function the institution would otherwise perform using its own faculty, teaching assistants, or graders. RavenGrader performs that same institutional function under the direction of, and on behalf of, the institution.

As a school official, RavenGrader:

• Processes student education records only to perform the grading function the institution directed;
• Is subject to the institution’s policies on use and re-disclosure of education records, and does not re-disclose student records except as necessary to provide the Service (for example, sending submission images and transcriptions to our AI model providers to produce a grade) or as required by law;
• Does not use student education records for its own commercial purposes, and does not sell them, use them for advertising, or build profiles of students outside the grading context; and
• Returns control of student records to the institution, including by supporting grade writeback to the institution’s LMS and by fulfilling deletion or data-access requests made by the institution on a student’s behalf.

Improvement and de-identified data.We improve our grading models using data that has had direct identifiers removed, as described in Section 3. Under 34 CFR § 99.31(b)(1), information from which all personally identifiable information has been removed, where a reasonable determination has been made that a student’s identity is not personally identifiable, is not subject to FERPA’s consent, use, and re-disclosure restrictions; we claim that exemption only for data meeting the de-identification definition in Section 3. As disclosed there, some research records currently retain an internal linkage to the originating submission; we treat those records as education records still subject to FERPA, apply the use limitations in Section 7.3 to them, and restrict research use of them to courses whose institution has consented to research use. We do not place student names or other direct identifiers in model-training data. See Section 3.

The institution remains the controller. The educational institution, not RavenGrader, is the controller of student education records. Institutions and instructors are responsible for ensuring their disclosure of student records to RavenGrader falls within an applicable FERPA exception (including the school-official exception at 34 CFR § 99.31(a)(1)(i)(B)) and for providing required notices to students or parents.

7.2 Education records and personally identifiable information

When RavenGrader is used by or on behalf of an institution, the following categories of student data we receive and process may constitute “education records” and “personally identifiable information” under FERPA, 34 CFR § 99.3 (and 20 U.S.C. § 1232g(a)(4)):

• Student submission files: handwritten images, PDFs, and text uploaded by instructors or submitted by students through the Canvas integration;
• AI-generated transcriptions of student work created during grading;
• Per-question scores and AI-generated feedback, including the total score and any instructor edits made during review;
• Student names provided by instructors or received from Canvas via LTI launch (name, given_name, family_name);
• Canvas user identifiers (the LTI sub claim) used to associate submissions and grade writebacks with a student; and
• Curve-adjusted final scores written back to the Canvas gradebook via Assignment and Grade Services (AGS).

We do not extract or store student email addresses, and we do not pull Canvas rosters (NRPS is not implemented).

Grades are not directory information. Scores, feedback, transcriptions, and other grading data are not“directory information” under 34 CFR § 99.3. We do not designate, publish, or disclose them as directory information, and we do not treat the absence of an opt-out as permission to share them. Grade data is disclosed only to the submitting institution or instructor, or written back to the institution’s own gradebook at the instructor’s direction.

7.3 Use limitation

Student education records are: used only to provide the grading Service and, as described below and in Section 3, to improve the grading models that deliver it; never used for behavioral or targeted advertising; never mined for commercial student profiling; never used to train or fine-tune any AI/ML model while they still carry direct identifiers such as a student name, email address, or Canvas user ID; and never sold, rented, licensed, or transferred for commercial gain.

Grading-model improvement, stated precisely.We improve our grading models using data drawn from submissions, transcriptions, and grading results with direct identifiers removed. Some of those records remain linkable to the originating submission inside our own systems, which under FERPA means they are still education records rather than de-identified data (Section 3). For those records we do three things: we use them only for improving the grading service itself, never to build a different product or to benefit from one institution’s data in a way the institution has not authorized; we restrict them to courses whose institution has authorized research use in writing; and we apply every other limitation in this section to them. Once data has been de-identified so that it can no longer reasonably be linked to a student (Section 3), it is no longer an education record, and we may use it to evaluate and improve the Service; we do not attempt to re-identify it.

7.4 Institutional direct control, return, and deletion

The institution (or an instructor acting under institutional authority) retains direct control over the use and maintenance of student education records. Authorized institutional personnel may, at any time, access submission files and grading results through the Service, and may request correction, export, or deletion of student records by emailing williamtjandra@ravengrader.com or christopherlauw@ravengrader.com; we will fulfill such requests, currently through a manual process. RavenGrader will not unilaterally delete or repurpose institution-controlled student records except as required by law or as directed by the institution. Important limitations (disclosed):we do not yet offer a self-service export interface, and export requests are fulfilled manually; deletion of student records is automatic but not immediate (stored files and rows are destroyed after the recovery window described in Section 5, and destruction ahead of that window is fulfilled manually on request); and we cannot compel our AI providers to delete a specific record on instruction — content sent to OpenAI remains subject to OpenAI’s limited abuse-monitoring retention pending a zero-data-retention arrangement, and content sent to xAI (our primary grading model) or Meta is not covered by any executed retention or deletion commitment at all (see Section 3).

7.5 Re-disclosure restriction and subprocessor obligations (34 CFR § 99.33)

RavenGrader will not re-disclose personally identifiable information from education records except (a) as directed by the controlling institution or educator, or (b) as otherwise authorized under FERPA (for example, in response to a lawful subpoena or court order after any required notice).

What we do when we receive legal process.If we receive a subpoena, court order, or similar demand seeking student education records we hold on an institution’s behalf, then unless a court order or applicable law forbids us from doing so, we will: (1) notify the controlling institution promptly and before producing anything, so the institution can make the advance notification to the parent or eligible student that 34 CFR § 99.31(a)(9)(ii) requires and can seek to quash or limit the demand; (2) where possible, direct the requesting party to the institution as the party that controls the records; (3) produce no education records before the institution has had a reasonable opportunity to object or intervene; and (4) if we must produce records, disclose only what the demand actually requires. Where a demand is sealed or the law otherwise bars notice, we will give the institution notice as soon as we are permitted to.

Each subprocessor that receives education records (OpenAI, Google, Supabase, Sentry, Railway, Vercel, MongoDB Atlas as to pseudonymised research records, and Canvas as the institution’s own system) is engaged under terms that limit use to performing the contracted function, prohibit further re-disclosure except as required by law, and require reasonable security. We disclose in Section 3 the remaining OpenAI abuse-monitoring retention window and the current region status of Google processing. Two further subprocessors receive education records under a disclosed contractual gap. xAI receives student submission images and transcribed student work in order to grade them, and Meta receives answer-key and rubric text that can include descriptions of student approaches derived from submissions (Section 3). Neither is yet engaged under an executed data processing addendum containing the commitments described above. We state this plainly rather than imply protections we have not secured; we are pursuing written agreements with both providers, and we will update this Section when they are executed. Institutions evaluating RavenGrader against their own vendor-oversight obligations should treat this as a current, disclosed limitation.

7.6 Student/eligible-student rights: contact your institution

Because the institution controls these records, FERPA rights flow through the institution, not directly through RavenGrader.

• Inspect and review (34 CFR § 99.10): If you are a student (or eligible parent) seeking to inspect education records processed through RavenGrader, submit that request to your institution, which has up to 45 days to comply. We will cooperate within that window upon a written request from an authorized institutional official.
• Amendment (34 CFR §§ 99.20–99.22):If you believe a record is inaccurate or misleading (for example, a score recorded under the wrong student), ask your institution to amend it; the institution will contact us if correction is needed. FERPA’s amendment right does not extend to challenging the academic judgment reflected in a grade. Disputes about whether a question was graded correctly are handled through your institution’s academic-appeals process.
• We do not adjudicate student record requests directly and are not authorized to release, amend, or confirm education records to students outside an institution-initiated process. Direct questions to your institution’s registrar or your instructor.

7.7 Solo and individual-instructor accounts

FERPA applies to educational agencies and institutions. Many RavenGrader accounts are created by individual instructors, TAs, or graders acting independently, without a formal agreement between their institution and RavenGrader. When you use RavenGrader on your own (not under an institutional contract and not as an authorized agent of a FERPA-covered institution for this purpose), the school-official exception does not, by itself, extend to RavenGrader through your individual use. In that case, our handling of the student data you upload is governed by our contractual commitments to you in this Policy and by applicable state law. In either context our substantive commitments are identical (we use student data only to provide the Service; we do not sell it or use it for advertising); the distinction affects the legal mechanism, not the safeguards. Because the research use described in Section 3 requires an institution’s written authorization, and a solo-instructor account has no contracting institution, coursework uploaded through a solo-instructor account does not enter our grading-model research corpus at all. If you are an individual instructor, you are responsible for determining whether you have authority to upload student work and whether your institution requires use of only institutionally contracted tools or any student consent. We do not verify institutional affiliation at signup.

7.8 Institutional agreements and data return/destruction

Institutions may execute a separate Data Processing Agreement / FERPA Addendum (DPA)with us governing use, re-disclosure, security, deletion, and (where applicable) data return or destruction upon termination. Upon termination and on written request, we will make available an export of the institution’s education records and, on request, delete them and the corresponding stored files and provide written confirmation of destruction, currently through a manual process given the deletion limitations disclosed above. To establish institutional terms, contact williamtjandra@ravengrader.com or christopherlauw@ravengrader.com.

7.9 No waiver of FERPA rights

RavenGrader does not require, and has never required, students or parents to waive any FERPA right as a condition of having coursework processed through the Service. Students are not parties to these terms and do not create accounts; our authority to process their records derives from the school-official relationship (or, for solo instructors, from our agreement with the instructor and applicable law), not from any student consent or waiver.

8. Your Rights and Choices

Depending on where you live, you may have rights to access, correct, delete, port, or restrict processing of your personal information, and to opt out of certain processing. We extend the core choices below to all account holders. State- and region-specific rights are in Sections 9 (California), 10 (other U.S. states), and 11 (EU/UK).

Account-holder data (you). As the controller of your own account data (email, display name, billing references, your courses/exams and grading history), you may request: access/portability (a copy of your personal account data); correction; deletion of your account; and withdrawal of consent. When we delete your account, the associated database records (your profile, courses, exams, submissions, grading results and runs, audit entries, credit balance, and credit ledger) are deleted, and the associated uploaded files are removed from our storage service by the same automatic process (see Section 5 for the 30-day grace period and the limited billing records retained in de-identified form).

How to submit a request: two methods. You may (1) email williamtjandra@ravengrader.com or christopherlauw@ravengrader.com from the address associated with your account, including the right you wish to exercise; or (2) submit a request through the contact form at ravengrader.com, noting your request in the message. We may verify your identity before acting. We currently fulfill all rights requests manually and aim to respond within 45 days; if we need more time we will tell you within that period.

Student data. If your data was uploaded by an institution or instructor (for example, your coursework as a student), those records are controlled by the institution or instructor. Direct access, correction, and deletion requests to them; we will cooperate in fulfilling such requests. We do not honor student-submitted deletion requests for education records directly, because doing so without institutional authorization could itself violate FERPA.

Transactional emails. We do not send marketing email, so there is no marketing list to unsubscribe from. Service and account emails (such as grading-complete notices) are necessary to operate the Service.

9. California Privacy Rights (CCPA/CPRA)

This section applies to California residents.

9.1 Categories of personal information collected (last 12 months)

Within the meaning of Cal. Civ. Code § 1798.140, in the past 12 months we have collected:

• Identifiers: instructor/TA/grader email, display name, internal account UUID, Stripe customer ID; student names and Canvas user IDs (received from instructors or Canvas); first-party session cookies. IP address is read transiently for rate-limiting and not stored in a persistent profile.
• Customer-records / commercial information: Stripe customer/payment-method/subscription IDs, subscription status, page-credit ledger and billing-event records, and cancellation feedback. No raw card numbers.
• Internet/network activity: Sentry error events, performance traces, backend profiling, forwarded logs, and Session Replay; in-app audit-log entries (action type, resource IDs, limited metadata such as file count or Canvas user ID; browser-recorded diagnostic entries additionally include user-agent and connection-quality readings — see Section 1); application server logs.
• Audio/visual/electronic: student submission files (handwritten images, PDFs, text) and answer-key files, stored privately and sent to xAI, Google, and OpenAI for transcription/grading, and answer-key and rubric text to Meta (Section 3).
• Education information (FERPA records): student names, submissions, transcriptions, per-question scores/feedback, total and curve-adjusted scores, and associated Canvas identifiers, processed on behalf of the instructor/institution (Section 7).
• Inferences: AI-generated per-question scores and feedback derived from submission content, used solely to deliver grading.

Sensitive personal information (SPI). The only SPI we collect from account holders is account log-in credentials(email and, for password accounts, a Supabase-managed hashed password we never see in plaintext; account holders who choose Sign in with Google authenticate through Google and have no RavenGrader-stored password). Student education records may reveal academic performance. We use SPI only to provide the requested Service and for no secondary purpose, so the Right to Limit does not apply to our current practices, and we do not post a “Limit the Use of My Sensitive Personal Information” link. We do not collect SSNs, precise geolocation, racial/ethnic origin, religion, biometric identifiers for identification, health, or sexual-orientation data.

9.2 Sources, business purposes, and recipients

We collect this information directly from you, from your institution’s Canvas LMS via LTI (student name and Canvas user ID), automatically through your use of the Service (diagnostic/usage data), and from Stripe (billing references). We use it for the business purposes in Section 2. We disclose it only to the service providers in Section 4 (Supabase, xAI, Google, OpenAI, Meta, Stripe, Sentry, Resend, Canvas, Railway, Vercel, MongoDB Atlas) to operate the Service. We do not sell personal information and do not share it for cross-context behavioral advertising.

9.3 Your California rights

You have the right to know (categories and specific pieces), delete, correct, opt out of sale/sharing (we do not sell or share, so there is nothing to opt out of, but you may submit a request to confirm), limit use of SPI (not applicable as explained above), and non-discrimination: we will not deny service, charge different prices, or provide a different level of service because you exercised a right.

Submitting and timing. Use either method in Section 8. We will acknowledge within 10 business days and respond within 45 calendar days, extendable once by up to 45 additional days with notice.

Authorized agents. You may use an authorized agent who provides either (a) your signed written permission or (b) a valid power of attorney under Cal. Probate Code §§ 4000–4465. For signed-permission requests we will verify the agent and confirm your authorization; for a valid power of attorney we will process upon verification. Send agent requests to williamtjandra@ravengrader.com or christopherlauw@ravengrader.com.

Notice at collection / Do Not Sell.This Section, together with Section 1, serves as our notice at collection. Because we do not sell or share personal information for cross-context behavioral advertising, we are not required to post a “Do Not Sell or Share My Personal Information” link; if our practices change, we will add the required mechanism before any such activity begins.

9.4 Automated decision-making (AI grading)

We use AI to assist grading; this section addresses California’s automated decision-making technology (ADMT) framework.

What we do.A multi-stage AI pipeline (xAI Grok-family, Google Gemini-family, and OpenAI GPT-5-family models, together with open-weight models for answer-key work; see Section 3) generates a rubric from the instructor’s answer key, transcribes student submissions, and scores them against the rubric, producing per-question scores and feedback. Where Canvas is integrated, an approved score can be written to the gradebook, which can affect a student’s academic record.

Human review.No AI-generated grade reaches a student without a human decision to send it. Before grading begins, the instructor must approve the AI-generated rubric, and they may first calibrate the grader by grading a sample of papers themselves. After grading, the instructor can view the per-question breakdown and the evidence behind each score, and can edit any score. Grades are released to students and written to the Canvas gradebook only when the instructor takes an explicit “Release Grades” action (which requires an instructor Canvas role), or emails a student their report. For transparency, and importantly: the system does notrequire the instructor to open or confirm each submission first, and the release step publishes every graded submission for the assignment. Whether any individual paper was read by a person before release is therefore the instructor’s choice, not something the product enforces. The instructor has full authority to edit any score before or after release.

Pre-use notice, opt-out, and appeals.Your instructor or institution is responsible for notifying you before your work is processed. Because we act at the institution’s direction, students who wish to opt out of AI-assisted grading, or to appeal a grade, should contact their instructor or institution (which can grade manually and can edit any score); we will honor opt-out and correction requests communicated to us by the instructor or institution, and you may also write to williamtjandra@ravengrader.com or christopherlauw@ravengrader.com and we will coordinate with the relevant party. We do not currently provide a student-facing in-app opt-out or appeal mechanism.

9.5 Narrow scope of the FERPA exemption

CCPA exempts FERPA-covered education records from most of its requirements, but that exemption is narrow. Your instructor/TA/grader account data, billing data, platform usage and diagnostic data, and contact-form communications are fully subject to CCPA/CPRA and may be the subject of the requests above. The FERPA exemption reaches only the student education records we process as a service provider on behalf of an institution.

10. Other U.S. State Privacy Rights

Residents of Virginia, Colorado, Connecticut, Texas, Oregon, Delaware, and other states with comprehensive privacy laws (VCDPA, CPA, CTDPA, TDPSA, OCPA, DPDPA, and similar) have rights to confirm/access, correct, delete, and obtain a portable copy of personal data, and to opt out of the sale of personal data, targeted advertising, and profiling that produces legal or similarly significant effects. We do not sell personal data, conduct targeted advertising, or perform such profiling, so those opt-outs are already satisfied. The categories of data we collect, the recipients we disclose to, and the request methods are described in Sections 1, 4, and 8.

For student data we process as a processor/service provider on behalf of an institution or instructor, direct rights requests to that institution or instructor; we will assist them.

Sensitive data.We do not process the categories of “sensitive data” defined under these laws (precise geolocation; racial/ethnic origin; health; genetic or biometric data for identification; religious beliefs; sexual orientation; immigration status), so no separate opt-in consent is required.

Response and appeal. We respond to verifiable requests within 45 days (extendable once by 45 days). If we decline a request, we will explain why; you may appeal by emailing williamtjandra@ravengrader.com or christopherlauw@ravengrader.comwith “Privacy Rights Appeal” in the subject line, and we will respond within 60 days. If your appeal is denied, you may contact your state attorney general’s consumer-protection office.

Oregon residents may additionally request a list of the specific third parties to which we have disclosed personal data; based on the flows in this Policy these are the recipients named in Section 4.

11. EU/UK Data Protection (GDPR / UK GDPR)

Where the GDPR or UK GDPR applies (for example, a contracting institution established in the EU/UK, or a student located in the EU/UK), the following applies. Our infrastructure and subprocessors are in the United States, so such processing involves an international transfer.

Our role. For student education records processed on behalf of an institution or instructor, RavenGrader is a processor(GDPR Art. 4(8)) acting on the controller’s documented instructions; the institution or instructor is the controller. For instructor/TA/grader account data, RavenGrader is an independent controller.

Article 28 DPA. Institutions and instructors may request a DPA compliant with GDPR Article 28; contact williamtjandra@ravengrader.com or christopherlauw@ravengrader.com.

Lawful basis (where we are controller of account data). Contract performance (Art. 6(1)(b)) for account and billing; legitimate interests (Art. 6(1)(f)) for security, fraud prevention, and error monitoring/diagnostics (including Sentry telemetry and Session Replay, which we have assessed against your interests and disclose as a known residual-risk channel in Section 1); and legal obligation (Art. 6(1)(c)) for financial-record retention.

International transfers.Our subprocessors are US-based, except that Google’s Gemini processing is served from a global endpoint (Section 3). We rely on the EU-US Data Privacy Framework (and UK Extension) where a subprocessor is certified, and otherwise on the European Commission’s Standard Contractual Clauses and, for the UK, the IDTA/UK Addendum. Transfer documentation is available on request. We have not yet appointed an Article 27 EU/UK representative; this is being addressed before we serve EU/UK users as a controller.

Data-subject rights. Where we are the controller of your account data, you have rights of access, rectification, erasure, portability, restriction, and objection; email williamtjandra@ravengrader.com or christopherlauw@ravengrader.com. We aim to respond within 30 days (extendable for complex requests). Where we are a processor, direct requests to the controlling institution/instructor; we will assist. You may lodge a complaint with your local supervisory authority (in the UK, the ICO).

12. Cookies and Tracking Technologies

We use a small number of first-party and limited third-party technologies. We do not use advertising cookies, cross-site behavioral-tracking cookies, or third-party analytics pixels.

• Session authentication cookie (Supabase, first-party): keeps you signed in; strictly necessary. Because our authentication library reads the session in the browser, this cookie is accessible to our page scripts (it is not HttpOnly); the Service is served exclusively over HTTPS, so the cookie is transmitted encrypted. Disabling it prevents sign-in.
• Error monitoring and Session Replay (Sentry): as described in Section 1, replay is active for ~10% of sessions and 100% of error sessions, with all text, inputs, and media masked or blocked so on-screen student information is not recorded; it is used solely for diagnostics, not advertising.
• Payment (Stripe): Stripe’s embedded checkout component may set its own cookies/storage for fraud prevention and checkout state when you initiate a purchase.
• Google Fonts (marketing landing page only): loads a font from Google’s CDN, sending your IP and user-agent to Google on that page only (Section 4).

Because the authenticated Service uses only strictly necessary first-party cookies plus the diagnostic technologies above, we do not currently display a general cookie-consent banner. Note that the Session Replay technology is non-essential; users with concerns may contact us to request that replay be disabled for their account, or may block the Sentry domain in their browser.

13. Do Not Track and Global Privacy Control

Do Not Track (DNT). Because there is no consistent industry standard for DNT signals, we do not respond to them. We do not perform cross-site tracking or behavioral advertising in any case.

Global Privacy Control (GPC). We acknowledge GPC signals. Because we do not sell personal information or share it for cross-context behavioral advertising or targeted advertising, there is no processing activity for a GPC signal to limit, and honoring it requires no change to how we handle your data. If we ever begin selling or sharing personal information, we will implement GPC detection and honoring within the time required by applicable law before doing so.

14. Children’s Privacy and COPPA

RavenGrader accounts are intended for educators (instructors, TAs, and graders), who are adults; we do not knowingly allow individuals to create accounts directly, and we do not knowingly collect personal information directly from children under 13 through registration or any direct interaction. Students do not create accounts and submit work through their institution’s tools.

Some coursework processed through the Service may belong to minors, including, in dual-enrollment contexts, students under 13. We process that data solely on behalf of, and at the direction of, the educator or institution under Section 7, not for our own purposes, not for advertising, and not to build profiles of students. We commit that coursework belonging to students under 13, and coursework from courses an institution identifies as K-12 or dual-enrollment, is not used for the grading-model improvement described in Section 3.Stated plainly about how that is enforced today: research ingest is gated on an institution having affirmatively authorized research use, and every ingest additionally requires a named reviewer and a recorded basis, so this is a procedural and contractual control rather than an automated age filter — we do not collect student ages or grade levels and therefore cannot screen on them automatically. We ask institutions to exclude K-12 and dual-enrollment courses when granting that authorization, and we are adding a technical control to enforce the exclusion directly; we will update this statement when that ships rather than before. Where the Children’s Online Privacy Protection Act (COPPA) applies, we rely on the school-authorization approach described in the Federal Trade Commission’s COPPA guidance for education technology, under which a school may authorize collection from a child where the information is used for the school’s educational purpose and for no other commercial purpose (the mechanism is set out in FTC guidance rather than in the text of 16 CFR § 312.5): the institution, not RavenGrader, is responsible for obtaining any required parental consent. Educators and institutions are responsible for any consents and notices required under FERPA, COPPA, and applicable state law before uploading student data. For minors aged 13–17 enrolled in post-secondary courses, FERPA rights vest in the enrolled “eligible student.” State student-privacy statutes such as California’s SOPIPA apply by their terms to services designed and marketed for K-12 school purposes rather than to every service a minor’s work may pass through; regardless of whether they reach us, we make their core commitments — no commercial use, no advertising, no student profiling — for all student data. If you are a parent who believes a child’s information was collected without proper consent, contact williamtjandra@ravengrader.com or christopherlauw@ravengrader.com and we will review and, where required, delete it.

15. No Sale of Data; No Targeted or Behavioral Advertising

RavenGrader does not sell personal information (student education records, instructor account data, or anything else) and does not share personal information for cross-context behavioral advertising, as those terms are defined under CCPA/CPRA and other state laws. We do not use advertising trackers, analytics pixels, or marketing tags; we do not share IP or device identifiers with advertising networks or data brokers; and we do not use any data to build advertising profiles of students or instructors. We do not send product recommendations, marketing campaigns, or surveys to students, and we do not use student data for marketing purposes or to develop any product other than the educational grading service the institution engaged us to provide, consistent with FERPA, SOPIPA-style state student-privacy commitments, and PPRA’s exception for developing, evaluating, or providing educational products or services (20 U.S.C. § 1232h(c)(4)(A)). Our use of student-derived data to improve the grading models is described in Sections 3 and 7.3. Our only outbound emails are transactional grading-completion notices to instructors and relays of voluntary contact-form messages.

For higher-education institutions handling student financial-aid data subject to the GLBA Safeguards Rule (16 CFR Part 314), RavenGrader operates as a downstream service provider, maintains the safeguards described in Section 6 (subject to the disclosed gaps), and will, on request and under a written agreement, provide additional information to support the institution’s vendor-oversight obligations.

16. Security Incidents and Breach Notification

Despite the safeguards in Section 6, no system is perfectly secure. If we discover a security breach affecting your personal information, or student education records we hold on behalf of an institution, we will:

• Investigate and assess the incident and the data and accounts affected.
• Notify the controlling institution (at its designated contact) without undue delay, and within the timeframe required by applicable law. These clocks run from our discovery of the breach, not from the completion of our investigation — for example, within 72 hours of discovering a reportable breach, or within 7 calendar days of discovery for customers subject to New York Education Law § 2-d — so the institution can meet its own notification obligations to students, parents, and regulators. We notify on discovery even where our assessment is incomplete, rather than delaying notice until the picture is settled. We will describe, to the extent then known, the nature of the incident, the categories and approximate number of records involved, likely consequences, measures taken or proposed, and a contact point, supplementing as our investigation progresses.
• Notify standalone instructor account holders at their account email within the timeframe required by applicable law.
• Notify regulators (state attorneys general or other authorities) where and within the timeframes that applicable law requires.

RavenGrader acts as a service provider; the institution or instructor is responsible for notices owed directly to students or parents, and we will cooperate. To report a suspected security issue, contact williamtjandra@ravengrader.com or christopherlauw@ravengrader.com.

17. International Users and Data Location

RavenGrader is operated from, and stores data in, the United States. Our primary storage is on Supabase (AWS US-East-1); OpenAI processing uses OpenAI’s US API; xAI and Meta processing uses those providers’ US APIs, and any open-weight model we run ourselves runs on our own US-based backend hosting; and our application is hosted on Railway (backend) and Vercel (frontend), both US-based. One exception (disclosed):Google’s Gemini processing is served from Google’s global endpoint and may transiently occur outside the United States; no content is stored at rest by Google (see Section 3). If you access the Service from outside the United States, your information will be processed in the United States, where data-protection laws may differ from those in your jurisdiction. We do not currently offer a non-US data-residency option; institutions with residency requirements should contact us before deploying.

18. Changes to This Policy

Every published version carries an effective date and a last updated date (shown at the top). Prior versions are available on request.

• Non-material changes (clarifications, contact updates, corrections that do not expand how we use your data): we update the “last updated” date and post the revised Policy.
• Material changes (new categories of data, new purposes, new subprocessors receiving personal data, or any expansion of data sharing): we will provide notice by email to your account address and a prominent in-app notice at least 30 days before the change takes effect, and we will give institutional customers at least 30 days’ advance written notice of changes affecting student-data processing so they may object or terminate before the change takes effect.
• Material expansions of data use (for example, using content or student submissions to train AI models, selling or licensing data, or using data for advertising): we will provide the advance notice above and obtain affirmative opt-inbefore applying the new use to existing data; for student education records, we will obtain the controlling institution’s prior written authorization. Continued use after the notice period will not, by itself, constitute consent to a material expansion. For clarity, we do not currently use your content or student submissions in identifiable form to train AI models, and any change to that will follow this opt-in process. Our use of de-identified and aggregated data to improve the Service (Section 3) does not involve your personal information and is not such an expansion.

19. Who We Are and How to Contact Us

RavenGrader, Inc. is responsible for this Policy and the Service. For account data we act as an independent controller; for student education records we act as a processor / service provider / FERPA school official, processing solely on behalf of and at the direction of the institution or instructor (see Section 7). We have not designated a formal Data Protection Officer; privacy inquiries, rights requests, and institutional DPA requests should be directed to:

RavenGrader, Inc.
Email: williamtjandra@ravengrader.com or christopherlauw@ravengrader.com