Service Level Agreement
DocAI Fabric cloud service. Availability, service credits, and recovery.
Version 1.0 · Effective 1 October 2026
What this covers. This Service Level Agreement sets out what we commit to for the DocAI Fabric cloud service: the availability we will maintain, how it is measured, the service credits available if we miss it, and how the service is recovered after a failure. Support channels, response times, and escalation are governed separately by the DocAI Fabric Support Policy.
This SLA is incorporated by reference into the Master Services Agreement or Terms of Service between AI Fabric Limited ("AI Fabric", "we") and the customer ("Customer", "you"). It applies to the DocAI Fabric cloud service. Self-hosted deployments are governed by the DocAI Fabric Support Policy (section 8); no availability commitment applies to software operated by Customer.
Capitalised terms used in this SLA are defined in section 02. A capitalised term not defined there has the meaning given in the Agreement.
01. Plans
Pro is available on self-registration under the Terms of Service, with Standard Support, and is billed for pages as they are processed. The figures shown for Pro are operational targets rather than commitments: sections 7.1 to 7.3 and section 08 do not apply to Pro, and the remainder of this SLA does.
Enterprise is purchased on an annual Order Form against a page commitment. It carries the availability commitment, service credits, recovery objectives, and termination rights set out in this SLA, and runs in a single Azure region. Standard Support is included; Enterprise Support is available as an add-on. Where that region is lost through a failure of the Azure platform, that period is excluded from the availability calculation for a time equal to the recovery time objective, and any unavailability continuing beyond it counts against the commitment.
Enterprise Premium runs in two or more Azure regions, with a warm standby environment in a second permitted region, automatic traffic failover, and continuous replication between regions. The service continues through the loss of a single region rather than being recovered after it, and loss of one region counts against the availability commitment rather than being excluded from it. Enterprise Support is included.
| Pro | Enterprise | Enterprise Premium | |
|---|---|---|---|
| Purchase model | Self-service, pay-as-you-go | Order Form | Order Form |
| Support | Standard | Standard; Enterprise Support add-on | Enterprise Support included |
| Deployment | Single Azure region, multiple availability zones | Single Azure region, multiple availability zones | Two or more Azure regions, automatic failover |
| Availability commitment, per Service Quarter | 99.5% (target only) | 99.90% | 99.95% |
| Platform-level failure of the deployment region | Excluded from the availability calculation | Excluded for a period equal to the RTO; time beyond that counts against the commitment | Counts against the availability commitment |
| Service credits | Not available | On claim within 30 days | On claim within 60 days |
| Recovery time objective (RTO) | 24 hours (target only) | 4 hours | 1 hour |
| Recovery point objective (RPO) | 24 hours (target only) | 1 hour | 15 minutes |
| Termination for chronic failure | No | Yes | Yes |
Data residency. Every plan is deployed, and stores and processes Customer Data, only in Azure regions within the Region Customer selected for its account (United States, Australia, or European Union), as defined in the Data Processing Agreement. On Enterprise and Enterprise Premium, Customer may specify narrower residency requirements on the Order Form, for example a named Azure region, and we will deploy the Covered Services only in Azure regions that meet them. This applies whether the deployment uses a single region or several.
02. Definitions
Covered Services: the functions listed in section 03, accessed through the web interface or the API (including the review interface where Customer embeds it in its own application), together with the authentication required to reach them.
Valid Request: a well-formed request to the Covered Services, submitted through a supported API version or the web interface, using valid credentials, within Customer's rate limits, quotas, and usage entitlements. Where a request fails, identical retries count as separate Valid Requests only where they are made with exponential back-off beginning at not less than 1 second.
Processing Baseline: for a given document, the median time taken to process comparable documents for Customer over the preceding 90 days, excluding periods of Downtime. Documents are comparable where they are of the same type and of similar size. Where Customer has not submitted enough comparable documents in that period, the equivalent median across the Covered Services as a whole applies.
Downtime: the Downtime Minutes determined under section 04. Downtime in a Service Quarter is the total of those minutes, and a run of consecutive Downtime Minutes is a period of Downtime.
Excluded Downtime: the periods described in section 05. Minutes falling within Excluded Downtime are not Downtime Minutes.
Service Quarter: a calendar quarter, being the three months beginning on 1 January, 1 April, 1 July, or 1 October. Where a subscription begins or ends mid-quarter, measurement covers only the active portion. Availability is measured, and service credits are determined, by Service Quarter; the limits on maintenance in section 06 are stated per calendar month.
Committed Volume: the number of pages Customer has committed to process over the subscription term, as stated on the Order Form.
Service Credit Base: one quarter of the annual committed subscription fee. Professional Services, implementation, migration, training and support fees, third-party pass-through charges, and taxes are excluded. Service credits are available on Enterprise and Enterprise Premium only.
Recovery Event: an incident involving the loss or sustained unavailability of a deployment region, or of a substantial part of the production environment, which we declare as a Recovery Event in the status page post for that incident. Most incidents are not Recovery Events.
RTO: the target maximum elapsed time between the commencement of the Downtime giving rise to a Recovery Event and restoration of the Covered Services to production operation.
RPO: the target maximum period of Customer Data loss on a Recovery Event, measured backwards from the point of failure.
03. Covered Services
The Covered Services are the DocAI Fabric production functions for submitting documents for processing, processing them, tracking their progress and retrieving results, together with the review workflow: retrieving documents awaiting review, opening a document and its extracted data for review, and recording review decisions.
3.1 Not covered
The following are outside the availability commitment. We maintain them with reasonable care and post incidents affecting them to the status page, but they are not measured under this SLA:
- Configuration, administration, and user management
- Reporting, analytics, and dashboards
- Beta, preview, trial, evaluation, sandbox, and free features, however designated
- Third-party integrations and Customer-developed extensions
- Non-production environments
- The documentation site, marketing website, and status page itself
04. Measuring availability
Availability is measured for each customer separately, from our server-side telemetry recorded at the service edge. It is calculated in minutes, as follows.
4.1 Operations
An Operation is a Valid Request, or a document accepted for processing.
A Valid Request is counted in the minute in which it was made. A document is counted in the minute in which it reached a result, terminated, or passed the deadline in section 4.2, whichever occurs first.
The following are not Operations, and count towards neither a rate nor a minimum in this section:
- documents that fail or are delayed because of their content, format, encryption, or integrity, or because they are of a type the Covered Services do not support; and
- Valid Requests and documents affected by an exclusion in section 05.
4.2 Failed Operations
A Valid Request is a Failed Operation if it returned an HTTP 5xx status, or did not return response headers within 30 seconds. The 30 second measure is the time taken to begin responding. It does not measure the time taken to transfer a result, or the time taken to process a document.
A document is a Failed Document if it did not reach a result within the greater of ten times its Processing Baseline and 15 minutes (the deadline), or if it terminated in an error state or with a recorded failure at an internal processing step.
A document delayed by a matter excluded under section 05, including Customer's own concurrency limits and a capacity constraint excluded under section 5.2, is not an Operation under section 4.1 and so is not a Failed Document. A document that reached a result after the deadline is a Failed Document for the purposes of this section 04 only: it was processed, and section 7.4 does not apply to it.
4.3 Request Error Rate
The Request Error Rate for a minute is the percentage of Valid Requests counted in that minute that were Failed Operations.
Where a minute contains fewer than 100 Valid Requests, the Request Error Rate is calculated across the 60 minutes ending with that minute. Where those 60 minutes also contain fewer than 100 Valid Requests, the Request Error Rate is not calculated for that minute and section 4.5 applies instead.
4.4 Failed Documents
Document processing is measured by the accumulation of Failed Documents rather than by a rate over a single minute, because documents are processed in far smaller numbers than requests are made.
For each minute we count the Failed Documents arising in the 60 minutes ending with that minute, and the documents accepted for processing in that period.
A Failed Document is counted once, in the minute determined under section 4.1. The 60 minute count determines whether document processing is failing; which minutes are Downtime Minutes on that account is determined under section 4.6, so that a failure already counted does not by itself make every later minute in the window a Downtime Minute.
4.5 Reference checks
We operate reference checks against the Covered Services, including from independent probes operated outside the Azure environment in which the Covered Services run.
Where the Request Error Rate is not calculated for a minute under section 4.3, availability for that minute is determined by those checks instead. Availability is never determined by the absence of telemetry alone.
4.6 Downtime Minutes
A minute is a Downtime Minute if any of the following applies:
- the Request Error Rate for that minute exceeds 5%, and at least one Valid Request counted in that minute was a Failed Operation;
- the Failed Documents counted for that minute under section 4.4 number at least 3 and exceed 5% of the documents accepted for processing in the same period, and in that minute either a Failed Document was counted or a document that had passed its deadline under section 4.2 had still not reached a result or terminated;
- Customer made at least 10 Valid Requests in that minute and every one of them was a Failed Operation; or
- reference checks record the Covered Services as unavailable in that minute, where section 4.5 applies.
A minute is a Downtime Minute once, however many of these apply.
4.7 Minutes we disregard
A failure, interruption, or malfunction of the reference checks themselves is not Downtime and does not give rise to service credits. Where reference checks are unavailable or unreliable for a minute, and the Request Error Rate is not calculated for that minute under section 4.3, that minute is disregarded and is not a Measured Minute.
Minutes disregarded under this section will not exceed 1% of the minutes in the Service Quarter. Where more would otherwise be disregarded, the excess minutes are Measured Minutes and are treated as available, unless evidence from Customer's own monitoring that meets section 4.9(3) shows that the Covered Services were unavailable in them, in which case they are Downtime Minutes.
We will record each period during which reference checks were unavailable or unreliable, together with the cause, and make that record available to Customer on request.
4.8 Quarterly Uptime Percentage
Measured Minutes are the total minutes in the Service Quarter, less any minutes disregarded under section 4.7.
Quarterly Uptime Percentage = (Measured Minutes less Downtime) ÷ Measured Minutes × 100, rounded to two decimal places.
4.9 Reporting and evidence
- The availability we measure for Customer's own traffic under this section is available in the DocAI Fabric console and through the API. It is shown by Service Quarter, broken down by month, by day and by period of Downtime, together with the proportion of minutes disregarded under section 4.7 in that Service Quarter. Service credits are calculated from these figures. We do not produce bespoke availability reports. Where Customer submits a claim under section 7.2, we will provide the underlying measurement data for the periods claimed.
- Service-wide status and history is published at status.docaifabric.com, including component-level status, incident history, and a rolling twelve month availability record. Customer may subscribe any number of contacts to notifications. Status page figures are service-wide and provided for information; they are not the basis on which service credits are calculated.
- Where Customer's own monitoring indicates a materially different result, Customer may submit that data in support of a claim under section 7.2 and we will review it in good faith. Measurements that include Customer's network path, DNS resolution, or client-side rendering are not determinative.
05. Exclusions
Downtime does not include unavailability arising from:
- Scheduled Maintenance and Emergency Maintenance conducted in accordance with section 06.
- Customer's network, connectivity, DNS configuration, firewall or proxy, local hardware or software, or end-user equipment.
- Customer's acts or omissions, including misconfiguration, use of the Covered Services other than in accordance with the Documentation, Customer-developed code, and use of unsupported API versions after the deprecation period has expired.
- Requests beyond Customer's rate limits, quotas, concurrency limits, or usage entitlements, and load materially in excess of contracted volumes. This does not apply where requests within Customer's entitlement were throttled or rejected as a result of an error in our own rate limiting, metering, or quota enforcement.
- Suspension or termination of access exercised in accordance with the Agreement or the Acceptable Use Policy, including for non-payment.
- Force majeure, including natural disaster, war, terrorism, civil unrest, government action, labour disputes, widespread internet or telecommunications failure, and denial-of-service attacks that could not reasonably have been mitigated by industry-standard protections.
- Third-party software or services procured directly by Customer, and integrations to systems operated by or for Customer.
5.1 Loss of an Azure region
DocAI Fabric is operated on Microsoft Azure. All plans are deployed across multiple availability zones within a deployment region. Failure of an individual availability zone, virtual machine, storage account, model deployment, or other Azure service instance is not Excluded Downtime and counts in full against the availability commitment.
Pro and Enterprise. For plans deployed in a single Azure region, Downtime does not include periods during which the deployment region is unavailable as a result of a platform-level failure of Microsoft Azure affecting that region as a whole.
This exclusion applies for a period equal to the RTO applicable to Customer's plan, measured from the commencement of the Downtime giving rise to the Recovery Event. Downtime continuing beyond that period is not excluded and counts against the availability commitment in the ordinary way.
Enterprise Premium. For plans deployed across two or more Azure regions, failure of a single region counts in full against the availability commitment. Downtime is excluded only where every permitted Azure region in which the Covered Services are deployed is concurrently affected by a platform-level failure of Microsoft Azure.
An exclusion under this section applies only where the failure is attributable to Microsoft Azure rather than to our configuration, capacity planning, deployment, or code, and where we identify the corresponding Microsoft incident reference in the post-incident record and make it available to Customer on request.
5.2 Inference capacity
Inference is performed on model deployments within the Azure regions permitted for Customer's plan. Where more than one such deployment is available, we distribute inference between them.
Downtime does not include periods during which processing is delayed as a direct result of a platform-level capacity constraint imposed by a third-party model provider affecting the relevant capacity class in the region generally, rather than arising from our own quota provisioning, capacity planning, or configuration. This applies only where we identify the provider incident or capacity notice in the post-incident record and make it available to Customer on request. Routine rate limiting or throttling of capacity we have provisioned is not excluded and counts as Downtime in the ordinary way.
Customer-supplied model endpoints. Where Customer configures a model endpoint of its own, we will route inference to it in accordance with Customer's configuration and, where alternative deployments are available to Customer, distribute inference between them. We make no commitment as to the availability, capacity, throughput, or performance of a Customer-supplied endpoint. Downtime does not include unavailability or delay arising from such an endpoint, including its rate limits, quotas, capacity, latency, or failure, and documents delayed or failed for that reason are not Operations under section 4.1.
06. Maintenance
Standard practice. We deploy changes continuously and design for zero-downtime deployment. Routine releases do not require Scheduled Maintenance and do not cause Downtime.
Scheduled Maintenance. Where a change requires a service interruption:
| Pro | Enterprise | Enterprise Premium | |
|---|---|---|---|
| Advance notice | 5 days | 7 days | 10 days |
| Maximum duration | 4 hours per month | 2 hours per month | 1 hour per month |
| Deferral | Not available | Reasonable efforts | Once per quarter on request |
Notice is given by email to Customer's designated technical contacts and posted to the status page. Maintenance is scheduled outside business hours in the deployment region.
Emergency Maintenance. We may perform Emergency Maintenance without the above notice where necessary to preserve the security, integrity, or availability of the Covered Services. We will give as much notice as is practicable and, for Enterprise and Enterprise Premium, a written explanation within 2 business days. Emergency Maintenance is Excluded Downtime up to 4 hours per calendar month and 12 hours per rolling twelve months; beyond those limits it counts as Downtime.
07. Service credits
Service credits are available on Enterprise and Enterprise Premium. Pro subscriptions do not carry service credits.
7.1 Credit schedule
The same schedule applies to both plans, measured for each Service Quarter against the commitment applicable to Customer's plan.
| Quarterly Uptime Percentage achieved | Service credit |
|---|---|
| Below the applicable commitment, and 99.50% or above | 10% of the Service Credit Base |
| Below 99.50% and 99.00% or above | 15% |
| Below 99.00% | 25% |
In a Service Quarter with 99.92% availability, an Enterprise Premium customer is entitled to a 10% credit because the 99.95% commitment was missed. An Enterprise customer is entitled to no credit for the same quarter, because the 99.90% commitment was met.
7.2 Claiming
Credits are not applied automatically. Customer must claim by email to support@docaifabric.com within 30 days of the end of the affected Service Quarter, or within 60 days for Enterprise Premium. A claim must identify the dates and times of the claimed Downtime, and reasonable supporting evidence of the impact on Customer's use, for example request identifiers, error responses, or logs from Customer's own monitoring. Where our own records already evidence the Downtime, no further evidence is required.
We will acknowledge a claim within 5 business days and respond substantively within 15 business days.
7.3 Application and limits
- Credits are applied against the next invoice issued. Enterprise and Enterprise Premium subscriptions are billed annually in advance, so a credit is ordinarily applied against the renewal invoice for the following term; where the Order Form provides for quarterly or other periodic billing, a credit is applied against the next periodic invoice. Credits have no cash value and are not exchangeable or refundable. Where the subscription is not renewed, or is terminated for any reason including under section 08, credits not yet applied expire on the date the subscription ends.
- Credits in any Service Quarter will not exceed 25% of the Service Credit Base, and in any contract year will not exceed 10% of the total fees payable for that year.
- No credit is payable where the calculated amount is less than $100, where Customer's account is more than 30 days past due, or in respect of a period during which Customer did not use the Covered Services.
7.4 Processing volume
Pages submitted for processing that fail, or that we are unable to process, as a result of Downtime are not charged. On Enterprise and Enterprise Premium, where such pages have already been counted against Customer's Committed Volume, we will restore them to it within the following billing cycle; on Pro, the corresponding charges are credited in the following billing cycle. This applies to all plans and is in addition to any service credit. Pages of a document that reached a result after the deadline in section 4.2 were processed and are charged in the ordinary way.
7.5 Exclusive remedy
Except as set out in sections 7.4 and 08, service credits are Customer's sole and exclusive remedy for failure to meet the availability commitment in this SLA.
This section does not limit Customer's rights or remedies in respect of breach of confidentiality obligations, breach of the Data Processing Agreement, a Security Incident, infringement, or any liability that cannot be limited by law. Liability for loss or corruption of Customer Data is governed by the limitation of liability provisions of the Agreement.
08. Chronic failure and termination
Customer may terminate the Covered Services, or the Agreement in its entirety, for cause on written notice given within 30 days of the qualifying event, if:
- Enterprise: the Quarterly Uptime Percentage falls below 99.00% in any two Service Quarters within a rolling four quarter period, or below 98.00% in any single Service Quarter.
- Enterprise Premium: the Quarterly Uptime Percentage falls below 99.50% in any two Service Quarters within a rolling four quarter period, or below 99.00% in any single Service Quarter.
A Service Quarter counts towards a recurrence threshold only if a service credit was payable for that quarter.
8.1 Prolonged loss of an Azure region
Downtime excluded under section 5.1 does not give rise to service credits and does not count towards the thresholds above. If such excluded downtime exceeds one hour in each of two or more Service Quarters within a rolling four quarter period, or exceeds 24 hours in aggregate within a rolling twelve month period, Customer may on written notice given within 30 days require us to present, within 30 days, a written remediation plan setting out the deployment topology, additional regions, or residency adjustments that would reduce the recurrence risk, including where applicable a proposal to move Customer to a multi-region topology.
If we do not present such a plan, or if the plan does not identify a change that would materially reduce that risk within Customer's residency boundary, Customer may terminate the Covered Services with effect from the end of the then-current subscription term or from a date not less than 90 days after notice, whichever is earlier. Prepaid fees are not refunded on termination under this section, and unused Committed Volume remains available until the effective date.
8.2 Effect of termination
On termination under section 08, we will refund prepaid fees for the terminated services covering the period after the effective date, pro rata. Where Customer has prepaid against a Committed Volume, the refund is calculated on the unused portion at the effective per-page rate paid.
That refund is the whole of what is payable on termination under this section. Service credits accrued before termination expire on the effective date under section 7.3, and are not refunded, paid in cash, or offset against the refund.
09. Recovery and data durability
9.1 Recovery objectives
| Pro | Enterprise | Enterprise Premium | |
|---|---|---|---|
| RTO | 24 hours (target only) | 4 hours | 1 hour |
| RPO | 24 hours (target only) | 1 hour | 15 minutes |
| Recovery mechanism | Restore into an alternate Azure region | Restore into an alternate permitted region | Automatic failover to a running warm standby in a second permitted region |
| Replication lag reporting | Not reported | On request | Monitored continuously and reported |
RTO and RPO apply where a Recovery Event is declared, and are measured from the commencement of the Downtime giving rise to it. They are distinct from routine failover between availability zones within a region, which is automatic and typically completes within minutes without a formal declaration.
Status of these figures. RTO and RPO are recovery objectives. They are not availability commitments, they do not give rise to service credits, and they are not warranties as to the durability or integrity of Customer Data. What we commit to is to design, test, and operate the recovery capability to meet them, to exercise it, and to report the results under section 9.3.
Replication lag. Cross-region replication on Azure is asynchronous and Microsoft publishes no commitment as to replication lag. On Enterprise Premium we monitor the lag continuously, alert on it, and report it to Customer; in normal operation it is materially shorter than the recovery point objective. Where the objective is exceeded solely because of a platform-level replication delay within Microsoft Azure, we will identify the corresponding Microsoft incident reference and make it available to Customer on request.
Service credits. Where a Recovery Event is Excluded Downtime under section 5.1, no service credits arise for the excluded period, and the recovery objectives are our operative obligation during it. Downtime continuing beyond the applicable RTO is not excluded: it is measured under section 04 and gives rise to service credits in the ordinary way. Where a Recovery Event is not Excluded Downtime, the whole period is measured under section 04.
9.2 Data durability
Customer documents and derived data are held in Azure object storage. The following applies to all plans.
| Storage redundancy | Zone-redundant within the deployment region: synchronous copies across three availability zones |
| Cross-region replication | Asynchronous replication to a second Azure region within the Region Customer selected for its account, and within any narrower residency requirement specified on the Order Form |
| Object versioning | Enabled; prior versions of overwritten objects retained for the Recovery Window |
| Deletion recovery | Deleted objects recoverable for the Recovery Window |
| Recovery Window | 90 days |
| Encryption | AES-256 at rest; TLS 1.2 or later in transit |
The Recovery Window is a platform-level configuration and is the same for every customer and plan. It does not extend Customer's contractual data retention or deletion rights under the Agreement and the Data Processing Agreement, which govern when Customer Data is deleted from live storage. Copies held within the Recovery Window are overwritten within it, as the Data Processing Agreement (clause 11.3) and the Agreement provide, and remain protected until then.
9.3 Testing and assurance
- We test recovery of Customer Data from the Recovery Window at least quarterly, and record the date and outcome of each test.
- We conduct a full recovery exercise at least annually, producing a measured recovery time.
- Enterprise and Enterprise Premium customers may request, once per contract year and under NDA, a written attestation of the most recent recovery test and annual exercise, stating the dates performed and the recovery time and recovery point achieved.
- Joint recovery walkthroughs, tabletop exercises, and customer-specific recovery documentation are available as Professional Services.
9.4 Customer-caused data loss
Loss of Customer Data caused by Customer, including accidental deletion, erroneous bulk operations, and corruption introduced through Customer's own integrations, is not a Recovery Event, does not engage the recovery objectives in this section, and is not covered by this SLA. Requests for assistance are handled under the DocAI Fabric Support Policy.
10. Service status and incidents
All incident communication is delivered through the status page at status.docaifabric.com, which provides component-level status, subscribable notifications by email, SMS, webhook, and RSS, and a rolling twelve month incident history.
| All plans | |
|---|---|
| Incident declared | Posted within 30 minutes of detection |
| Updates during an incident | Posted at least hourly until resolved |
| Recovery Event | Identified as such in the status page post, where section 09 applies |
| Post-incident summary | Published within 5 business days for incidents affecting availability for more than 1 hour |
Availability is measured under section 04 from our telemetry, independently of whether an incident is posted. Posting an incident does not by itself establish Downtime, and not posting one does not by itself exclude it. This does not affect section 5.1, under which the exclusion depends on our declaration of a Recovery Event.
Customer is responsible for subscribing its own contacts to status page notifications and keeping those subscriptions current. We do not maintain separate notification lists.
Customers on Enterprise Support (included in Enterprise Premium, optional on Enterprise) receive a written root cause analysis for every P1 incident affecting their subscription, as the DocAI Fabric Support Policy provides. For other customers the status page post is the record of the incident.
Notification of a Security Incident or personal data breach is governed by the Data Processing Agreement and is not limited by this SLA.
11. Changes to this SLA
We may update this SLA from time to time. Where an update is materially adverse to Customer, we will give at least 30 days' prior written notice to Customer's designated contacts and the update will take effect at the start of Customer's next renewal term. Updates that are neutral or beneficial to Customer, and updates required to comply with law, take effect on posting.
Where Customer has agreed an amended version of this SLA in an Order Form or addendum, that version prevails for the term to which it applies.