Service Level Agreement

DocSync — Service Level Agreement

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

What this is. A pre-release draft, written from the DocSync source code, its operations documentation, and measured drill figures recorded on the pilot server. It has not been reviewed or settled 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, listed in the Annexure.

And it is nonetheless live, which is why the paragraph above matters. This document is served, without a login, at docsync.tech/legal/sla, so a reader can see exactly what we do and do not promise before they depend on the service. No customer has executed it and nobody is entitled to a service credit under it: [CUSTOMER NAME] and [AGREEMENT NAME] are unfilled, the pilot is free, and §2.4 says the availability target carries no credit until [MEASUREMENT START DATE] exists — which it does not.

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 the settled Terms it accompanies. 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 number in this document is either measured on the production server or explicitly marked as a target or a budget. There is no number in here that was chosen because it looked good in a tender.

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

Supplier: [LEGAL ENTITY NAME] (ABN [ABN], ACN [ACN]), of [REGISTERED ADDRESS] Customer: [CUSTOMER NAME] (ABN [CUSTOMER ABN]) Forms part of: [AGREEMENT NAME] (the Agreement)

0. Read this first

0.1 The one-paragraph version

DocSync runs on one server, operated by one person. There is no second server, no failover, and nobody on call overnight. What this agreement gives you instead of a percentage is: a stated availability target with a defined measurement method; maintenance scheduled around an Australian site day; support response times a real person can actually hit; a service credit if we miss, once there is a monitor to measure the miss; a right to walk away if we miss chronically; recovery numbers that were measured on the actual server, twice, with a stopwatch; and a blunt list of what is not guaranteed yet and why. In exchange we ask one thing of you: do not build your statutory deadlines around us being up.

0.2 Why there is no 99.9% in this document

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.

The arithmetic behind that, so you can check it. A 99.9% monthly commitment allows 43 minutes and 12 seconds of downtime in a 30-day month. Our documented delay in merely noticing an outage is 0 to 8 hours, because nothing outside the server currently asks DocSync whether it is alive. An outage at 2am is discovered at 7am when somebody tries to open a drawing. One overnight incident exceeds a 99.9% monthly budget by an order of magnitude — and would blow through 99% too.

Publishing a number we cannot measure creates a liability with no evidence base behind it. It also risks being misleading conduct. So we publish the number we can defend, we call it a target, and §2.4 says exactly when it becomes a measured commitment.

0.3 What we are, and the promise that is actually worth something

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.

How the offline part works. Defects and their status changes, daily logs, observations, incidents, inspection responses, photographs and attachments are held on the device and replay automatically when the connection returns. The app treats a 502 / 503 / 504 from us as an outage, not a rejection — queued items stay pending with their retry budget untouched and drain on return. Nothing queued on a device is ever discarded.

The same holds for the one case that is our doing rather than the network's. If we publish a new version of the Terms of Service or the Privacy Policy while work is queued on a device, that work is held, not rejected: the items stay pending with their retry budget intact, the Sync Center says what they are waiting for — "Waiting for you to accept the updated Terms" — and the queue drains itself on the next replay after the person accepts. A legal republish cannot cost a crew a day's capture, and there is a test that fails if that ever stops being true.

Also genuinely strong, and stated because they belong in an availability conversation:

• You can export your company's records and files, any time, without asking us — an archive built from the database schema itself, so it covers every table that carries a company identifier and cannot silently miss one when a feature is added. It is not literally everything: seven tables are not scoped to a company and are outside it, and Terms of Service §8.2 names them and says how to ask for what they hold.
• Non-payment destroys nothing. There is no suspension or lock-out mechanism in the product.
• The audit ledger is tamper-evident, so after any incident we can prove what was changed, and by whom — reads and downloads are not recorded.

1. Scope

1.1 This SLA applies to the DocSync platform provided at the Customer's tenant on the production deployment (the Service).

1.2 It does not apply to:

• AI Features (assistant, drafts, summaries) — excluded entirely, see §9.3;
• Beta or preview features, including Site 3D capture and reconstruction;
• Email delivery, which depends on a third-party relay and is treated as a degraded-subsystem event (severity S3), not as unavailability;
• Accounting integrations, inbound email ingestion, and any other optional integration;
• anything running on the Customer's own devices, browsers or network.

