Privacy Policy

DocSync Privacy Policy

⚠️ PRE-RELEASE DRAFT — NOT LEGAL ADVICE — NOT SETTLED BY AN AUSTRALIAN LAWYER

What this is. A pre-release draft, prepared by the DocSync engineering process for review by an Australian legal practitioner. It has not been reviewed, settled or approved by one, and it is not legal advice to anyone. There is no registered company name, ABN, ACN or registered address yet: the bracketed placeholders are real gaps, not formatting, and nothing in a bracket may be read as though it had been filled in. The complete list, with the number of times each token appears in each document, is in legal/COMPLIANCE_REGISTER.md; the ones that appear in this policy are listed at the end of it.

And it is nonetheless the live privacy statement, which is why the paragraph above matters. This policy is served, without a login, at docsync.tech/legal/privacy; the sign-up screen links it; and every user must tick a box naming it before an account is created. It describes what the running service actually does with information about people — including a cross-border disclosure that is happening today (§8). That is a deliberate choice: a pilot user is better served by a candid draft they can read than by no privacy statement at all. What you tick is this text at this version — the acceptance record stores the document key, the version number and a digest of the exact bytes you were shown.

What happens next. A settled version will be issued once an Australian legal practitioner has reviewed this pack and every placeholder is filled, and everyone will be asked to accept that version. Until then, and this is a rule we hold ourselves to rather than an instruction to you: we will not put this document into a tender or present it as a settled commercial commitment.

Every factual statement about how the DocSync software behaves is traceable to source code read on 2026-08-27 (branch full-web-app-build) and re-verified on 2026-08-31. Where a fact could not be established from code, this policy says so in its own words — as a fact about the service — rather than making a claim. The questions still open for our lawyer are recorded internally and are not part of this text.

The statements about how this deployment is configured — the mail backend, the AI provider, the operator surface, the worker count, the backup destination and retention — were read off the production server itself on 2026-08-31, not from a file in the source repository. An earlier version of this pack drew a deployed value from a repository default and was wrong about it; a configuration claim now names where it was read.

Document version: 0.8 · Effective date: [EFFECTIVE DATE]

1. In one page

We build DocSync. Builders and contractors use it to run construction projects: RFIs, drawings, defects, daily logs, timesheets, incidents, photos, claims.

Because of what construction work involves, DocSync holds some information that matters a great deal:

• Injury records. If a worker gets hurt, DocSync records their name, which part of their body was injured, what kind of injury it was, whether they got medical treatment, how many days they were off work, and a written account of what happened. Under Australian privacy law that is health information, which gets the highest level of protection.
• Time and pay data. Hours worked per person per day, who approved them, and the labour rate applied.
• Information about people who never signed up. Incident witnesses, site visitors, people a safety notice was issued to, subcontractor contacts, and people you share a project link with.
• Site photos and videos, which routinely show workers' faces, vehicle plates and whiteboards with names on them.

Three things you should know up front, because they are unusual and we would rather you heard them from us:

1. AI features are switched on in the pilot deployment, and prompt text leaves Australia today. Where they are on for your company, the text your team writes is sent to a provider outside Australia, so §8 is written in the present tense and says exactly what goes. Your company owner can switch AI off from Company → Editions, and you can refuse it entirely and permanently at no charge. §8.1 also records the thing we would rather not have to record: we said we would assess that provider before enabling AI, and AI was enabled first.
2. Our audit trail has no edit and no delete, and any tampering with it is detectable. That is deliberate — it is what makes a signed certificate or a served payment claim provable years later. Two limits, because an absolute we walk back twice is worse than the weaker sentence: the operator has administrative access to the server and the database, so what the chain actually gives you is detection, not impossibility (§9.1); and the whole chain for a company is destroyed when that company's account is deleted (§11.4). Within the running service there is no code path that updates or deletes an entry. It also means some personal information in that trail cannot be corrected or erased in the normal way. §13 explains what we do instead.
3. When a company deletes its account, we destroy everything except five things, and we name all five. A tombstone; short-lived error diagnostics we could not attribute to you; any nightly backup set still in its retention window; a handful of queued emails a worker was holding at that instant, deleted regardless within about three hours; and text your team already sent to our AI provider, which we cannot recall and whose retention we do not know. The tombstone is one permanent record holding the company name and the email address of the person who asked, so we can prove the deletion happened. §11.4 explains all five.

2. Who this policy covers, and who you should actually complain to

This is the part people find confusing, so we are going to be blunt about it.

There are two different relationships, and which one you are in changes who is responsible for your information.

2.1 If you are the account holder

If you signed up for DocSync, agreed to our terms, and pay us (or run the pilot with us), then we collect your information directly — your name, email, job title, password, and the record of you signing in. For that information, we are the entity responsible. This policy governs it. Complain to us.

2.2 If your employer or head contractor put you in DocSync

If a builder added you to their DocSync account — as a member of their team, a subcontractor contact, a person named in a defect, a witness to an incident, a visitor in a daily log, or a worker on a timesheet — then:

• The builder decides what to collect about you, what to write about you, who inside their business can see it, and how long to keep it while their account is open.
• We hold and protect it on the builder's behalf. We do not decide to collect it, we do not use it for our own purposes, and we do not sell it or use it to advertise to you.

What this means: if you want to know what a builder has recorded about you, or you think it is wrong, ask the builder first — they control it and they can fix it inside the product in seconds. If you cannot get an answer from them, contact us at [CONTACT EMAIL] and we will help you reach the right person and, where the law requires us to act, we will act.

A worked example. A plumber is named in a safety violation entry on a builder's daily log. The entry says who issued it and what it was about. That entry is the builder's record. If the plumber thinks it is wrong, the builder can edit it. We will not rewrite another business's project records on a third party's say-so — but we will pass the request on, tell the plumber we have done so, and escalate if they get nowhere.

2.3 Can you deal with us anonymously, or under a pseudonym? (APP 2)

No, and we would rather say so than leave the question unanswered. APP 2 gives you the option of not identifying yourself when you deal with an organisation, unless that is impracticable or the organisation is required by law to deal with identified individuals.

For DocSync it is impracticable, and we rely on APP 2.2(b) for that. The whole point of the product is attribution. The audit trail exists so a builder can show a certifier, an insurer or an adjudicator that a signed certificate or a served payment claim is genuine — which only works if it names who did what. A sign-off by nobody is not a sign-off. A timesheet approval has to name the person whose hours were approved. An account cannot be pseudonymous because every record it touches has to be attributable to a real person, years later, to somebody who was not there.

And there is a harder point underneath that one. If a builder put you in DocSync, you never had the choice at all. Your name reached us inside a witness statement, an injury record, a visitor log or a safety notice, written by somebody else. APP 2 gives an option to a person who is dealing with us; a worker named by their employer is not dealing with us and was never asked. That is why §2.2 tells you who to ask, and §13 tells you what we will do if you come to us anyway.

3. Small business, and why we are not relying on the exemption

Under the Privacy Act 1988 (Cth), a business with an annual turnover of $3 million or less is generally exempt from the Australian Privacy Principles. [LEGAL ENTITY NAME] is below that threshold today.

We are not relying on that exemption, for three reasons:

1. Health information removes it anyway. Handling health information — which injury records are — takes an organisation outside the small business exemption for that handling. DocSync's core scope includes incident and injury records.
2. It is being narrowed. Australian privacy reform is progressively removing the small business exemption. Building a product now that only complies while we are small is building it twice.
3. Our customers will require it contractually. A head contractor onboarding a software vendor asks for APP compliance regardless of the vendor's size.

So: we write and operate to the Australian Privacy Principles. If we ever formally rely on the exemption for anything, we will say so here in plain terms.

A note on what that sentence is. It is a statement about how we conduct ourselves, not a claim about our legal status. Whether the entity is an APP entity, and whether it is a collector of sensitive information rather than a holder of somebody else's, are questions for a lawyer and they are not settled. We are not going to settle them by asserting the flattering answer in our own privacy policy. What we can commit to, and do, is the conduct: we handle personal information in accordance with the Australian Privacy Principles.

3.1 How we manage privacy (APP 1.2)

APP 1.2 asks for practices, procedures and systems that make compliance real rather than stated. Here is what exists — and only what exists.

• A named person. [PRIVACY OFFICER] is responsible for privacy enquiries, access and correction requests, and complaints, and is reachable at [CONTACT EMAIL]. There is one person operating this deployment (§7.2), so that is the same person. We would rather tell you that than imply a team.
• A review cycle. This policy, the service-provider list and the data-residency page are reviewed at least every six months, and additionally whenever a configuration change touches a service provider or a new category of information starts being collected. Every review that changes the text bumps the document version at the top of this page.
• A written breach plan. We hold an internal data-breach response plan covering assessment, containment, the Notifiable Data Breaches obligations, and who we tell in what order. §12 sets out what it commits us to and what we cannot do.
• A compliance register. We keep an internal register of the obligations we believe apply to us, what we have done about each one, and what is still unresolved. It is what this policy is drawn from, and it is the reason this policy is willing to publish a list of what we do not have (§9.3).

What we do not have, so this section cannot be read as more than it is: no formal privacy training programme, no privacy impact assessment process, and no external privacy audit. With one person, two of those would be a document describing a meeting with himself. They are on the list for when there is a second person, and we will say so here when they exist.

4. What we collect

Everything in this section is a real field or real behaviour in the software. Nothing is aspirational.

4.0 How we collect it, and how we hold it

How we collect it. Almost none of the personal information in DocSync comes to us from the person it is about. It comes from our customer — a builder or head contractor — who types it in, uploads it, or invites you. We collect directly from you only when you create or use an account: your email, name, job title, password and sign-in records. Everything else — your injury record, your hours, your name in a witness statement, your face in a site photograph — reached us because a builder put it there. Section 2 explains what that means for who you should ask.

