Terms of Service

DocSync — Terms of Service

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

What this is. A pre-release draft, written by an engineering process from a factual audit of the DocSync codebase. It has not been reviewed, settled or approved by an Australian legal practitioner, 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. Do not let "DocSync" — a product name — become the entity name by default.

And it is nonetheless the agreement actually in effect, which is why the paragraph above matters. This document is served, without a login, at docsync.tech/legal/terms; the sign-up screen links it; and every user must tick a box naming it before an account is created. Between us and the pilot users we invite ourselves, these are the operative terms. That is a deliberate choice: a pilot user is better served by candid draft terms they can read than by no stated terms 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, so what you agreed to can be produced later rather than reconstructed.

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 what the software does is traceable to code or to the audit reports listed in Appendix B. Anything that could not be verified is not stated as a promise. Every placeholder is listed in Appendix A.

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

Service: DocSync, at docsync.tech

The six things that matter most

If you read nothing else, read this. Each row links to the clause that says it properly.

0. How to read this document

Plain English on purpose. Where a clause is dense there is a "What this means" line under it in italics. Where a fact about the software matters, it is stated as a fact and it has been checked against the code.

Defined words. A word in bold the first time it appears is a defined word and keeps that meaning throughout:

• We, us, our — [LEGAL ENTITY NAME] (ABN [ABN]; ACN [ACN]) of [REGISTERED ADDRESS].
• You, your, the Customer — the business that signs up for or is invited to administer a DocSync company account.
• Service — the DocSync software made available at docsync.tech, including its web application, its documented API, and any mobile or offline field mode.
• Order Form — a document or email recording what you are buying, at what price, for how long, signed or confirmed by both of us. There is no Order Form today: DocSync is not charging for the pilot and none has been issued. Where there is none, every reference in these Terms to the Order Form simply has nothing to operate on — it does not import a blank.
• Customer Data — everything you or your Users put into the Service, or that is generated from it: records, drawings, documents, photos, videos, signatures, comments, custom fields, and the personal information of any individual inside them.
• User — any person you or your administrators give access to your company account, including your staff, your subcontractors, and anyone you add as a directory contact.
• AUP — the DocSync Acceptable Use Policy, which forms part of this agreement (§1.3).
• SLA — the DocSync Service Level Agreement, published at docsync.tech/legal/sla. It is where the availability target, the support response times, the maintenance windows and the service credits are written, and it does not form part of this agreement unless it has been signed for you — see §1.3A. Nobody has signed one.
• Data Processing Terms — the DocSync Data Processing Terms, a template for a customer who asks for a data-processing schedule. It is not published on the website and it does not form part of this agreement unless it has been signed for you — see §1.3A. Nobody has signed one.
• Pilot Period — the period stated in the Order Form or, if none is stated, the period beginning on the start date and ending on the earlier of (a) the date we give you revised availability terms under §13.6 and (b) 12 months after the start date.

What this means: a "pilot" cannot run forever. If nobody wrote a period down, it is twelve months, and after that the availability terms in §13 stop applying.

1. Who this agreement is between

1.1 This agreement is between us and you. It starts on the earlier of the date you first access the Service and the date stated in the Order Form, and it continues until it is ended under §9.

1.2 The person who accepts this agreement warrants that they are authorised to bind the Customer. If you accept on behalf of a business, "you" means that business.

1.3 What this agreement is made up of — and it is only what you were actually given. This agreement is made up of these Terms of Service, the Acceptable Use Policy and the Privacy Policy. All three are published at docsync.tech/legal, all three are linked from the screen where you create an account, and you tick a box to accept the Terms and the Privacy Policy before the account exists. If they conflict, the order of priority is: these Terms, then the Acceptable Use Policy, then the Privacy Policy.

1.3A Three further documents, and none of them binds you unless you have signed it. DocSync also publishes a Service Level Agreement and holds a Data Processing Terms template and an Order Form template. They are not part of this agreement. Each of them is written to be signed for a particular customer — they carry blanks for a customer name, an agreement name and commercial figures — and none has been executed by anybody. The Service Level Agreement therefore gives you no availability commitment and no service credit today, and the Data Processing Terms impose no obligation on you and grant you no right. If and when one of them is signed between us, it becomes part of this agreement from that date, and from that date: an Order Form prevails over everything; a signed Data Processing Terms prevails on the handling of personal information; and a signed Service Level Agreement prevails on availability, support and credits.

What this means, and why it changed. An earlier version of this clause listed all six documents as part of the agreement and gave the Data Processing Terms priority over the Privacy Policy on personal information. That was wrong twice over: the Data Processing Terms are not served on the website, so you could not read them; and their own first page says nobody is bound by them. An agreement you tick should not silently make an unreadable document the top authority on your personal information. So the clause now incorporates the three documents you were actually shown, and says plainly what the other three are — templates for a deal that has not been done.

1.4 We are not a party to your construction contracts. Nothing here makes us your contractor, your subcontractor, your superintendent, your certifier, your principal, or your agent, and nothing here gives either of us rights or obligations under any contract you have with anybody else.

1.5 How you accept, and what we record

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.

These are pre-release drafts. They have not been settled by a lawyer, a settled version will be issued, and we will ask you to accept it then.

What this means: the record proves what we put in front of you and that you clicked accept. It does not prove you read it, and we will not claim it does. If you were added to a company account by an invitation rather than by creating the account yourself, no acceptance record is created for you today — the person who created the company accepted on the company's behalf under 1.2.

2. What DocSync is

2.1 DocSync is a record-keeping and coordination tool for construction businesses. It gives you a shared place to keep and route project records: RFIs, submittals, transmittals and correspondence; drawings and specifications with markup and pins; documents and photos; daily logs, defects, observations, inspections, incidents, meetings, tasks and forms; procurement, deliveries, equipment and timesheets; budgets, commitments, change orders, invoices, progress claims and retention; programme and schedule; and per-trade edition tools where you have subscribed to them.

2.2 The Service also does some arithmetic and some date maths for you — for example, budget roll-ups, retention calculations, programme critical-path figures, and due-date clocks on payment claims. These are conveniences built from the numbers and dates you enter. They are not advice, not a determination, and not a substitute for you or your advisers checking the result.

2.3 We provide the Service on a non-exclusive, non-transferable, non-sublicensable basis for your internal business purposes, during the term, subject to this agreement.

2.4 We keep ownership of the Service, the software, and everything in it other than Customer Data. You get no rights in it beyond the right to use it under this agreement.

3. What DocSync is NOT (read this one)

This section is deliberately blunt. It is the section a lawyer will ask you to point to if something goes wrong on a job.

3.1 DocSync is not engineering, building, surveying, legal, accounting or safety advice. It does not review, approve, check, validate or endorse anything you put into it. A drawing marked "current" in DocSync is current because someone in your business said so.

3.2 DocSync does not certify anything. The Service can produce documents that look like certificates — compliance certificates, lot and pour certificates, electrical, façade, steel and fire cause-and-effect records, ITP sign-offs, inspection sign-offs, handover dossiers, and photo capture certificates. In every case the certifier is the human being who signed it, using their own licence and their own judgment. The Service records the signature, freezes a copy of what was signed, and adds a tamper-evident hash so the record can later be shown not to have changed. That is an integrity record about a document. It is not our certification of the work, and we make no statement about whether the work complies with anything.

What this means: if a certifier, an insurer or a court asks who certified it, the answer is your signatory — never DocSync.

3.3 DocSync is not a substitute for your statutory duties. In particular:

• Work health and safety. The Service holds incident records, injury records, witness statements, corrective actions, inspections and safety observations. It has a "notifiable" flag and fields for a regulator reference and a reporting deadline. Those fields are things you fill in. The Service does not decide whether an incident is notifiable, does not notify any regulator, and does not tell you what your duties are. The reporting-deadline field is an internal reminder only. Its default is derived from an overseas recordkeeping standard and it is not the Australian notification deadline. Under Australian WHS legislation a notifiable incident must be notified to the regulator immediately on becoming aware of it, and the injury classifications in the Service are not the classifications your regulator uses. Notifying the regulator, preserving the incident site, and everything else the WHS legislation in your jurisdiction requires remains entirely yours.
• Security of Payment. The Service calculates indicative payment-schedule and adjudication due dates for NSW, Queensland, Victoria, South Australia, Western Australia and the ACT. If your project is in Tasmania or the Northern Territory the Service does not calculate any statutory date for you. These calculations contain known, deliberate simplifications: business-day counting skips weekends only and does not model public holidays; the adjudication window is treated as running after the payment-schedule window; and the calculated date can be manually overridden by a user. The Service does not serve a payment claim, does not serve a payment schedule, does not make an adjudication application, and does not tell you what your rights are. Any date the Service shows is a prompt, not a deadline. Check every statutory date yourself.
• Recordkeeping. The Service has no concept of a statutory retention period. It does not model limitation periods for contract or building actions, financial-record retention, or WHS incident-record retention. See §16.6 and §9.4.

3.4 DocSync is not a document-control authority, a QA system of certification, or an independent verifier. Where the Service marks something "current", "approved", "verified", "closed" or "signed", that reflects an action a User took under permissions you granted them.

3.5 DocSync is not a backup service and it is not an archive. See §13.4.

3.6 Third-party information is not ours. The Service can pull weather observations and forecasts, and geocode a project location, from a third-party public data source. We do not warrant that information and it must not be relied on for anything safety-critical or contractual. If a daily-log weather entry matters to a delay claim, verify it independently.

4. Your account, your Users, your responsibility

4.1 You control who gets in. Access to your company account is granted by your company owner and administrators. You choose which people become Users, which projects they can see, and what level of access (none, read only, standard, admin) they get on each tool. You can also add people as directory contacts — people whose name, email, phone and role you record but who never sign in.

4.2 You are responsible for what your Users do. Subject to 4.2A, every act or omission of a User in your company account is treated as your act or omission for the purposes of this agreement, including contractors, consultants and subcontractors you invite.

4.2A Except where we caused it. Clause 4.2 does not apply to an act or omission to the extent it was caused or contributed to by our breach of this agreement, by a defect in the Service, or by our failure to supply the Service with due care and skill.

What this means: you answer for the people you let in. You do not answer for what someone did because we left a hole they walked through — including a hole we chose not to close, like the absence of multi-factor authentication (§15.2).

4.3 Two things about visibility you should know before you invite anyone:

• Every person you add to a project can see the name, email address, job title and company role of every other person on that project. There is no per-tool permission that hides the project directory from a project member. If that is a problem for a particular person, do not add them to that project.
• Company owners and administrators can see every project in your company account, whether or not they have been individually added to it.

4.4 Look after your credentials. Keep passwords confidential, do not share logins, and tell us at [SECURITY CONTACT EMAIL] as soon as you suspect any unauthorised access. Sessions use short-lived access tokens with rotating refresh tokens, and changing a password signs every session out. The Service does not currently offer multi-factor authentication or single sign-on — see §15.2.

4.5 External share links. The Service lets you create a link that gives an outside party read access to a limited slice of a project — progress, photos, documents and drawings only. Financial, directory and audit data can never be shared through that surface. A link is a bearer credential: anyone who has it can use it until it expires or you revoke it, and it is normally delivered by ordinary, unencrypted email. You decide who receives a link and what it exposes. Revoke links you no longer need.

4.5A You are the sender. You authorise every invitation, share, notification and scheduled report email that your use of the Service causes to be sent, and for the purposes of the Spam Act 2003 (Cth) you are the sender of it. You warrant that each recipient has consented to receive it, or that you are otherwise permitted to send it. We transmit the message on your instruction and identify ourselves as the transmitting platform.

What this means: when DocSync emails your subcontractor an invitation, that email is yours, not ours. Only invite people who expect to hear from you about the job.

4.6 What you put in is your call, and your responsibility. The Service lets you define custom fields of any type on any tool and type anything into them, and its free-text fields are unbounded. We do not inspect, classify or validate what you collect. You are responsible for having a lawful basis to collect it, for telling the people concerned, and for not putting things in that do not belong there (see the AUP).

4.7 Accuracy. You are responsible for the accuracy, quality, legality and integrity of Customer Data, and for the means by which you acquired it.

5. Your data stays yours

5.1 You own your Customer Data. Nothing in this agreement transfers ownership of it to us.

5.2 The only licence we take is the one we need to run the Service. You grant us a non-exclusive, royalty-free licence — in Australia, and elsewhere only as described in the Privacy Policy and the subprocessor list — to host, store, copy, transmit, display, index, reformat and back up Customer Data, and to create derived copies (thumbnails, PDF renders, extracted text for search, canonical snapshots for the audit record) — solely to:

(a) provide, maintain and support the Service to you; (b) prevent or address technical problems or security incidents; and (c) comply with the law.

That licence ends when the data is deleted, except for the limited residual copies described in §9.4.

5.3 What we will not do with your data.

(a) We do not use your data to train, fine-tune or improve any machine-learning model of our own, and we never will. (b) We will not sell, rent or licence Customer Data to anyone. (c) We will not use Customer Data for advertising, profiling or marketing. (d) We will not disclose Customer Data to anyone except as set out in this agreement and the Privacy Policy, or as required by law.

5.3A Third-party AI providers

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 have not 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. AI features are switched on in the pilot deployment today, so that assessment is outstanding while a disclosure is already happening — clause 6.5A says so in terms rather than leaving you to work it out. 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, and your company owner can switch them off directly.

What this means: 5.3(a) is a promise about us, and we can keep it because we do not train models at all. We are not making a promise about somebody else's company whose terms we have not read. A supplier who tells you "your data is never used for AI training" while relying on a third party whose terms they have not obtained is telling you something they do not know. We would rather say the narrower thing that is true.

5.4 Aggregate statistics. We may produce statistics about how the Service is used (for example, how many projects use a tool) provided they are aggregated, contain no Customer Data, and do not identify you, any User, or any individual.

5.5 Our access to your data. Our operational staff have technical access to the servers on which Customer Data is stored, because they run those servers. Access is limited to the smallest number of people needed to operate and support the Service, and is only used for the purposes in 5.2. We will tell you before accessing Customer Data for support, by email to your company owner, unless you asked us to, or an emergency makes prior notice impracticable.

6. AI features

6.1 AI features are switched on in the pilot, optional, and never load-bearing. The Service's AI features are gated behind a per-company entitlement, and an AI provider is configured for the deployment: AI features are switched on in the pilot deployment today, and prompt text is sent to a provider outside Australia. Where the entitlement is not active for your company, or where no provider is configured, every AI surface falls back to a deterministic, non-AI result and the product remains fully usable.

Who switches it on. Your company owner does, from Company → Editions, after confirming they understand that prompt text goes to a provider outside Australia. The same owner can switch it off there, and you can ask us to instead (6.8). We do not switch it on for you, and — stated plainly because it matters to how much weight this clause carries — nothing in the software stops an owner switching it on before we have assessed the provider.