1.3 Where this SLA sits in the Agreement

Once this SLA has been signed for a customer, it forms part of that customer's Agreement. The Agreement is then made up of: the Terms of Service; the Acceptable Use Policy; the Privacy Policy; and whichever of an Order Form, a Data Processing Terms and this Service Level Agreement has been signed. If they conflict, the order of priority is: a signed Order Form, then the Terms of Service, then the Acceptable Use Policy, then the Privacy Policy — except that (a) a signed Data Processing Terms prevails on the handling of personal information, and (b) this SLA, once signed, prevails on availability, support and credits.

This SLA does not claim a precedence the Terms of Service do not give it, and today it has none. The precedence in (b) is granted by clause 1.3A of the Terms of Service, and only once this SLA has been signed for a particular customer. None has been signed, so this document is not part of anybody's agreement and confers no availability commitment and no service credit. This clause restates the position so that a reader of the SLA alone is not misled, and it is subordinate to clause 1.3A if the two are ever read differently.

Availability, support and recovery numbers appear in this document and nowhere else. If you find one in another document in the Agreement, this one governs.

2. Availability target

2.1 The target

Target: 99.0% availability per calendar month.

This is a target, not a guarantee and not a warranty. It becomes a measured commitment attracting service credits from the Measurement Start Date (§2.4).

And, so the target is never read as a published uptime figure:

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.

99.0% permits approximately 7 hours 12 minutes of unavailability in a 30-day month.

We have chosen that figure deliberately over a higher one. §0.2 explains why. We do not use the words guarantee, warrant or ensure about availability anywhere in this agreement, and if you find one, it is a drafting error and it does not bind us in that sense.

2.2 What "unavailable" means

The Service is Unavailable during any minute in which the external availability probe (§2.3) records the Service as failing, from the first minute of two consecutive failed checks until the first minute of the next successful check.

Partial degradation is not unavailability for the purposes of this SLA. It is a support event under §5. Specifically, the Service is not Unavailable merely because:

• email is not being delivered;
• background jobs (reminders, digests, scheduled reports, expiry warnings) are delayed;
• AI Features are degraded or off;
• an export or a PDF render is slow or fails — but a blocking export failure is a severity S2 support event, not S3: see §5.1;
• a single tool, screen or record is faulty while the rest of the Service responds.

2.3 How it is measured — the method, stated so you can audit it

This endpoint is a genuine deep check, not a ping. It returns 200 only when the database, the file store, the disk and the background job queue are all healthy, and 503 when any of them is not — so "alert on non-2xx" is exactly the right rule, and it is the rule we use.

Two things the probe cannot see, disclosed:

1. A background job stranded for less than about 35 minutes. The queue self-heals inside that window, so reporting healthy is correct rather than a lie — but a job chain can be dead for up to ~35 minutes before anything reacts.
2. Anything to do with email. The deep check has no email check at all. A total, permanent email outage reads as perfect health. This is why email is a support event under §5 and not an availability event.

2.4 The Measurement Start Date — the honest gate

No external probe is installed today. Nothing outside the server currently asks DocSync whether it is alive. There is no external uptime check, no certificate or domain monitor, and no heartbeat.

Accordingly:

• Until the Measurement Start Date, the 99.0% figure in §2.1 is a statement of the operational standard we work to. It is not measured, and no service credit accrues.
• From the Measurement Start Date, availability is measured under §2.3 and service credits under §6 apply.
• Measurement Start Date: [MEASUREMENT START DATE]. That date is filled in only once an external probe meeting §2.3 is installed and its log is available to the Customer. Until then the field stays blank, and a blank field means no credit regime is in force.

A credit clause you cannot measure is a clause the customer measures for you. We would rather name the gate than pretend it is closed.

2.5 Exclusions

Minutes are Excluded and do not count against the target when unavailability is caused by:

1. Planned maintenance within a window under §3, including deployments;
2. Emergency maintenance under §3.5;
3. Suspension permitted under the Agreement (for example, to contain a security incident);
4. Upstream and third-party failure outside our reasonable control — the hosting provider, the domain registrar and DNS, the certificate authority, the email relay, or the public internet between the Customer and us;
5. The Customer's own connectivity, devices, browsers, browser extensions, corporate proxies, VPNs, firewalls or network;
6. The Customer's own acts or omissions, including misconfiguration, misuse, a load pattern materially beyond ordinary use, or the acts of anyone using the Customer's credentials;
7. Beta features, AI Features, and email delivery (§1.2);
8. Force majeure — anything genuinely beyond our reasonable control, including natural disaster, war, civil unrest, industrial action, government action, and large-scale internet or power failure.

The carve-back, and it is deliberately wide. We will not use exclusion 4 to disclaim an outage caused by our own failure to renew, configure, pay for or maintain something within our control. That includes, expressly and without limitation: the hosting account or its credit; the domain name; and the TLS certificate. If the server goes away because we did not pay for it or did not renew it, that is our outage and it counts. Our own risk register scores the hosting account as the failure most likely to happen, so naming it here rather than sheltering it under "the hosting provider" is the whole point of this paragraph.

3. Planned maintenance

All times are Australian Eastern Time — AEST (UTC+10) or AEDT (UTC+11) as applicable. Our customers are Australian builders; maintenance is scheduled around an Australian site day, not a northern hemisphere one.

3.1 The standard maintenance window

Tuesday and Thursday, 02:00 – 04:00 Australian Eastern Time.

Routine maintenance and deployments are performed in this window wherever possible.

3.2 Backups — frequency is the commitment, timing is operational

A full backup of the database and the file store is taken once every day. The whole set takes about 3 seconds on the current data volume, so a backup is not expected to interrupt the Service.

What this agreement commits to is the frequency — daily. The time of day at which the backup runs is set in our operations documentation, not in this agreement, because it is an operational schedule we may need to move.

That is not a detail you can ignore, and we are not going to let it hide. The consequence of the run time is stated in §7.3: the recovery point is the last completed daily backup, so the later in the working day that backup runs, the more of a working day a restore loses. A backup taken at lunchtime means a restore on Monday morning recovers a copy taken at lunchtime on the Friday, and everything typed after that is gone from it. Moving the run into the early hours is item 2 on the roadmap in §10 for exactly that reason. Read §7 before relying on any of this.

3.3 Notice

• At least 48 hours' notice for planned maintenance we expect to interrupt the Service for more than 5 minutes.
• No advance notice is required for maintenance inside the standard window that we expect to interrupt the Service for less than 5 minutes.
• Notice is given by email to the Customer's nominated contact.

How a notice is actually sent, so nobody reads more into it than is there. A maintenance notice is written and sent by a person, from the operator's own mail account. The product's outbound mail on the pilot is configured to log and drop messages rather than send them. There is no automated notification service, no status page and no published changelog, and DocSync must not be described to anybody as having one.

3.4 Deployments cause a short interruption — stated, not hidden

Every deployment interrupts the Service. This is architectural, not a defect we are hiding:

• there is one instance of each component and no rolling update, so during a container swap there is no second instance left serving;
• the reverse proxy has no retry and no failover configured, so a request arriving during the swap is returned to the browser immediately as a 502 rather than being held until the new instance is up;
• the health gate that orders the restart correctly lengthens the gap — the web tier waits for the API to pass a health check with a 20-second start period before it will even start;
• a full recreate replaces the reverse proxy itself, and while that happens the site is not reachable at all — a connection refusal or TLS handshake failure, not a 502;
• database migrations run as a gate on every start, adding to the window even when there is nothing to migrate.

Expect a few seconds to a few minutes for a code-only deployment, and 10 to 20 minutes for a deployment or rollback that rebuilds images on the server, because the image build is the slow part.

And, again: a deployment costs a crew on site nothing (§0.3).

3.5 Emergency maintenance

We may perform maintenance outside a window, without notice, where necessary to preserve the security, integrity or availability of the Service — for example to apply a security fix or to stop data loss. We will tell the Customer as soon as practicable and explain what happened. Emergency maintenance minutes are Excluded.

