Service Level Agreement & Support Policy

Plain-language summary

This summary is here to be read. It is not the Policy, and if it ever disagrees with the numbered clauses below, the numbered clauses apply.

• What this document is. Two Parts. Part A is our Support Policy: how you reach us, when, how quickly we aim to answer, when we do maintenance, and what we monitor. Part B is a Service Level Schedule — an uptime commitment with service credits — and it applies only if your Order Form says it applies.
• We do not sell an uptime guarantee today, and we say so. Clause 7 sets out the position: we do not publish an availability figure. We would rather have no SLA than a number we cannot stand behind.
• Support targets are targets, not guarantees. Clause 4 sets first-response targets by severity. They are the times we aim at and staff for, not promises of a fix by a deadline. Missing one does not by itself entitle you to money back — it entitles you to the escalation ladder in clause 4.6.4 and the complaints route in clause 4.3.4, and it takes nothing away from your rights over the underlying problem.
• Things outside our control are outside this Policy. ABS Twin runs on other people's platforms — WhatsApp and Meta, Twilio, carriers, AI model providers, hosting and payment providers. If one of them fails, suspends a number or changes a rule, that is not us failing to provide the service (clause 8). That is not the end of it in your favour: where a part of the service is unavailable because of an event outside both our control, your fees for that part are abated pro-rata under clause 22.3 of the Master Subscription Agreement. The Refund & Cancellation Policy provides a further fee-relief route on its own terms, which apply where unavailability continues beyond the period stated there. What you cannot do is collect twice for the same period and the same failure (clause 9.8).
• Your own line and hardware are yours. The voice channel bridges your existing landline through a SIP gateway device. Your line, your internet, your electricity and that device are on your side of the line — except for our own configuration work where we supplied and configured the device (clause 3.2.2).
• Throughput is not ours to promise. Messaging limits, template approvals and quality ratings are set by Meta, not by us, and we make no commitment about any of them (clause 2.3).
• If something goes wrong, we fix it first. Re-performance and remediation come first (clause 9.1). Where Part B applies and we miss the uptime target, you get service credits against future fees; if we keep missing it, you can walk away without penalty and get your unused prepayment back.
• We do not take away rights the law gives you (clauses 9.5 and 9.6), and clause 4.3 is a real complaints route, on every tier, outside support hours, that does not replace your right to go to a regulator, a dispute committee or a court. If you think our records are wrong, clause 6.8 gives you a route to challenge them.

PART A — SUPPORT POLICY

Part A is the operative document. It applies to every Studio from the Effective Date of its Order Form. It contains no availability commitment and no service credits.

1. About this Policy

1.1 Who publishes it. This Policy is published by Carnelian Technologies L.L.C-FZ, a limited liability company licensed in the United Arab Emirates by Meydan Free Zone, Dubai, licence no. 2415615.01, expiring 25 January 2027, registered address Meydan Grandstand, 6th floor, Meydan Road, Nad Al Sheba, Dubai, U.A.E. ("Carnelian", "we", "us", "our"). Full identity, licence and contact particulars are published in the Legal Notice.

1.2 What it covers.

1.2.1 what ABS Twin is for the purposes of support, and what this Policy does not promise (clause 2); 1.2.2 which services are covered and which are not (clause 3); 1.2.3 support channels, hours, severity levels and response targets (clause 4); 1.2.4 maintenance (clause 5); 1.2.5 monitoring, incident handling and how we tell you about problems (clause 6); 1.2.6 the availability position as it stands today (clause 7); 1.2.7 exclusions (clause 8); 1.2.8 remedies and their limits (clause 9); 1.2.9 governing law and forum (clause 10), changes (clause 11), notices and contact (clause 12), language (clause 13), publication (clause 14) and survival (clause 15); and 1.2.10 Part B — the Service Level Schedule, which applies only when an Order Form expressly applies it.

1.3 Who it is for. This Policy is for the Studio. It is not addressed to Guests, and it confers no rights on a Guest. A Guest who books a treatment contracts with the Studio, not with us.

1.4 Defined terms. Capitalised terms used but not defined in this Policy have the meaning given in the Master Subscription Agreement (the "MSA") or, where defined there rather than in the MSA, in the Order Form or the Billing & Tax Invoice Terms. In particular, Live Pilot takes its meaning from clause 9 of the Order Form, and One-Off Fee and Top-Up Pack take their meaning from clause 1.4 of the Billing & Tax Invoice Terms, the equivalent term in the MSA being One-Off Charges. The terms used most often here are:

Downtime, Excluded Downtime and Monthly Uptime Percentage are defined in Part B and have no meaning under Part A. Service Credit is defined in clause B6 and is referred to in Part A only to state that none arises there (clauses 4.5.1 and 9.2A) and to prevent double recovery (clause 9.8).

1.5 Where this Policy sits. This Policy forms part of the Studio's contract stack and is incorporated into the MSA. Where documents in that stack conflict, they take effect in this order: (1) the Order Form, for the commercial variables and negotiated terms it actually addresses, and subject to clause 1.6 of the Order Form; (2) the Restricted / Health Data Addendum, for its subject matter only — Parts I, II and IV in every case, Part III only where executed; (3) the Data Processing Agreement, for data-protection subject matter only; (4) the AI & Communications Addendum, for artificial-intelligence and communications subject matter and no other; (5) the MSA; (6) the Billing & Tax Invoice Terms; (7) the Refund & Cancellation Policy, only to the extent it states the Studio's refund, cancellation and fee-relief rights, and only on the basis that where the Refund & Cancellation Policy gives the Studio a better right on that subject matter, it applies; (8) the Public Sub-processor List, as the operative sub-processor list only; (9) this Policy; (10) the Acceptable Use Policy; (11) the AI & Recording Disclosure, Parts C, D and E only; (12) the Staff App Privacy Notice, for the single purpose of the notice the Studio must serve under clause 7.8.3 of the MSA; (13) the Service Description, Documentation and Known Limitations Annex; and (14) any Country Addendum, for the jurisdiction it addresses only, except to the extent it gives effect to a mandatory requirement of that jurisdiction's law. This order mirrors clauses 2.1.1 and 2.2 of the MSA item by item, including the subject-matter limitations; where this clause and the MSA differ, the MSA governs. The Studio's attention is drawn in particular to item (6): the Billing & Tax Invoice Terms rank above this Policy, so where a Service Credit under Part B falls to be given effect as a Credit Note, the invoicing and VAT treatment in clause 10 of the Billing & Tax Invoice Terms governs (clause B6.3).

1.6 This Policy does not enlarge the MSA's liability regime. Liability arising under or in connection with this Policy is subject to the limitations, exclusions, carve-outs and aggregate cap in the MSA. This Policy does not create a separate or uncapped route to damages, and it does not reduce any liability the MSA does not permit to be reduced.

2. What ABS Twin is for the purposes of support, and what this Policy does not promise

2.1 Scope of the service. ABS Twin is a booking and customer-communications system that a Studio operates for its own Guests — an AI-assisted reception, scheduling and customer-record platform, operated under the Studio's configuration, on the Studio's data, in the Studio's name. It is not a general-purpose AI assistant, and it is not sold, described or supported as one.

2.2 What is not promised. Nothing in this Policy is, and nothing in it should be read as:

2.2.1 a guarantee that any particular Guest message, call or booking will be received, answered, understood, completed or converted; 2.2.2 a guarantee of any booking volume, revenue, response rate, conversion rate, no-show rate, occupancy, review score or Guest satisfaction outcome; 2.2.3 a guarantee of the speed at which the Assistant replies to a Guest, or of a message delivery time, delivery rate, throughput or read rate on any channel; 2.2.4 a guarantee that any Platform Provider will deliver, accept, approve, route or refrain from suspending any message, template, number, account or call; 2.2.5 a recovery time objective, a recovery point objective, or any commitment about how quickly data can be restored after a failure (clause 6.6); 2.2.6 an emergency, urgent-care, medical, safety or life-safety channel. ABS Twin must not be relied on for any emergency, and the Studio must not configure or hold it out as an emergency contact route; or 2.2.7 a commitment that the Studio's own use of ABS Twin complies with the laws, licences or regulatory obligations applicable to the Studio. We provide tooling and configurable controls; we do not provide legal or compliance advice.

2.3 Throughput is not ours to promise. Messaging limits, quality ratings and template approvals on the WhatsApp Business Platform are set by Meta and are outside our control. Depending on the account topology that applies to a Studio, one sender's messaging conduct may affect another sender's limits or standing — the topology that applies to a Studio is recorded in its onboarding schedule (clause 19.1A of the AI & Communications Addendum). We therefore make no throughput, message-rate, template-approval or quality-rating commitment of any kind.

2.4 A Platform Provider may impose responsiveness rules on us. A Platform Provider may impose responsiveness or conduct requirements on us as the operator of an automated experience on its surfaces. Any such requirement is an obligation imposed on us by that Platform Provider; it is not a service level we offer to the Studio, and a failure caused by that Platform Provider's own systems is not our breach.

2.5 Product behaviours are not service levels. The Documentation and, where published, the Service Description record certain product behaviours — for example an independent watchdog on inbound conversation turns that, where a reply is not produced, sends the Guest an apology and raises a staff alert. Those behaviours are described so the Studio knows what the product does. They are descriptions of design, not commitments, not targets and not service levels, and they may change in accordance with clause 11.

2.6 Scope is a promise never made. Clauses 2.1 to 2.5 define what was sold. They are not exclusions of liability, and they operate whether or not any limitation in this Policy or the MSA is enforceable.

3. Covered Services, and what is not covered

3.1 Covered Services.

3.1.1 the Console at app.abstwin.com — the owner, reception and manager surfaces; 3.1.2 the Staff App served at staff.abstwin.com, and any native Staff App client we publish, in each case excluding the app stores' own distribution, review and availability; 3.1.3 any documented Studio-facing ABS Twin API that we make available to the Studio, where and from the date any such API is made available and documented; and 3.1.4 the ABS Twin server-side conversation and booking logic — the parts we operate — to the exclusion of the Platform Provider services those parts call.

3.2 Not covered. For the avoidance of doubt, none of the following is a Covered Service, and no target, commitment, credit or remedy in this Policy applies to any of them:

3.2.1 any service of a Platform Provider, including WhatsApp and Meta (message delivery, template review and approval, business verification, messaging limits, quality ratings, account or number actions), Twilio, telephony and SIP carriers, AI model and speech providers, hosting providers, app stores and payment processors; 3.2.2 the Studio's own telephone line, its internet connectivity, power, local network, firewalls, routers, devices, browsers and operating systems; and its analogue-to-SIP gateway device, together with the Studio's own configuration or reconfiguration of that device and its ongoing operation. Where we have supplied and configured that device as part of a Voice Line Kit purchased under an Order Form, our own configuration work is a service we provided and clause 9.1 applies to it; the device itself, and any statutory rights in respect of it as goods, are dealt with in the Order Form and the Billing & Tax Invoice Terms; 3.2.3 the Studio's own Meta business assets — its business portfolio, WhatsApp Business Account, Instagram professional account, page roles, verification status and any enforcement action against them; 3.2.4 Preview Features; 3.2.5 access provided free of charge, or as a pilot, trial, demonstration or proof of concept, unless the Order Form expressly says otherwise; 3.2.6 any use of ABS Twin outside the documented method of use stated in the Documentation, the Acceptable Use Policy and the AI & Communications Addendum; 3.2.7 the content the Studio configures — its catalogue, prices, durations, staff, hours, policies, FAQs, offers and templates — and any consequence of that content being inaccurate, incomplete or out of date; and 3.2.8 any period during which the Covered Services are suspended in accordance with the MSA or the Acceptable Use Policy as a result of the Studio's own act, omission or breach, or during which a Platform Provider or a regulator requires suspension (clause 8.1.6).

4. Support

4.1 Channels. Support Requests may be raised through:

4.1.1 the public support form at https://app.abstwin.com/support, and, where and from the date one is made available, an in-product support form in the Console; 4.1.2 email to info@contact.abstwin.com, marked "Attn: Support" — or, for a billing query, "Attn: Billing". support@carnelian.tech is our corporate address and remains valid as an alternative; a Support Request is never rejected, delayed or treated as not raised because it was sent to that address or because an attention line was omitted or the wrong one used; 4.1.3 a priority WhatsApp support line, for the tiers identified in clause 4.7. The number is given to an eligible Studio when the channel is made available to it; where no number has been given to a Studio, that channel is not yet available to it, and its Support Requests are raised through the other channels in this clause 4.1 without any effect on a Response Target. Messaging on this channel is subject to the messaging platform's own rules, including its customer-service window and template requirements. Where those rules prevent a reply on this channel, we reply by email and the Response Target is unaffected; and 4.1.4 the published complaints telephone number, +971 56 498 4007, which is answered by a person and not by the Assistant. We do not publish answering hours for this number and we do not promise that it is answered continuously; where a call is not answered, a complaint raised through any other channel in clause 4.1 is treated identically and the periods in clause 4.3.4 run from receipt. This number is not the demo hotline — the number on our marketing pages (+971 4 329 4347) is answered by the voice AI and is not a support or complaints route. This number, and the complaints route in clause 4.3.4, are available to every Studio on every subscription tier, are not limited to Support Hours, and are not gated by the tier table in clause 4.7.

4.2 Support Hours. Support Requests are received at any time. They are worked, and Response Targets run, only during Support Hours. Time outside Support Hours does not count towards a Response Target. Clause 4.2 does not apply to the complaints telephone number in clause 4.1.4 or to the complaints route in clause 4.3.4, which are available continuously.

4.3 How to raise a Support Request, and the complaints route.