How we hold it. On one server. Your records sit in a PostgreSQL database and your files — documents, drawings, photographs, signature images, video — sit in an object store, both running on the same virtual machine in [HOSTING REGION], with no published port on either. Nightly backups are written to the same disk (§11.5). Two smaller stores sit outside that server and inside your own equipment: the cookies and cached profile in your browser, and, on a phone or tablet used in the field, an offline queue holding work and photographs that have not synced yet. §4.8 sets out exactly what is in those.

Where to find each thing the law says this policy must tell you.

Three more principles have their own home in this policy because a reviewer will look for them: APP 1.2 (how we manage privacy) is §3.1, APP 2 (anonymity and pseudonymity) is §2.3, and APP 1.7 (automated decision-making) is §6.

4.1 Your account (we are the collector)

What the acceptance record is, and what it is not. When you create an account we record, against your user, which documents we required you to accept, the exact version of each one that we served you at that moment, when you accepted, and whether it was at signup or in response to a new version — and we record nothing about any document we did not require and did not show you.

The record is append-only: accepting a new version adds a row and never alters or removes the old one, so the history of what you agreed to, and when, stays intact. The wording itself is not held in a database table where it could be edited without a trace — the documents are files, versioned in our source control, and the version you accepted names the file as it stood.

From 2026-08-30 the record also keeps a fingerprint of the words, not just the version label. A version number says which edition you agreed to and nothing about what that edition said, and these documents are files a person edits — so somebody forgetting to bump a version could silently change what every existing record appears to attest. Each new record now stores a digest of the document text exactly as it was served to you, so an edit made at an unchanged version is detectable rather than invisible.

Rows written before that date do not have one, and we have not gone back and added them. We do not know which words those users saw, and writing today's digest into an old row would be manufacturing evidence inside the one record whose whole job is to be trustworthy about the past. So the check has three answers — yes, no, and we cannot tell — and a row with no digest is reported as the third, never as the first.

It does not prove you read anything. It proves what we required, what we showed you, that the words we showed you were these words, and that you clicked. We are not going to dress that up as informed consent to sixty pages.

4.2 Your project records (we hold these on the customer's behalf)

People in the directory. Names, email addresses, job titles, company role (owner/admin/member), which projects each person can open, and their permission level on each tool. This includes "contacts" — people with a name and email in the directory who never sign in.

Subcontractor and supplier contacts. Primary contact name, email and phone; a tax or licence number field; insurance policy details (carrier, policy number, limit, dates); and qualification or licence references with expiry dates and notes.

Note: the tax/licence field is free text with no validation. A sole trader's ABN is personal information. Nothing stops someone typing something more sensitive into it.

Work records. RFIs, submittals, transmittals, correspondence, defects, observations, inspections, tasks, meetings, daily logs, drawings, documents, specifications, forms, budgets, commitments, invoices, claims, deliveries, equipment and warranties.

Most of these have a person's name somewhere — as creator, assignee, approver, or ball-in-court. Many have free-text fields where names appear even though the field is not a name field:

Custom fields. A company can define its own fields, of any type, on any tool, and put anything in them. We do not classify, validate or restrict what goes in. If a company uses a custom field to record something sensitive — a tax file number, a medical note, a home address — we will hold it, and neither we nor the software will know. This is the one place where we genuinely cannot tell you what categories of information DocSync holds about you. Ask the company.

4.3 Sign-offs and signatures

Daily logs, inspections, ITPs, incidents, progress claims, handover dossiers and eight kinds of trade compliance certificate can be signed. A signature is captured as a drawn image (you sign on a screen with a finger or stylus, and we store the PNG), together with who signed, when, and a hash of the exact record content at the moment of signing.

A handwritten signature image is personal information and is a known identity-fraud target. We treat it as such: signature images live in the same access-controlled storage as your documents and are never exposed by a public share link.

We do not treat a signature image as sensitive information, because it is not a biometric template captured for automated verification or identification — it is a picture of a signature. We protect it as a high-value piece of personal information regardless, because it is an identity-fraud target, and that is the standard the controls above are set to.

4.4 Photos, videos and their hidden data

For every photo uploaded we record the filename, any description typed, the uploader, a SHA-256 hash of the exact bytes (this is the evidence anchor), and — read out of the photo's own EXIF metadata — the time it was taken and the GPS coordinates of where it was taken. Those coordinates drive a map view of a project's photos.

Three things you need to know about photos:

1. We do not strip EXIF from the original. The original file is stored byte-for-byte, untouched, deliberately, because changing a single byte would break the hash that makes the photo usable as evidence. That means the original still contains everything the camera wrote: GPS, capture time, camera make and model, serial numbers, lens, software. Anyone who can download the original can read all of it, including fields DocSync never looked at.
2. The blur tool is not redaction. Markup — arrows, text, redline and blur — is stored as a separate overlay and composited on top for display. It is never baked into the original. A face you blurred in DocSync is still fully visible in the original file, in a data export, and to anyone who downloads the original. This is correct for evidence integrity and wrong for anyone who thinks they redacted something. We are telling you plainly so you do not rely on it.
3. Thumbnails are re-encoded and therefore happen to be EXIF-free. The original is not.

Site capture videos. DocSync can hold a walkthrough video of a site for 3D reconstruction. A walkthrough video will contain identifiable people. See §7.4 — that processing path is currently switched off.

4.5 Injury and incident records

See §5. That is the most important section in this policy.

4.6 Timesheets

Per person, per day: hours worked (recorded in minutes), the cost code worked against, free-text notes, who approved or rejected the entry, when, a free-text reason for that decision, and the labour rate applied when the entry was costed.

Time entries are always created by the person themselves — DocSync does not let one person log hours for another. The approval and the approval note are a supervisor's record about a worker.

One thing worth knowing about the employee-records exemption. The Privacy Act's employee records exemption protects an employer handling records about its own employees. It is not an exemption we can stand behind as the platform operator, and it would not reach a subcontractor or a labour-hire worker in any event. So we do not rely on it, and this policy applies to timesheet data in full.

4.7 Technical and operational information

One honest gap in that table. A client IP address is personal information, and we cannot yet tell you how long the reverse proxy's access log keeps one. Container logging on the deployment runs without a rotation policy, so the practical answer today is "until the log is rotated or the host is rebuilt", which is not a retention period. We are not going to quote you a number we have not set. Setting one, and publishing it here, is on the list in §9.3's spirit: a gap named is a gap somebody can hold us to.

4.8 What is stored in your browser or on your device

What this means: a lost or shared site tablet can hold un-synced site photos and observations. Use a device passcode. That queue is the price of DocSync working with no signal, and we think it is worth it — but you should know it is there.

4.9 What we do not collect

We do not collect a date of birth, a government identifier, payment card details, or location data from your device beyond what a photo's own EXIF contains. There is no field for any of them anywhere in the data model. We do not buy information about you from anyone, and we do not use your information to advertise.

5. Sensitive information: injuries, and why it gets special treatment

5.1 What is recorded

When an incident is logged, DocSync records the type (injury, near miss, property damage, environmental, other), severity, exact date and time, location on site, a free-text description of what happened, immediate actions taken, whether it is notifiable to a regulator, and the regulator reference and deadline.

Then, for each affected person, DocSync records:

• their name, in clear text;
• the filing type — first aid, medical treatment, restricted duty, lost time, fatality, or other recordable;
• which parts of their body were injured, from a 22-item list including head, eye and internal;
• the nature of the injury — injury, skin disorder, respiratory condition, poisoning, hearing loss, amputation, loss of eye, other illness;
• how many days they were away from work, and how many on restricted duty;
• a free-text account of the injury.

And for each witness: their name and their statement, verbatim — and a witness does not need to be a DocSync user at all.

5.2 Why this is different

Under the Privacy Act 1988 (Cth), information about a person's health is sensitive information. It carries a higher bar than ordinary personal information:

• Collecting it generally requires the individual's consent (APP 3.3), unless a specific exception applies — for example, where collection is required or authorised by an Australian law such as work health and safety legislation.
• It can only be used or disclosed for the purpose it was collected for, or a directly related purpose the person would reasonably expect (APP 6).
• It attracts the strictest expectation of security (APP 11).

And the Commonwealth Act is not the only law in the room. New South Wales, Victoria and the ACT each have their own health records legislation — the Health Records and Information Privacy Act 2002 (NSW), the Health Records Act 2001 (Vic) and the Health Records (Privacy and Access) Act 1997 (ACT). Those Acts operate independently of the Commonwealth small business exemption, so "we are under the turnover threshold" is not an answer to them; the NSW Act reaches information about a person who has been dead for less than 30 years, which is not hypothetical in a system with a fatality filing type. Separately, state and territory workers compensation legislation imposes its own confidentiality duties on injury information, and those duties sit on the employer whose records these are. We are telling you these exist. We are not telling you how they apply to your business or to ours — that is a question we have put to a lawyer, and the answer is not settled.

5.3 Where the responsibility sits — read this if you are a builder

You decide to record an injury. We built the field it goes in.

DocSync gives you a place to record incidents because WHS law and your insurer require you to. You decide that a particular worker's injury goes into a particular project, who inside your business can read it, and how long it stays there. We handle that information in accordance with the Australian Privacy Principles.

What we are deliberately not doing is telling you which of us the law calls the "collector" of it. That question turns on facts about both of us — we designed the fields and prompt for body part and nature of injury; you are the one who solicits the information from the worker and decides to record it — and it is with our lawyer. We are not going to settle it by writing the convenient answer into our own privacy policy. What we can tell you is where the practical burden sits, and it sits with you: you are the one who must have a lawful basis for recording injury details about a named worker, because you are the one who decides to record them. Before you do, you should be satisfied that:

• you have the worker's consent, or you are required or authorised by an Australian law (for example your jurisdiction's WHS Act or its incident notification duty) to record it;
• the people who can open the Incidents tool in that project are the people who should be reading it;
• you have told the worker what you have recorded and why, and how they can see it.

Two honest gaps in the software, which you should plan around:

1. There is no consent capture in DocSync. No screen asks whether the injured worker consented, and nothing stores the answer. If you need to evidence consent, you need to do it outside the product (or attach the evidence as a document).
2. Injury records are not access-controlled any more tightly than anything else. The Incidents tool has the same four permission levels as every other tool (none, read only, standard, admin). There is no separate "health information" permission. If you give someone standard access to Incidents, they can read every injury record in that project, body parts and all. Set that permission deliberately. A company owner or admin can read everything in every project by design.

Two changes would close both of those gaps — an elevated permission tier for injury sub-records, so a person can be given the Incidents tool without being given body parts and diagnoses; and a consent flag on the injury record, so the answer to "did the worker agree to this being recorded here" lives beside the record. Neither exists today, and we are not giving you a date. When they exist this section will say so, and until it does, plan around their absence.

What we recommend while that is true — and it is not boilerplate. DocSync today has no multi-factor authentication, no encryption at rest, and no off-site encrypted backup (§9.2, §9.3, §11.5). Holding a whole workforce's injury detail on that posture is a pilot-scale decision, so:

• keep injury detail in DocSync to the minimum your WHS obligations actually require — the fields are there because the regulator's forms ask for them, not because more is better;
• restrict the Incidents tool to the smallest group that can do the job, and review it when people change roles;
• hold medical certificates, diagnoses and treatment records outside DocSync. A certificate attached to an incident is a health record sitting in general-purpose document storage that any standard-access member of that project can download.

We would rather write that than have you find out from an incident report.

5.4 Witnesses and other people who never signed up

A witness statement is collected about — and often from — a person with no DocSync account and no relationship with us. The same is true of site visitors, people named in safety violations, subcontractor contacts, and people you send a share link to.

We have no way to give those people a collection notice through the product today. That obligation (APP 5 — telling someone when you collect their information) sits with the builder who collected it. If you record a witness statement, tell the witness what you recorded and where it is going.

Whether we owe you a notice too is a question we have not closed. Our position is that the builder who wrote your name into a record is the one who collected it from you and owes you the notice. It is arguable that we owe a parallel one, as the entity that holds the record. Rather than argue it, we do the cheap thing that works either way: this policy is published at a public address and anybody can read it without an account, so if you have been named in somebody's DocSync records, the notice you are owed is this page.

6. Why we collect and hold all this

On our own behalf, we use personal information only to:

• create and run your account and sign you in;
• send the transactional email the product needs to work — invites, password resets, notifications you asked for, scheduled reports you configured, digests you opted into;
• keep the service secure and working: rate-limit sign-in attempts, detect stolen sessions, diagnose errors, and maintain the audit trail;
• respond to your support requests;
• meet our own legal obligations.

On our customers' behalf, we hold project records so that the customer can run their projects. We do not mine them, we do not use them to train any model, we do not sell them, and we do not use them to market to anyone.

We do not use your information for automated decision-making that has a legal or similar effect on you. AI features draft text for a human to edit; they do not decide anything. Nothing in DocSync approves, rejects, prices, rates, ranks or excludes a person automatically — a defect is closed by a person, a timesheet is approved by a person, an inspection is signed by a person, and an AI-drafted paragraph only exists once a human has read it and pressed save.

That paragraph is our APP 1.7 statement — the disclosure about automated decision-making — and we are labelling it so a reviewer does not have to go looking for it.

7. Who your information goes to

The full list, with countries and current status, is in legal/SUBPROCESSORS.md. This section summarises the parts that matter.

7.1 Inside your own company

• Directory information — every name, email address, job title and company role — is visible to any member of a project. There is no separate permission for it. If you add someone to a project, they can see every other member's email address.
• Tool records are governed by per-tool permissions: none, read only, standard, admin, set per person per project.
• Company owners and admins can read everything in every project of their company, by design.
• Attempting to reach another company's data returns "not found", never "forbidden" — so nothing leaks, not even the existence of a record.

7.2 Us — what our staff can see

[LEGAL ENTITY NAME] currently has one person operating the deployment. Being honest about this matters more than sounding bigger than we are.

• There is a restricted operator surface in the product that shows error diagnostics across all companies — exception types, routes, counts. It shows no project records. By design, reaching it requires two separate deployment-level values — the operator's email must be on a deployment-level allowlist and a separate server-side token must be presented. That is not multi-factor authentication and we do not count it as one (§9.3). Either one missing and the surface does not exist for anybody. It is not a role, it cannot be granted from inside the app, and no company owner or admin can obtain it. We are describing how that surface is built. We are not offering it to you as the control that protects your records — whether those two values are present in a particular deployment is an operational fact, not a design one, and the boundary you should judge us on is the next bullet. On the deployment you are using today neither value is set, so that surface does not exist for anybody, including us (read from the server on 2026-08-31). We mention it because it is part of how the product is built, not because it is protecting you right now.
• Separately, and more importantly: the operator has administrative access to the server, the database and the file store. That is unavoidable for a self-hosted deployment run by one person. We are not going to pretend the operator surface is the boundary. The real controls are that access is limited to one identified person, every action taken through the application is written to the tamper-evident audit trail, and we do not access customer records except to fix a fault you have reported or where the law requires it.

7.3 Service providers

On the Open-Meteo row, and why it is now a list rather than an absolute sentence. Three times the code tried to keep an absolute promise by removing what must not go — a regex, then a list of designator words, then a positional strip. Each was defeated by an address shape nobody had anticipated, and this policy was rewritten each time to match. On 2026-08-31 the approach was inverted and the heuristics deleted: the address line is no longer read at all, and the City value is sent only if it passes an allow-list that says what a place name is. A digit cannot leave because a value containing one is never sent, not because we tried to take one out.

That fix holds. The sentence we wrote on top of it did not, and we are not going to write a fifth one. A fourth version of "the only location detail that ever leaves" went into this policy and was falsified within the week by the weather request, which sends the project's own latitude and longitude — fields somebody types into, which the allow-list never touched. So the row above says what leaves rather than what does not, and those coordinates are rounded to two decimal places on the way out. If we find another, it joins the list.

The two limits stay inside the row rather than outside it. A street name typed into the City box does leave — Ocean Drive Terrigal contains no digits, so the allow-list passes it — and on a residential job that narrows a private dwelling to one street. Excluding it would need a list of street-type words, and St, Broadway and Beach are locality names too. The cost of the rule is that a City value which is not a plain place name gets no coordinates, so the project has no map pin and its daily log falls back to manual weather entry; the screen that takes the City value says so where you are typing it.

What happened before that date does not un-happen. Until 2026-08-31 a project with no City set had its address line shortened and sent, and street numbers did reach the geocoder. Projects located under the old rule are not re-geocoded, and the project.geocode audit rows record the query that was sent at the time.

7.4 Paths that exist in the software but are switched off

We list these because switching them on is a configuration change, not a new release, and we would rather you knew now than found out later. Each is fail-closed: with the configuration absent the feature returns an error rather than working insecurely.

• Off-site backups (Azure Blob Storage) — not configured. See §11.5.
• 3D reconstruction GPU worker — not configured. If enabled, a separate machine would download full site walkthrough videos. Note that the worker's queue is not scoped to one company — a single worker would receive video from every company on the deployment. DocSync also has a fully on-premises path for 3D (upload a model directly), so this disclosure is avoidable.
• Inbound email ingestion — not configured. If enabled, emails sent to a project address would be filed into the project, including sender addresses and attachments from third parties.
• Accounting export (Xero, QuickBooks Online) — not configured. If enabled, would send vendor names, line descriptions and amounts.
• Stripe billing — an inbound webhook stub only. Nothing is sent to Stripe by this software today.

We will not turn any of these on without updating legal/SUBPROCESSORS.md and giving you notice first. See §7.6.

7.5 Where your data physically lives

The long answer is in legal/DATA_RESIDENCY.md, which is written for your IT person. The short answer is this.

Everything you put into DocSync — your records, your files, your photographs and your backups — is held on one server in [HOSTING REGION]. That server is a virtual machine we rent from Microsoft Azure, so Azure holds it: row 2 of the service-provider list records what Azure receives as everything, because the machine's disks — and any snapshot Azure takes of them — are Azure's to hold, and we have not verified how they are stored. Beyond that hosting provider, no third party holds a copy of your file store or your database: the off-site backup destination has never been set, so no copy of either has ever left the machine.

That is a statement about copies, not about content. Parts of what your team types do leave. Earlier versions of this policy tried to say there was only ever one such thing, and were wrong four times running — each time a new path was found next to the one just fixed. So we no longer make that kind of claim. What follows is the list, measured from the code and the deployment on 2026-08-31. If we find another, it goes in the list.

What leaves that server today is a list, not a count. None of the items on it is your file store or a copy of your database, but one of them does carry record text your team typed: a place name and a pair of coordinates, to the weather service; our own domain name and an administrative email address, to the certificate authority; and AI prompt text, to the model provider. Outbound email is a further path: it is built, it is switched on in the product, and it delivers nothing at all. If we find another, it joins the list — and the list is the only thing that has to change, which is the reason it is written as a list.

(1) A place name and a pair of coordinates. What carries part of a project's location off this server is a list, not a count. Four successive drafts of this pack published a count of it and each one was falsified within the week by a path next to the one just fixed, so the count is gone and the list is what we state: the project's City field; the project's stored latitude and longitude; and the project's own name, which goes to the AI provider in a prompt — path (3) below — and which on a residential job is often the street address. If we find another, it joins the list. The first two are what this paragraph is about. We send the City field to Open-Meteo to turn it into coordinates, and only when it holds a plain place name — letters plus the joiners a locality name can contain, at most four words. The address line is never a source. We then send a latitude, a longitude and a date to the same service for the weather. Those coordinates are the ones stored on the project, which somebody may have typed in by hand rather than obtained from the City field, so they are rounded to two decimal places — about a kilometre — before they are sent: the request names a suburb rather than a building, and the value stored on your project keeps its full precision. No project name, no identifier, no key, and no end-user IP address — the request is made by our server, not by your browser. §7.3 states the two limits on the City field.

(2) Our domain name. Sent to Let's Encrypt, in the United States, together with an administrative email address, to issue the certificate that encrypts your connection. No customer information is involved.

