Privacy and data handling

Uploaded resumes and applications are analyzed solely to produce the reviewer's report: claim extraction, evidence checks, findings about material inflation, and evidence-bounded restatements. The analysis exists for the reviewer who requested it, and for the applicant it is about, and no one else.

To send the notices the law requires, Gram needs a way to reach the applicant. It takes the applicant's email address from the same place the document came from: the candidate record in a connected ATS, the respondent address on a Google Form, or the address the reviewer enters (or that appears in the contact block of the document) at upload. Gram does not ask the applicant for additional screening data; an applicant may choose to send a dispute statement and supporting evidence. The address is used only for the notices described on the applicant rights page: the disclosure and authorization request, reminders, notice that a report was furnished, a copy of the report when one is requested, pre-adverse and adverse-action notices, and correspondence about a dispute.

The address is encrypted at the application layer before storage, with a one-way hash stored beside it so it can be looked up without being read. Reviewers see it masked in the app; it does not appear in logs, in exports, or in the report itself; and it is never used for marketing or given to anyone except the email provider that delivers the notice.

Every applicant a report is about has the right to know a report was furnished and to whom, to receive a free copy of it, to dispute anything in it and have the dispute reinvestigated, and, before an adverse decision is made on the basis of it, to receive the report and a summary of their rights with time to respond. Where the report is for employment, the applicant is asked to authorize it first, and can decline. The applicant rights page explains each of these and how to exercise them; the short version is to write to disputes@nolarping.com.

Documents and their reports are stored so the reviewer can return to them. Accounts keep reviews until the reviewer deletes them unless the reviewer selects 30-day or 90-day automatic deletion in Settings. The selected window runs from each review's creation date and applies to existing reviews as well as new ones. Integration credentials (ATS API keys, Google tokens) are encrypted at the application layer before storage. Deleting a review purges its documents, reports, and queued work, with the exception described in the next section.

A consumer reporting agency has to be able to show, long after a report is gone, that the applicant was told, that they authorized it, what was sent to them and when, what they disputed and how it was resolved, and what adverse action followed. So Gram keeps a separate compliance record — consent and authorization records, every notice sent to an applicant, disputes and their outcomes, and adverse-action records — that is not deleted when the review is, when the reviewer's retention window runs out, or when a workspace uses the account-wide purge. Those records hold the applicant's name and encrypted email address, the review identifier, the notice text, and the dispute correspondence; they do not hold the document or the report, which go with the review. While a dispute is open, an adverse-action process is active, or a required report email is queued or sending, the affected review and report are temporarily held. They become deletable when that process closes or the delivery finishes.

Consent and notice records are kept for five years from creation. Closed disputes use their resolution date, and adverse-action records use their last status transition; open or active processes are not aged out. Eligible records are then purged on their own schedule. Five years is the outer limit for bringing a claim under the FCRA, and a record that cannot be produced in that window protects neither the applicant nor the reviewer.

[COUNSEL: confirm the five-year figure against §618's two-years-from- discovery / five-years-from-violation limits and any state retention rule, and confirm that compliance records may survive an account's deletion request under the state privacy laws that grant a right to delete.]

After a report is furnished, the applicant's file page may offer to keep a copy of it in a record of their own. This is optional, separate from any authorization the applicant gave, and nothing about the report, the organization's decision or the applicant's rights changes if they decline; nothing is recorded about a decline. The offer is made only after the report, never on the authorization page.

A kept record holds the furnished report (the statements checked, the findings, the sources cited), the outcome of any dispute, the applicant's name and encrypted email address, and the consent text as they read it. It is keyed to the applicant, not to the organization's review: the organization deleting its review, its retention window running out, or its account-wide purge leave the applicant's copy in place. If a rerun or a dispute changes the report, the kept copy follows it, so a corrected finding reaches the applicant's record and a withdrawn one does not travel on.

The record is reached by a link emailed to the applicant, valid for seven days and re-sent on request to that address alone; there is no account and no password. It is shown to no one else. The applicant can delete it at any time from that page, immediately and completely; a record not opened or added to for two years is deleted automatically. Deletion does not remove the compliance records described above or the organization's own copy of the report. Kept records are not read for model improvement; that capture happens only from the reviewer's workspace, as described in the next section. This feature is enabled per deployment and may not be offered.

When a reviewer keeps, dismisses, or files feedback on a finding, Gram keeps that finding — the claim as written, the applicant details the check was given, the evidence it cited, the verdict and restatement it produced, and the reviewer's response — to improve its own models. This is on by default and each workspace can turn it off in Settings. Turning it off stops collection from that workspace and does not remove what was already collected; erasing the workspace's data or deleting the account does remove it. The model API Gram calls does not train on anything sent to it, per its provider terms.

Analysis makes exactly two kinds of outbound requests: calls to the model API that performs the restatement, and public-records lookups (such as scholarly indexes and code-hosting sites) whose queries are derived from individual claims. Separately from analysis, Gram sends the applicant notices described above through a transactional email provider. No document leaves the system in any other way.

The service providers and connected systems that receive customer or candidate data in the current product are listed below. Public-source websites can also receive claim-derived search terms and ordinary request metadata when Gram checks evidence.

• OpenAI— the model API behind extraction, claim checking and the server-side web search those checks run. It receives document text and claim text, and, for a claim about a person, the candidate's name and identifying anchors as search vocabulary — so candidate names do appear in web-search queries.
• SendGrid (Twilio) — delivers the applicant notices. It receives the applicant's email address, the notice text, and, when a notice carries one, the report as an attachment. It receives nothing about applicants who are never emailed, and its delivery events (delivered, bounced) are recorded against the notice, not the person.
• Clerk — authentication. Reviewer account identity only; no candidate data.
• Microsoft Azure — hosts the API, the analysis workers and the database, so everything Gram stores rests there.
• Vercel — hosts this site and the app; sees request metadata, and candidate data only in transit.
• Google— only when a reviewer connects a Google Form, whose questions and responses (applicant answers and any attached files) are read under read-only Forms scopes, plus the reviewer's own email for display.
• Stripe — billing details only; no documents and no candidate data.
• Sentry — optional browser error reporting when a deployment configures it. It receives exception and page context with default PII collection disabled; session replay and performance tracing are not enabled.
• A connected ATS — an integration the reviewer owns. Candidates and attachments are read with the key they supply; nothing is written back.
• Public-source hosts — scholarly indexes, code-hosting sites, and source pages consulted during a check receive the query or URL needed for that lookup and ordinary network request metadata.

Deleting a review removes its documents, reports and queued work at once. Settings also offers an account-wide purge that erases every review, document and report held under the account and removes every stored integration credential, while leaving the account itself intact so the reviewer stays signed in. Neither is reversible, and neither removes the compliance records described under “Records we keep longer”, which go only on their own clock.

Transport, storage, credential encryption, prompt-injection handling and what Gram is not certified for are described on the security page.

Questions about data handling: nathan@nolarping.com. Applicants with a question or dispute about a report: disputes@nolarping.com.