4. Support — hours, and what happens outside them

4.1 Business hours

8:00am – 5:00pm Australian Eastern Time, Monday to Friday, excluding public holidays in New South Wales.

4.2 How to raise something

By email to [SUPPORT EMAIL]. For a suspected S1 (§5.1), also by telephone to [SUPPORT PHONE]. For a suspected security incident, [SECURITY CONTACT EMAIL] — see the Data Processing Terms §9.

4.3 Outside business hours — the honest statement

Outside the hours in §4.1:

• there is no monitoring;
• there is no on-call rotation, no pager, no escalation path, and no second person. There is one operator;
• no response target applies. A ticket raised at 8pm on a Friday has its response clock start at 8:00am on the next business day.

The operator may in fact respond outside hours, and often will. That is a courtesy and not a commitment, and doing it once does not create one. Committing to a 24/7 or overnight response would be committing on behalf of a person who is asleep and has no pager.

4.4 Planned operator absence, and the one clause it reaches into

Where the operator will be unavailable for more than three consecutive business days, we will tell the Customer in advance and say what cover, if any, applies.

There is one operator and there is no cover arrangement. We are not going to describe that as a contingency plan. If an incident coincides with an extended absence, the realistic worst case is an outage lasting as long as the absence. If the Customer needs continuity assurance, that is a commercial conversation and it is not a clause either of us can write today.

This clause is the trigger for one carve-out elsewhere, and only one. Where we have told the Customer in advance of a period during which the operator is unavailable, that period does not count towards the 72-hour breach-notification clock in the Data Processing Terms §9.2, and we will notify within 72 hours of the operator's return. We will not use that carve-out to delay a notification we are able to make. It reaches no other clock in this agreement: an absence we have not told you about in advance carves nothing out of anything.

5. Severity, response targets and communication

5.1 Severity definitions

What makes an export failure "blocking". An export failure is ordinarily S3. It is S2 where the export is being run to answer an individual's access or correction request under the Data Processing Terms §8, or inside the 30-day export window after termination. In both of those cases somebody's legal right depends on the archive, and "same business day" is the wrong clock for it. The Customer only has to tell us which of the two applies.

We assign the severity in the first five minutes and write it down. The Customer may ask us to reconsider it and we will.

5.2 Response targets

Every clock in this table starts when [LEGAL ENTITY NAME] becomes aware of the issue — either because we detected it, or because the Customer told us — and runs only during business hours (§4.1). No clock starts at the moment an outage began, because our detection delay is documented at 0 to 8 hours and is not something we can contract away by pretending otherwise.

5.3 Response, never resolution

These are acknowledgement and update commitments. They are not fix times. We do not commit to a resolution time for any severity. A single operator with no cover arrangement cannot honour a resolution SLA, and a resolution SLA we cannot honour is worse for the Customer than a response SLA we can.

5.4 What a first response contains

"We know, we are on it, and here is what still works." That message goes out on the clock in §5.2 whether or not we yet know the cause. We would rather tell you early with an incomplete picture than late with a complete one.

Two standing rules we hold ourselves to:

• We tell you before you tell us, where detection allows it.
• We never say "no data was lost" until we have checked.

5.5 Incident report

For any S1, and for any S2 lasting more than 4 business hours, we will provide a written incident summary within 5 business days of resolution: what happened, what was affected, whether any data was lost, what we did, and what we are changing. Where the Service's tamper-evident audit ledger bears on the answer, we will say so — remembering that the ledger records what was changed, and by whom, and does not record reads or downloads.

6. Service credits

6.1 The remedy under this SLA

If measured monthly availability (§2.3) falls below the target, the Customer's sole remedy under this SLA is a service credit against the following month's fees:

*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. The words "sole remedy under this SLA" mean what they say and no more: they limit the remedies this document* creates. They do not touch the Australian Consumer Law, they do not touch §6.4, and they do not touch any right you have under the rest of the Agreement.

6.2 How credits work