(3) AI prompt text — and this is the one that carries your records. AI features are switched on in the pilot deployment. Where they are on for your company, the text of the prompt — record titles, descriptions, short excerpts of a record's own text, and other free text your team typed, which can therefore include a person's name — is sent to our AI provider, whose endpoint is outside Australia. Section 8 says exactly what is sent, by which feature, and how to stop it.

(4) Email — built, switched on in the product, and delivering nothing. DocSync composes invitations, password-reset links, notifications, share links, scheduled reports and its own error alerts. On this deployment the mail backend is console, which writes each message to the server's own log and discards it. No message is handed to a mail relay, so our relay, SMTP2GO, receives nothing at all today. The log line records the recipient address, the subject and the message length; it does not record the body, and it stays on the same server as everything else. The plain product consequence: a password reset, an invitation or a notification reaches nobody. Where DocSync confirms one of those actions on screen it reads this deployment's own email status first and says the message was not emailed rather than implying it was sent — the password-reset screen, the two invitation screens and the meeting-minutes screen all do. Every other screen says nothing about delivery in either direction, so nothing in DocSync should be read as proof that a message arrived. §7.3 describes what the relay would receive on the day a real mail transport is configured — that is a configuration change rather than a new release, and this policy has to be true then too.

Other paths exist in the software and are switched off — an off-site backup destination, a rented GPU host for 3D reconstruction, an inbound-mail provider and an accounting export. They send nothing while they are off. §7.4 lists them.

A word about [HOSTING REGION], because that placeholder is load-bearing. The deployment plan specifies an Australian region — but a plan is not a record, and nobody has yet confirmed in the hosting provider's portal which region the virtual machine, its disks and any snapshot actually sit in. Until that is confirmed we will not tell you your data is hosted in Australia. We will tell you it is on one server, in one region, and that we have not yet proved which one.

7.6 Changing a service provider

We publish the full list of every service provider that can receive information you put into DocSync — including the ones that are switched off — at docsync.tech/legal/subprocessors, and we will not let a new provider receive your information until we have updated that list and given you at least 30 days' written notice by email to your company owner.

If you object to a new provider within those 30 days, tell us: we will either keep the feature that uses it switched off for your company, or you may terminate the affected part of your subscription and we will refund the unused portion of anything you have prepaid. Two things you should know about how this works. The notice is written and sent by a person, not generated by the system — there is no automated broadcast. And if we ever have to replace a provider immediately for a security or continuity reason, we will make the change first and tell you within five business days, with our reasons.

The full mechanics are set out in legal/SUBPROCESSORS.md §4.

8. AI features and the disclosure outside Australia (APP 8)

This is the section a careful customer will read twice, so it is the most detailed.

8.1 AI features are switched on in the pilot, and this is what happened first

AI features exist in DocSync and they are switched on in the pilot deployment. Prompt text is going to a provider outside Australia today. The rest of §8 is therefore written in the present tense: it describes what is sent, and to whom.

Two switches control it, and both are on:

• AI features are gated by a per-company entitlement. Without it, every AI surface in the product silently uses a deterministic, non-AI fallback and nothing leaves our server. The entitlement is active on the one company using DocSync.
• The provider is also set at deployment level — the deployment's provider setting is deepseek, with a key configured. A company without the entitlement still gets the fallback, and the product is fully usable with zero AI.

Two different protections are at work here, and they are not the same kind of thing. One is unconditional and one is a gate. Earlier versions of this section blurred them together and over-claimed as a result, so this version separates them and states the limit of each in the same breath as the promise.

Unconditional, on every path: three kinds of contact detail are stripped out before anything is sent. Before a prompt reaches the provider, DocSync removes email addresses, ABN-shaped numbers and Australian phone numbers from it. That removal does not sit in a switch somebody has to remember to use. It sits inside the single piece of code that opens the connection to the provider, and it runs on the finished request on the way out. So it applies no matter which part of DocSync assembled the prompt, including a feature written next year by somebody who has never read this policy, and there is no version of the provider anywhere in the running program that skips it. This is the part you can hold us to without knowing anything about our source code.

What that does NOT cover, and this is the half that matters most to you. The removal is three pattern matches. It cannot recognise a person's name. Free-text titles, descriptions and notes your team typed go to the provider as typed, and a title can name a worker, a subcontractor or a client. The project's own name goes with them, and on a residential job a project is routinely named after its street address. So the true sentence is those three classes of contact detail are removed on every path. The sentence no personal information leaves would be a stronger claim and a false one, and we are not going to write it.

The entitlement check is the second protection, and it is a gate rather than a property of the code. It is enforced at one seam, entitlement_service.ai_provider(), which every AI feature in the product goes through, so a feature added later inherits it instead of having to remember it. That is the right place for it, because the entitlement is the thing a company pays for: getting around it would mean the model running for a company that has not bought it — an invoice to correct, not a disclosure to notify. It is not a privacy control and we do not offer it as one.

What we are not claiming. Somebody with our source code who sets out to defeat this can write their own short program that talks to the provider directly and touches none of the above. No arrangement of code inside a running program prevents that. Four earlier versions of this section claimed a form of impossibility instead, and each time a reader with the repository disproved it in a couple of lines — the last of them in two. What is true is narrower, and it is the thing worth telling you: anything DocSync sends through its own AI layer has had those three classes removed, whichever part of the product sent it, and names are not among them.

A separate test enumerates every screen that reaches a model and fails if a new one appears without a disclosure of its own, and a third records, field by field, exactly which pieces of your data the health-summary prompt reads — so a new field added to that prompt fails the build until this policy describes it.

Who switches it on. A company owner does, for their own company, from Company → Editions, after ticking a box that says the text their team types — including record titles and notes that can name workers and subcontractors — goes to the destination the server reports, that they have told those people or are otherwise permitted to share it, and that the AI provider is a setting our operator can change, including to one outside Australia. The activation is refused without that tick, so for any future activation it is the consent record, not a notice. The same owner can switch it off there. We do not do it for you, and nothing in the software asks us first.

And the one activation that has ever happened has no acknowledgement behind it. That tick is new. The AI entitlement on the pilot company was switched on 2026-08-24, so it predates the acknowledgement and no acknowledgement was recorded for it. There is no consent artefact standing behind the cross-border disclosure that is actually happening — only this paragraph. Anyone who asks for that artefact should be shown this sentence, not the screen.

What we said we would do first, and what actually happened. We said that before AI was enabled for any customer we would, in this order: obtain and read the provider's published terms; record on the service-provider page at docsync.tech/legal/subprocessors, for that provider, the country in which it processes, how long it keeps API inputs and whether it uses API inputs to train models; name that country here and in the sentence the product shows at the point of use; and give the 30 days' notice §7.6 promises.

None of those four things was done before AI was switched on. AI was enabled on the pilot company first. The only company on the deployment is our own test company — read from the production database on 2026-08-30 — so no other DocSync customer's records have been involved. That is narrower than it sounds, and the first half of it is the only part we can evidence. Our own test company holds the names of real subcontractors, suppliers and workers; nobody has examined what personal information about those people its records contain; and we therefore do not claim that no individual's personal information has left the country. Australian Privacy Principle 8.1 requires the reasonable steps to be taken before the disclosure, not after it, and the order was wrong. We are recording that here rather than writing the assessment in the future tense while the disclosure is already happening, because a privacy policy that does the second thing is worse than the mistake it is hiding.

The assessment is still to be done, and it is a person's job, not a feature. It is ours as operator. Nothing in the product enforces it, and nothing in the product would stop a company owner switching AI on before it is finished — so treat it as a commitment you can hold us to and ask us about, not as a gate.

To decline AI permanently: tell us, and we will keep the entitlement off your company, at no charge — and your company owner can switch it off directly, in the product. Nothing you write will then be sent to any AI provider. You lose no core functionality; the affected features fall back to templates and counts.

8.2 Who would receive it, and where — and what we will not promise about them

The provider the software is built against, and the one it is configured to use, is DeepSeek, reached at api.deepseek.com, and it is served outside Australia. Our own code says so in three separate places and we are not going to soften it: the text in the prompt leaves the country. The specific country in which the provider processes is not established — we have not obtained its published terms — so "outside Australia" is the strongest thing we can honestly say.

We have not obtained or read that provider's terms. Which produces the sentence in this policy we would most like you to notice, because most vendors write its opposite:

Where AI features are switched on for your company, the text of the prompt is sent to a third-party provider outside Australia. We do not warrant what that provider does with it, and we will not tell you that your prompt is excluded from that provider's training unless that provider's published terms say so and we have read them. We will obtain and assess the provider's published terms and record, at docsync.tech/legal/subprocessors, for each provider: the country in which it processes, how long it keeps API inputs, and whether it uses API inputs to train models. That assessment is outstanding while AI is switched on — see §8.1. If you require that no customer data reaches any third-party AI provider, tell us and we will keep AI features switched off for your company at no charge.

What we do promise, because it is ours to promise: we do not use your data to train, fine-tune or improve any machine-learning model of our own, and we never will.

And the option most vendors cannot offer. DocSync's AI features can run against a model hosted on the same server as your data. That removes the cross-border disclosure entirely, and it is one configuration value. Ask us.

8.3 What is removed before it leaves — and what is not

Every prompt passes through an automatic scrubber at the single point where it leaves our server. It replaces matches with [redacted].

It removes exactly three things:

1. Email addresses.
2. ABN-shaped numbers — 11 digits, with or without the standard 2-3-3-3 spacing.
3. Australian phone numbers in five formats: +61..., (0X) XXXX XXXX, 0X XXXX XXXX, 1300/1800 XXX XXX, and the spaced 13 XX XX form.

That is the entire list. It does not remove:

• Personal names, in any form. This is the important one. A pattern-matcher cannot recognise a name, and our own code says so in its documentation. If a defect description reads "Dave left the panel open", that sentence goes as written.
• Street or postal addresses. In particular, on a residential job the project name is often the address — "14 Wattle St renovation" — and the project name is sent with the health summary.
• International phone numbers, or a bare compact 13XXXX.
• Tax file numbers, licence numbers, vehicle registrations, dates of birth or Medicare numbers. There is no pattern for any of them. If someone typed one into a note or a custom field and that text is in the prompt, it goes.
• Job titles, trades and company names, which on a small crew identify one person ("the Level 3 electrician").