This section is written in the present tense on purpose. An earlier draft of these Terms described AI in the prospective voice, as something that would happen if you asked. That was not true of the deployment, and a term written that way would tell you the opposite of what the Service does.

6.2 What the AI features do. They draft text a human then edits and saves — RFI drafts, defect-resolution notes, chase notes, submittal escalation notes, a weekly-review draft, a project-health summary, and an assistant that answers questions about records you already have permission to read, with citations. Nothing the AI produces is created, sent, approved or saved automatically. A person always reviews it and saves it through the normal form.

6.3 AI output is a draft. Treat it as one. AI output can be wrong, incomplete or misleading. It is not advice of any kind and it must never be presented as professional certification (see the AUP). You are responsible for checking anything you keep.

6.4 We do not store prompts or answers. The AI seam is stateless. There is no conversation store, no answer store, and no AI-generated record in the database. Our audit record captures only metadata about a request — which provider was used, how many characters were sent, which kinds of facts travelled — never the question, the evidence excerpts or the answer.

6.5 What leaves Australia, stated plainly

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 term about copies, not about content. Parts of what your team types do leave. Earlier versions of these Terms 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 state it that way. 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, so there is no unit and no street number to strip: the code does not read it. 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. Two limits on the City field: a street name typed into the City box does leave — Ocean Drive Terrigal contains no digits, so the check passes it — and a City value that is not a plain place name yields no coordinates at all, so the project gets no map pin. No project name, no identifier, no key, and no end-user IP address — the request is made by our server, not by your browser. The Privacy Policy §7.3 sets this out in full.