• Credits apply only from the Measurement Start Date (§2.4).
• The Customer must claim in writing within 30 days of the end of the affected month, with the dates and times relied on. We will check the claim against the probe log and answer within 10 business days.
• Credits are applied against future fees. They are not payable as cash and are not refundable.
• The maximum credit in any month is 30% of [MONTHLY FEE], and credits do not accumulate across months.
• Excluded minutes (§2.5) are excluded from the calculation.
• If the Agreement ends before a credit is applied, any unapplied credit for a period already invoiced and paid is refundable pro rata.

6.3 What the credit regime does not touch

Service credits are the Customer's sole remedy under this SLA for a failure to meet the availability target. This does not exclude, restrict or modify any right or remedy the Customer has under the Competition and Consumer Act 2010 (Cth), including the consumer guarantees, where those cannot lawfully be excluded — and nothing in this SLA should be read as attempting to.

We do not offer, and this document does not create, a damages promise for downtime. If the Customer needs a service that carries one, we are not that service today, and we would rather say so now than in a dispute.

6.4 Persistent failure — the right to leave

A credit capped at 30% of one month's fee is a small remedy set against one server, eleven single points of failure and a documented 0-to-8-hour detection delay. So it is not the only one.

If measured monthly availability falls below 95.0% in any two consecutive months, or below 99.0% in any three consecutive months, the Customer may terminate the Agreement on written notice for cause, without penalty, with a pro-rata refund of fees paid in advance and the post-termination export window in the Agreement.

This right runs from the Measurement Start Date (§2.4), for the same reason the credits do: until there is a monitor, there is no measured figure for either of us to point at.

7. Backups and recovery — what is measured, and what is not offered

7.0 The backup position, stated before any number

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.

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.

[BACKUP_RETENTION_DAYS] is set by the operator; today that number is 15. It appears as a placeholder rather than as a fixed contractual number so that a change to the configuration cannot silently make this agreement false. If it changes, this document, the Privacy Policy, the Data Processing Terms and the Retention Policy are updated in the same change.

7.1 What was measured

The numbers below were measured on the production server on 26 August 2026, using the actual backup and restore scripts, run twice back to back, against scratch database and bucket names with the live data untouched. They are not estimates.

Integrity was proved, not assumed. A real document was read out through its storage key, hashed, destroyed, restored and hashed again, and compared against the live object. All three hashes matched.

7.2 The conditions those numbers assume — read this before relying on them

1. The drill restored from a backup set that lives on the server being restored. It proves the scripts work. It does not prove the disaster recovery runbook can be executed, because the disaster the runbook exists for takes those sets with it.
2. The data volume was small — a 642 KB database dump and 94 files. A tenant with millions of rows and a large file store has not been tested. These numbers will grow.
3. The server, its disk and its network were healthy. They measure a data recovery, not a rebuild.
4. Detection time is not in them. Every figure in §7.1 measures the work after somebody has decided to restore. Add §7.5.

7.3 Recovery Point Objective (RPO)

Category A — the server survives (data corrupted, deleted, or a bad migration):

RPO: up to 24 hours. Nothing is continuous — there is no write-ahead-log archiving, no point-in-time recovery, and no streaming replication. The recovery point is the last completed daily backup.

The practical worst case depends on the time of day the daily backup runs (§3.2). The later in the working day it runs, the more of a working day a restore loses, and it can be materially worse than "yesterday".

What is not lost even at a 24-hour RPO: anything captured on a field device that has not yet synchronised is held on the device and replays when the connection returns (§0.3) — subject to the caveat that this only helps if the Service still exists to synchronise back into. If the server is lost, those queues have nowhere to go.

Category B — the server is lost (deleted, ransomed, or deallocated):

No RPO is offered.

The reason, stated without spin: the off-site backup target is unconfigured. Every backup set is written to the same disk as the database and file store it is backing up, and nothing has ever left the server. As at 26 August 2026 there were 1.6 GB of backup sets on that disk and zero copies anywhere else.

Until an off-site copy exists and has been pulled back at least once, for real, from a machine that is not the application host, we will not state an RPO for host loss, will not make a disaster recovery or business continuity representation, will not claim geographically separated or redundant copies, and will not agree to a "restore customer data on request" obligation. A container full of blobs nobody has ever pulled is a hope, not a backup.