We are not going to call this de-identification, because it is not.

8.4 What each AI feature sends

This table is happening today wherever the entitlement is on (§8.1). It is what each feature sends. There are eight of these features, not five — earlier versions of this policy grouped the four drafting surfaces into one row, which made the list look shorter than the software is. They are separated below, because at three in the morning somebody scoping a disclosure will count the rows.

What row 1 adds up to, in characters, from the code's own constants. The sentence above gives the ceiling on ONE excerpt. Two multipliers sit on top of it and neither used to be published: the same record may be cited as many as three times, and each citation carries that passage's section heading — the record's own words — outside the excerpt cap. So the two figures a reader should hold are 3,060 characters of any one record (three passages of 900, each with a heading of up to

1. and 10,200 characters of record text in total for one question (ten citations of the same

shape). Not 900, and not the 9,000 the older arithmetic implied. Those four numbers are EXCERPT_MAX_CHARS, MAX_PASSAGES_PER_SOURCE, MAX_HEADING_CHARS and MAX_CITATIONS in the API source; scripts/check_legal_pack.py reads all four and fails if this paragraph and the code disagree, so raising either multiplier without amending this page is a build failure rather than a quiet widening.

One correction to row 8, because a policy that quietly widens a claim is as bad as one that narrows it. Earlier versions of this table said "daily-log summary lines" travel. They do not. The daily-log block is a grouped count and renders lines of the form "26/08/2026: delays x3, manpower x1" — a date, a section name from a fixed list, and a number. No entry text and no author. What that row omitted were the audit action counts and the carried-over items, and both are now named. The screen in the product has said the accurate thing for some time; this table was the one that was wrong.

What is never sent to an AI provider: attachments, documents, drawings, photos, video, signature images, full extracted document text (bounded excerpts only), and — unless both money gates are open — any financial figure.

8.5 What would happen to it at our end

• We do not store prompts or AI answers. There is no conversation table and nothing AI-generated is written to the database. Every AI feature returns text a human edits and then saves through the normal form.
• A multi-turn conversation lives in your browser, not on our server. When you ask the assistant a follow-up, the panel keeps the thread in the browser tab's own storage and sends the last three exchanges up with the next question. We never receive a copy to keep: the request is served and discarded like any other. Closing the tab, or pressing New conversation, ends it. This is why the sentence above is still true now that the assistant holds a conversation — and it is the reason we built it this way round.
• One honest consequence of holding it in your tab. Because the thread is on your screen and not on our server, an answer you have already been given stays on your screen until you close the tab or press New conversation — including if your access to a record it cited is removed in the meantime. What changes immediately is everything the next question does: a record you can no longer read is not fetched, not cited, not quoted and not sent to the AI provider again, and the answer that was written from it is dropped from what we send. Opening the record from the old answer fails, as it should. We cannot reach into a browser tab to unsend what was already, lawfully, shown.
• The audit trail records the shape, not the content. An entry says which provider was used, how many characters the prompt was, and which kinds of fact travelled. It never contains the question, the excerpts, or the answer. An auditor can prove a 6,000-character prompt went offshore without the audit record becoming a second copy of your text.
• We distinguish "we built a prompt and threw it away" from "we sent it". If the AI is unavailable, the prompt is discarded inside our own process and nothing left the country. If the reply came back unusable, the prompt was sent. The product records the difference deliberately so a disclosure is never optimistic.

8.6 Our position under APP 8

APP 8.1 says that before we disclose personal information to an overseas recipient, we must take reasonable steps to ensure the recipient does not breach the Australian Privacy Principles — and if they do, in most cases we are treated as having done it ourselves.

We accept that. We are not asking you to consent your way around APP 8, and we are not relying on the "informed consent" exception in APP 8.2(b). We are telling you what goes, where it goes, and that we carry the responsibility for it. If you are not comfortable with that, switch AI off — and nothing goes.

And we accept the harder half. APP 8.1's reasonable steps are steps to be taken before a disclosure. In the pilot they were not: AI was switched on before the provider was assessed (§8.1). The only company on the deployment is our own test company — read from the production database on 2026-08-30 — so no other DocSync customer's records have been involved. That is narrower than it sounds, and the first half of it is the only part we can evidence. Our own test company holds the names of real subcontractors, suppliers and workers; nobody has examined what personal information about those people its records contain; and we therefore do not claim that no individual's personal information has left the country. That is the honest limit of the mitigation, and §8.6 is the reason it matters: the people most likely to be named in that free text are precisely the ones who are not our users. The sequence is the defect, and it is ours.

Now the part that consent language usually hides, and it is worth reading twice. Turning AI on is a decision made by the customer's company owner — the builder. It is not a decision made by the person whose name is sitting in the free text. A subcontractor named in a defect, a worker named in an observation, a person named in a project manager's weekly review: none of them has any relationship with us, none of them is asked, and none of them would be told. The architecture is that one business flips a switch and another business's people are named in text that leaves the country.

We are not going to pretend that a company owner's click is those people's consent. So: if you are a builder and you enable AI features, telling the people whose personal information is likely to be in that free text is your obligation, before you enable it. The Data Processing Terms carry that as an express obligation, and if you would rather not take it on, the answer is easy — switch AI off, or never switch it on, and nothing leaves.

8.7 The sentence the product shows you at the point of use

DocSync shows you, on the screen where you press the button, what that AI feature is about to send. Most of those sentences are assembled from the payload itself rather than from a setting, which is the right way round.

Where they stand today, screen by screen, because a general reassurance would be worth nothing here. All eight surfaces in §8.4 now carry a sentence whose field list matches the prompt behind it, and seven of the eight add the caveat that free text can contain a name. The eighth is the RFI draft assist, where the first thing the sentence names is the notes you type here — the free text is the subject of the sentence rather than a footnote to it.

*The defect resolution draft used to end "No names, photos or comments were" sent. That was wrong in its first third: the prompt sends the defect's title and description, which are free text a site team typed and routinely name a person, and as §8.3 explains, pattern matching cannot support a "no names" claim. Earlier versions of this policy recorded the sentence as outstanding and warned you that the product and the policy disagreed. It has since been corrected in the product.* What that screen says now, in full, is:

"This defect's number, title, description, location, trade, priority, severity, current status, due date, the role it's awaiting, its aging and its status-history counts were sent to our AI provider, outside Australia. No photos or comments were sent, and no name, assignee or contact field was — but the title and description are free text and may contain a name."

Four of the eight screens name the destination; four say only "the AI provider". The project assistant, the defect resolution draft, the project health summary and the weekly review each take the destination from the server, which reports where the model actually is, so the words change if the provider ever moves to an Australian or on-server model instead of going stale. The RFI draft assist, the two chase notes and the submittal escalation note say "the AI provider" and name no country. That is not false — it is narrower than this policy, which does name the destination — and we would rather tell you which four than describe the set as uniform.

And one screen that is not in §8.4 at all, because it is not a feature — it is the consent. When a company owner switches AI on, the confirmation dialog will not proceed until they tick a box that says text their team types, including record titles and notes that can name workers and subcontractors, goes to a named destination, and that they have told those people or are otherwise permitted to share it. That tick is the only evidence either of us will ever have that the question was asked, so the destination in it is taken from the server rather than written into the screen, and it adds the one thing that is true on every deployment: the AI provider is a setting the operator can change, including to one outside Australia.

8.8 EU and UK staff

If you have staff or contacts in the EU or the UK, the GDPR may apply to their information regardless of where we sit. We have not drafted for the GDPR and this policy does not claim GDPR compliance. That is a deliberate choice, not an oversight: writing GDPR terms we have not analysed would be the same kind of unbacked claim this policy exists to avoid. If GDPR compliance is a requirement for you, raise it with us before you sign and we will tell you honestly where we are.

9. How we protect it

This section lists only controls that exist in the software today. §9.3 lists what does not exist. We would rather lose a deal than write a security section we cannot stand behind.

9.1 What is in place

Getting in