4.3.1 A Support Request must be raised by an authorised Studio contact identified under clause 4.8.1. 4.3.2 A complete Support Request states: the Studio and branch affected; the surface or channel affected; what was expected and what happened instead; when it started and whether it is continuing; how many Guests or Authorised Users are affected; the steps to reproduce it; and any reference, correlation identifier, screenshot or message identifier available. A Response Target runs from receipt of a complete request. Where we say a request is materially incomplete, we say which of the items in this clause is missing, we ask once for what is missing where practicable, and the Studio may disagree under clause 6.8. 4.3.3 Ticket reference and status. Every Support Request is recorded, and the Studio may ask for the current status of any open ticket at any time through the channel used to raise it. Where and from the date we issue a Studio-facing ticket reference, we quote it in our first substantive response, and where and from the date we make a Studio-facing ticket view available, the Studio may also track status in that view. 4.3.4 Complaints. A complaint about the Covered Services, this Policy or our handling of a Support Request may be raised through any channel in clause 4.1 — including the complaints telephone number in clause 4.1.4 — marked "complaint", or in writing by post to Carnelian Technologies L.L.C-FZ, Meydan Grandstand, 6th floor, Meydan Road, Nad Al Sheba, Dubai, U.A.E., or by email to info@contact.abstwin.com, marked "Attn: Complaints" in the subject line — although a complaint is never rejected, delayed or treated as not raised because it was sent to another address we publish, including legal@contact.abstwin.com or our corporate address support@carnelian.tech, or because an attention line was omitted or the wrong one used. Every complaint is given a tracking reference and its status can be tracked through the channel used to raise it. We acknowledge a complaint within 1 Business Day and respond substantively within 10 Business Days. Where a complaint is not resolved within that period we say so, give our reasons and give a revised date. This route is available on every tier, is not limited to Support Hours, and is without prejudice to any right the Studio has to take a complaint to a competent authority, regulator, dispute committee or court, and to any mandatory right of recourse or forum preserved by clause 10.2. 4.3.5 Tickets awaiting the Studio. Where a Support Request cannot be progressed because we are waiting for information, access or a test result from the Studio, we will say so and ask for what is needed. Where the Studio does not respond within 15 calendar days of a reminder, we may close the ticket, and we will say in the closure that it may be reopened. A closed ticket may be reopened on request, and reopening does not prejudice any right of the Studio. Time during which a ticket is awaiting the Studio does not count towards a Response Target or an update cadence.

4.4 Severity. We classify each Support Request as follows. Severity is assessed on the effect on the Studio, not on the cause. Where the Studio and we disagree on Severity, we will discuss it promptly and, absent agreement, apply the higher classification until the facts are established.

4.5 Response Targets. The following are targets we aim at and staff for. They are not guarantees, and they are not commitments to resolve within any period. We do not publish a resolution-time commitment for any Severity.

4.5.1 A Response Target is a statement of what was sold, and carries no financial remedy. A Response Target and an update cadence state what we aim at and staff for. They are not contractual commitments, and a failure to meet one is not a failure to provide the Covered Services in accordance with this Policy. Accordingly, no Service Credit, refund, price adjustment, fee relief or set-off arises from a failure to meet a Response Target or an update cadence. Where a target is missed, the Studio's routes are the escalation ladder in clause 4.6.4 and the complaints route in clause 4.3.4, both of which are available on every tier. This clause defines the perimeter of what was promised rather than excluding a liability, and it operates whether or not any limitation in this Policy or in the MSA is enforceable. It is in every case subject to clause 9.5, and it does not affect: the warranty in clause 9.1 or the re-performance remedy that attaches to it in respect of the underlying failure the Support Request concerns; any right preserved by clause 9.6; or, where Part B applies, the availability commitment in Part B. Exception: where an Order Form expressly states a contractual response-time service level for the Studio, that service level and the remedy stated for it apply, and this clause governs every other Response Target.

4.6 What we do after the first response.

4.6.1 We work to identify the cause, provide a workaround where one is available, and remediate. 4.6.2 For an S1 or S2 we tell the Studio when we believe the issue is resolved, and we will provide a written summary of what happened on request, within 10 Business Days of resolution. That summary is provided in confidence, and we may withhold information whose disclosure would compromise security, another customer's confidentiality, or an ongoing investigation. 4.6.3 Where the cause sits with a Platform Provider or with the Studio's own systems, our role is to identify that, to tell the Studio, and to assist reasonably with the Studio's own escalation to that Platform Provider. It is not to procure that Platform Provider's performance.

4.6.4 Escalation. Where an S1 or S2 has not received a first substantive response within its Response Target, or has not moved after the elapsed period below, the Studio may escalate, and we will escalate internally, as follows. Escalation is by reply on the existing ticket marked "escalate", or by the complaints telephone number in clause 4.1.4.

Every S1 trigger above is stated in Support Hours and every S2 trigger in Business Days. Escalation is a route, not a remedy: clause 4.5.1 applies to it.

4.7 Support by subscription tier. The channels and Response Targets available depend on the subscribed tier. The complaints route is not tier-gated: the published complaints telephone number in clause 4.1.4 and the complaints route in clause 4.3.4 are available to every Studio on every tier and outside Support Hours. The table below governs support channels and Response Targets only, and does not limit the complaints route or any statutory right. There is no Diamond tier, and this table is the operative tier table. Clause 4.6 of the Order Form is conformed to it, and neither table is amended without the other being amended in the same change (clause 4.1.1 and this clause).

No availability commitment, Response Target, support channel, support language, escalation contact, named contact or other service level is offered other than as stated in this Policy and on the Order Form (clause 7.4).

4.8 What the Studio does, so that support works. These are obligations of the Studio, and a failure to meet them reduces our liability to the extent the failure caused or aggravated the problem or the delay.

4.8.1 Named contacts. Designate at least one, and preferably two, authorised contacts for support, keep their details current in the Console, and tell us promptly when they change. 4.8.2 Monitoring and oversight. Monitor the Console during the Studio's own operating hours; review escalated and flagged conversations; act on complaint escalations; and retain the final decision on any booking, price, promotion, treatment suitability or health-related statement made in the Studio's name. ABS Twin acts autonomously on some channels; the Studio's oversight duty is the counterpart of that autonomy and is set out in full in the MSA and the AI & Communications Addendum. 4.8.3 Accuracy of configuration. Keep the catalogue, prices, durations, staff, rosters, opening hours, branch details, policies, FAQs and offers accurate and current. We are not responsible for a correct output produced from incorrect input. 4.8.4 Cooperation. Provide the information in clause 4.3.2, respond to reasonable requests for information or access, and test a fix or workaround when asked. 4.8.5 Security on the Studio's side. Keep credentials confidential; provision and promptly de-provision Authorised Users; assign roles appropriately; and secure the Studio's own devices and network. 4.8.6 Platform obligations. Maintain the Studio's own accounts and approvals with Platform Providers where those are held in the Studio's name, and comply with the Platform Providers' terms as they change. 4.8.7 Restricted Data. Do not submit, and configure the Assistant not to solicit, Restricted Data. Where Restricted Data is nonetheless present, tell us, and follow the process in the Restricted / Health Data Addendum.

4.9 Out of scope of support. Support does not include: development of new features or customisations; training beyond any sessions stated on the Order Form; data entry, data cleansing or bulk edits on the Studio's behalf beyond any import service purchased; recovery of data lost through the Studio's own act; support for a Platform Provider's product or account; support for the Studio's own hardware, network, devices or telephone line; or advice on the Studio's legal, tax or regulatory compliance. We may agree to provide any of these as chargeable professional services at our then-current rates.

4.9.1 Fair use. Support is provided for the Studio's reasonable operational use of the Covered Services by its authorised contacts. Where a Studio's support volume is persistently and materially out of proportion to its subscription — for example repeated requests for work described in clause 4.9, or volumes that materially degrade support for other Studios — we will tell the Studio, explain what we are seeing, and discuss it before we do anything about it. Thereafter we may quote the work as chargeable professional services under clause 4.9, or deprioritise Severity 3 and Severity 4 requests. That is the whole of the consequence: this clause is not a right to suspend or terminate, and it never applies to a Severity 1 or Severity 2 issue, or to a complaint under clause 4.3.4.

4.9.2 Support on exit. Support continues throughout any notice period and throughout the data-retrieval window provided for in the MSA and the DPA — at the Studio's subscribed level where the account is current, and otherwise limited to export assistance, the complaints route in clause 4.3.4 and any Severity 1 issue. Support includes handling the Studio's request for an export of its Customer Data and answering questions about the format in which it is provided. Export is provided on request; no self-service export surface is offered today. Bespoke extraction, transformation or migration work beyond that export is a chargeable professional service under clause 4.9, quoted before it is done. Personal-data export is never conditioned on payment.

