Service Level Agreement
DocAI Fabric cloud service. Availability, service credits, and recovery.
Version 1.3 · Effective 22 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 Customer Data and runs OCR, 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. AI model inference is processed where clause 13.7 of the Data Processing Agreement says: by default on Global model deployments, in any Azure region where the model is hosted. On Enterprise and Enterprise Premium, Customer may specify on the Order Form an AI processing location (the Region's data zone, or a named country or Azure region) and narrower residency requirements for the deployment, for example a named Azure region, and we will process and deploy the Covered Services only in locations 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.
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. On a Partner Subscription the Service Credit Base is stated in pages, under section 7.3(4).
Partner Subscription: an Enterprise or Enterprise Premium subscription that Customer purchased through a reseller or distributor authorised by us, where we invoice that partner and the partner invoices Customer. For a Partner Subscription, references in this SLA to the Order Form are to the order under which the partner purchased Customer's subscription from us.
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 60 minutes of being accepted for processing (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: health checks by the edge service in front of each deployment, at least once a minute, and independent probes operated outside the Azure environment in which the Covered Services run, at least every five minutes. For a minute without a check of its own, the most recent check before it applies.
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
- On Customer's request we provide a report of the availability we measure for Customer's own traffic under this section, from our edge and platform telemetry, 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 may also show them in the DocAI Fabric console or through the API; where we do, those figures are the same report. We do not produce bespoke availability reports beyond this one. 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, through the means the status page offers. 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, including for non-payment or a breach of its acceptable-use terms.
- 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 in the locations permitted for Customer's plan (Global by default, or the AI processing location stated on the Order Form). 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.
- Partner Subscriptions. On a Partner Subscription, service credits are provided in pages, added to Customer's Committed Volume, rather than applied against an invoice. Neither the partner's price to Customer nor our price to the partner is used in calculating them. Items 1 to 3 apply with these changes:
- the Service Credit Base is one quarter of the Committed Volume for a twelve-month term, or of the proportionate part of it for a term of another length, and the credit for a Service Quarter is the percentage of it set out in section 7.1;
- we add the credited pages to the Committed Volume of the subscription term current when we accept the claim under section 7.2, within 15 business days of accepting it, or, where that term has ended and the subscription has been renewed, to the Committed Volume of the renewal term;
- the annual limit in item 2 is 10% of the Committed Volume for that contract year, determined in the same way;
- the $100 minimum in item 3 does not apply, and Customer's account is past due where Customer is more than 30 days late in paying the partner for the subscription; and
- pages added as service credits have no cash value, are not refundable or exchangeable, are not counted as unused Committed Volume in any refund or credit for unused Committed Volume (including under section 8.2), and expire at the end of the term to which they were added.
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, notifications by subscription through the means the status page offers, 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.
Change history
| Version | Effective | Changes |
|---|---|---|
| 1.3 | 22 October 2026 | 02 and 7.3(4): on a Partner Subscription, purchased through an authorised reseller or distributor, service credits are pages added to Committed Volume and the credit limits are calculated from Committed Volume rather than fees. Direct subscriptions unchanged. Archived copy of 1.2 |
| 1.2 | 19 October 2026 | 4.2: a document's deadline is 60 minutes from acceptance (previously the greater of ten times a Processing Baseline and 15 minutes; the definition of Processing Baseline is removed). 4.5: the reference checks named, with their frequency. 4.9(1): availability figures are a report provided on request (previously shown in the console and through the API). 10 and 4.9(2): status page notifications through the means it offers. Commitments, credits and recovery objectives unchanged. Archived copy of 1.1 |
| 1.1 | 8 October 2026 | Data residency (section 01) and 5.2: AI model inference on Global model deployments by default, or at the AI processing location stated on the Order Form |
| 1.0 | 1 October 2026 | First version. Archived copy |