• Passwords are hashed with argon2id and re-hashed automatically when the parameters need strengthening. We never store or see a plaintext password.
• Sign-in is timing-safe — a wrong email takes the same time as a wrong password, so nobody can discover whether an account exists — and the error message never says which field was wrong.
• Sign-in, registration, session refresh and the two link-redemption paths are rate-limited, on the five windows listed below, and changing your own password is metered on the same budget. Every window is counted per worker process and this deployment runs two, so the ceiling a person can actually reach is double the configured number; every figure printed below is the deployed one, and no number in this pack may be published without that doubling applied. (1) 20 attempts a minute against any one account from one address, so one host cannot grind one person's password. (2) 240 password hashes a minute from one address, whatever accounts they name. (3) 1,200 session refreshes a minute from one address — a much larger window, because a refresh is cheap, and a separate one so that a stranger spraying failed logins at a site's address cannot log out the people already working there. (4) 1,200 attempts a minute from one address to redeem an invitation link or a password-reset link, kept separate from (3) for the same reason. (5) Inside that, 120 wrong links a minute from one address — attempts that turn out to carry a link we do not recognise or that has expired. A genuine link is never refused by window (5), because presenting a correct one is proof the caller is not the person guessing. Separately, a password reset may be requested at most 6 times an hour for any one email address from any one internet address.
• Both of the first two windows meter the expensive work rather than the request, and that is where they are spent. Windows (1) and (2) are charged on the line immediately before the password hash itself and nowhere else, so a successful sign-in costs a unit exactly as a failed one does, while a refusal that never reaches the hash — a stale consent version, an email already registered, an unrecognised link — costs nothing.
• Until 2026-08-31 window (1) was charged at the door instead, and that was a way to lock a named person out of their own account. It was spent on the first line of sign-in and registration, before the cheap refusals. So a stranger who knew your email address could offer it to the registration form twenty times — which hashes nothing, takes a fraction of a second and is refused every time because the address is already registered — and your correct password would then be refused for the rest of the minute. Repeated across a crew, it took a whole site office off the air for the cost of a stranger's afternoon. The charge has been removed from the door rather than moved: registration is metered by the work it does and is not keyed on the email address it names at all, so there is no longer a place in the code where that charge could be written back. Grinding one person's password still stops at window (1), which is what that window was always for.
• Until 2026-08-31 the password-reset window was keyed on the email address alone, and that made it a remote switch on somebody else's account recovery. Anyone who knew a colleague's email address could spend that colleague's entire hourly budget from anywhere, at no cost and without signing in, and the colleague would then be refused a reset link — on the one screen where a person who cannot get in has no other way past. It is now keyed on the asking internet address and the email address together, so a stranger spends the stranger's budget. That fix has a cost, and no way of keying a single window avoids it. The old key bounded your inbox at six reset messages an hour however many people asked; the new one bounds it at six an hour per asking address, so somebody with many addresses can send more. The choice was between unwanted mail in an inbox, which you can recover from, and losing account recovery, which you cannot. Nothing here should be read as a promise that the number of reset emails arriving at one address is capped overall, because it is not.
• Until 2026-08-31 the two link paths shared one budget, and a stranger could exhaust it with rubbish. Sixty malformed links cost the server almost nothing — one hash and one lookup each, no password hashing, nothing written — and used up the whole allowance for everyone sharing that internet address. A site office is one address, so a new starter could fail to accept this morning's invitation because a passer-by had been sending nonsense. There are now two budgets: the large one in (4) for attempts, and the small one in (5) charged only after a link has been found wrong. A real invitation or a real reset link never touches (5). What it still cannot do: an address that sustains 1,200 attempts a minute does still exhaust window (4) for everyone behind it — the same shared-address limitation described further down, now costing twenty times what taking a site office off the air used to cost.
• Changing your password while signed in is metered too, on the same address budget and for the same reason: it verifies your current password with argon2, and an authenticated caller should not be able to compel unlimited hashing any more than a stranger can. It is deliberately not keyed on your account, so a stolen session cannot lock you out of changing your own password.
• Every field and every credential a stranger can present carries a maximum length, checked before the value reaches any code, any database or any log — in the body of a request, in the web address, in a header and in a cookie alike. An oversized value is refused outright rather than cut short and stored. The limits are set at what a person could plausibly type or paste, and an automated test walks every public address in the product and fails the build if one is missing or is set so high that nobody could reach it.
• An earlier version of this policy said a successful sign-in did not count against window (2). That is no longer true, and the change was deliberate. Metering only failures left the most expensive request in the system — a correct password, which costs the server about 75 milliseconds of real work — free to anyone who knew one valid account. The window now counts the work, which means a crew's own morning contributes to it. At 240 a minute that takes a 240-person shift all arriving at once to matter, but the honest statement is that the budget is shared, not that your crew is exempt from it.
• What those limits still cannot do, said plainly. A limit keyed on an address is shared by everyone behind that address, and a site office is one address. Somebody sustaining 240 password attempts a minute from a site's public address will make new sign-ins from that address fail for up to a minute after they stop. People already signed in keep working throughout, a refused attempt is not itself recorded so hammering while blocked does not extend the block, and the attacker now has to pay for real hashing work rather than for cheap refusals. Closing the gap entirely needs either per-person state we do not keep or a CAPTCHA we have not added, and we would rather tell you the limit than imply there is none.
• The address those limits are keyed on is the address the connection actually came from. Until 2026-08-31 the reverse proxy added the true visitor to a header the visitor could also write, and the server picked an entry out of that header — so the address in the throttle, in the audit trail and on a consent record was one the visitor could choose, and two successive attempts to fix it were each defeated by an input nobody had anticipated. The header-reading code has been deleted. The proxy replaces the header with the connection's real peer, the server takes the address from the network connection itself, and the only machine that can reach the server is the proxy, because nothing else has a route to it. We are recording this because earlier versions of this policy described these controls as in place, with a number, and the number was defeatable by one header.
• Sessions live in httpOnly cookies, not in browser storage where a script could read them. Access tokens last 15 minutes; refresh tokens last 14 days. The refresh cookie is path-scoped so it is not sent on ordinary requests.
• Refresh tokens rotate on every use, and re-use is treated as theft — presenting an already-used token revokes that entire session family immediately. Tokens are stored hashed, never in the clear.
• Changing your password revokes every session everywhere.

Keeping companies apart

• A request for another company's data returns 404 Not Found, never 403 — so nothing leaks, not even the existence of a record.
• Which tables belong to a tenant is derived from the database schema automatically, not from a hand-written list. A new table that escapes it fails the build.
• Every stored file's key begins with the company id, and file keys are never exposed to the browser — downloads stream through an authenticated endpoint.
• Paid edition gates run ahead of the company-manager bypass, so an un-entitled manager and a stranger get the identical 404.

In transit

• HTTPS everywhere, with certificates issued and renewed automatically, HSTS enabled, and HTTP/3 available.
• Standard security headers on every response: nosniff, X-Frame-Options: DENY, a referrer policy, and a Content-Security-Policy. The API's policy is a full lock-down.

Logs and diagnostics

• Bearer credentials are stripped out of logs in three places — the URL and the referrer header are both filtered, because a single-origin app sends the full path in the referrer. The application server's own access log is disabled entirely because it was writing share and reset tokens verbatim.
• Error records are minimised before storage: paths are redacted, stack traces are reduced to file:line with no source text and no variable values, messages are capped and passed through the same scrubber that removes emails, phone numbers and ABNs, and database parameter dumps are removed wholesale.
• Operator alert emails deliberately omit the exception message, because that is the field most likely to carry your record titles and names, and an alert leaves the system to a mailbox outside the app's access controls.
• Delivered email jobs have their link tokens scrubbed once delivery finishes.

Proof that a record was not tampered with

• Every change writes an entry into a per-company hash chain. Each entry's hash includes the previous entry's hash, so altering or deleting anything breaks every entry after it and is detectable. This is what makes a signed certificate or a served payment claim provable later.

Build integrity

• Every third-party container image is pinned by cryptographic digest; Python dependencies install from a fully pinned lockfile; the web build uses a committed lockfile. Continuous integration tests the exact versions that ship.
• Only the reverse proxy is reachable from the internet. The database, the file store and both application servers sit on a private network with no published port.
• The deployment refuses to start if a required secret is missing, rather than starting with a weak default.

9.2 About encryption at rest — the honest answer

Your data is encrypted while it travels to us and it is not encrypted where it is stored: there is no transparent database encryption, no column encryption, the file store is not encrypted, and the backups are not encrypted.

There is one layer we have not accounted for and will not claim: our hosting provider's own disk-level encryption, which on that platform is normally on by default. We have not verified it, so we do not count it. Whether the underlying managed disk is encrypted by the platform is a question for the hosting provider, and when we have the answer in writing this section will say what we found and which layer it covers.

We will not say "your data is encrypted at rest" until that is confirmed, and even then we will say exactly what layer it applies to — because "encrypted at rest" meaning "the cloud provider encrypts its own disks" is not the same protection as "we encrypt your records", and vendors who blur the two are the reason that phrase has stopped meaning anything.

9.3 What we do not have

A security page that only lists strengths is not worth reading. As at [EFFECTIVE DATE], DocSync does not have:

• multi-factor authentication for users, single sign-on, SAML, or SCIM;
• an email verification step at sign-up;
• a penetration test, SOC 2, ISO/IEC 27001, IRAP assessment, or any external security certification;
• intrusion detection, a web application firewall, endpoint protection, or file-integrity monitoring;
• centralised log collection, a SIEM, or any off-host log shipping;
• automated dependency vulnerability scanning or a patch cadence — our builds are pinned and reproducible, which means they cannot drift, but also means nothing tells us when a pinned version becomes vulnerable;
• off-site backups (see §11.5), backup encryption, a database replica, or point-in-time recovery;
• automated breach detection of any kind (see §12);
• 24/7 support, an on-call rotation, or more than one operator.

To put the top of that list in one paragraph, because it is the paragraph that matters:

There is no multi-factor authentication for anyone, including us. There is no single sign-on, no email verification at sign-up, and no anomaly detection. There is no breach detection of any kind — the clock on any incident starts when a person tells us, not when a system does. And as at the date of this document we do not hold cyber or professional indemnity insurance. We will tell you when we do.

That last sentence is in here on purpose. A limit of liability behind a supplier who could not pay it is a number on a page, and you should be able to price that in before you sign rather than discover it afterwards.

We are one person building carefully, not a company with a security team. Judge us on that basis. These items are on the roadmap; off-site backups, an external uptime monitor and a published security contact are the first three.

10. Keeping it accurate (APP 10)

We are required to take reasonable steps to make sure the personal information we hold is accurate, up to date and complete. Here is how that works in practice, and where it does not.

What the software does well:

• Records are editable by the people who own them. A defect description, an inspection note, a directory entry, a daily log — the customer can correct any of them in the product, and the correction is recorded in the audit trail alongside what it replaced.
• You maintain your own details. Your name, email and job title are yours to change.
• Attribution is automatic, not typed. Creator, assignee and approver are set from the signed-in account, so they cannot be mistyped.

Where accuracy is genuinely limited, and we would rather say so:

• Free text is whatever someone typed. A visitor's name, a "responsible contractor", a person named in a safety violation or a witness statement is a foreman's typing on a phone at a job site. We do not validate it and cannot verify it. If a record about you is wrong, the fix is with the builder who wrote it — see §13.2.
• We do not verify email addresses. There is no email confirmation step at sign-up. An invitation sent to a mistyped address goes to whoever holds it.
• The audit trail is a historical record, not a current one. It says what was true at the moment something happened. It is not updated when the underlying fact changes, and by design it cannot be. That is the point of it — see §13.3.
• Custom fields are unvalidated by design. Whatever a company chooses to record, we hold.