7.4 Recovery Time Objective (RTO)

Every target in this table is a best-efforts target, not a guarantee, and every one of them is subject to §4.4 and to the operator being contactable. There is one operator. A target that assumes a person is awake, in range and not on an aeroplane is a target that a fourteen-hour flight breaks, and we would rather write the condition down than be held to a clock nobody could have met.

One operational limit the Customer should know about. Rolling back a deployment on the pilot server is a manual re-copy of a previous revision rather than a one-command source-control checkout. That is slower and more error-prone than the 10–20 minute budget above implies, and the budget above is the technical work only.

7.5 Detection delay — add it to everything above

A 5-minute restore that starts 6 hours after the outage is a 6-hour outage. That is why every clock in this document starts at "becoming aware", and why we have not written a lower availability target than we can defend.

7.6 The Recovery Commitment Date

From the date on which all four of the following are true, we will offer the commitments below. Not before.

(a) off-site backups are configured; (b) an off-site restore has been performed at least once from a machine that is not the application host; (c) backups are encrypted before leaving the server; and (d) an alerting path exists that fires within one backup interval when an off-site push fails, and it has been verified as installed.

(d) is not a formality and it is why this list has four conditions rather than three. (a), (b) and (c) can all be true on a Monday and the off-site push can stop silently on the Tuesday: the backup script deliberately exits successfully when a push fails — a failing job gets disabled, and then there is no backup at all — and §7.5 already records the detection time for silently stopped backups as "unbounded, until the day you need one". A 24-hour recovery point promised on top of a backup nobody is watching is a promise with no floor under it.

From that date:

• RPO: 24 hours for all failure categories; and
• RTO: best efforts, target one business day for loss of the host.

We will notify the Customer when that date arrives and this section will be amended.

8. Do not architect your statutory deadlines around our availability

This is the most important clause in this document for a builder.

The Customer must not rely on the Service being available in order to meet a legal or contractual deadline. In particular, and without limitation:

• Security of Payment. Every Australian state and territory imposes short, strict clocks — a payment schedule due within 10 to 15 business days of a payment claim, and an adjudication application within 10 to 20 business days, depending on the jurisdiction. Missing one can cost the full claimed amount. DocSync helps you track those clocks; it is not a guarantee that you will meet them.
• Regulator notification. Notifiable incidents carry their own statutory timeframes, often measured in hours.
• Contractual notices — extensions of time, variations, delay notices — under your own head contract or subcontracts.

If a deadline is approaching and the Service is unavailable, serve or lodge by another means. Send the email, post the letter, hand it over on site. Do not wait for us. Our own incident communication templates say exactly this, and we mean it: our outage must not become your delay.

The Customer acknowledges that it is responsible for meeting its own statutory and contractual deadlines and that [LEGAL ENTITY NAME] is not liable for a deadline missed because the Service was unavailable. This does not exclude any right or remedy under the Competition and Consumer Act 2010 (Cth) that cannot lawfully be excluded.

9. Pilot / Beta — what is not guaranteed, and why that is the honest position

We are not going to bury this in a definitions section.

9.1 What DocSync is today

One production deployment, on one virtual server, operated by one person. There is no staging environment — there is one environment and it is production.

9.2 The eleven single points of failure

There is no load balancer, no failover, no clustering, no second host, no second region and no second operator. Counting the components whose loss takes the whole Service down:

1. the virtual server; 2. its single disk (database, files, backups, container images and logs all

share it); 3. the hosting account and its credit; 4. the reverse proxy — the only component with a public port; 5. the database — one instance, one volume, no replica; 6. the file store — one instance, one volume, no replication; 7. the API container; 8. the web container; 9. the domain name; 10. the TLS certificate; 11. the operator.

None of them has a redundant partner. At least four of them — the server, the disk, the hosting credit, and the operator — can produce an outage measured in days, or an unrecoverable loss.

9.3 Specific pilot-period exclusions

During the pilot period the following are provided on an as available basis with no availability commitment and no service credit:

• Site 3D capture and reconstruction — beta;
• AI Features — switched on in the pilot deployment, and excluded from this SLA entirely: they depend on a third-party provider outside Australia, every AI surface falls back to a deterministic non-AI path when that provider is unavailable, and a company owner can switch them off from Company → Editions;
• Email delivery — dependent on a third-party relay with a monthly volume quota;
• Accounting integrations and inbound email ingestion — optional, not enabled by default;
• Disaster recovery — see §7.3, Category B.

9.4 What the Customer gets in exchange

Because we are taking a guarantee off the table, the Customer gets a fair exchange:

1. A no-fault termination right. The Customer may terminate on 30 days' written notice at any time during the pilot period, without cause and without penalty, with a pro-rata refund of fees paid in advance. And a termination right for chronic unavailability — §6.4.
2. Export on exit. A complete self-serve export at any time, and for 30 days after termination — every record and, if requested, every file. See the Data Processing Terms §11.1.
3. No data destruction for non-payment. Verified in the code: there is no suspension or lock mechanism. We commit not to add one without notice and an export window shipping first.

The converse is not true, and you should know it. That commitment is about your non-payment. Our non-payment is a different thing entirely: the hosting account is single point of failure #3 in §9.2, and if it lapses the server is deallocated rather than degraded — the data, the file store and every backup go with it, because the backups are on the same disk (§7.0, §7.3 Category B). Nothing in this agreement can undo that, so we do not pretend otherwise; what we do instead is refuse to shelter it under an exclusion (§2.5, the carve-back).

1. Candour. We will tell the Customer what broke and what we are doing about it, and we will not describe a control we do not have.

9.5 Security — what protects your data, and what does not

The Data Processing Terms carry the full schedule, in Annexures C-1 and C-2. This is the summary, in the same words the rest of our documents use, because a customer reading an availability document is entitled to see it here too.

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 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 an availability document on purpose. A liability cap behind a supplier who cannot pay it is a number on a page, and you are entitled to price that in.

9.6 When this section goes away

This §9 is replaced, and a full availability commitment offered, once the following exist: external availability monitoring (§2.4); off-site backups with a proven restore and a working failure alert (§7.6); encrypted backups; and either a second operator or a documented cover arrangement (§4.4). We will not remove this section quietly, and we will not remove it before those things are true.

10. Roadmap — the order we are closing the gaps in

Stated as a plan, not as a promise that any of it already exists.

11. General

11.1 No exclusion of the Australian Consumer Law. Nothing in this SLA excludes, restricts or modifies any consumer guarantee, right or remedy under the Competition and Consumer Act 2010 (Cth) that cannot lawfully be excluded, restricted or modified. Where liability can lawfully be limited, it is limited as set out in the Agreement.

11.2 Changes to this SLA. We may amend this SLA on at least 30 days' written notice. If an amendment materially reduces the Customer's rights, the Customer may terminate the Agreement without penalty before it takes effect and receive a pro-rata refund of fees paid in advance. We do not reserve a right to vary this SLA unilaterally without notice, and we do not reserve a right to vary it without giving the Customer a way out.

11.3 Records. We will keep the probe log and the incident records for at least 12 months from the date the record is created, and make those relevant to a credit claim available to the Customer on request.

Two limits on that commitment, and they are real. First, there is no probe today (§2.4), so there is no probe log to keep until the Measurement Start Date; the incident records exist from now. Second, those records are held on the production host, along with everything else — see §7.0 and §7.3 Category B. If the host is lost, they are lost with it. This is a retention commitment against deletion and overwriting; it is not, and until an off-site copy exists it cannot be, a durability commitment against loss of the server.

11.4 Governing law. New South Wales, Australia. The parties submit to the non-exclusive jurisdiction of its courts.

11.5 Notices. To us: [CONTACT EMAIL] and [SUPPORT EMAIL]. To the Customer: the contact nominated in the Agreement.

Annexure — Placeholder register

No company name, ABN, ACN or address has been inferred from the product name or the domain.

End of SLA. Draft for Australian legal review. Nothing in this document has been executed, sent, published or committed.