4.10 How we handle support content, and our use of AI in support.

4.10.1 A Support Request and its attachments may contain Personal Data. We process it as described in the Privacy Policy and, where it is Customer Data, on the Studio's documented instructions under the DPA. Please do not include more Personal Data in a Support Request than the request needs, and never include Restricted Data. We do not use the contact details, or the content of a Support Request or a complaint, for marketing. Marketing preferences are set per channel under the Privacy Policy. 4.10.2 We use AI assistance to draft support replies and to triage incidents. A drafted reply is never sent automatically. A person reviews it, edits it where needed, and approves the send; our records show whether a draft was edited before sending. We say this here because it is true and because it matters to the Studio.

4.10.3 Our access to the Studio's data while providing support. Where we need access to the Studio's tenant data — including a production read, a session taken in the Console in the Studio's tenant, or a screen-share — in order to diagnose or resolve a Support Request or an incident, that access will be: (a) on the Studio's documented instruction under the DPA and for that purpose only; (b) limited to the personnel who need it and to the least data needed to do the work; (c) time-bounded to the investigation and withdrawn when it ends; and (d) where Restricted Data is or may be present, taken from within the United Arab Emirates, with no copy, export, screenshot or session recording leaving the State, in accordance with the Restricted / Health Data Addendum. Where Restricted Data is encountered incidentally in the course of support, we will not process it beyond what is necessary to secure it, will tell the Studio, and will follow that Addendum.

4.11 We may change the support services. We may change the channels, hours, tiers, Response Targets and processes in this Part A where the change develops, upgrades, secures or makes lawful the support services, or where it is for a reason beyond our reasonable control, in each case on the notice in clause 11.2. Where a change is materially adverse to the Studio, clause 11.3 applies and the Studio may terminate without penalty.

5. Maintenance

5.1 Scheduled Maintenance. We carry out Scheduled Maintenance inside the following window, and give the following notice:

5.2 Emergency Maintenance. We may carry out Emergency Maintenance at any time. We give as much notice as is reasonably practicable in the circumstances, and where advance notice is not practicable we give notice as soon as possible afterwards, with a short explanation of why.

5.3 Platform Provider maintenance. Maintenance, deprecation, migration or change carried out by a Platform Provider is that Platform Provider's, is outside our control, and is dealt with under clause 8. We pass on advance notice we receive, where we receive it and where we may lawfully do so.

5.4 Changes made under maintenance. Maintenance may include changes that develop, upgrade, secure or make lawful the Covered Services. Where a change materially and adversely alters the Covered Services as described in the Documentation or the Service Description, clause 11 applies.

6. Monitoring, incident handling and notification

6.1 What we monitor. We operate an internal operations layer which, as at the date of this Policy:

6.1.1 files incidents automatically, de-duplicated by fingerprint so a repeating fault does not become a hundred tickets; 6.1.2 pages us on a severity basis — the most severe class pages at any hour; the next class waits for 09:00–21:00 Gulf Standard Time; 6.1.3 publishes an internal daily digest of incidents and their status; 6.1.4 runs a dead-man switch on itself, so that a failure of the monitoring is itself detected; 6.1.5 runs a daily read-only synthetic check at approximately 04:00 Gulf Standard Time which fails if the booking-slot engine cannot produce a bookable slot; and 6.1.6 takes a nightly encrypted backup of the primary operational database at approximately 03:00 Gulf Standard Time, encrypted before it leaves our systems. No backup is taken of the conversation and operations database — the nightly job covers the primary operational database only, and our internal retention and deletion schedule records the same fact. It cuts both ways: a shorter deletion tail, and a worse recovery position. No retention, rotation or expiry period for backups is published, and clause 6.6 applies to them: the existence of a backup is not a commitment about restoration.

6.2 Incident handling. We operate a written incident-response runbook with defined severity classes, a triage procedure, and a rule that a production incident is not closed until a regression test exists for it. Diagnosis, a fix and a rollback may be prepared automatically; merging a change to production and any credential or third-party dashboard action are gated on a human decision.

6.3 Telling the Studio. For an incident that we reasonably assess as materially affecting the Studio's use of a Covered Service, we will notify the Studio's registered contacts and, where a Console notice surface is available, post a notice in the Console. Where an incident of a systemic kind affects a class of Studios, we will notify the affected Studios promptly, and will not rely on the Studio noticing it. A notice under this clause takes effect on despatch (clause 12.1).

6.4 Personal-data breaches are not handled under this clause. They are handled under clause 11 of the Data Processing Agreement — which governs what we notify to the Studio, within what time and with what content — and under our written internal personal data breach response procedure, which governs how a suspected breach is assessed and classified, who decides, the notification path to the Studio and to any competent authority, and the evidence kept. Where an incident handled under clause 6.2 is found to involve Personal Data, it is escalated into that procedure, and from that point clause 11 of the Data Processing Agreement and that procedure govern it, not this clause.

6.5 Status communications. Where we publish a public status page, its address is notified to the Studio's registered contacts and, where and from the date a Console notice surface is made available, stated in the Console, and the page is maintained accurately. Absent a published status page, incident communication is by the route in clause 6.3.

6.6 No recovery objectives. We publish no recovery time objective and no recovery point objective, and we make no commitment about how quickly or how completely data can be restored after a failure.

6.7 (Reserved.)

6.8 Our records, and what happens if the Studio disagrees with them. Our monitoring, ticketing and audit records are the primary record of availability, incidents, Support Requests and response times. They are not conclusive. Where the Studio disagrees with what our records show, it may tell us within 30 calendar days of the record being communicated to it or of the event it records, whichever is later, stating its reasons and enclosing any evidence it holds — its own logs, error messages, screenshots, ticket references or correlation identifiers. We will review the position, take that evidence into account, and give a reasoned written answer within 20 Business Days. Where the disagreement is not resolved, it may be taken through the complaints route in clause 4.3.4 and, failing that, under clause 10. This clause applies in its own right under Part A whether or not Part B applies, and clause B8.5 applies it to a determination under clause B8.4.

6.9 How long we keep those records. Because clauses 6.8, B8.4 and B9 rest on our monitoring, ticketing and status records, we retain those records — the availability measurements and their underlying check results, Support Request and complaint records, and any status-page history — for at least 5 years from the end of the Service Month to which they relate, or for the remainder of the Subscription Term if longer. That period is anchored to the record-keeping period in clause 11.4 of the Billing & Tax Invoice Terms, under which the invoices and Credit Notes that give a Service Credit effect are themselves retained, and to our internal retention and deletion schedule. This clause fixes a floor for the records we rely on; it is not a commitment about the retention of the Studio's Customer Data, which is governed by the DPA and that schedule. A record retained beyond this period for a litigation or regulatory hold is retained until the hold ends. A record lost through the failure of a Platform Provider is not itself a breach of this clause.

7. Availability — the position today

7.1 No availability commitment applies by default. Part A contains no uptime commitment, no availability percentage and no service credits. We use commercially reasonable efforts to keep the Covered Services available and to restore them promptly when they are not, and we provide the monitoring, maintenance and incident handling described in clauses 5 and 6. That is the whole of the availability position under Part A.

7.2 Why we say so plainly. We do not publish an availability figure that our monitoring, backup and restore practice does not yet support. Committing to a number and offering no remedy for missing it, or committing to a number we cannot measure, would be worse for the Studio than saying this.