What this means: we keep your information accurate by making it easy to correct and by recording who corrected what. We do not audit our customers' records for truthfulness, and we could not.

11. How long we keep it, and how deletion works

11.1 The short version

There is no per-customer retention setting. Every retention period above is set for the whole deployment, by us. You cannot shorten or lengthen one, and this policy is where you find out what they are.

11.2 Deleting your company account

Only a company owner can do it, from Company settings → Data & privacy. It is deliberately hard to do by accident:

1. You must type your company's name back to confirm.
2. Nothing is destroyed for at least seven days. The deadline is seven days, rounded up to the next midnight in Sydney time — so it is never less than seven full days, and can be up to eight.
3. During that window every member of the company sees a banner, every owner and admin is emailed, and any owner can cancel. Cancelling really does defuse it.
4. Export first. The same screen offers a full export — one ZIP containing readable CSVs per tool per project, plus a complete raw dump of every table, plus every file if you ask for them. Take it before you delete, not after.

Then the purge runs. It removes every row belonging to your company, every file stored under your company's prefix, and every user account left with no other company — a user who works for two builders is not deleted with one of them.

In one sentence: when a company owner asks us to delete the account we wait at least seven days — and never less than seven full days, because the deadline rounds up to the next midnight in Sydney — during which any owner can cancel and every member sees a banner; after that we destroy the company's records and files from the live service completely, in one operation, proved by a test that walks every table and every foreign key in the database.

We can say something about that proof most vendors cannot, and one thing about it they usually overstate. Completeness is proved by an automated test that walks the entire database schema, checks that no row belonging to your company and no orphaned reference survives, and does so with database cascades switched off so the sweep cannot be leaning on the database to do its job. A table added next year that escaped the sweep would fail our build rather than quietly keeping your records. What that test does not prove is that nothing anywhere survives — it reasons about rows tied to your company, so the three exceptions in §11.4 are outside its reach by construction. That is why §11.4 lists them by name.

11.3 What happens after the purge

• Any email still queued at that moment is finished off within about three hours.
• If a deletion job were ever lost — say, after a restore from an older backup — a daily sweep finds the overdue request and purges it, adding at most a day.

11.4 The five things that survive — and we are telling you before you ask

Five things survive that deletion, and we would rather you knew all five.

(1) A tombstone. One permanent record holding the company's name, the email address of the person who asked, and the date. It exists so we can answer "was this company deleted, and when" years later, and so a deleted account cannot be silently re-created.

(2) Error diagnostics we could not attribute to you. When something fails on a request that was not signed in — a failed sign-in, an expired reset link, an anonymous view of a share link — we record a diagnostic that carries no company. The deletion cannot find those rows because they are not linked to your company. They age out on their own within 30 days, or sooner once 10,000 have accumulated.

(3) Backups taken before the deletion. See §11.5. Your data is gone from the live service on the deletion date, and gone everywhere once the backup window closes.

(4) Background jobs that were still running when the purge ran. DocSync sends email through a queue, and a queued message holds the recipient's address, a subject naming your company and the full body of the message. The purge deletes those rows — but it cannot delete one that a worker is holding at that instant. A follow-up sweep chases the stragglers, and deletes them regardless after about three hours. The tombstone carries a count of how many were still outstanding, kept current until it reaches zero, so the record of the deletion can never overstate what was destroyed.

(5) Text already sent to our AI provider. If AI features were switched on — and they are switched on in the pilot deployment — prompt text has already left our server. There is no deletion path to it: we cannot reach another company's systems, and we have not obtained that provider's terms, so we do not know how long it keeps it. Deleting your account does not recall it, in the same way that a report you have already emailed out cannot be recalled. The only control is switching AI off before the text is sent. §8 sets out exactly what each feature sends.

The tombstone in detail. When a company is purged we write a permanent tombstone. It contains:

• the company name;
• the email address of the person who requested the deletion;
• the dates requested and purged;
• counts (how many audit entries, rows and files were destroyed) and the final hash of the destroyed audit chain.

It contains no project records. It exists so that a deletion can be proved to have happened — without it, a purged company is indistinguishable from one that never existed, and we could not answer "did you really delete it?" A copy is also written to file storage outside the company's own area so the file sweep cannot take it.

We have no path to delete a tombstone. So "delete my account" does not delete the email address of the person who asked. We think that is the right trade — accountability for deletion is worth one email address — but you should decide that knowing about it, not after.

11.5 Backups — and the thing you should know today

We take a backup of the database and the file store every night and keep it for up to [BACKUP_RETENTION_DAYS] days — but that backup is stored on the same server it is a backup of, no copy has ever been taken off that server, and until that changes we do not offer any disaster-recovery commitment, any recovery point objective for the loss of the server, or any promise to restore your data on request. Today that number is 15: the retention is 14 days, evaluated only when the next nightly run happens.

A backup held on the disk it backs up protects you against a mistake — a bad deployment, a corrupted table, a deletion that should not have happened. It does not protect you against the loss of the server itself. If that server were destroyed the backups would be destroyed with it. We are telling you this rather than describing our "backup regime", because the difference between those two sentences is the whole of the risk you are taking. Old backup sets are only removed after a successful backup, so if backups start failing the history is kept rather than pruned.

What that means for a deletion. A company deleted today remains inside backup sets for up to [BACKUP_RETENTION_DAYS] days. During that window your data is not accessible in the service and is used only to restore the service after a failure. The truthful formulation, which we would rather you had than a rounder number: your data is removed from the live service on the deletion date; backup copies taken before that date are destroyed once the retention window closes.

Backups are not encrypted, and when an off-site copy does exist we will say here how long it is kept and whether it is encrypted before it leaves the server. Today neither question arises, because nothing has ever left.

11.6 "Delete" inside the product is not always deletion

Six kinds of record — comments, corrective actions, documents, folders, forms and photos — are soft-deleted. They are hidden and recoverable, and their files are kept. There is no empty-trash, no purge and no age-out for them. They go when the whole account goes.

So: do not treat deleting a document in DocSync as destroying it. Most other record types are hard-deleted, so we also cannot offer a blanket "deleted items are recoverable" guarantee. If you need something genuinely gone before your account ends, ask us.

11.7 Records that outlive the person

Two categories of record hold information about people who never had an account, and nothing deletes them before the account ends:

• Share links. An expired or revoked link's record is kept, including the recipient's name and email address and how many times it was opened.
• External approvals. Where someone approves or rejects something through a public link, we keep their typed name and their free-text note.

We keep these because they are the record of who was given access to what and who approved what. If you are one of those people and you want that removed, contact [CONTACT EMAIL] and we will work out what we can do — see §13.

11.8 Your legal retention obligations are yours

DocSync has no concept of a statutory retention period. It does not model limitation periods, financial record retention, or WHS incident record retention obligations, and it will not stop you deleting something you are required to keep.

Security of Payment legislation, WHS law and your contracts may require you to keep construction records for years. DocSync helps you produce and hold them; it does not police them. Export your records before you delete your account, and keep them where your obligations require. The deletion email we send you says the same thing.

12. Data breaches

Australia's Notifiable Data Breaches scheme applies to eligible data breaches. If we suspect one, we must take all reasonable steps to assess it, and complete that assessment within 30 days, and if we conclude serious harm is likely, notify the OAIC and the affected individuals as soon as practicable.

Here is the honest part. We have no automated breach detection. No intrusion detection, no anomaly alerting, no alerts on unusual downloads, failed sign-ins or bulk exports, and no off-host log collection. Our controls are preventive and forensic — strong password hashing, session-theft detection, the tamper-evident audit trail, credential redaction in logs — not detective.

So in practice: we find out because a customer tells us, a third party tells us, or an attacker tells us. If a compromise is quiet, we may not learn of it.

Consequently:

• Every clock we commit to starts when we become aware, not when a breach occurs. We cannot commit to a time measured from an event we cannot detect.
• If we become aware of a breach affecting your information we will tell your nominated contact without undue delay and in any event within 72 hours of becoming aware; where we have told you in advance of a period during which the operator is unavailable, that period does not count towards the 72 hours and we will notify you within 72 hours of the operator's return — and we will not use that carve-out to delay a notification we are able to make. We will tell you even before we have finished assessing it. The carve-out exists because there is one operator and no cover arrangement, and a qualified clause we can meet is better evidence than an unqualified one we cannot.
• We ask you to tell us. If you see something — an account behaving oddly, a share link where it should not be, an email you did not expect — report it to [SECURITY CONTACT EMAIL]. With no detection on our side, you are a material part of the control, and we would rather have ten false alarms than miss one real one.

And one thing we are telling you against our own interest. [SECURITY CONTACT EMAIL] has to be created and a vulnerability disclosure policy published before this policy is issued, because until then a security researcher who finds something in DocSync has no way to reach us. With no automated detection on our side, a stranger's email is one of the few detection paths we have, and it does not work yet.

13. Seeing your information, and correcting it

13.1 Getting a copy (APP 12)

• If you are a company owner: use Company settings → Data & privacy → Export. You get one ZIP: readable CSVs per tool per project, a complete raw dump of every table your company owns, and, if you ask, every file. The download itself is recorded in your audit trail.
• If you are anyone else: ask the company that added you — they can produce it in minutes and they hold the context. If you cannot get an answer, email [CONTACT EMAIL] and we will help.
• If you are asking us about your own account: email [CONTACT EMAIL] and we will respond within 30 days, usually far sooner.

One record about you that is easy to overlook. We hold, against your user, which documents we required you to accept, the exact version of each one we served you at that moment, when you accepted, and whether it was at signup or in response to a new version (§4.1). It is yours to ask for and we will give it to you. It does not appear in a company's export, because it belongs to you rather than to the company — the Terms of Service say so.

What it costs you, and what happens if we say no. Making a request costs nothing — we will never charge you for asking (APP 12.7). If giving you access involves real work and we do charge for that work, the charge will not be excessive and we will tell you what it is before we do the work, not after (APP 12.8). If we refuse a request, in whole or in part, we will tell you in writing, give you our reasons, and tell you how to complain — including that you can go straight to the OAIC without our permission (§18). The same applies if we refuse to correct something (§13.2).

