What happens to your tender documents
Last updated 27 August 2026. This describes how the system actually works today, not a boilerplate template. It is rewritten whenever the system changes, and it is checked against the code rather than from memory.
Where SpecBrief runs
Three separate places, and they are worth keeping apart in your head.
- The app runs at
specbrief.onrender.com, hosted on Render. That service sits in Render's Oregon region, in the United States. Anything the app processes is processed there. - Your account — the firm, its seats, its plan and its usage counters — lives in a Postgres database hosted by Supabase in Sydney, Australia (
ap-southeast-2). The app refuses to serve without it rather than fall back to a copy that a restart would wipe. - Your finished brief is written to that same Sydney database. If it is unreachable, SpecBrief writes the brief to temporary storage on the app host instead, so your download link still works. Either way the expiry below still applies.
- This page and the marketing site are static files on Vercel. They hold no documents, set no cookies, and run no analytics.
So: processing happens in the United States, and the brief is stored in Australia. If Australian-only processing is a condition of your work, say so before you send anything and you will get a straight answer about whether SpecBrief can meet it today.
What SpecBrief collects
- Your tender documents (PDF, Word, Excel), so SpecBrief can put your brief together.
- Contact details you give through the enquiry form: your name, work email, and what you are tendering. So we can get back to you.
- Your account details: email address, firm, seat role, plan and usage. Passwords are stored only as salted hashes, not as readable passwords.
SpecBrief does not need sensitive personal information. Tender packs can still contain names, signatures, email addresses and phone numbers as part of the job. Please do not add personal information that the pack does not need.
The app sets one session cookie once you sign in. It keeps you signed in and protects the forms against cross-site posting. There is no advertising cookie and no third-party tracker on any SpecBrief page.
How your documents get read
SpecBrief reads each document's text. Drawing-image reading is off in production today, so no drawing page image is sent to a vision provider. That is what your brief gets built from. Every number in it — carbon-cap feasibility, volumes, conflict checks — is worked out in SpecBrief's own code. None of that is asked of the AI model. The model reads. The code calculates.
gemini. This page previously named a different provider and said no model was connected; both were out of date and were corrected on 26 August 2026. The section below is the one that governs.No customer document has been sent to the model from the live service. Unlike the sentence above, that one is not something this page can prove to you:
/healthz reports which provider is configured, not what has been read. It is a statement by SpecBrief, true as at 26 August 2026, and it will be taken down the day it stops being true rather than quietly left standing.Your document text is sent to the Gemini API. SpecBrief uses the API on a billed account, not a consumer chat app, and that distinction is the whole point — Google's terms for its two tiers are opposites. Google's own published terms say:
- On the paid tier, "Google doesn't use your prompts…or responses to improve our products" (Gemini API Additional Terms of Service, checked 26 August 2026).
- Google logs prompts and responses "for a limited period of time, solely for detecting and preventing violations of the Prohibited Use Policy", and for any required legal or regulatory disclosure. Google does not publish a maximum number of days for that logging, so SpecBrief cannot quote one. The previous provider did publish a figure; this one does not, and saying so is more useful than implying a number (same source).
- Google states that data "may be stored transiently or cached in any country". SpecBrief's own database and brief storage are in Sydney, but the model call is not, and a pack under an NDA should be assessed on that basis (same source).
- On the unpaid tier Google does the opposite: it uses submissions to improve its products, human reviewers may read them, and Google says plainly "do not submit sensitive, confidential, or personal information to the Unpaid Services". SpecBrief must therefore stay on a billed account for the paragraph above to hold — if billing lapsed and the key fell back to free quota, the no-training position would stop being true (same source).
That is Google's contractual commitment, not something SpecBrief's code can enforce. It is quoted here so you can read the source rather than take our word for it. If the provider ever changes, this page names the new one before a customer document is sent to it.
The sample brief
The sample and demo buttons on the marketing site take you off that site to specbrief.onrender.com/demo. Worth knowing what that is and is not.
- Nothing is uploaded. The demo runs over a fixed sample pack that ships with the app. There is no file picker and no document of yours involved.
- No AI provider is involved. The demo deliberately runs the real pipeline against the offline stand-in, which is why it works with no model key.
- It is generated on SpecBrief's server, not in your browser. The page it produces is stored like any other brief, under a random link, and clears after 24 hours.
Caching, so you are not billed twice
So an AI provider is not paid twice to read the same document, the extracted result is cached on the app server, keyed to that document's content. The cache holds extracted values, not your file.
There is no scheduled expiry on that cache. Nothing in the code deletes it on a timer, and this page will not pretend otherwise. What limits it instead is the host: the app runs with no persistent disk, so the cache lives on the instance's own temporary filesystem and is wiped every time the service restarts or redeploys. Nothing in it survives a deployment. If you want a specific document's cached extraction cleared sooner, ask and it will be cleared.
Storage & retention
- The raw file you upload sits in a temporary folder while SpecBrief processes it. That folder is deleted the moment the read finishes, and that is the default for every account.
- A pack larger than one brief covers gets quoted before it is read, and that means it waits on the server for your answer. The wait is capped at 30 minutes and applies to every account, including accounts that keep nothing. SpecBrief deletes the held copy when you continue, when you cancel, and when the 30 minutes run out.
- An account can choose to keep its packs, so a revised drawing can be run against the documents it supersedes. An admin turns that on and sets the period, up to a year. Any pack can be deleted from its brief at any time, and SpecBrief deletes it automatically at the end of the period. The switch sits on the Team page and starts off.
- Your generated brief stays up for 24 hours so you can get back to your download link. After that it will not open, and the stored copy is deleted. The window is checked every single time a brief is asked for, rather than being left to a scheduled sweep — so an expired brief is gone whether or not anything else has run since. A brief attached to a kept pack stays for as long as that pack. Want it gone sooner? Just ask.
- Your brief opens through the private link made for it, and through the tender register belonging to your account. Anyone holding a seat on your account can open every brief and every kept pack on it, because an estimating desk shares its work. Nothing is listed publicly, indexed, or browsable by anyone outside the account.
Confidentiality
SpecBrief does not sell your documents. These are the current services that receive customer or account information to operate the service:
- Render runs the app in Oregon and processes the upload, extracted text and requests. Its temporary disk also holds the extraction cache and any emergency local fallback.
- Google Gemini, on the paid API terms described above, receives extracted text. Drawing-image reading is currently off.
- Supabase stores accounts, pending extracted text and generated briefs in the Sydney database.
- Sentry receives scrubbed error reports. Before an event leaves SpecBrief, the code removes request bodies, query strings, cookies, headers, environment values, user details, breadcrumbs, extra context and stack-frame local variables.
- GitHub Actions makes the daily database backup on a temporary hosted runner. The database includes every unexpired brief present at that time. The dump is encrypted before upload; only the encrypted artifact is kept, for 30 days.
- Resend receives an account email address and one-time sign-in link when email sign-in is requested. It does not receive tender documents through the SpecBrief workflow.
The Vercel marketing site does not receive tender uploads. The published Gmail address is for enquiries and support only; SpecBrief does not accept tender packs by email. Information is also handed over where the law requires it.
Your choices
Ask what is held on you, or ask for it to be deleted. The email address is below.
This is a plain description of how things work right now, not legal advice. If you handle personal information at volume, you may have obligations under the Privacy Act 1988 (Cth). A solicitor has not reviewed this note yet.