7.3 When Part B applies. The Service Level Schedule in Part B applies only where the Order Form for the Studio expressly states that the Service Level Schedule applies, and only from the date it states. Absent that statement, Part B has no effect and no Service Credit accrues. For the avoidance of doubt, the presence of Part B in the text of this Policy is not the publication of a service level for the purposes of clause 17.6 of the MSA or clause 8 of the Refund & Cancellation Policy, and creates no availability commitment in respect of any Studio whose Order Form does not expressly apply it.

7.4 No back-door commitment. No statement in a proposal, demonstration, sales conversation, marketing page, status page or support message creates any availability commitment, Response Target, support channel, support language, escalation contact, named contact or other service level other than as stated in this Policy and on the Order Form. Where the Studio has been given any such statement, it should tell us before signing so that it can be recorded on the Order Form or corrected.

8. Exclusions

8.1 These exclusions apply throughout this Policy — to Part A and, where Part B applies, to the availability calculation, the Response Targets and the Service Credits alike. None of the following is a failure by us, and none of it counts as Downtime:

8.1.1 Platform Providers. Any act, omission, outage, degradation, latency, throttling, rate limit, queueing, suspension, disconnection, deprecation, API change, policy change, pricing change, approval, rejection, review outcome, quality rating, enforcement action or account action of a Platform Provider as defined in clause 1.4 — including WhatsApp and Meta, Twilio, telephony and SIP carriers, AI model and speech providers, hosting and serverless-compute providers, database and data-platform providers, identity and authentication providers, queue, scheduling and caching providers, object and file storage providers, push-notification, webhook-delivery and transactional-email providers, bot-protection providers, app stores and payment processors, as published from time to time in the Sub-processor List — and any consequence of it. A period excluded by this clause 8.1.1 is not a failure by us and is not Downtime; it may nonetheless attract the pro-rata abatement of Fees under clause 22.3 of the MSA, and the fee relief in clause 8.6 of the Refund & Cancellation Policy on the terms stated there. Neither is a remedy for a breach by us, and both are subject to the no-double-recovery rule in clause 9.8. 8.1.2 Studio causes. Any act or omission of the Studio, an Authorised User or anyone acting with their credentials — including configuration choices, content, instructions, integrations, failure to apply a notified fix or workaround, use outside the documented method of use, or breach of the MSA or the Acceptable Use Policy — to the extent that it caused or contributed to the failure or to the period of unavailability. 8.1.3 The Studio's own environment. The Studio's telephone line, internet access, power, local network, security appliances, devices, browsers and operating systems, any third-party product the Studio connects, and its analogue-to-SIP gateway device (subject to the carve-back in clause 3.2.2 for our own configuration work). 8.1.4 Maintenance. Scheduled Maintenance and Emergency Maintenance carried out in accordance with clause 5. 8.1.5 Preview Features, and services excluded by clause 3.2. 8.1.6 Suspension. Any period during which the Covered Services are lawfully suspended under the MSA or the Acceptable Use Policy as a result of the Studio's act, omission or breach, or where a Platform Provider or a regulator requires suspension. 8.1.7 Restricted Data handling. Any period during which we restrict or block processing because Restricted Data has been detected, in accordance with the Restricted / Health Data Addendum. 8.1.8 Force majeure. Any event outside our reasonable control, including natural events, fire, flood, power failure, industrial action, war, civil unrest, epidemic, government or regulator action, internet or telecommunications failure, and a cyber-attack not caused by our failure to meet the security standard in the DPA. The consequences of force majeure are dealt with in the MSA, which provides for notice, suspension of the affected obligations, proportionate fee relief while the service is unavailable, a good-faith renegotiation step, and a termination right for both parties if it continues. 8.1.9 Throughput and delivery. Message throughput, delivery, delivery timing, delivery rate, template approval outcomes, messaging limits and quality ratings (clause 2.3). 8.1.10 Beta or trial access, demonstrations and the Live Pilot, unless the Order Form says otherwise.

8.2 What is not excluded. We do not exclude, and clause 8.1.1 must not be read as excluding, our own responsibility for our selection, integration, configuration and operation of a Platform Provider's service. If a Covered Service fails because of something we did or failed to do in integrating or configuring a Platform Provider, that is ours.

8.3 One exclusion list. The exclusions in this clause 8 are the single operative exclusion list for this Policy — for Part A and for the availability calculation in Part B alike. Clause 17.6.3 of the Master Subscription Agreement adopts this clause 8 as that single list for the Agreement. Nothing stated for the purposes of the Refund & Cancellation Policy narrows this clause 8, which continues to govern the exclusions under this Policy and the availability calculation in Part B.

9. Remedies, and their limits

9.1 Our warranty, and the first remedy. We warrant that we will provide the Covered Services with reasonable skill and care, and that the Covered Services will perform materially in accordance with the Documentation and, where published, the Service Description, during the Subscription Term. Where no Service Description has been published, the warranty is measured against the Documentation alone. Where the Covered Services do not perform as warranted, the Studio's first remedy is re-performance and remediation: we will use reasonable efforts to correct the failure or provide a workaround within a reasonable period, having regard to its Severity. Where we do not, the further remedies in the MSA apply, including a pro-rata refund of prepaid fees for the affected period and, where the failure is material and uncured, a right to terminate.

9.1.1 What this clause is. Clause 9.1 states the warranty given in respect of the Covered Services under this Policy. The service warranty at clause 17.2 of the Master Subscription Agreement and the exclusive remedy for its breach at clause 17.3 of that Agreement are unaffected, and are neither enlarged nor reduced here. Nothing in this clause affects any warranty or remedy that applicable law confers and does not permit to be excluded (clause 9.5). The scope of what was sold is defined by clauses 2 and 3, which operate whether or not any limitation is enforceable (clause 2.6).

9.2 Service Credits. Where Part B applies, Service Credits are the sole financial remedy for a failure to meet the availability commitment in Part B, except:

9.2.1 except where applicable law does not permit this; 9.2.2 except for the chronic-failure termination right in clause B9 and the termination rights in the MSA; 9.2.3 except in the case of fraud, fraudulent misrepresentation, wilful misconduct or gross fault; and 9.2.4 except for any liability that applicable law does not permit to be limited or excluded.

9.2A Response Targets carry no financial remedy. Clause 9.2 addresses the availability commitment in Part B. The support commitments in Part A are addressed separately: a Response Target is a target and not a commitment, and no Service Credit, refund, price adjustment, fee relief or set-off arises from missing one — see clause 4.5.1, including the Order Form exception stated there. Clause 4.5.1 does not affect the warranty in clause 9.1 in respect of the underlying failure, and is subject to clause 9.5.

9.3 Missed bookings and lost revenue. The heads of loss excluded or limited, and the aggregate cap, are stated in clause 20 of the MSA and are not repeated, narrowed or enlarged here. Loss that is not a natural and direct consequence of a failure of the Covered Services is not recoverable. That allocation rests on three things together: (a) the scope of what was sold (clauses 2 and 3); (b) the Studio's oversight and data-accuracy duties (clause 4.8 and the MSA); and (c) the defined remedies in clauses 9.1 and 9.2 and the liability regime in the MSA. Damage resulting from use outside the documented method of use (clause 3.2.6) is outside the Studio's right to compensation. This clause is subject to clause 9.5.