Two honest limits on an export:

1. An export does not contain error diagnostics. Those are deliberately excluded because they are our operational data across all customers, not yours, and they hold no project records. Most of them are destroyed with your account; the ones we could not attribute to a company are not, and they age out on their own — §11.4(2) explains why. If you want to know whether any exist about you, ask us and we will check by hand.
2. A company export contains other people's information — colleagues' names and email addresses in the directory and inside audit entries. That is unavoidable in a portable copy of a shared workspace. Handle it accordingly; you take on obligations when you receive it.

13.2 Correcting your information (APP 13)

• Your own account details — name, email, job title — you can change yourself, or ask the company owner.
• Project records about you — a defect description, an inspection note, a daily-log entry — are the customer's records. Ask the customer. They can edit them. We will pass a request on and follow up, but we will not rewrite one business's project records because a third party asked us to.
• The audit trail is a different matter, and here is the honest position.

13.3 Why we cannot edit the audit trail

Every change is chained: each entry's hash is computed from its content plus the previous entry's hash. Change one character and every entry after it stops verifying.

That chain is not decoration. It is what lets a builder show a certifier, an insurer, an adjudicator or a court that a signed compliance certificate or a served payment claim is genuine and unaltered. An erasure that broke the chain would make every signed certificate in that company fail verification — potentially years later, when it matters most.

Personal information does sit in that chain. Snapshots taken at the moment of a change include email addresses (when someone is added to a project or accepts an invite), a witness's name when they were added to an incident, the recipient list of a scheduled report, and an individual's trade licence number on a signed compliance certificate.

What we will not do: promise to remove it. We would be promising something the software cannot do, and a chain that can be recomputed is a chain that can be forged — which would destroy the only property it exists to provide.

And be clear about how much of it is genuinely stuck. The person who performed an action, their IP address and their browser string sit outside the hash. The before-and-after snapshots sit inside it — so a witness's name, an email address and a trade licence number captured in a snapshot are hashed, and they cannot be altered without destroying the chain. Any offer to "remove your identity from the audit trail" that did not say that would be describing the easy third of the problem.

So here is what we actually offer, and it is the remedy the statute contemplates:

1. A statement attached to the record (APP 13.4). If you ask us to correct something and we cannot — because it sits in the audit ledger, which is a hash-chained record we deliberately cannot edit — you may ask us to attach your statement that the information is inaccurate, out of date, incomplete, irrelevant or misleading, and we will add that statement as a new entry in the ledger so that anyone who ever reads the original also reads yours.

Adding an entry is exactly what the ledger is built to do, so your statement joins the chain without breaking it and without altering the original. Be clear about how it is done, though: there is no button in the product, no request form and no automated path. An operator writes the entry by hand, on request, using the ledger's own append mechanism, and tells you where it is held. We are describing a person doing a job, not a feature. Where a correction is possible in the ordinary records, we make it. If we refuse a correction or an access request we will tell you in writing, give our reasons, and tell you how to complain.

1. Complete destruction happens when the account is deleted. The audit chain belongs to the company and is destroyed with it. If your information sits in one customer's account, that deletion erases it entirely.

What we are not offering, and used to. An earlier draft of this policy said we would strip your identity out of the actor, IP and user-agent fields on request. We have removed that, for two reasons. It described a capability that does not exist — there is no such function in the product. And even if there were, it would leave untouched the personal information the paragraph above concedes is hashed into the chain, which is the part a person actually cares about. A remedy that sounds broader than it is, is worse than a narrower one that is real.

One forward fix worth naming. Two avoidable pieces of personal information are hashed into the chain and need not be — a scheduled report's recipient email list, which could be a count, and a compliance certificate's licence number, which could be a hash. Changing that helps future records only, never past ones, which is precisely why we would rather change it sooner.

14. Cookies, tracking and analytics

We use two cookies, both strictly necessary, and nothing else.

Both are httpOnly — JavaScript cannot read them — SameSite=Lax, and Secure in production. There is no cookie banner because there is nothing to consent to: we set no advertising, analytics or preference cookies, and no JavaScript in DocSync writes a cookie at all.

That absence is deliberate and it is the correct Australian position — please do not read it as an oversight. The cookie banner is a European mechanism, driven by the EU ePrivacy Directive's consent requirement for non-essential cookies. Australian privacy law has no equivalent provision; the Privacy Act regulates the handling of personal information, and a strictly necessary session cookie that we set on our own site is not a consent event. Adding a banner here would ask you to consent to something that neither needs your consent nor exists, and would train you to click through the ones that do matter. If DocSync ever sets an analytics or advertising cookie, this section changes first.

There is no third-party analytics or tracking in DocSync. None. Specifically:

• No Google Analytics, no Segment, no Mixpanel, no Amplitude, no PostHog.
• No session replay (no LogRocket, no FullStory, no Hotjar).
• No third-party error tracking (no Sentry, no Datadog). Errors go into our own database with the minimisation described in §9.1 and a 30-day maximum.
• No advertising pixels, no tracking images, no third-party scripts, no content delivery network.
• Fonts are downloaded at build time and served from our own server, so your IP address is never disclosed to Google or any font host.

This is enforced structurally, not by policy. The application's Content-Security-Policy blocks connections to any host other than our own — no analytics beacon, no external script, no third-party image can load. Adding one would require a code change, not a setting. And a search of the entire web application source finds not a single external URL outside test fixtures.

We think this is a feature, not an absence. Your project data does not leak into an advertising graph because there is no path for it to travel down.

We do use browser storage (not cookies) as described in §4.8 — a cached copy of your own profile, some UI preferences, and the offline queue for field work.

15. Children and young workers

DocSync is a business product. It is not directed at children, and there is no field anywhere in the data model for a date of birth or an age — so we could not tell you a user's age even if we wanted to, and we are not going to claim we screen for one.

But construction employs apprentices, and some of them are under 18. A 17-year-old apprentice can appear in DocSync exactly as any other worker does: in the directory, on timesheets with their hours and approvals, in site photographs, in a daily-log entry, in a toolbox-talk attendance record, and — if they are hurt — in an incident record with their injury details.

If you are a builder employing apprentices under 18:

• their information is treated by us exactly as any other worker's — the protections in this policy apply in full;
• you should consider whether a parent or guardian needs to be involved in consent for sensitive information, particularly injury records;
• you should be deliberate about photographs of minors on site and who can see them.

We do not have a mechanism to flag a minor in the product, and we are not going to imply we do. Whether anything further is required of you where your records include workers under 18 — particularly consent for health information — is a question for your own advice, and we would encourage you to get it before an incident, not after one.

16. Marketing

We do not send marketing email from DocSync, and there is no marketing email template in the product. Every email DocSync sends is transactional — an invite you were sent, a password reset you asked for, a notification you configured, a scheduled report you set up, a digest you opted into, or a service notice.

If we ever start sending marketing, it will be opt-in, it will have an unsubscribe link, and we will update this policy first.

17. Changes to this policy

We will publish any change at docsync.tech/legal/privacy with a new version number and effective date.

We give you at least 30 days' written notice before a change to these terms, to the Acceptable Use Policy, to the Privacy Policy, to our fees, or to the list of service providers who can receive your information; and if a change materially and adversely affects you, you may terminate before it takes effect and we will refund the unused portion of anything you have prepaid.

Thirty days, for every change to this policy. Not thirty days for the important ones and silence for the rest. An earlier draft of this policy reserved the right to make "clarifications and corrections" without notice, and we have deleted it. The reason is simple and does not depend on which document outranks which: a change to how we handle personal information is exactly the change you must be told about, and "clarification" is what every no-notice amendment clause calls itself on the way in. If the wording of this policy changes at all, the version number at the top changes, you get the notice, and — because the Terms of Service and this policy are both documents you accept in the product — you will be asked to accept the new version.

What this means, and where this policy sits: the Terms of Service §1.3 set the order of priority for the three documents that make up your agreement — the Terms, then the Acceptable Use Policy, then this Privacy Policy. On the handling of your personal information, this policy is what you have. An earlier draft of this section ranked the Data Processing Terms above it. That was wrong twice over: those Terms are not served on this site, so you could not read them, and nobody has signed one — ToS §1.3A now says so. If a Data Processing Terms is ever signed for your business it prevails from that date, and not before.

We will not change this policy silently, and we will not use a "we may amend this at any time by posting on our website" clause.

18. Complaints — and how to escalate past us

Step 1 — tell us. Email [PRIVACY OFFICER] at [CONTACT EMAIL], or write to [REGISTERED ADDRESS]. Tell us what happened and what you would like done. We will:

• acknowledge within 5 business days;
• investigate and give you a written response within 30 days;
• if we need longer, tell you why and when to expect an answer.

Step 2 — if it is your employer's or head contractor's record, we will route it. See §2.2. We will tell you who we passed it to and when, and we will follow up if they do not respond.

Step 3 — go over our heads. If you are not satisfied with our response, or we do not respond in 30 days, you can complain to the Office of the Australian Information Commissioner (OAIC), the independent regulator:

• Online: oaic.gov.au (complaint form)
• Phone: 1300 363 992
• Post: GPO Box 5288, Sydney NSW 2001

These are the OAIC's published contact details as at the date of this policy. Regulators move and renumber; if any of them has changed, oaic.gov.au is the authority and this page is not.

The OAIC can investigate, conciliate, and make determinations. You do not need our permission to go to them, and complaining costs you nothing. We would rather fix it first, but the escalation path is real and we are telling you about it deliberately.

You may also raise a work health and safety concern about an injury record with your state or territory WHS regulator — that is a separate path from privacy, and also open to you.

19. Placeholders in this policy

Every placeholder below must be filled before this policy is published. They are blanks waiting on a fact that exists, not uncertainty about what the software does.

End of draft. Prepared for review by an Australian legal practitioner. No corporate name, ABN, ACN or address has been inferred from the product name, the domain, or anything else.