How we handle your contract.
You are handing over something you would not want loose in the world. Here is exactly what happens to it: how it is encrypted, how long it is kept, who touches it, and how to reach us if something looks wrong.
- TLS in transit, AES-256 encryption at rest.
- Every uploaded file is deleted seven days after the read. The report stays until you delete it.
- Your contracts are never used to train AI models.
Encryption, in transit and at rest
Every connection to BeforeJD™, from the moment your browser or the iOS app opens a session, runs over encrypted transmission (TLS 1.2 or higher). Nothing you upload or read back crosses the network in the clear.
Stored files, every analysis result in your account and the contracts you keep are held at rest with server-side encryption (AES-256) inside our managed database and storage provider. Authentication runs through Supabase Auth.
Where your data lives
BeforeJD serves customers in the United States only. The servers that run the web application are in Oregon. Your account data, reports and stored files are held in a database and storage service, also in Oregon. A backup copy of stored files is held by our backup provider, in a location that provider sets.
When a read runs, the text of your contract is sent to our AI processing partners for that read. They run their own infrastructure under their own data-protection terms, so where a partner processes a request is its choice and not ours. We can name each provider and its terms to a customer under a nondisclosure agreement.
Retention & deletion
Every file you upload for a read is stored, encrypted, for seven days after the read, and is then deleted automatically by a nightly job. The report, which contains the full text of the contract as read, stays until you delete the analysis or your account, and deleting an analysis also deletes its stored files. A contract you keep in Contracts stays until you delete it or your account. You can delete a stored file, an individual analysis, a kept contract or your entire account at any time.
| Data type | Default retention |
|---|---|
| Uploaded files (every upload) | Seven days after the read, then deleted automatically |
| Contracts you keep in Contracts | Until you delete them or your account |
| Analysis output (the report, including the full contract text as read) | Until you delete the report or your account |
| Organization audit log (organizations only): who acted, and what was asked and returned | At least one year by default, or the period an administrator of the organization sets, up to seven years. Content a member deletes leaves the log with it; the record that the event happened stays for the retention period. |
| Account information | Until account deletion |
When you delete your account, we delete your analyses and the reports they contain, your drafts, the contracts you kept with their search index, your profile and your account record, and remove the files stored for all of them from our storage provider. An organization you created passes to its longest-standing remaining administrator, then member, then viewer. Completed signing records are kept as the record of the agreement for every party to it, as our Privacy Policy describes. Any remaining personal information is deleted or anonymized within 30 days, except where we are required to retain it for legal or compliance purposes (for example, payment transaction records, which financial record-keeping rules require us to hold for 7 years).
Your documents are not used to train AI models
Your contract text is transmitted only to provide the features you use: your analysis and redline, a contract you ask us to draft, search and questions about a contract you keep, and our automated quality checks on those outputs. We do not use uploaded documents, or the analysis generated from them, to train our AI models, and we do not sell, rent, or share your information for third-party advertising. Our AI processing partners do not use your submitted contract data to train their models either.
We never use the text of your contracts to train models or to build benchmarks. We may review results to test and improve the quality of our own service. We also use aggregate, non-identifying measurements, for example how long a read took or how many findings it had. Those measurements never identify you or your contract, and they are never sold or licensed.
Subprocessors
BeforeJD relies on a small set of infrastructure and service providers to run the product. Each is bound to use your information only to provide its service to BeforeJD, never for its own independent purposes.
Updated October 22, 2026: we are adding error monitoring (Sentry) that receives only technical error reports. It takes effect November 6, 2026.
Serves the web application and runs the serverless analysis functions
Persistent storage of account data, analysis results, uploaded files for seven days and the contracts you keep, and account authentication
Processes payments; BeforeJD receives transaction metadata only and never stores full card numbers
Sends transactional email: analysis delivery, receipts, account notifications
Powers the spoken Q&A feature for account holders who use Contract Assistant
Collects usage events, and session recordings of our public website only, used to improve the product. Never loaded for a browser that sends Global Privacy Control
Receives technical error reports from our website and servers: the kind of error, where in our code it happened, the page path and the browser or server software. A report contains only technical details like these: no contract text, nothing you type and no personal details. Hosted in the United States. Starts November 6, 2026.
Generates your Analysis Output; no provider uses submitted contract text to train its models
Sits in front of beforejd.ai to absorb denial-of-service traffic and to run the bot challenge on our forms, and holds a backup copy of stored files, drafted contracts and signing records for disaster recovery
Converts an uploaded PDF into an editable document so that we can prepare your redline
Sends signing verification codes to a signer's mobile phone
Records purchases made through the App Store in our iOS app
We may add, replace, or remove subprocessors over time, provided any replacement is held to contractual obligations at least as protective as those above. Questions about a specific provider: email info@beforejd.ai.
Access & isolation
Every table in our database enforces row-level security, a policy layered into the database itself rather than application code we could get wrong, scoping each row to the account that owns it. Your reads, your analysis output, and your stored documents are reachable only by your account and, when they belong to an organization, by that organization's members.
Every request for a report is checked against the account that owns it, and reads that belong to an organization are also open to its members. Internal access to production data is limited to what is required to operate and support the Service.
You can sign in with a passkey, a password, an emailed sign-in link, or an Apple or Google account. Authenticator-app two-factor sign-in is built and is enforced for any account that enrolls, but enrollment is not yet open to customers. We will say so here when it is.
Responsible disclosure
If you believe you have found a security vulnerability in BeforeJD, email info@beforejd.ai with what you found and, if you can, the steps to reproduce it. We investigate every report and will follow up with you directly. Please give us the chance to address an issue before disclosing it publicly.
If you believe your own account has been compromised, or you have any other privacy or security question, that same address reaches us: info@beforejd.ai.
Our disclosure contact is also published in machine-readable form at /.well-known/security.txt.
The full legal detail
This page is a plain-language summary. The governing terms live in our Privacy Policy and Terms of Use. If anything here ever reads differently from those documents, the Privacy Policy and Terms govern.
Our security practices, in writing
Reviewers at larger customers often ask for the documents behind this page. They exist, and these are their summaries.
A written security overview describes how the service protects documents: encryption on every connection and at rest, tenant isolation enforced at the database layer rather than in application code alone, and security guards that are validated by confirming they fail against a deliberately broken state before they are relied upon.
A written incident response plan defines how we detect, contain, and disclose a security incident, and who is accountable for each step. Reports reach us at the address given under Responsible disclosure.
A written business continuity and disaster recovery procedure exists. We have rehearsed restoring our database structure and security rules into a clean environment and confirmed that one customer still cannot read another's data, with the rehearsal and its acceptance criteria recorded on a dated internal record. A rehearsal that restores backed-up customer data has not yet been performed.
The full documents are available to reviewers on request.
Certifications and independent audits
BeforeJD does not hold a third-party security certification or audit report today. No independent penetration test has been performed. We say so here because you are entitled to the current state, and because a badge we have not earned would be worse than none.
What we offer instead is evidence you can read: the written practices, the retention table and the subprocessor list above. When an independent audit begins or finishes, this page will say so.
If your organization needs an independent attestation before it can buy, tell us early. It changes the timeline, and we would rather plan it with you than promise it.
How to verify a BeforeJD document
Every document executed through BeforeJD carries a certificate of completion. Documents executed after a sealing certificate was issued also carry a cryptographic seal. The seal is what lets a person who was never a party to the agreement confirm, without asking us, that the file in front of them is byte for byte the file that was signed.
- 1. Open the file in a reader that understands document signatures
The reader shows a signature panel. It reports whether the signature is intact and names the certificate that produced it. If a single byte of the document has changed since it was signed, the panel says so.
- 2. Compare the fingerprint
The last page of the certificate of completion prints the fingerprint of the sealing certificate. Compare it with the fingerprint published on this page. If the two do not match, the document was not sealed by BeforeJD, whatever the reader says about the signature being intact.
- 3. Check the recorded hash
The delivery email for every executed document states the SHA-256 of the file it carried. Computing the hash of the file you hold and comparing the two is a check anyone can run with the tools already on their computer.
Sealing certificate fingerprint, SHA-256
98ba2e1cf2efc83e640595560db8efc5f5994414e210c124465b32bb8b4e009b
Download the public certificateThe sealing certificate is issued by BeforeJD itself rather than by a commercial certificate authority. A reader may therefore show the signature as intact and the issuer as unrecognized. That wording is about who vouches for the issuer, not about whether the document was altered, and a single changed byte invalidates the seal either way. We will move to a commercially rooted certificate when a customer needs their reader to show a check mark without comparing fingerprints.