9.4 Mitigation and contributory fault. Our liability is reduced to the extent that a loss is caused or aggravated by the Studio's own act, omission, instruction, configuration choice, content, or failure to follow the Documentation, the escalation process or a notified workaround, or by a failure to take reasonable steps to mitigate.

9.5 Savings clause. Nothing in this Policy excludes or limits any liability, right or remedy that cannot lawfully be excluded or limited. Where any limitation, exclusion or remedy in this Policy would otherwise be unenforceable in whole or in part, it applies to the maximum extent permitted by applicable law, and the remainder of this Policy is unaffected.

9.6 Statutory rights preserved. Nothing in this Policy affects any right the Studio has under applicable law that cannot lawfully be excluded. This clause is without prejudice to Carnelian's position, recorded in clause 3.5 of the MSA, that the Studio acquires the Covered Services exclusively for the purposes of its business or trade; it states the position that applies where and to the extent a mandatory right in fact applies, and is not an admission that any particular consumer-protection regime applies to the Studio. The Refund & Cancellation Policy explains how those rights interact with our fee terms.

9.7 No liability created towards Guests. This Policy confers no rights on a Guest and creates no duty owed by us to a Guest. It confers the benefit of clauses 2, 3, 4.5.1, 8 and 9 and, where it applies, Part B on our affiliates, officers, employees, contractors and Sub-processors, who may rely on them.

9.8 No double recovery. Where, for the same period and the same failure, more than one of the following would otherwise apply — a pro-rata refund of prepaid fees under clause 9.1; the pro-rata abatement of Fees under clause 22.3 of the MSA where the cause is a force-majeure event, which under clause 22.1 of the MSA includes an act or omission of a Platform Provider; the fee relief in clause 8.6 of the Refund & Cancellation Policy; a Service Credit under Part B; or a refund under clause B9.1 — they are not cumulative. The Studio receives the greater of them and not both, and any amount already credited, abated, discounted or refunded for that period and that failure is set off against the amount otherwise due. A claim for abatement or fee relief under this clause should be made within the period in clause 9.9. This clause applies whether or not Part B applies. It does not limit any right to terminate, and it does not affect any liability, right or remedy that clause 9.5 preserves.

9.9 Telling us about a claim. Clause 20.7 of the MSA governs notification of a claim. Without varying it, the Studio is asked to tell us — through a channel in clause 4.1, quoting any ticket reference — as soon as it becomes aware that we have failed to provide the Covered Services in accordance with clause 9.1, stating what happened and what it claims, because our ability to investigate while the evidence exists, to provide a workaround and to limit the loss depends on it. Clause 20.7.1 of the Master Subscription Agreement fixes the notification period at 12 months from the date the claiming party became aware of the matter giving rise to the claim. That is the only period; this Policy states no other, and no shorter period applies to a claim under it. Under clause 20.7.2 of the MSA, failure to give notice does not bar the claim but reduces liability to the extent of the prejudice caused by the delay. It is a notification condition and is not a variation of any limitation period. Where Part B applies, clause B8.1 governs the deadline for a Service Credit claim and this clause does not extend it.

10. Governing law, forum and data protection

10.1 Governing law. This Policy, and any dispute, claim or obligation arising out of or in connection with it, its subject matter or its formation — including any non-contractual dispute, claim or obligation — are governed by the law of the Dubai International Financial Centre (DIFC). The parties agree that the chosen law extends to non-contractual obligations between them. This states the same regime as clause 30.1 of the Master Subscription Agreement, which governs.

10.2 Forum — express opt-in. The parties expressly, specifically and clearly agree that the courts of the Dubai International Financial Centre shall have exclusive jurisdiction to settle any dispute or claim arising out of or in connection with this Policy, its subject matter or its formation, including any non-contractual dispute or claim, and the parties irrevocably submit to that jurisdiction — without prejudice to any mandatory right of recourse or forum that applicable law confers and that cannot be varied by agreement. In particular, and without limiting that saver, this clause does not purport to exclude, and must not be read as excluding: (a) any statutory complaints route, dispute committee or competent authority available in respect of trading by modern technological means or under consumer-protection legislation, where such a route applies notwithstanding this clause; (b) any regulator or supervisory authority; or (c) the routes preserved by clause 4.3.4. Where a mandatory forum applies to a dispute, this clause applies to every other dispute and to the remainder of that dispute so far as the law permits. The same saver is carried in clause 30.1.8 of the Master Subscription Agreement, and in every restatement of the forum clause across the studio contract stack, in these terms. This clause is intended to be a specific, clear and express opt-in for the purposes of Article 14(B) of Dubai Law No. 2 of 2025, or any successor provision.

10.3 Small Claims Tribunal election. Where the Order Form contains a written election to that effect, the parties elect that the DIFC Courts' Small Claims Tribunal shall hear claims up to the higher value threshold that an election permits.

10.4 Data protection is a separate question. The applicable data-protection regime for Personal Data processed in connection with ABS Twin is the UAE Personal Data Protection Law and any other Applicable Data Protection Law, whatever forum or governing law applies to a commercial dispute. A choice of governing law and forum in clauses 10.1 and 10.2 is a choice about commercial disputes: of itself it neither imports nor displaces any data-protection regime.

10.4.1 Where a Studio is established in the DIFC or in ADGM, or where Processing takes place there, that jurisdiction's data-protection regime may apply in addition — including, in the DIFC, DIFC Data Protection Law No. 5 of 2020 and its regulations on the Processing of Personal Data through autonomous and semi-autonomous systems. Under those regulations the Studio is ordinarily the Deployer and Carnelian the Operator of such a system, and obligations may fall on Carnelian directly, including as to notice, the maintenance of a system register, design requirements and human-intervention mechanisms, and — for higher-risk processing — certification or the appointment of a suitably qualified officer. Where that regime applies, the parties' respective obligations are addressed in an addendum to the Data Processing Agreement and not in this Policy, and nothing in clauses 10.1 to 10.3 limits them.

10.4.2 See the Privacy Policy and the DPA.

10.5 Pre-action step. Before commencing proceedings, the party raising a dispute shall give written notice of it to the other party's notice address, and the parties shall attempt in good faith to resolve it for 30 days from that notice. This is a step, not a bar, and it does not prevent either party seeking urgent interim relief.

10.6 No arbitration, no collective-action waiver. This Policy contains no arbitration agreement and no waiver of collective or representative proceedings.

10.7 Studios established outside the United Arab Emirates. Where the Studio is established outside the United Arab Emirates, this Policy applies as supplemented by the country addendum for that jurisdiction, and clauses 4.1.4, 4.3.4, 10 and 13 apply subject to any mandatory local rule as to complaints handling, forum and language.

11. Changes to this Policy

11.1 We may change this Policy. When we do, we publish the new version at its canonical address, abstwin.com/legal/support (with any alternative published slug resolving to it by permanent redirect), in English and Arabic, with a new version number and effective date, and we keep every superseded version accessible with its own effective date. We do not silently edit a published page.

11.2 Notice. We give at least 30 days' advance written notice of a change, to the Studio's registered contacts and, where a Console notice surface is available, in the Console. A change that is required by law, is necessary for security, is required by a Platform Provider, or is favourable to the Studio takes effect on notice — save that where such a change is materially adverse to the Studio, clause 11.3 applies to it whatever caused it.

11.3 Material adverse changes. Where a change is materially adverse to a Studio — including a reduction in Support Hours, the removal of a support channel available to that Studio's tier, a material lengthening of a Response Target, or a reduction in an availability commitment that applies to that Studio under Part B — that Studio may terminate its subscription without penalty at any time before the change takes effect, and receive a pro-rata refund of prepaid, unused fees.