(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. Clause 6.5A says exactly what is sent, and clause 6.8 says 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, and it is a limitation of the Service rather than a fine point: a password reset, an invitation or a notification reaches nobody. Where the Service 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 the Service should be read as proof that a message arrived. On the day a real mail transport is configured the relay begins to receive every message — recipient, subject, and the full body including single-use invitation and reset links, and any scheduled report's table of your record data — and clause 6.6 requires us to tell you before that happens.

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, and all of them are listed on the subprocessor page named in 6.6.

The countries, as precisely as we can state them. Open-Meteo is operated from Germany, according to its own published information; we have not independently verified where its servers are. SMTP2GO is an Australian and New Zealand company; the country in which its mail servers process our messages is not established, and we have asked. Let's Encrypt (the Internet Security Research Group) is in the United States. Our AI provider processes outside Australia as at 2026-08-31; the specific country in which it processes is not established — we have not obtained its published terms. That country is read from the deployment's configuration, not written into the software: every AI screen asks the server where a prompt would physically go under the configuration it is actually running, and the answer today is a vendor endpoint outside Australia. DATA_RESIDENCY.md §5 sets out the mechanism and the two other answers it can give.

6.5A What an AI feature sends

Where AI features are on for your company, this is what is sent for the project health summary, which is the surface that sends the most.

No name field is sent — not the assignee, not the creator, not the attendee, not a contact — but a record title is free text somebody typed, a title can name a person, and on a residential job the project name is often the address.

What the project health summary sends: the project name, today's date, counts of open and overdue items per tool, the communications needing attention, and up to two record titles per tool. Budget figures only if both money settings are switched on, and they are off by default. Before anything is sent we remove email addresses, ABN-shaped numbers and Australian phone numbers by pattern matching. Pattern matching cannot recognise a name, so we do not tell you that names are removed.

Full detail, surface by surface, is in the Privacy Policy.

The order this happened in, because a term that hides it is worse than the fact. We said we would obtain and assess the provider's published terms, and record its processing country, its retention of API inputs and its training position, before AI was enabled for anyone. AI was switched on in the pilot first and that assessment has not been done. 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 those steps before a disclosure, not after it, and 5.3A now says so instead of promising it in the future tense.

6.6 Provider transparency and change. 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.

6.7 We do not warrant what an AI provider does with your prompt. See §5.3A, which sets out what we will and will not tell you about a provider's retention and training terms, and what we will obtain and publish — an assessment that is outstanding while AI is switched on.

6.8 You control whether AI runs on your account, and you do not have to ask us. Your company owner switches the AI entitlement off directly, in the product, at Company → Editions → Deactivate. It takes effect immediately, costs nothing, and affects nothing else: every AI surface falls back to the deterministic version and the product stays fully usable. You may also ask us to do it for you, and we will, without charge — but the control is yours and it does not depend on us answering an email.

What this means: the switch that stops prompt text leaving the country is one your own owner can press, at any hour, without us. What it does not do is recall text already sent — §9.4(d)(5) says so.

7. Fees, trials and non-payment

7.1 Fees. You pay the fees in the Order Form: [FEES], billed [BILLING PERIOD], in Australian dollars. Unless the Order Form says otherwise, fees are exclusive of GST, and GST is payable in addition on a valid tax invoice.

7.2 Trials and pilots. Where the Order Form provides a free trial or a pilot, the Service is provided free for [TRIAL PERIOD]. We will tell you at least 14 days before a free period ends and what it will cost after that. If you do nothing, the account does not automatically convert to a paid subscription — we will not start charging you without your agreement.

7.3 Payment. Invoices are payable within [PAYMENT DAYS] days. If you dispute an invoice in good faith, tell us within 14 days of receiving it, pay the undisputed part, and we will work through the rest under §20.

7.4 Price changes. We may change our fees for a renewal term by giving you at least 60 days' written notice before the renewal date. If you do not want to pay the new price, you may decline to renew, or terminate on the renewal date, at no cost. We will not change the price during a term you have already paid for.

7.5 What happens if you do not pay

This clause describes what the software actually does today.

(a) If an invoice is overdue we will email you. We will give you at least 14 days' written notice before taking any of the steps below.

(b) We may switch off paid trade editions. Switching an edition off removes its tools from your navigation and marks the custom fields it added as inactive. It does not delete anything. Every value recorded against those fields is preserved exactly as entered and reappears, unchanged, if the edition is switched back on.

(c) We may suspend access to the account if an invoice remains unpaid 30 days after the notice in (a). Suspension means you cannot sign in. It does not delete Customer Data. We will lift a suspension promptly once payment is made.

(d) We will not delete your project records because you stopped paying. The base platform does not have a payment gate and non-payment does not trigger deletion of any kind. The only thing that destroys your project records is a deliberate deletion request by your company owner under §9.4.

(e) Your export right survives non-payment. If we suspend under (c) we will, on request, either restore access for long enough for you to run a full export, or run one and give it to you. We will not hold your data hostage over a fee dispute.

(f) Disputed invoices are excluded. We will not deactivate an edition under (b) or suspend under (c) in respect of an amount you have disputed in good faith under §7.3, while the dispute is being worked through under §20 and you have paid the undisputed part.

What this means: not paying costs you access and costs you the paid add-ons. It does not cost you your records. And a bill you are genuinely arguing about is not a bill you can be switched off over.

8. Getting your data out

8.1 You can export everything, any time, without asking us. A company owner can trigger a full export from Company settings → Data & privacy → Export. The Service builds an archive containing:

• a readable layer — one CSV per tool per project, the same exports the app produces;
• a raw layer — every table that carries your company's identifier, derived automatically from the database schema rather than a hand-written list, so it is complete by construction (see 8.2 for the seven tables that do not carry one);
• an inventory of every stored file, with its name, size and SHA-256 hash; and
• optionally, the file bytes themselves — every document, drawing, photo, PDF render and signature image.

8.2 What the export deliberately leaves out. Two credential fields are replaced with [redacted] (a project's inbound-email token and a share link's stored token hash), because handing them over would hand over live access. Internal error-diagnostic records are not included; if you want those, ask us at [CONTACT EMAIL] and we will provide what we hold about your company. Integrity hashes are deliberately not redacted, so an exported audit ledger can still be verified after you have it.

It also leaves out seven tables that are not scoped to a single company. The raw layer is built from the tables that carry a company identifier, so the export does not contain your members' own user records, the jobs queue, password-reset or session tokens, your members' notification preferences, their legal-acceptance history, or the deletion tombstone register. In plain terms: a departing customer does not receive their members' user records, their notification preferences, or their people's legal-acceptance history. Session and reset tokens are credentials and are excluded for the same reason as the two redacted fields. If you need any of the rest, ask us at [CONTACT EMAIL] and we will provide what we hold about your company's people.

8.3 Export is owner-only, and it is audited. Running or downloading an export is the largest single disclosure the Service can make, so only your company owner can do it, and the request, completion and download are each recorded in your audit ledger.

8.4 Export archives are stored under your account and are not automatically deleted. They are removed when your company account is deleted. If you want an export archive removed sooner, ask us at [CONTACT EMAIL].

8.5 Before you leave, export. See §9.4.

9. Ending this agreement

9.1 Term

This agreement runs for the term in the Order Form and then renews for successive periods of the same length, unless either party gives written notice not to renew at least 30 days before the end of the current term. We will remind you at least 30 days before each renewal, telling you the renewal date and the price.

9.2 Ending it for convenience

• You may terminate at any time on 30 days' written notice. If you have prepaid for a period beyond the termination date we will refund the unused portion on a pro-rata basis, less any amount you owe us and any reasonable loss we actually suffer as a result of the breach where we terminated under 9.3(a) for your material breach. We will give you a written breakdown of any amount withheld.
• We may terminate for convenience on 90 days' written notice. If we do, we will refund the unused prepaid portion, and we will keep your export available for the 30 days after termination described in 9.4(a).

9.3 Ending it for cause

Either party may terminate immediately by written notice if the other:

(a) materially breaches this agreement and does not fix the breach within 30 days of written notice describing it (or, for a breach that cannot be fixed, immediately); (b) becomes insolvent, has an administrator, liquidator or receiver appointed, or takes any similar step — in each case only to the extent that exercising the right is permitted by law, including Parts 5.1, 5.2 and 5.3A of the Corporations Act 2001 (Cth); or (c) is required to stop by law.

What this means: if you go into voluntary administration, Australian law suspends a supplier's right to walk away just because of the administration. We are not pretending otherwise.

We may also suspend rather than terminate for an AUP breach — see §10.

9.4 What happens to your data when this agreement ends

This is the honest description of what actually happens. It is deliberately more detailed than a standard clause, because "we delete everything" would not be true.

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.

(a) A 30-day window to get your data. For 30 days after termination we will keep your account available so you can run a full export (§8), or run one for you on request. There is no separate read-only or suspended mode in the product; this is something a person does.

(b) Deletion is something you trigger, and it is reversible for at least seven days. Only your company owner can request deletion, and they must type the company name back to confirm. Every company owner and administrator is emailed, and every member of the company sees an in-app banner. Any owner can cancel at any point during that window.

(c) What the purge destroys. When the grace period expires, the Service deletes every database row and every stored file belonging to your company, plus any user account left with no membership of any other company. This completeness is enforced automatically: the set of things deleted is derived from the database schema, and an automated test walks every table and every foreign key in the whole database and fails the build if a single row belonging to your company, or an orphan of one, survives. It also destroys your audit ledger.

(d) What survives, stated in full. 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. It also records when the purge ran, how many audit events the ledger held, and the ledger's final hash. It is held in two places (a database row and a file in object storage) and there is no process that removes either. This is a permanent retention of a small, specific set of personal information and it is disclosed here and in the Privacy Policy.

(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. Those records are automatically stripped of email addresses, phone numbers, business numbers, credentials and source-code text before storage.

(3) Backups taken before the deletion. See (e). 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 — §6.8 says how.

(e) Backups. We take a backup of the database and the file store every night and keep it for up to [BACKUP_RETENTION_DAYS] days — today that number is 15 — 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. Backups taken before the purge still contain your data until they age out. During that window your data is not accessible in the Service and is used only to restore the Service after a failure.

(f) Some queued background work finishes afterwards. This is survivor (d)(4), stated here as a timeline rather than as a category. Work an internal worker was already holding at the moment of the purge is cleaned up separately and is finished within about three hours of the purge, whether or not the worker that was holding it ever comes back. Until then the tombstone carries the count of what is outstanding, so it never claims the deletion is more complete than it is.

(g) What the completeness test actually proves. It proves that no row belonging to your company survives. The seven tables that do not carry a company identifier (see §8.2) and the unattributed diagnostics in (d)(2) are outside its reach, which is why (d) sets them out separately rather than leaving you to infer them.

(h) "Deleted" inside the product does not always mean destroyed. For documents there is a recycle bin and deleted items can be restored. For most other tools, deleting a record removes it immediately and we cannot undo it, except by restoring the whole system from a nightly backup that may be up to 24 hours old. Comments, corrective actions, folders, forms and photos are hidden rather than destroyed when deleted, and remain recoverable until the company account is purged.

(i) We do not delete your data just because the agreement ended. If you do not request deletion, your data stays until you do. If you want it destroyed, ask, or run the deletion yourself.

9.5 Your records are your problem, not ours

Before you terminate or request deletion, export and keep anything you are required by law to retain. The Service holds records that Security of Payment legislation, WHS legislation, tax law, limitation periods and your own contracts may require you to keep for years. The Service does not model any of those retention periods and will not warn you about them. Once a purge completes, we cannot get your data back, and neither can you.

One of those obligations is the one a deletion is most likely to defeat. The timesheet module holds hours, approvals, approval notes and applied pay rates for named individuals. Those are employee records, and under s 535 of the Fair Work Act 2009 (Cth) and the Fair Work Regulations an employer must keep them for seven years. A deletion requested by your company owner destroys them seven to eight days later. Export your timesheet records before you request a deletion, and keep the export. We will say the same thing on the deletion-confirmation screen.

9.6 Survival

Sections 3, 4.2, 4.2A, 4.5A, 5, 9.4, 9.5, 9.6, 15, 16, 17, 18, 19, 20, 21 and 24 survive termination, along with any accrued rights and any clause that by its nature should survive.

10. Acceptable use and suspension

10.1 You and your Users must comply with the AUP, which forms part of this agreement.

10.2 Before we suspend, we talk to you. If we believe you or a User have breached the AUP:

(a) we will give you written notice describing the conduct and what needs to change; (b) you have 7 days to fix it (or a shorter period we state, if the breach is serious and ongoing); and (c) if it is not fixed, we may suspend the affected User, the affected feature, or the account, by written notice.

10.3 Emergency exception. We may suspend immediately, without the notice in 10.2, only where we reasonably believe it is necessary to:

(a) stop an imminent and serious risk to the security or integrity of the Service or another customer's data; (b) stop material harm to a person; or (c) comply with a law, court order or regulator direction.

If we suspend under this clause we will tell you as soon as reasonably practicable and in any event within 24 hours, explain why, and work with you to restore service as quickly as we safely can. Where we have told you in advance of a period during which the operator is unavailable, that period does not count towards the 24 hours and we will tell you within 24 hours of the operator's return — and we will not use that carve-out to delay a notification we are able to make.

10.4 Suspension is not termination. A suspension does not delete Customer Data, and your export right under §8 continues (if suspension prevents you from using it, we will run an export for you on request). We will lift a suspension as soon as the cause is resolved.

10.5 Proportionality. We will suspend the narrowest thing that solves the problem — a single User or a single feature before the whole account.

11. Changes to the Service

11.1 We will keep improving the Service, and most changes will simply appear.

11.2 We will not materially reduce the core functionality you are paying for during a term you have already paid for, except where we must for legal or security reasons.

11.3 Deprecation. If we are going to remove or materially change a feature you use, or change the documented API in a way that is not backwards-compatible, we will give you at least 60 days' written notice together with a documented migration path, and we will keep the old behaviour available for that period where it is technically possible.

What this means, and why 60 and not 90: running two versions of a feature side by side is work one person does by hand. Sixty days with a written migration path is a promise we can keep; ninety days was a longer number we would have had to break. Every other notice period in this agreement is 30 days — this one is longer because a deprecation is harder to work around.

11.4 Emergency changes. We may make a change with less notice where it is needed for security, to fix a serious defect, or to comply with the law. We will tell you as soon as we can and explain why.

11.5 If a deprecation materially and adversely affects you, you may terminate under §12.3.

11.6 How a notice actually reaches you. A notice under §6.6, §11, §12 or §15.7 is written and sent by a person, by ordinary email from [CONTACT EMAIL] to your company owner. There is no automated announcement broadcast in the Service, no status page and no published changelog — and this is not a stylistic preference: the Service does not deliver email at all on this deployment (§6.5(4)), so a notice cannot be automated even if we wanted it to be. When the Service does deliver mail, it runs through a single relay with a monthly volume cap. See §21.5 for when the notice period begins.

12. Changes to these terms

12.1 We may update these Terms, the AUP or the Privacy Policy, but only on the following basis.

12.2 Notice. 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.

The notice describes what is changing and why. We will not change this agreement unilaterally without notice. Changes take effect at the end of the notice period. The one longer period in this agreement is the 60 days for a deprecation under §11.3.

12.3 If you do not accept a change

If a change (or a deprecation under §11.3, or an AI provider change under §6.6) materially and adversely affects you, you may terminate this agreement by written notice given before the change takes effect. If you do:

(a) termination is at no cost and no penalty; (b) we refund the unused prepaid portion of your fees on a pro-rata basis; and (c) the 30-day export window in §9.4(a) runs from the termination date.

12.4 Immediate changes we can make without notice, where we consider acting reasonably that they only ever benefit you or are forced on us: fixing a typo or a broken link; a change required by law with a shorter compliance deadline than 30 days (we will still tell you as soon as we can); and a change that gives you more rights or fewer obligations. If you disagree that a change falls into this clause, tell us — and if it materially and adversely affects you, §12.3 applies as though we had given notice under 12.2.

What this means: we do not get to decide, on our own and finally, that a change was good for you. The list is closed, we have to be reasonable about it, and if we get it wrong you have the same exit you would have had.

12.5 Changes are not retrospective. A change never applies to a dispute or a claim that arose before it took effect.

13. Availability — pilot and beta

This section is the most important one for setting expectations, and it is written from a factual audit of how the Service is actually run.

13.1 The Service is currently provided as a pilot. Subject to §16.1, and to the maximum extent the law allows, during the Pilot Period the Service is provided on an "as is" and "as available" basis, may contain defects, may change without warning, and may be unavailable. *Nothing in this clause excludes, restricts or modifies any consumer guarantee or other right you have under the Competition and Consumer Act 2010 (Cth) that cannot lawfully be excluded.*

13.2 What you should know about how it is run today. DocSync runs on one server. Every deployment restarts it. There is no redundancy behind any component, and if something fails overnight we may not know for several hours. Our availability target is stated in the Service Level Agreement, it is a target and not a guarantee, and the service credits that go with it do not begin to accrue until the independent monitor named in that agreement is running and its start date is recorded. The promise we can actually keep is a different one: an outage of ours does not stop a crew working. Site packs, offline capture and queued replay mean work captured on a phone on site is held on the device and sent when the connection returns, and our incident notices tell a customer with a statutory deadline not to wait for us.

The server is operated by a single person. There is no failover, no second server, no second region, and no on-call rotation. There is no external monitoring, which means we may not know the Service is down until somebody tells us. Support is available during [SUPPORT HOURS] Australian Eastern Time only. There is no 24/7 support.

13.3 What we do commit to during the Pilot Period. Not a number, but a practice:

(a) Support response times are set out in the SLA §5. (b) Backups run daily, on the same server they back up — see 13.4(c). (c) We will never tell you to wait for us when you have a statutory deadline. If the Service is down and you have a payment claim to serve or a notification to make, serve it and make it by other means. See §16.6. (d) Field work keeps working when we do not. The offline field mode holds captured defects, defect transitions, daily logs, observations, incidents, inspection responses, photos and attachments on the device and replays them when the Service returns. An outage costs a crew on site nothing except the delay in syncing. This is the strongest availability promise we can honestly make, and we make it deliberately.

13.4 What we do NOT promise during the Pilot Period

(a) We do not publish an uptime percentage, because we do not yet measure uptime: there is nothing outside the server asking it whether it is alive, and a number we cannot measure is a number we cannot defend, disprove or credit against. (b) Recovery points and recovery times are set out in the SLA §7. (c) Backups. We take a backup of the database and the file store every night and keep it for up to [BACKUP_RETENTION_DAYS] days — today that number is 15 — 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.

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. (d) No commitment to restore Customer Data on request. (e) No resolution times. We commit to responding and updating, never to a time by which something will be fixed.

What this means: keep your own copies of anything you cannot afford to lose. Run an export regularly. We would rather tell you this now than have you discover it later.

13.5 Excluded from any availability measure, if one is agreed in future: planned maintenance (including deployments, which cause downtime); failures of upstream providers (hosting, DNS, certificate authority, email relay, AI provider); force majeure; your own connectivity or equipment; features labelled beta; and AI features.

13.6 When the Pilot Period ends, we will offer revised availability terms in writing at least 30 days beforehand, and §12.3 applies if you do not accept them.

14. Support

14.1 Support is by email to [SUPPORT EMAIL] during [SUPPORT HOURS] Australian Eastern Time. There is no telephone hotline, no 24/7 support and no after-hours guarantee.

14.2 We commit to acknowledging and updating, never to a fix time. The response times and the incident communication clocks are set out in the SLA §5, and they live there and nowhere else so there is only ever one set of numbers.

14.3 All response clocks start when we become aware of an issue. Because there is no automated outage detection today (§13.2), you telling us is often how we find out — please do.

15. Security and privacy

15.1 What we do. We take reasonable steps to protect Customer Data. Today those steps include: HTTPS everywhere with automatic certificate management and HSTS; argon2id password hashing; short-lived access tokens with rotating refresh tokens and reuse detection; sessions in HTTP-only, same-site cookies; rate-limited sign-in and password reset; timing-safe login that does not disclose whether an account exists; a strict per-tenant isolation model in which a request for another customer's data returns "not found" rather than "forbidden", so the reply does not tell a prober whether the record exists; per-tenant namespacing of stored files, only ever served through authenticated endpoints; a per-company tamper-evident audit ledger; automatic redaction of bearer credentials out of server logs; automatic stripping of email addresses, phone numbers, business numbers, credentials and source-code text out of internal error diagnostics; and pinned, reproducible builds of every dependency and container image.

One thing that is in the software and is not in operation, named here so the list above is not read as longer than it is. The product contains a privileged operator surface — a screen showing error diagnostics and no customer records — gated on an email allowlist held in the server environment and a separate server-side token. On this deployment the allowlist is not set, the gate fails closed, and the surface returns "not found" to everybody, including us (read from the server on 2026-08-31). It is a design we can describe, not a control we are relying on, and it is not multi-factor authentication for anybody's login — see §15.2, which says there is none.

15.2 What we do not have

We would rather be honest than impressive. As at the date of this draft the Service does not have: multi-factor authentication or single sign-on; an independent penetration test; SOC 2, ISO/IEC 27001, IRAP or any other security certification; intrusion detection, a web application firewall, or DDoS protection; security event monitoring, log aggregation or alerting; automated dependency vulnerability scanning; application-level or database-level encryption at rest; encrypted backups; or a second operator. Do not describe DocSync to anyone as "enterprise-grade", "SOC 2 aligned" or "bank-level" — none of those is true.

Said once more, in the words we use everywhere else in this pack: 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.

What this means: the liability cap in §16.3 is backed by the business, not by an insurer. We would rather you knew that before you signed than after something happened.

15.3 Encryption at rest. 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.

15.4 Security incidents and data breaches.

(a) We do not have breach detection. There is no intrusion detection, no anomaly detection and no security alerting. We may learn of a breach because you tell us, because a third party tells us, or not at all. You must tell us promptly at [SECURITY CONTACT EMAIL] if you observe or suspect anything. (b) 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 what we know, what we are doing, and what you may need to do. Every clock in this clause runs from our awareness, not from the incident. (c) Where the incident is an eligible data breach under the Notifiable Data Breaches scheme in Part IIIC of the Privacy Act 1988 (Cth), we will carry out a reasonable and expeditious assessment within 30 days of becoming aware of grounds to suspect it, and notify the Office of the Australian Information Commissioner and affected individuals where the scheme requires. We will consult you first where the affected individuals are yours, unless the law requires otherwise. (d) You must not make a public statement attributing a breach to us without first giving us a reasonable opportunity to review it — except where you are required by law to notify, in which case you may notify, immediately, without our agreement.

15.5 Privacy. How we handle personal information is set out in the Privacy Policy at docsync.tech/legal/privacy, which forms part of this agreement. In summary: you decide what personal information goes into the Service and why; we handle it to run the Service for you; the Australian Privacy Principles govern how we do that; and what leaves Australia is set out in §6.5 — four things, none of which is your file store or your database, and one of them is AI prompt text, because AI features are switched on in the pilot deployment.

15.6 Your privacy obligations. You must have a lawful basis for collecting the personal information you put into the Service, must give the people concerned whatever notice the law requires, and must not put in categories of information you are not entitled to collect. This matters more than usual in DocSync, because the Service holds injury and health information about workers, statements about people who never signed up, worker time and pay-rate records, photographs of people on site, and free-text fields into which anything can be typed. See the AUP.

15.7 Subprocessors. 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.

16. Liability

Read 16.1 first. It is the clause that protects your rights.

16.1 Your Australian Consumer Law rights are untouched

Nothing in this agreement excludes, restricts or modifies any guarantee, condition, warranty, right or remedy that you have under the Competition and Consumer Act 2010 (Cth) — including the consumer guarantees in the Australian Consumer Law — or under any other law, where doing so would be unlawful. Those guarantees include that services will be supplied with due care and skill, will be fit for any purpose you made known to us, and will be supplied within a reasonable time.

Where we are entitled to limit our liability for failing to comply with a consumer guarantee (rather than exclude it), our liability for that failure is limited, at our option, to:

(a) resupplying the services; or (b) paying the cost of having the services resupplied.

This clause operates under s 64A of the Australian Consumer Law, which applies because the Service is not of a kind ordinarily acquired for personal, domestic or household use or consumption.

What this means: if we do a bad job, you have rights under Australian law that this contract cannot take away, and we are not trying to take them away.

16.2 What neither of us is liable for

Subject to 16.1, neither party is liable to the other for any indirect or consequential loss, or for any of the following however arising, even if the party was told it was possible: loss of profit, loss of revenue, loss of anticipated savings, loss of business or opportunity, loss of goodwill or reputation, loss or corruption of data, except to the extent the loss or corruption was caused by our failure to take the backup steps described in §13.3(b) or by our failure to supply the Service with due care and skill, or any liquidated damages, delay costs, prolongation costs, disruption costs or acceleration costs payable by you under a construction contract.

What this means: an exclusion of data loss with an exception that points at a promise we do not make would be an exclusion with no exception at all. This one points at two things we do promise — running the nightly backup, and doing our job with due care and skill — so if we lose your data by not doing either of those, the exclusion does not save us.

16.3 The cap

Subject to 16.1, 16.3A and 16.5, each party's total aggregate liability under or in connection with this agreement, in contract, tort (including negligence), under statute or otherwise, is limited to the greater of:

(a) the total fees you paid or owed us for the Service in the 12 months immediately before the event giving rise to the liability; and (b) AUD $[LIABILITY FLOOR].

16.3A A higher cap for privacy and confidentiality

Our liability for loss arising from our breach of the Privacy Act 1988 (Cth), our breach of §19, or our breach of any Data Processing Terms signed for you (§1.3A) is limited instead to the greater of three times the annual fees payable for the Service and AUD $[PRIVACY SUPER-CAP].

What this means: a mass disclosure of your workers' injury records is not the same kind of event as a billing error, and it should not sit under the same number. It is the risk you cannot mitigate, could not insure through us, and did not create.

And the thing behind the cap. As at the date of this document we do not hold cyber or professional indemnity insurance. We will tell you when we do. A cap is a promise to pay up to an amount; it is worth what the business behind it is worth, and we would rather say so than let you assume otherwise.

16.4 One cap, not many

Each of the caps in 16.3 and 16.3A is a single aggregate cap across all claims to which it applies, not a cap per claim.

16.5 What the cap does not apply to

The caps in 16.3 and 16.3A and the exclusion in 16.2 do not apply to:

(a) liability that cannot be limited or excluded by law (including under 16.1); (b) your obligation to pay fees; (c) either party's fraud, or wilful or deliberate breach; or (d) death or personal injury caused by a party's negligence.

16.6 The construction clause

This clause exists because DocSync is used on construction projects with hard legal deadlines.

(a) The Service being unavailable, slow, degraded or wrong does not relieve either of us of our own contractual or statutory deadlines, and it does not relieve you of yours. If a payment claim must be served, a payment schedule must be provided, an adjudication application must be made, a notice must be given, an incident must be notified to a regulator, or a record must be produced, that obligation is unaffected by anything that happens to the Service. Serve it, give it, make it, and notify it by other means. (b) You must maintain your own records for statutory purposes. You must not rely on the Service as your only copy of any record you are required by law or by contract to keep. Export regularly (§8) and keep the export somewhere else. (c) Subject to §16.1, we are not liable for loss arising from a deadline you missed, a claim you failed to make or defend, a notice you failed to give, an adjudication you lost, a record you could not produce, or a regulator's action, except to the extent that loss was caused by our failure to supply the Service with due care and skill, or by a defect in the Service that we knew of and had not disclosed to you. (d) Date calculations in the Service are indicative reminders, not statutory deadlines. The Service labels them as such, states the simplifications it applies (§3.3), and permits you to override them. Subject to §16.1 and to (c), we are not liable for loss arising from reliance on an indicative date.

What this means: DocSync is a tool that helps you meet your deadlines, and meeting them stays your job. But if we build a calculator, ship it with a defect we knew about and did not tell you about, and you relied on it, that one is on us. The exclusion is not a licence to build something wrong.

16.7 Contribution

Each party's liability is reduced to the extent the other party (or someone the other party is responsible for) caused or contributed to the loss.

16.8 Mitigation

Each party must take reasonable steps to mitigate its loss.

17. Warranties

17.1 We warrant that: we have the right to provide the Service; we will provide it with due care and skill; we will not knowingly introduce malicious code into it; and we will comply with the laws that apply to us in providing it.

17.2 You warrant that: you have the right to provide Customer Data to us and to permit its use under §5.2; Customer Data does not infringe anyone's rights; and you and your Users will comply with the AUP and with the laws that apply to you.

17.3 Beyond 17.1 and §16.1, and to the extent the law allows, all other warranties are excluded — including any implied warranty that the Service will be uninterrupted, error-free, or fit for a particular purpose we were not told about. *Nothing in this clause excludes, restricts or modifies any consumer guarantee or other right you have under the Competition and Consumer Act 2010 (Cth) that cannot lawfully be excluded.*

18. Indemnity

18.1 You indemnify us against loss we actually suffer from a claim by a third party that Customer Data infringes that third party's intellectual property rights or breaches their privacy rights, or that arises from your material breach of the AUP.

18.2 We indemnify you against loss you actually suffer from a claim by a third party that the Service (excluding Customer Data and anything you combined it with) infringes that third party's intellectual property rights.

18.3 Both indemnities are subject to the caps in §16.3 and §16.3A, and neither extends to loss the indemnified party caused or could reasonably have avoided. Neither is unlimited. The indemnity in 18.1 is also subject to §4.2A: you do not indemnify us for something a User did because of our breach, a defect in the Service, or our failure to supply it with due care and skill.

18.4 An indemnity only applies if the indemnified party: tells the other promptly; does not admit liability or settle without the other's consent (not to be unreasonably withheld); lets the other conduct the defence if it chooses; and gives reasonable assistance at the other's cost.

19. Confidentiality

19.1 Each party must keep the other's confidential information confidential, use it only for this agreement, and protect it as carefully as it protects its own. Customer Data is your confidential information.

19.2 This does not apply to information that is public through no fault of the receiving party, was already known to it, is independently developed by it, or must be disclosed by law — and in that last case the party must, where it lawfully can, tell the other first.

19.3 Confidentiality obligations survive for 5 years after termination, and indefinitely for Customer Data and for anything that is personal information.

20. If we disagree

We want this to be cheap and quick for both of us. You are never forced into an expensive process.

20.1 Talk first. Email [CONTACT EMAIL] setting out the problem and what you want. We will respond within 10 business days and try to sort it out.

20.2 Escalate. If that does not work, either of us can give the other a written Dispute Notice. Within 14 days of the notice, someone senior on each side (for us, the founder) must meet — in person, by phone or by video — and try in good faith to resolve it. This costs nothing.

20.3 Mediation, if it helps. If the dispute is still unresolved 30 days after the Dispute Notice, either of us may propose mediation. If both agree, the mediator is chosen jointly, and we share the mediator's costs equally. If you are a small business, the Australian Small Business and Family Enterprise Ombudsman can help you access low-cost mediation, and we will participate in a mediation arranged through them.

20.4 You are never blocked from going elsewhere. Nothing in this section prevents either of us from: applying to a court for urgent injunctive relief; bringing a small claim in a tribunal; making a complaint to the Office of the Australian Information Commissioner about privacy, to the ACCC or a State fair-trading body about consumer law, or to any other regulator; or commencing proceedings where the other party refuses to participate in 20.2 or 20.3.

20.5 There is no compulsory arbitration in this agreement, and no waiver of class or representative proceedings.

20.6 Governing law and courts. This agreement is governed by the laws of New South Wales, Australia. The parties submit to the non-exclusive jurisdiction of the courts of New South Wales and the courts able to hear appeals from them. Non-exclusive is deliberate: if you are in another State, you are not forced to litigate in Sydney.

21. Notices

21.1 A notice under this agreement must be in writing and sent by email:

• to us, at [CONTACT EMAIL];
• to you, at the email address of your company owner recorded in the Service, and at any billing or notice address in the Order Form.

21.2 A notice is taken to be received on the business day it is sent, if sent before 5pm Australian Eastern Time on a business day, and otherwise on the next business day — unless the sender receives a delivery failure.

21.3 Keep your contact details current. If the owner email in your account stops working, our notices stop arriving, and that is on you.

21.4 In-app banners and product notifications are useful but are not formal notice, with two exceptions: (a) the deletion-request banner and the emails that accompany it are effective notice of a pending deletion; and (b) the in-app display required by 21.5, which forms part of the notice it accompanies.

21.5 For a notice under §6.6, §11.3, §12.2, §15.7 or a change to fees under §7.4, the notice period does not begin until we have both sent the notice and displayed it in the Service to your company owner.

What this means: 21.2 and 21.3 between them would otherwise let a change bind you because an email was sent to an address that had stopped working. For the changes that matter — a new service provider, a removed feature, a change to these terms, a change to the price — you have to have been able to see it in the product as well. If we do not do both, the clock does not start and the change does not take effect.

22. Assignment

22.1 Neither party may assign or novate this agreement without the other's written consent, not to be unreasonably withheld.

22.2 Exception: either party may assign to a successor of its business (by sale, merger, restructure or incorporation) on at least 30 days' written notice, provided the successor assumes all obligations. §12.3 applies if the assignment materially and adversely affects you. We expect to use this — the business is pre-incorporation and this agreement is expected to be novated to the operating company once it exists. That novation will not change your rights, your fees or your data-handling terms.

What this means: the entity holding your workers' injury records is not allowed to change overnight. You get the same 30 days and the same exit you get for any other material change.

22.3 We may use subcontractors and suppliers to help provide the Service (see §15.7), and we remain responsible for what they do.

23. Force majeure

23.1 Neither party is liable for a failure to perform (other than a payment obligation) caused by something genuinely beyond its reasonable control — including natural disaster, fire, flood, pandemic, war, civil unrest, industrial action not involving that party's own workforce, government action, and failure of a telecommunications, hosting or electricity provider.

23.2 The affected party must tell the other as soon as it can, do what it reasonably can to work around the problem, and resume as soon as it can.

23.3 If a force majeure event continues for more than 30 days, either party may terminate on written notice, and we will refund the unused prepaid portion of your fees.

23.4 Force majeure is not an excuse for everything. It does not cover a failure we could have prevented by taking the steps a reasonable provider would take, and it does not extend the notification obligations in §15.4.

24. General

24.1 Entire agreement. This agreement — these Terms, the AUP and the Privacy Policy (§1.3), together with any Order Form, Data Processing Terms or Service Level Agreement signed for you (§1.3A) — is the whole agreement about the Service and replaces anything said or written beforehand. This does not exclude liability for fraud or for misleading or deceptive conduct.

24.2 Severability. If a clause is unenforceable or unfair, it is read down to the minimum extent needed to make it enforceable, and if it cannot be read down it is severed and the rest continues.

24.3 No waiver. Not enforcing a right does not waive it.

24.4 No partnership. Nothing here creates a partnership, joint venture, employment or agency relationship.

24.5 No third-party rights. Nobody other than you and us can enforce this agreement.

24.6 Variation by agreement. Apart from §12, this agreement can only be varied in writing signed by both parties.

24.7 Counterparts and electronic signature. This agreement may be signed electronically and in counterparts.

24.8 Publicity. We will not use your name or logo publicly without your written consent.

Appendix A — Placeholder register

Every placeholder in this document. No corporate name, ABN, ACN or address has been inferred from the product name "DocSync", from the domain docsync.tech, or from anything else.

Appendix B — What this draft relies on

Every factual claim about the software traces to one of the four engineering audits produced on 2026-08-27 against branch full-web-app-build:

Facts specifically relied on, and where they came from:

• Deactivation preserves data. entitlement_service.deactivate and _deactivate_packs flip status and mark custom-field definitions inactive; no CustomFieldValue row is touched. There is no plan, subscription_status, suspended or past_due field on Company, and no base-platform payment gate exists. → §7.5(b), §7.5(d).
• Deletion is owner-gated, name-confirmed, and has a grace period of at least seven local days (7 days rounded up to the next Sydney midnight), cancellable, with email to every owner/admin and an in-app banner to every member. → §9.4(b).
• Purge completeness is enforced by an automated whole-schema test that walks every table and every foreign key and fails on a single surviving row or orphan belonging to the company. The seven tables that carry no company identifier are outside its reach. → §9.4(c), §9.4(g).
• The tombstone survives permanently and contains the requester's email address, in two places. → §9.4(d)(1).
• Error diagnostics recorded on unauthenticated requests carry no company, so the purge cannot find them; they age out within 30 days or once 10,000 have accumulated. → §9.4(d)(2).
• Backup retention is RETENTION_DAYS default 14, pruned with -mtime +14 by a daily cron — a real worst case of 15 days — and pruning only runs after a successful backup. → §9.4(e), §13.4(c).
• No backup copy has ever left the server. BACKUP_OFFSITE_SAS_URL is unset and the backup sets sit on the same disk as the database and file store they back up. → §9.4(e), §13.4(c).
• Deferred background jobs are finished within 3h 3m of the purge. → §9.4(d)(4), §9.4(f).
• Six models are soft-deleted (deleted_at) with no purge path; a recycle bin exists for documents only; there are 76 hard-delete routes. → §9.4(h).
• Export is owner-only, audited, built from the tables that carry a company identifier, with exactly two redacted columns, error_events excluded, and no TTL on the archive. The seven tables excluded from tenant scope are users, jobs, password_reset_tokens, refresh_tokens, user_notification_prefs, legal_acceptances and tenant_tombstones. → §8.1, §8.2.
• AI is entitlement-gated, AI_PROVIDER defaults to none, the seam is stateless, prompts and answers are never stored, audit rows carry metadata only, and the scrub removes emails, ABN-shaped numbers and AU phone numbers but cannot recognise a name. → §6.
• The project health prompt carries the project name and up to two free-text record titles per tool, and no name field. Incident titles do not reach it. → §6.5A.
• AI features are switched on in the pilot deployment: the provider setting is deepseek with a key configured, and the entitlement is active on the one company on the deployment. Prompt text goes outside Australia. → §6.1, §6.5, §6.5A.
• The acceptance record holds the user, the document key, the version the server served, the time and whether it was signup or re-acceptance; it is append-only; the documents are files in source control, not database rows. → §1.5.
• legal_acceptances carries no company identifier, so an acceptance history is not in a tenant export. → §8.2.
• Security of Payment date maths: per-jurisdiction windows, weekends-only business days, public holidays not modelled, manual override available. → §3.3.
• Eleven single points of failure; no external monitoring; 0–8 hour detection delay; no off-server backup; no encryption at rest by us; unencrypted backups; no MFA/SSO; no pen test; no certification; one operator. → §13, §15.2, §15.4(a).
• Offline field capture holds and replays work through an outage. → §13.3(d).
• Cross-tenant access returns 404, never 403. → §15.1.
• Every project member can read every other project member's email address; the members endpoint is gated by project membership only, with no tool permission on the read path. → §4.3.
• Share links expose exactly four sections — progress, photos, documents, drawings — and never financials, directory or audit. → §4.5.

Appendix C — Open questions before this can be issued

For the founder and the reviewing lawyer. These are decisions, not drafting.

1. The entity. Sole trader or company? Until there is one, there is no contracting party. §22.2 is drafted to allow novation to the operating company later.
2. AI on or off — and it is on. An earlier draft was written on the basis that AI features were switched off on every account, with §6 in the prospective voice. That was wrong: the production configuration was read on 2026-08-30 and the provider setting is deepseek with a key configured, with the entitlement active on the pilot company. §5.3A, §6 and the headline table are now in the present tense. The decision that remains is whether AI stays on, and the provider's published terms still have to be obtained, assessed and recorded — a step APP 8.1 required before the disclosure and which was not taken. The no-training warranty about a third party that stood in the previous draft has been deleted, not softened.
3. The liability floor (§16.3(b)) and the privacy cap (§16.3A). A cap of "fees paid" is a cap of zero during a free pilot. Both need real numbers.
4. Fees, trial length and billing (§7). None of this exists in the software. Everything is invoiced and tracked out of band today.
5. Support hours (§14.1). One person. Be realistic.
6. The two things that must exist before this contract can be honoured. The subprocessor page now exists and is published. Still outstanding: a way to display a notice in the Service to a company owner (§21.5) — there is no announcements surface, only the deletion banner and the legal re-acceptance prompt — and a monitored security contact address (§15.4(a)).
7. Off-server backups (§13.4). Until they exist and a real restore has been performed from them, §13.4(c) must stay exactly as written.
8. At-rest encryption (§15.3). The clause now states what we apply, which is nothing. If disk-level encryption is later confirmed in the hosting console it is an addition, not a replacement.
9. Exclusive vs non-exclusive jurisdiction (§20.6). Non-exclusive is drafted deliberately so a small builder in another State is not forced to Sydney. Confirm that is the intention.
10. Unfair contract terms review. Every clause that gives us a right you do not have — 9.2 (90-day termination for convenience), 10 (suspension), 11 (service change), 12 (variation) — has been drafted with notice and an exit right for this reason, and 4.2A, 7.5(f), 9.2, 9.3(b), 12.4, 13.1, 16.2, 16.3A, 16.6(c)–(d), 17.3, 21.5 and 22.2 have each been narrowed in this revision. A lawyer must confirm the balance is right, because since November 2023 proposing an unfair term in a small-business standard-form contract is itself a contravention carrying penalties. §24.2 (severability) is not a defence to proposing one.
11. GDPR. Not drafted, and deliberately so. A customer with EU or UK staff whose personal data ends up in the Service may ask for it. Flagged as future work.
12. Does any existing pilot arrangement, tender response or conversation already promise something these Terms contradict? Check before issuing.
13. The two product changes that would move the sensitive-information position more than any drafting: an elevated permission tier for injury sub-records, and a consent flag on the injury record. Neither is built. §15.6 and the AUP disclose their absence rather than pretending otherwise.

End of draft. Prepared for review by an Australian legal practitioner. Nothing in this document has been sent, published, executed or committed.