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.
- Source documents cleared by default. Opt-in storage is capped at 7 days, then auto-deleted.
- Your contracts are never used to train AI models.
1. 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.
Documents you elect to store, and every analysis result in your account, are held at rest with server-side encryption (AES-256) inside our managed database and storage provider. Authentication runs through Supabase Auth.
2. Retention & deletion
By default, the document you upload is not stored after your analysis completes. It is processed and then removed. If you opt into temporary document storage, it is encrypted, held for your elected period up to a maximum of 7 days, and then deleted automatically. You can delete a stored document, an individual analysis, or your entire account at any time.
| Data type | Default retention |
|---|---|
| Uploaded documents (default, no opt-in) | Deleted upon completion of the analysis pipeline |
| Uploaded documents (opt-in storage) | Your selected period, maximum 7 days, then auto-deleted |
| Analysis output (scan results) | Until you delete the scan or your account |
| Account information | Until account deletion |
When you delete your account, we remove your stored documents from our storage provider and delete your scan history, profile, and account record. 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).
3. Your documents are not used to train AI models
Your contract text is transmitted for one purpose: producing your analysis. 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.
Separately, we may de-identify and anonymize analysis inputs and outputs for internal product development, model evaluation, and quality benchmarking. That process strips all personally identifiable information, party names, contract values, and other identifying details before the data is used. It never identifies you or your contract, and it is never sold, licensed, or shared with third parties.
4. 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.
Serves the web application and runs the serverless analysis functions
Persistent storage of account data and analysis results, opt-in encrypted document storage, 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 anonymized usage events used to improve the product
Generates your Analysis Output; no provider uses submitted contract text to train its models
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 [email protected].
5. 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 scans, your analysis output, and your stored documents are only ever reachable by your account.
Analyses are scoped per scan as well as per account, so a report is retrievable only by the session that created it. Internal access to production data is limited to what is required to operate and support the Service.
6. Responsible disclosure
If you believe you have found a security vulnerability in BeforeJD, email [email protected] 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: [email protected].
Our disclosure contact is also published in machine-readable form at /.well-known/security.txt.
7. 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.
8. 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 in section 6.
A written business continuity and disaster recovery procedure exists, and it has been rehearsed against restored production backups, with the rehearsal and its acceptance criteria recorded on a dated internal record.
The full documents are available to reviewers on request.
9. 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
No sealing certificate has been issued yet. Documents executed before one exists carry the certificate of completion and the recorded hash, and state plainly on their last page that they carry no cryptographic seal.
The 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 unrecognised. 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.