11.4 We do not rely on silence or on continued use as acceptance of a materially adverse change. For such a change we ask for a fresh acceptance and record it. Where the change is required by law, by security or by a Platform Provider and the Studio does not accept it, the Studio's remedy is the exit in clause 11.3 with a pro-rata refund, and we may implement the change or terminate the affected part of the Covered Services under the MSA.

11.5 Upstream changes. Where a Platform Provider changes its terms, availability, limits or policies, we may need to change this Policy at shorter notice than clause 11.2 provides. Where that happens we give as much notice as we receive and as is practicable, we say that the change is upstream-driven, and clauses 11.3 and 11.4 still apply to a materially adverse change.

11.6 Version history. Every version of this Policy is recorded with its version number and effective date, and the version each Studio accepted is recorded with its acceptance record.

12. Notices and contact

12.1 Operational notices under this Policy are given by email to the Studio's registered contact addresses and, where and from the date a Console notice surface is made available, in the Console. A maintenance notice under clause 5, an incident notice under clause 6.3 and a status notice are effective on despatch, and the notice periods in clause 5.1 run from despatch. Other operational notices are deemed received in accordance with clause 26.3 of the MSA. Where an email to a registered address is returned undelivered, we give the notice by any other contact route the Studio has registered and, where a Console notice surface is available, in the Console.

12.2 Notices of termination and formal notices of breach are given in accordance with the notice provisions of the MSA, and require the additional method stated there.

12.3 Contact details for support, complaints and legal notices are in clauses 4.1 and 4.3.4, and in the Legal Notice.

13. Language

13.1 English is the language of this Policy and of any proceedings relating to it.

13.2 An Arabic text of this Policy is published at the same address as, and at the same time as, the English text. Unless clause 13.3 applies, the Arabic text is provided for convenience and is marked non-binding; in the event of any conflict between the English and Arabic versions, the English version prevails, to the fullest extent permitted by applicable law.

13.3 Where any provision of this Policy is required by applicable law to be made available in Arabic, the Arabic text of that provision governs to the extent the law so requires.

13.4 (Reserved.)

13.5 The language in which support is delivered. Clauses 13.1 to 13.4 govern the language of this Policy. Support itself is provided in English, and we make no commitment to answer a Support Request in any other language. Where support is provided in a language other than English, the English text of this Policy still governs its interpretation under clause 13.2.

14. Publication

14.1 This Policy is published as HTML, reachable without a login and without a geo-gate, not as a PDF and not as an editable document, at its canonical address abstwin.com/legal/support, and linked from the site footer, the pricing page, the Master Subscription Agreement and the Legal Notice — and, where a Console support surface exists, from that surface.

14.2 Where Part B applies, the Service Credit claim deadline in clause B8.1 is disclosed at the point of sale and in the Console, and not only in this Policy.

14.3 (Reserved.)

14.4 (Reserved.)

15. Survival

15.1 The following survive termination or expiry of the Studio's subscription, in respect of any period during which this Policy applied to the Studio: clause 1 (About this Policy, including the defined terms), clause 2 (scope of what was sold), clause 3 (Covered Services and what is not covered), clause 4.5.1 (Response Targets carry no financial remedy), clause 4.8 (in respect of the subscription period), clauses 6.8 and 6.9 (records and their retention), clause 8 (Exclusions), clause 9 (Remedies and their limits) in full, clause 10 (Governing law and forum), clause 12 (Notices), clause 13 (Language), this clause 15, and — where Part B applied to the Studio — clauses B5, B6.4, B6.7, B8 and B10.

PART B — SERVICE LEVEL SCHEDULE (AVAILABILITY COMMITMENT AND SERVICE CREDITS)

Part B applies to a Studio only where that Studio's Order Form expressly states that the Service Level Schedule applies, and only from the date stated (clause 7.3). It is not offered as at the date of this Policy.

B1. Application of this Part

B1.1 Part B has effect in respect of a Studio only as provided in clause 7.3. Where it has not been applied by an Order Form, nothing in this Part creates an availability commitment, a Service Credit entitlement or any other right.

B2. What Part B covers

B2.1 The Part B Services. Part B applies only to the Console (clause 3.1.1) and, where a documented Studio-facing ABS Twin API under clause 3.1.3 exists, is documented and the Order Form expressly says that Part B applies to it, to that API (together, the "Part B Services"). Nothing else is a Part B Service, and in this Part the availability commitment, the measurement and the Service Credit are computed on the Part B Services alone.

B2.2 Part B does not apply to: the Staff App; the server-side conversation and booking logic; any Platform Provider service; message or call delivery on any channel; the Assistant's replies to Guests; the Staff App's distribution through an app store; Preview Features; the Live Pilot; free, demonstration or trial access; or anything excluded by clause 3.2 or clause 8.

B2.3 A channel-level service level would need its own schedule. Any availability or performance commitment offered in future in respect of a channel or product — voice, WhatsApp, Instagram, message or call delivery, or the Assistant's replies — may not be applied through clause B3.4, and may not be inferred from the commitment in clause B4.1. It requires its own schedule, with its own measurable perimeter, its own measurement method, its own exclusions and its own credit table.

B3. How availability is measured

B3.1 Monitoring. Availability of the Part B Services is measured by external synthetic monitoring, from at least two independent network locations, at intervals of no more than 60 seconds, against a documented health endpoint and a representative authenticated read path.

B3.2 Downtime. A period is Downtime where the monitoring records a failed or timed-out check on a Part B Service from at least two locations continuously for at least 5 minutes. Downtime is measured in whole minutes and starts at the first failed check in that continuous period and ends at the first successful check after it.

B3.2A What this measure does and does not capture — said plainly. Availability under Part B is measured only by the synthetic checks described in clause B3.1. It follows, and the Studio should understand before it buys, that a Part B Service which is degraded, slow or partially impaired but still answering the health endpoint and the authenticated read path is not Downtime and does not accrue a Service Credit, even where the degradation materially affects the Studio's use of it. This is narrower than a commitment framed as the service operating "in material accordance with its specifications", and it is stated here rather than left to be discovered. Degradation of that kind is handled under Part A, as a Severity 1 or Severity 2 Support Request under clause 4.4, with the escalation ladder in clause 4.6.4, the warranty and re-performance remedy in clause 9.1, and the complaints route in clause 4.3.4 — none of which is displaced by Part B.

B3.3 Excluded Downtime. A period attributable to anything in clause 8 is Excluded Downtime. Excluded Downtime is not Downtime and does not count as Downtime Minutes.

B3.4 Monthly Uptime Percentage. For each Service Month:

Monthly Uptime Percentage =
    (Total Minutes − Downtime Minutes)
    ──────────────────────────────────  ×  100
              Total Minutes

where Total Minutes is the number of minutes in the Service Month and Downtime Minutes is the total of all Downtime in that Service Month that is not Excluded Downtime.

B3.5 Partial months. Where the Subscription Term starts or ends part-way through a calendar month, the Service Month is the part of the calendar month within the Subscription Term, and Total Minutes is adjusted accordingly.

B4. The availability commitment

B4.1 We will use commercially reasonable efforts to achieve a Monthly Uptime Percentage of at least 99.5% (the "Availability Figure") for the Part B Services in each Service Month.

B4.1A The obligation is an efforts obligation; the credit trigger is arithmetic. Clause B4.1 obliges us to use commercially reasonable efforts. The Service Credit trigger in clause B6.1 is not conditioned on that obligation: a Service Credit accrues where the Monthly Uptime Percentage calculated under clause B3.4 is below the Availability Figure, whether or not the efforts obligation in clause B4.1 was met.

B4.2 (Reserved.)

B4.3 The commitment in clause B4.1 is a commitment about the Part B Services as measured under clause B3. It is not a commitment about anything in clause 2.2 or clause 8.

B5. Exclusions from the calculation

B5.1 Clause 8 applies in full to the calculation of Monthly Uptime Percentage for the Part B Services. In particular and without limiting clause 8, Downtime attributable to a Platform Provider is Excluded Downtime, whether the Platform Provider's own service failed, was suspended, was throttled, was rate-limited, was deprecated, changed its interface or policy, or took an account action.

B6. Service Credits

B6.1 Where the Monthly Uptime Percentage for a Service Month, calculated under clause B3.4, is below the Availability Figure stated in clause B4.1 — whether or not the commercially reasonable efforts obligation in clause B4.1 was met (clause B4.1A) — and the Studio claims in accordance with clause B8, the Studio is entitled to a Service Credit calculated as a percentage of the Subscription Fee (clause 1.4) for that Service Month. The Subscription Fee is taken as a whole and is not apportioned between Part B Services, because clause B3.4 produces a single Monthly Uptime Percentage for them collectively. Where an Order Form states an allocation of the Subscription Fee between Part B Services, that allocation applies instead.

B6.2 Monthly cap. The total Service Credits for any one Service Month may not exceed 25% of the Subscription Fee for that Service Month.

B6.3 Form, and what a Service Credit is. A Service Credit is a price adjustment to the Subscription Fee, not a payment of damages or compensation. Service Credits are applied against future Subscription Fees, not paid in cash, and are applied to the next invoice issued after the credit is determined. Where the credit is applied to an invoice not yet issued it is shown as a discount line on that invoice; where a credit falls to be applied against an invoice already issued, it is given effect by a Credit Note issued under clause 10 of the Billing & Tax Invoice Terms, and the VAT treatment follows that clause. Carnelian is not registered for VAT and holds no Tax Registration Number, so while that remains the position no VAT arises on a Service Credit or on the Credit Note that gives effect to it, and the Credit Note is a commercial document rather than a tax credit note.

B6.4 Expiry. Unapplied Service Credits expire on the earlier of 12 months from determination and the end of the Subscription Term, and are not refundable, transferable or exchangeable for cash. By express exception to clause 17.6.2 of the MSA (under which Service Credits expire on termination), where the Subscription Term ends because we terminated for our own material breach or terminated for our convenience, any unapplied Service Credit is instead paid as a refund. This exception is written into the MSA at clause 17.6.2A, because clause 2.2.1 of the MSA ranks the MSA above this Policy and, without it, this clause would be dead letter. The two clauses state the same exception.

B6.5 No accrual during the Studio's own suspension. No Service Credit accrues for a period during which the Covered Services are suspended under clause 8.1.6.

B6.6 (Reserved.)

B6.7 Eligibility. No Service Credit accrues, and none is applied or paid, in respect of any Service Month in which, or at any time at which the credit would otherwise be applied, (a) the Studio is in material breach of the MSA, this Policy or the Acceptable Use Policy and has not remedied it within the period the MSA allows, or (b) an undisputed invoice is overdue under the Billing & Tax Invoice Terms. An amount disputed in good faith under the billing-dispute process in the Billing & Tax Invoice Terms is not overdue for this purpose. A Service Credit withheld under this clause is applied once the breach is remedied or the overdue amount is paid, provided the claim was made within the deadline in clause B8.1, and subject to the expiry in clause B6.4.

B7. Preview, pilot and non-production use

B7.1 Preview Features, the Live Pilot, demonstration environments, and free access are excluded from Part B in full: no availability commitment, no Service Credit, and no Response Target beyond those in Part A.

B7.2 Preview Features are optional, must be affirmatively opted into by the Studio, and that opt-in is logged. They may be changed or withdrawn at any time. They are provided without the warranty in clause 9.1. Liability in connection with Preview Features remains inside the aggregate cap in the MSA.

B8. How to claim a Service Credit

B8.1 Deadline. A claim must be submitted within 30 days after the end of the Service Month to which it relates. A claim submitted after that period is not payable. The deadline in this clause is a condition of eligibility for a price adjustment. It does not affect any claim the Studio may have in respect of the underlying failure, and clause 9.9 governs notification of such a claim. The deadline is disclosed at the point of sale and in the Console (clause 14.2).

B8.2 How. By a Support Request marked "service credit claim", through a channel in clause 4.1.

B8.3 Contents. A claim must state: the Studio and the Order Form reference; the Service Month claimed; the dates, start times and end times of each period of claimed Downtime, in Gulf Standard Time; the Part B Service affected; and any evidence the Studio holds — error messages, screenshots, ticket references or correlation identifiers.

B8.4 Our determination. We will assess the claim against our monitoring records and respond within 20 Business Days of receiving a complete claim, stating the Monthly Uptime Percentage we calculated, the Excluded Downtime we applied and why, and the Service Credit (if any) that results.

B8.5 If the Studio disagrees. Our determination is not final and binding. Clause 6.8 applies to a determination under clause B8.4.

B8.6 Good faith. Neither party may use the claim process to manufacture, prolong or exaggerate an outage, and a claim must be made honestly and on a reasonable basis.

B9. Chronic failure — the termination right

B9.1 Where the Monthly Uptime Percentage falls below 99.0% in any two Service Months within any three consecutive Service Months, the Studio may terminate the affected Part B Services, or the subscription in whole, without penalty, by written notice given within 30 days after the determination for the last of those Service Months, and receive a pro-rata refund of prepaid, unused fees for the terminated services.

B9.2 The right in clause B9.1 is in addition to, and not instead of, the Service Credits for those Service Months, and in addition to any other termination right in the MSA.

B10. Relationship to the rest of the contract

B10.1 Clause 9 applies to Part B. Service Credits and any refund under clause B9 count towards, and are not additional to, the aggregate liability cap in the MSA.

B10.2 Nothing in Part B enlarges the MSA's liability regime, and clause 9.5 (savings clause) applies to Part B in full.

B10.3 No double recovery. Clause 9.8 applies to Part B.

────────────────────────────────────────────────────────────
Document:      Service Level Agreement & Support Policy
Version:       v0.9           Effective date: on publication
Supersedes:    v0.8           Language: English and Arabic, published together — see clause 13
Publisher:     Carnelian Technologies L.L.C-FZ
               Meydan Grandstand, 6th floor, Meydan Road, Nad Al Sheba, Dubai, U.A.E.
               Licensing authority: Meydan Free Zone, Dubai, United Arab Emirates
               Trade licence no. 2415615.01 — issued 26/01/2024, expires 25/01/2027
               TRN: none — Carnelian is not registered for VAT
               Authorised representative: Syed Sharique Ali
Contact:       Support / billing: info@contact.abstwin.com (Attn: Support / Billing)
               Complaints: info@contact.abstwin.com (Attn: Complaints)
               Legal notices: legal@contact.abstwin.com (Attn: Legal)
               Telephone +971 56 498 4007
               Privacy / Data Subject requests: privacy@contact.abstwin.com
               DPO: Syed Sharique Ali, Manager — dpo@contact.abstwin.com
               Security: security@contact.abstwin.com
               Corporate / alternative: support@carnelian.tech
────────────────────────────────────────────────────────────