Public Sub-processor List

Plain-language summary

ABS Twin does not run on our computers alone. To answer a guest on WhatsApp, understand a voice call, book an appointment, store a client record, send an email or take a subscription payment, we rely on other companies. Those companies are called sub-processors, and this page names every one of them.

We list them in two tiers, and the second tier is the important one.

• Tier 1 is the companies we contract with directly — the AI model providers, the messaging and voice providers, the databases, the hosting, the login system, the billing provider.
• Tier 2 is the companies those companies use in turn, where your guests' data actually reaches them. Most vendors stop at Tier 1. We publish Tier 2 because it is where a voice call really goes: a phone call to a studio using ABS Twin passes through a speech-to-text company and a text-to-speech company that we do not contract with directly, and a studio's compliance officer deserves to know that before they sign, not after.

For each entry we say who the company is, what it does for ABS Twin, what kinds of personal data it touches, which countries the data is processed in, how long it keeps it, and where to read that company's own privacy and data-protection terms.

We also say, for every entry, which parts of ABS Twin cause your data to reach it — the "Applies to" column. Not every studio touches every company on this list. If you use messaging only, your guests' data never reaches the speech companies that handle phone calls. If you use neither the staff app nor the reception and manager device notifications, nothing of yours reaches the push-notification companies. Two companies on the list — our source-control provider and our marketing-website analytics provider — receive no studio or guest data at all, and are listed only so that nothing is hidden. Telling you which parties are yours matters as much as naming them.

One more boundary, stated plainly: the phone line itself is yours. The voice assistant answers your existing landline, on your own contract with your own telephone company. We do not contract with your telephone company and it is not on our list — it is on yours. What we supply is a small gateway box, installed at your premises, that bridges that line to the voice platform over an encrypted connection. Clause 9 sets this out.

We also say plainly what we do not know yet. Where a fact has not been confirmed from a primary source, the entry says so in terms, and says when the answer will be published, rather than stating a guess. A studio's own compliance review will find the gap anyway; we would rather it find it here.

Three things this page also tells you:

1. On training. We do not use a studio's data or a guest's data to train AI models, and we never train anything across studios. Our text AI providers state in their own published terms that they do not train on business API content; we have not yet evidenced that from an executed agreement, and we say so rather than assert it. For the voice chain, the providers in our live path are now named on this page — Soniox turns speech into text, ElevenLabs turns text into speech, and OpenAI's gpt-4.1 is the model that runs the conversation — but speech providers of this kind commonly retain or train on audio by default unless the setting is turned off or a specific agreement is signed, and the arrangement that displaces that default is not yet evidenced for either of them. Until it is, we will not make an absolute promise. Clause 14 says exactly what we can and cannot claim today.
2. On locations. Some of this stack genuinely is in Europe, and we say so plainly: the conversation database — where the messages themselves are stored — is in Ireland (eu-west-1), our outbound and inbound email run in Ireland, our billing entity is Irish, and our marketing-site analytics are on the EU cloud. The rest is in the United States: the operational database, the AI providers, the whole voice chain, the hosting, the file storage and the login system. We are a Dubai company serving UAE studios, and we would prefer to tell you everything sits in the UAE — but it does not, and saying so would be false. Clause 15 names the countries, data set by data set.
3. On changes. When we add or replace a sub-processor we tell you before it starts processing, we record the date on this page, and a studio can object. Objecting does not force us to change our stack — it gives the studio the right to stop using the affected part of the service and get its money back for the unused part. Clauses 16 to 18 set that out.

An Arabic version of this page is published alongside the English version; this page is not published in English only (clause 26).

1. What this list is, and what it is not

1.1 This Sub-processor List is published by Carnelian Technologies L.L.C-FZ ("Carnelian", "we", "us"), the company that provides the ABS Twin platform, to identify every third party engaged by Carnelian to process Personal Data in connection with ABS Twin.

1.2 It is the operative list. The Data Processing Agreement authorises Carnelian to engage the Sub-processors published at this URL, and defines "Sub-processor" by reference to this page together with each listed party's own onward sub-processors. The Privacy Policy and the AI & Communications Addendum also refer to it.

1.3 It is drafted as evidence, not as marketing. Each entry is intended to be supportable from an executed written agreement with the named party, and each stated fact is intended to be traceable to that party's own published terms. Annex B records, per Sub-processor, whether that written agreement is in place. Where Annex B shows that it is not, the equal-protection assurance in clause 13.2 is not yet available for that party.

1.4 What this page does not do. It does not vary any agreement. It is not an offer. It does not describe the ABS Twin service (see the Service Description referred to in the Master Subscription Agreement), does not by itself state how Personal Data is used (see the Privacy Policy), does not state the security measures (see Annex 2 of the Data Processing Agreement), and does not constitute legal, medical, financial or regulatory advice to any person. It also does not discharge a Studio's own obligations as Controller, and is not the Studio's own transfer risk assessment — see clause 22.4.

1.4A This page is not incorporated into the Master Subscription Agreement. Clause 2.1.2 of the Master Subscription Agreement states that this page is not incorporated into that Agreement and does not vary it, save that it is the operative list of Sub-processors referred to in the Data Processing Agreement. Clause 24.2 of the Master Subscription Agreement states that only the documents listed in clause 2.1.1 of that Agreement, and terms agreed in writing under its clause 2.3, bind Carnelian. This page is therefore disclosure published in support of those agreements, and the statements on it take contractual effect only through the Data Processing Agreement. That limitation is stated here, on the page a reader actually reads, rather than left in a document the reader has not been shown; it does not affect the savings in clauses 22.1 and 22.2, and it does not exclude any pre-contractual disclosure duty that applicable law does not permit to be excluded.

1.5 Precedence. Where this page and the Data Processing Agreement differ, the Data Processing Agreement governs as between Carnelian and a Studio. Where this page and the Privacy Policy differ on a matter of processing description, the Privacy Policy governs as against a data subject. Clauses 16 to 18 of this page describe a mechanism that operates as a contractual term only through the Data Processing Agreement.

1.6 Defined terms. Capitalised terms not defined here have the meaning given to them in the Master Subscription Agreement. In particular: Studio (also called Customer) is the licensed business that subscribes to ABS Twin; Guest is an individual who contacts, books with or receives services from a Studio; Customer Data is everything a Studio and its Authorised Users submit to or generate through ABS Twin; Guest Data is the subset of Customer Data that is Personal Data relating to a Guest; Carnelian Data is Personal Data for which Carnelian itself determines the purposes and means; Platform Providers are the messaging, telephony, model, hosting, app-store and payment providers on which ABS Twin depends and whose terms, availability, pricing, approvals, rate limits, quality ratings and enforcement actions Carnelian does not control; Restricted Data has the meaning given in clause 2.2 of the Restricted / Health Data Addendum, which is the master definition for the whole document set and which governs. For the convenience of a reader of this page, and without varying that definition, the categories it reaches are clinical, diagnostic or treatment records; health information about an identified person; biometric identifiers; payment card data; and government identification numbers — subject to that Addendum's own closing carve-out in clause 2.2, that an item is not Restricted Data to the extent it is objectively necessary to book, schedule or deliver the specific service the Guest has requested and is limited to what that purpose objectively requires. Health-Adjacent Content — the health-adjacent free text a Guest volunteers in the ordinary course of booking a beauty or wellness service — is dealt with separately at clause 3.5; it is a description of what Guests in fact send, not a carve-out written into the definition of Restricted Data, and nothing on this page narrows clause 2.2 of that Addendum.

2. How to read this list

2.1 Two tiers.

2.1.1 The tables cover the live path; clause 12 completes the register. Tables 6.1, 6.2 and the table in clause 8 state the parties in the live processing path — the parties to whom Personal Data is sent today. They are not, by themselves, the whole register. A party that has been removed from the live path but that may still hold Personal Data remains a processor for so long as it holds it, because storage is processing; those parties are in clause 12, and they are carried into the destination table in clause 15.1 and into Annex B on the same footing as a live party. The register of parties processing Personal Data in connection with ABS Twin is therefore clauses 6, 8 and 12 read together, and a reader who reads only the clause 6 tables has read the live path and not the register. Clause 12.1.1 states when a clause 12 party ceases to be a current processor.

2.2 The columns. Identity, capacity and role are in Table 6.1; data, location, retention and source links are in Table 6.2. Material nuances that do not fit a table cell are set out per Sub-processor in clause 7.

2.2.1 "Applies to" — the surface each party serves. Tables 6.1 and 6.2, the Tier 2 table in clause 8 and the table in clause 12 each carry an "Applies to" column, because the chain is not uniform and no Studio touches every party on it. A Studio that takes messaging only does not reach the voice platform or the speech vendors; a Studio that uses neither the Staff App nor the reception and manager device notifications does not reach the push transport providers; and two parties receive no Studio data at all. Presenting the list without that column would overstate every Studio's exposure. The column is also what makes clause 17 workable: "the affected part of the Service" in an objection is the surface named in this column for the party objected to. The remaining tables on this page — the destination table at clause 15.1, the vendor-cap table at clause 18.3, the deletion-tail table at clause 20.2, and Annexes A and B — are cross-cutting registers rather than party listings, and clause 17.3 is applied to a party named in one of them by reference to that party's row in Tables 6.1, 6.2, clause 8 or clause 12.

2.2.1A Instagram — a channel stated conditionally, and why. Every "Instagram" entry on this page applies only where and if that channel is enabled for a Studio, and this page does not state that the channel is operating. The channel is in testing and is not available in production. It is not enabled for any Studio, no Guest is served on it, and it will be announced when it becomes available — so every "Instagram" entry on this page is, today, a statement of what would apply if the channel were enabled and not a statement that it is. The identity position stated at clause 21.5 — that a Guest record originating on Instagram has no telephone number on file — is unaffected by that gate and is stated as a fact about the platform.

2.2.2 Added on / Removed on. The date each Sub-processor was added, and the date each former Sub-processor was removed, is recorded in Annex A, which is kept as a dated, append-only register. Tables 6.1 and 6.2 also carry an Added on / Removed on column as a reading convenience, so that a reader scanning the tables sees the dates in place: the cell states the Added on date while the party is current, and the Removed on date is entered into the same cell when the party leaves the live path, at which point the row also moves to clause 12 if that party may still hold Personal Data. Annex A — not the tables — remains the operative record of when a change took effect, and it is the evidence that the notice obligation in clause 16 was performed. Where the two ever differ, Annex A governs. On first publication, every Sub-processor listed in clauses 6 and 8 carries the publication date of this page as its Added on date, because all of them were engaged before this page first existed. This column is the dated record promised by clause 13.10 of the Data Processing Agreement.

2.3 Capacity. Several parties act partly as a processor on Carnelian's instructions and partly as an independent controller for their own purposes, such as fraud prevention, service security, billing and legal compliance. That dual capacity is real and is disclosed in the Capacity column. It means that for those purposes the party is not acting on Carnelian's instructions and its own privacy terms govern.

2.4 Where a fact is not yet confirmed. Where a fact on this page has not been confirmed against a primary source, the entry says so in terms, and says when the answer will be published, rather than stating a guess. No live party is published with its processing location unresolved.

2.5 Currency of the list. Vendor terms change without notice. Carnelian re-reads each Tier 1 Sub-processor's terms, data-protection agreement and sub-processor list at least annually and on any notified change, and re-publishes this page. See clause 24.

3. Who is the controller, and for what

3.1 For Guest Data, the Studio is the Controller and Carnelian is the Processor. Bookings, treatment and service history, client records, conversation content, voice transcripts and the Guest Profile (the Digital Twin) the Assistant maintains are the Studio's data. Carnelian holds them to run the Studio's reception, on the Studio's instructions, and does not repurpose them as Carnelian's own commercial intelligence.

3.2 For some data, Carnelian is the Controller. This includes: marketing-website visitor analytics; waitlist sign-ups; studio application data submitted through the public application form; Console and Staff App account, identity and audit records; support tickets raised with Carnelian; and Carnelian's own billing data. The Privacy Policy describes that processing.

3.3 The demo studio. Carnelian operates its own demonstration studio, published as "Aura Beauty Lounge", and a demonstration hotline on +971 4 329 4347 that answers real enquirers. Anyone who messages or calls that line is Carnelian's own data subject, not a Studio's, and Carnelian is the Controller for that interaction. That same number is presently both the AI-answered demonstration hotline and the production WhatsApp sender, so a message sent to it may be an enquiry to Carnelian's own demonstration studio rather than to a Studio; the distinction matters to whoever is the Controller of the resulting record. Whether that dual use continues at launch, or whether the demonstration line and the production WhatsApp sender are separated before the first paying Studio, is stated on this page in the next published revision.

3.4 Why this matters on this page. A Sub-processor listed below may be processing Guest Data (Studio as Controller), Carnelian Data (Carnelian as Controller), or both. The Capacity column describes the party's capacity toward Carnelian; it does not change who the Controller is for a given data set.

3.5 Health-adjacent content. ABS Twin is a booking and customer-communications system for a Studio's own clients. It is not a clinical system and must not be used as one. Guests nevertheless volunteer health-adjacent information in free text — allergies, pregnancy, skin or hair conditions — and that text lands in conversation records and voice transcripts, and therefore reaches the Sub-processors that handle those records. Studios must not configure the Assistant to solicit, and must not enter, Restricted Data. See the Acceptable Use Policy and the Restricted / Health Data Addendum.

3.5.1 What happens when it is nevertheless detected — the prohibition is paired with a response path, not left as a disclaimer. A prohibition is not an answer to content that is already in the system, and this page does not present it as one. Carnelian therefore also operates the detection-and-response path committed in clause 18.9A of the Data Processing Agreement, in summary: a classifier already runs in the Assistant's output path and forces a deferral rather than a clinical answer; classification events are logged against the organisation and a correlation identifier; a defined threshold raises an internal alert that a human reviews under the incident procedure; and on a confirmed indication that Restricted Data is present in a Studio's tenant, Carnelian notifies that Studio, tells it what was found and where, stops the offshore flow of the affected content so far as is technically possible while the matter is open and records what could not be stopped, and requires the Studio to stop the practice producing it. Carnelian may then restrict, quarantine or remove the affected content, and may suspend the affected feature; those rights are exercised under clause 18.9A of the Data Processing Agreement, which applies to every Studio, and do not depend on any separately executed addendum. The Studio, as Controller, remains responsible for any communication owed to the Guest.

Executing the Restricted / Health Data Addendum is not an alternative to stopping the practice, and is not a cure. Part II of that Addendum applies automatically to every Studio whether or not it is separately signed, so there is nothing for a Studio to execute in order to bring it into effect; its clause 4.4 states expressly that executing it does not permit any Restricted Data to be submitted to, generated within, or otherwise to enter ABS Twin; and the localised mode in Part III of that Addendum applies to no one and is not offered today. No instrument on this page or in the document set makes the offshore processing of regulated health information lawful — see clause 15.5.

3.5.2 The honest limit on clause 3.5.1. The classifier is a control on output, not a filter on input. It does not prevent a Guest from typing or speaking health information, it does not scan every stored record, and it does not detect every instance. Carnelian does not represent that Restricted Data will be detected, and detection is a mitigation rather than a warranty: its failure does not waive the Studio's obligation under the Acceptable Use Policy and the Restricted / Health Data Addendum, and does not transfer the Studio's responsibility to Carnelian. The transfer position that applies to any health information that does reach the chain is stated at clause 15.5, and is a matter of the architecture rather than of drafting.

4. Carnelian group entities

4.1 As at the version date of this page, Carnelian's own records identify no affiliate, subsidiary, parent company or group entity that processes Personal Data in connection with ABS Twin, and identify no intra-group transfer, no offshore support entity and no shared-services company in this chain. This statement is made from Carnelian's records and is limited to the position as at that date; it is not a warranty, and it is subject to the confirmation in clause 4.2. If a group entity is ever introduced, it is added through Annex A like any other Sub-processor addition and notified under clause 16.

4.2 carnelian.tech is not another entity. It is the corporate website of Carnelian Technologies L.L.C-FZ — the same company named in the table above — and the mailbox support@carnelian.tech on that domain is that company's own. No separate company operates under it, and none processes Personal Data in connection with ABS Twin. Whether any contractor or freelancer outside the UAE has standing access to production data is stated on this page in the next published revision; until it is, clause 4.1 is published as a records-based, time-bounded statement rather than a flat assertion.

5. Summary of the chain

5.1 ABS Twin's processing chain has four layers below the Guest:

Guest (data subject)
    │
    ▼
Studio  ─────────────────────────  CONTROLLER of Guest Data
    │
    ▼
Carnelian Technologies L.L.C-FZ ─  PROCESSOR (this is us)
    │
    ▼
Tier 1 — Direct Sub-processors ──  we contract with these (clause 6)
    │
    ▼
Tier 2 — Onward Sub-processors ──  they contract with these (clause 8)

5.2 The chain is not uniform. A WhatsApp message touches a different set of parties from a phone call, which touches a different set again from a Console login or a subscription invoice. The "Applies to" column in Tables 6.1 and 6.2, in the Tier 2 table in clause 8 and in the table in clause 12 states, per Sub-processor, which surfaces cause a Studio's data to reach it (clause 2.2.1), and clause 7 adds the material nuances.

6. Tier 1 — Direct Sub-processors

Table 6.1 — Identity, capacity, purpose and the surfaces each party applies to

How to read the "Applies to" column. It states which parts of ABS Twin cause a Studio's data to reach that party, and it is what makes the objection right in clause 17 operable, because "the affected part of the Service" is identified per party. All Studios means every Studio on any plan. A named surface (WhatsApp, Voice, Instagram, Staff App, Console) means only a Studio for which that surface is enabled. Carnelian-only means the party receives no Customer Data and no Guest Data at all and is listed for completeness — a label used on this page only where that is strictly true.

Table 6.2 — Data categories, locations, retention and sources

7. Tier 1 — material notes per Sub-processor

These notes state the things a Studio's compliance reviewer would otherwise have to discover for themselves.

7.1 Anthropic. This is the reasoning model behind the Assistant's WhatsApp and Instagram replies and behind the Digital Twin. Two facts matter. First, there is no EU or UAE processing region for this vendor: all processing is in the United States or under a global setting. Second, the vendor's published commercial terms state that it does not train on business API content; that statement is made from those published terms and is not yet evidenced from an executed agreement (Annex B row 1 is open), and clause 14(b) carries the same qualification. The open verification is which route production actually uses (clause 6, row 1): if Claude is consumed through a cloud marketplace, the cloud provider is the processor and this list would be naming the wrong company. Third, and stated for the same reason the same point is made about the messaging and billing providers: this vendor is not purely a processor. Content flagged by its own trust-and-safety processes is retained for that vendor's own purpose, for a period stated in Table 6.2 as up to two years, and retention for a vendor's own trust-and-safety, abuse-detection and security purposes is not processing on Carnelian's instructions. For those purposes the vendor acts as an independent controller on its own terms, and Carnelian can neither instruct nor delete that retention.

7.1.1 The contracting entity and the processing region are two different questions, and this page keeps them apart. Which Anthropic entity Carnelian contracts with determines who the Sub-processor is, which transfer terms apply and where a claim would be brought. It does not determine where the data is processed. In particular, contracting with an Anthropic entity established in Ireland would not create an EU processing region for this vendor, and would not make any Guest Data resident in the European Union: the first sentence of clause 7.1 would still be true. A contracting entity is not a processing region, and this page does not treat it as one. Clause 15.2 states the position that applies to the platform as a whole.

7.2 OpenAI. Used narrowly, for transcribing Guest voice notes. This is the only model vendor in the stack that offers processing in the UAE, subject to approval. That is worth knowing for a Studio with an in-country processing requirement, but it is not configured, not approved and not offered today, and ABS Twin does not process in the United Arab Emirates on that route. As with the primary model vendor, this vendor is not purely a processor: it retains abuse-monitoring logs for a period stated in Table 6.2 for its own trust-and-safety and security purposes, and for those purposes it acts as an independent controller on its own terms rather than on Carnelian's instructions.

7.3 Vapi. This vendor orchestrates the live telephone conversation. It is the layer everything on a call passes through, and it is proprietary: raw audio, transcribed text, model responses, emotion metadata and call signalling all transit this vendor's orchestration layer, and that layer cannot be replaced or self-hosted, whatever configuration is chosen elsewhere. See clause 9 for the full chain. Its own terms do not impose a recording-consent obligation on Carnelian — that obligation reaches Carnelian through the messaging provider's acceptable-use policy and through UAE law, and Carnelian imposes it on Studios through the AI & Communications Addendum and delivers it as a fixed product behaviour under the AI & Recording Disclosure.

7.4 Twilio. Two facts a Studio should be told before it signs. First, this vendor processes partly as an independent controller for its own fraud-prevention, service-improvement and legal-compliance purposes; for those purposes it is not acting on Carnelian's instructions. Second, WhatsApp traffic runs only in this vendor's United States region. There is no European region for WhatsApp. Any statement that a Studio's WhatsApp conversations stay in Europe or in the UAE would be false.

7.5 Meta / WhatsApp. Meta is both a Sub-processor and a Platform Provider (clause 10). It reviews and approves message templates, sets and changes quality ratings and messaging limits, and can suspend a WhatsApp sender or an entire business portfolio. Those are Meta's decisions, made under Meta's policies, and Carnelian cannot control or guarantee them. Meta's business terms also place obligations on the business that holds the WhatsApp account — including maintaining an active administrator — which is why the Master Subscription Agreement and the onboarding schedule must record who holds the WhatsApp Business Account for each Studio. Who holds the WhatsApp Business Account for a given Studio, who is its administrator of record, and whether Studio senders are pooled in one Meta business portfolio are settled in that Studio's onboarding schedule and stated on this page in the next published revision.

7.6 Airtable. This is the operational heart of ABS Twin and it holds the most sensitive combination in the system: Guest identity and history alongside the Studio's own staff records, including immigration status, professional certification expiry and payroll fields. Three things must be stated honestly. It is hosted in the United States by default. Its terms give it no committed advance-notice period for sub-processor changes — which is why Carnelian's own notice commitment in clause 16 is expressed conditionally. And its terms reserve broad suspension rights and disclaim responsibility for unauthorised access; Carnelian's mitigations are the nightly encrypted backup, the export commitment in the Master Subscription Agreement, and the sub-processor liability position in clause 18.

7.7 Supabase. Holds the conversation content itself — the message bodies. It gives one of the two firmest breach-notification commitments in the stack — within 48 hours of discovery — alongside Stripe, whose 48-hour commitment is stated for European and United Kingdom personal data and may therefore not reach a UAE Studio's Guest Data (both commitments are re-read on the annual re-check under clause 24.3, because vendor breach-notice terms change), and honours a customer's regional directive, which makes the region question in Table 6.2 the single most answerable residency item on this page. Carnelian's own control at this layer — row-level security enabled on every table with no permissive policies, enforced in the schema itself so a new table is closed in the same change — is described in Annex 2 of the Data Processing Agreement.

7.8 Vercel. Hosts everything and stores uploads and backups. The region of each Blob store is settled — the stores were created in this vendor's default United States region, and a Blob region is chosen at creation and immutable afterwards, so a different region could only be reached by creating a new store and migrating to it. What remains gating is each store's access mode. The honest position on access mode is stated rather than implied: this object store has been used on a public-with-an-unguessable-URL basis — objects keyed under the organisation identifier with a random suffix — and a public store is readable by anyone who has the URL and is cached by the content-delivery network for up to a month. That is not adequate for a UAE client database, and it is precisely why Carnelian encrypts the nightly database backup with its own key before upload (the backup job does nothing at all if that key is absent). No store holding Personal Data may be public, and every store holding Personal Data — in particular the client-import store, which holds an entire client book — is migrated to a private store.

7.9 Clerk. Holds Authorised User identities. Note the 90-day deletion tail after termination when reading clause 20. Carnelian enforces its own access controls above this vendor's baseline; those controls, and their honest limits, are described in Annex 2 of the Data Processing Agreement and are not overstated on this page.

7.10 Stripe. Used for the Studio's subscription to Carnelian, and for the hosted billing portal. Carnelian is not a payment processor, is not the merchant of record for the Studio's own takings from its Guests, and does not store, process or transmit cardholder data. One question is open and is stated rather than assumed away: whether any Guest payment to a Studio flows through a Carnelian-controlled Stripe account, or whether all such payments are the Studio's own arrangement with its own provider. It is open because the guest payment records in the operational database carry Stripe payment-intent and payment-method identifiers alongside a card's last four digits, and those identifiers do not exist unless a Stripe object exists for a Guest's payment. The answer is stated on this page in the next published revision. The two arrangements are kept separate in the contract and on this page, and the same note is carried in Table 6.1 row 10 and Table 6.2 row 10.

7.11 Upstash. Short-lived operational state. It is easy to overlook because nothing is stored for long, but it holds Guest telephone numbers and one-time verification codes, and it schedules the reminder and campaign jobs. It is a Sub-processor and is listed as one.

7.12 Bird / Pusher Beams. The least well-documented vendor in this stack, because Pusher was acquired and the governing data-protection agreement has not been confirmed for the Beams service. Until that is confirmed in writing, Carnelian's mitigation is a product rule rather than a contract: no personal data in a push payload beyond a Guest's first name, a service name and a time. That rule is enforced in the code that builds the payloads. It is also why the push transport providers in clause 8 receive so little.

7.13 Resend. Email bodies are content. A complaint escalation email to a Studio owner contains the complaint. Carnelian applies the same minimisation instinct here as everywhere else — no more Personal Data in an email body than the message actually requires — but the honest position is that these bodies sit in this vendor's logs for the life of the agreement, and that its compliance records persist for three years after termination.

7.14 Amazon SES, Cloudflare, Telegram, GitHub. Thin or nil exposure, listed for completeness. Cloudflare carries a capacity point despite that thin exposure: the challenge, threat and traffic data it collects when a public form is submitted is used for that vendor's own network-security, threat-intelligence and abuse-prevention purposes across its whole network, which is not processing on Carnelian's instructions; for those purposes it acts as an independent controller on its own terms.

7.14A Telegram — the one party with no written instrument, and what follows in law. Telegram is the entry that deserves a Studio's attention. It is a consumer messaging platform used for operational alerting — Carnelian's own, and a Studio's own staff alert channel where the Studio opts into one — and it is not covered by a negotiated data-protection agreement, and none is expected. Carnelian's rule that alerts carry a correlation identifier rather than a conversation lane exists precisely because of that; but a complaint-escalation alert can carry limited Studio-side detail, so this is not a zero-data recipient and this page does not label it as one. Three consequences are stated rather than left to be found:

(a) The equal-protection assurance in clause 13.2 is not available for this party, and the requirement in clause 13.1 is expressly stated as subject to this disclosed exception (clause 13.1A).

(b) The platform position. Where a messaging platform requires a written agreement with every service provider that touches its platform data, this party cannot satisfy that requirement; the alert paths are therefore to be kept clear of any content derived from that platform's data.

(c) The statutory position, stated because no clause on this page can limit it. Where processing involves more than one processor, the applicable data-protection law requires the processing to be governed by a written agreement clearly defining the roles, failing which the processors are jointly liable. Carnelian does not represent that this exposure is limited by anything on this page.

7.15 PostHog. The boundary here is architectural, not a policy promise: analytics is loaded on the marketing website only and is never loaded in the Console, the Staff App or any Guest-facing surface. That boundary is enforced by an automated test, not by a memo. The event schema is checked property by property against that same boundary — no Guest identifier, no booking detail, no URL containing an identifier — at every review under clause 24.3, and the property allowlist is recorded in our internal records.

8. Tier 2 — Onward Sub-processors

8.1 Carnelian does not contract with the parties in this clause. They are engaged by a Tier 1 Sub-processor. They are published because Customer Data or Guest Data reaches them. Competitors typically stop at Tier 1; Carnelian publishes Tier 2 because the second tier is where a voice call actually goes.

8.1.1 Why this table carries a retention column and a terms column. Tier 2 is where raw call audio goes and it is the tier where Carnelian has no contract to show. A table that names those parties but gives a reader nothing to click and no period to read is at its weakest exactly where the exposure is greatest, and it invites the reader to assume the position is worse than it is — or better. The retention and terms columns are therefore treated as first-class here, on the same footing as the equivalent columns in Table 6.2, because those are the rows a Studio's compliance reviewer turns to first. Where Carnelian has not confirmed a period, this page states that it has not confirmed it rather than describing a default in words that read like a commitment.

8.1.2 The live voice chain is named — and what is still open about it is named too. The providers in ABS Twin's live voice path are identified: Soniox performs the speech-to-text, on model stt-rt-v5; ElevenLabs performs the text-to-speech; and the language model that runs the in-call conversational turn is OpenAI's gpt-4.1. All three are reached through the voice platform, and each was verified against the live voice configuration on 23 August 2026. All three process in the United States, and clause 15.1 carries them in the United States row accordingly.

What is not settled is the terms limb, and this page keeps the two apart: the retention period that applies to ABS Twin's traffic at each speech provider, and the executed opt-out, zero-retention arrangement or data-protection agreement that displaces each provider's published default, are not yet evidenced. Speech vendors in this market commonly retain or train on content by default. Knowing who receives a Guest's call audio and knowing what that recipient may do with it are two different questions, and treating the first as if it answered the second is how a Studio comes to believe it has a protection it does not have. Clause 14(d) is hedged for that reason.

8.2 Each Tier 1 Sub-processor publishes its own onward list. The links are in Table 6.2. Those lists change more often than this page, and a Studio evaluating a specific vendor should read the vendor's own list as well as this one.

8.3 This clause is not exhaustive of every party in every vendor's supply chain. No published list in this market is. It names every onward party that Carnelian has identified as receiving Customer Data or Guest Data, and Carnelian updates it on the same cycle as the rest of this page.

9. The voice chain, disclosed as a chain

9.1 A telephone call to a Studio using ABS Twin's voice assistant does not touch one vendor. It touches a chain, and each hop is a separate exposure:

Guest's phone
   │
   ▼
The Studio's OWN telephone line           ── on the Studio's own carrier contract. That
   │  and its own carrier                    carrier is NOT a Carnelian Sub-processor.
   │                                         See clause 9.1.1
   ▼
On-premises gateway device                ── Carnelian-supplied, installed at the Studio's
   │  (analogue → encrypted SIP)              premises. Equipment in the audio path, not a
   │                                          party and not a storage location. Clause 9.1.2
   ▼
Vapi orchestration layer                  ── PROPRIETARY. Cannot be replaced or self-hosted.
   │                                          The gateway bridges the line TO THIS LAYER, and
   │                                          this layer routes the audio onward. Raw audio,
   │                                          transcribed text, model responses, emotion
   │                                          metadata and call signalling ALL transit here
   ├──▶ Speech-to-text: SONIOX             ── receives RAW CALL AUDIO. Model stt-rt-v5.
   │      (model stt-rt-v5)                   United States. Clause 8
   │
   ├──▶ Language model: OPENAI gpt-4.1     ── receives the conversation text. United
   │                                          States. This is the model that runs the
   │                                          live in-call turn — NOT the model in
   │                                          Table 6.1 row 1, which is engaged only
   │                                          after the call. Clause 8.1.2
   │
   └──▶ Text-to-speech: ELEVENLABS         ── receives the text to be spoken. United
                                              States. Clause 8
   │
   ▼
back through the orchestration layer to the Guest's phone
   │
   └─▶ after the call: transcript, summary, caller number, duration and end reason
        are written to the operational database (Airtable) and used to update the
        Digital Twin. The post-call transcript handling, summary and Digital Twin
        update are where the model provider in Table 6.1 row 1 is engaged

9.1.1 The first hop, stated expressly — the telephone line and the carrier. The voice assistant does not use a telephone number provisioned by Carnelian for the call leg between the Guest and the Studio. It answers the Studio's own existing telephone line, provided to the Studio by the Studio's own telecommunications carrier under the Studio's own contract with that carrier. Carnelian does not contract with that carrier, does not select it, does not configure it and does not instruct it. That carrier is therefore not a Carnelian Sub-processor and is not listed in clauses 6 or 8; in relation to the call traffic it carries for the Studio it is the Studio's own supplier, and the Studio's own arrangements with it govern. A Studio's compliance review should treat its carrier as a party in its own chain, not in Carnelian's.

9.1.2 The gateway device, and what Carnelian does supply. The bridge between that analogue line and the voice platform is an analogue-to-SIP gateway device supplied and configured by Carnelian and installed on the Studio's own premises. It converts the call to an encrypted SIP session (transport-layer security, with authentication) carried over the Studio's internet connection to the voice platform. The device is equipment in the audio path; it is not a third party, it is not a Sub-processor, and it stores no call content. It is disclosed here, and in clause 11, for the same reason clause 11 exists: equipment sitting in the audio path on a Studio's premises is far worse discovered later than published in advance.

One limit on that description, stated here rather than left to the Order Form: not every line and not every carrier can be bridged. Some carriers and networks restrict or block the protocols involved, and Carnelian does not warrant that a given line or carrier can be bridged. The Order Form, at its own clause 12, states that position and governs it.

Whether any intermediate SIP trunk provider, session border controller operator, hosted PBX or other telephony intermediary is interposed between the on-premises gateway and the voice platform is stated on this page in the next published revision. If any such party is interposed, it receives raw call audio, it is a Sub-processor, and it is added to clause 6 or clause 8 with its contracting entity and its processing country, and carried into clause 15.1.

9.1.3 Instagram and WhatsApp do not use this chain. The chain in clause 9.1 applies to a telephone call only. A WhatsApp or Instagram message never reaches the speech vendors or the voice platform.

9.2 Three consequences a Studio should understand.

(a) The orchestration layer cannot be engineered around. Even with the maximum bring-your-own configuration, everything on the call passes through it.

(b) Raw audio leaves the chain's control at the speech layer. The speech vendors in clause 8 are the reason clause 14 is hedged.

(c) The transcript is durable, and it is the record — there is no audio recording. Call audio is not recorded. No recording of a call is made or retained, by Carnelian or by the voice platform, on any configuration in use. What is stored after the call is the full written transcript, an AI-written summary, the caller's number, the duration and the end reason, and the transcript feeds the Digital Twin; the transcript is kept as the record of what was communicated on the call. That the audio is not kept does not make the transcript any less a capture of the conversation — the AI & Recording Disclosure treats it as recording and requires it to be announced and declinable, and the UAE treats recording without the consent of all parties as a criminal matter. The exact words a caller hears at the start of a call are the runtime scripts published in the AI & Recording Disclosure, which governs them; its clause 9.1A records that the live spoken introduction identifies the Assistant as an AI but does not yet state that the call is written down.

9.3 Restricted Data must not enter this chain. Studios must not configure the Assistant to solicit, and must not enter, Restricted Data as that term is described at clause 1.6 — the same scope stated at clause 3.5, not a narrower one. See the Acceptable Use Policy and the Restricted / Health Data Addendum.

9.3.1 And if it does. The prohibition in clause 9.3 is paired with the detection-and-response path summarised at clause 3.5.1 — notification to the Studio, stopping the offshore flow of the affected content so far as is technically possible, restriction, quarantine or removal, and the right to suspend the affected feature — and with the honest limits at clause 3.5.2. The voice chain is the hardest case, because raw call audio has already left for the speech layer by the time any text control could operate (clause 9.2(b)): on this chain the response is retrospective, and clause 15.5 states the transfer position that follows. A Studio whose Guests are likely to volunteer health information on the telephone should read clauses 3.5, 9.2, 15.5 and the Restricted / Health Data Addendum together before enabling the voice assistant.

10. Platform Providers — a note on what Carnelian does not control

10.1 Some of the parties on this page are more than Sub-processors. They are Platform Providers: Meta Platforms and WhatsApp; Twilio; telephony carriers and SIP providers; the AI model providers; the hosting providers; the app stores (Apple and Google); and the payment providers.

10.1.1 Not every Platform Provider is a Carnelian Sub-processor, and the difference is deliberate. Two classes of Platform Provider named in clause 10.1 do not appear in clauses 6 or 8, and their absence is a boundary rather than an omission:

(a) Telephony carriers and SIP providers. The telephone line the voice assistant answers is the Studio's own line on the Studio's own carrier contract. Carnelian does not contract with, select, configure or instruct that carrier, and it is therefore not a Carnelian Sub-processor. Clause 9.1.1 states the position in full, and clause 9.1.2 carries the confirmation for any telephony intermediary that may turn out to be interposed.

(b) The app stores — Apple and Google, as distributors. The Staff App is a web application today: the native iOS and Android builds are in development and have not been submitted to any app store (see the Staff App Privacy Notice). Where the native Staff App is distributed through the Apple App Store and Google Play, then in distributing the app, operating the store account, processing any store transaction and enforcing their store policies, those parties act in their own right as controllers of their own store data on their own terms, not on Carnelian's instructions, and they are not Carnelian Sub-processors in that capacity. The Staff App Privacy Notice describes what a store receives. Where Apple or Google does act as a Carnelian Sub-processor it is listed as one — Apple as the push-notification transport (APNs) and Google as Firebase Cloud Messaging and as Google Cloud, all in clause 8.

10.2 Carnelian does not control, and does not promise, their terms, their availability, their pricing, their approval decisions, their rate limits, their quality ratings or their enforcement actions. Specifically and without limitation, a Platform Provider may: suspend or ban a messaging sender or an entire business portfolio; reject, pause or re-categorise a message template; change the price of a message or a minute; change its policies unilaterally; reduce or share message throughput across a portfolio; deprecate a feature; or suspend a service for a reason of its own.

10.3 This is a statement of scope, not an exclusion of liability. It describes what ABS Twin is and what it depends on. It does not purport to relieve Carnelian of responsibility for its own acts and omissions, including its selection and configuration of those providers. Equally, a Platform Provider's suspension, throttling, template rejection, policy change, deprecation or outage is not itself a breach by Carnelian; where one occurs, the relief that applies is the relief and force-majeure regime in the Master Subscription Agreement and the service-level regime in Support & Service Levels. The contractual consequences — for availability, for fees, and for a Studio's remedies — are in the Master Subscription Agreement, Support & Service Levels and the AI & Communications Addendum, and are subject to the savings clause in clause 22 of this page.

10.4 What ABS Twin is, and is not. ABS Twin is a booking and customer-communications system for a Studio's own clients. It is not a general-purpose AI assistant, and it must not be configured or described as one. This positioning is a condition of the messaging platform's terms, and Studios are bound to it through the Acceptable Use Policy and the AI & Communications Addendum.

11. On-premises processing — the operations runner, and the voice gateway on a Studio's premises

11.1 Carnelian discloses two unusual entries that would not appear on a competitor's list.

11.2 A headless operations agent runs on a single machine on premises in Dubai, United Arab Emirates, on hardware controlled by Carnelian's principal — the same description used in clause 13.12 of the Data Processing Agreement, and not a company data centre. It runs on a short schedule and drafts fixes and support replies from a privacy-capped evidence bundle assembled for a specific incident or ticket, in a disposable working copy. It is not a third party and is not a Sub-processor: it is Carnelian, as Processor, processing data it already holds, on its own hardware. It is not a location at which Carnelian processes only its own data — the evidence bundle can contain a Studio's data, which is why clause 11.4 remains open. It is disclosed because an undisclosed on-premises processing location found later is far worse than one published in advance.

11.3 That machine is configured so that nothing is sent from it to any recipient not otherwise named on this page, and drafted support replies are sent only on human approval. That is a statement of how the machine is configured, not a warranty that no other transmission is technically possible.

11.4 What is not yet stated about that machine. Its disk-encryption, access-control and physical-security posture, and whether an evidence bundle can contain Guest conversation content or only correlation identifiers and excerpts, are governed by the security measures at Annex 2 of the Data Processing Agreement and are stated on this page in the next published revision.

11.5 The voice gateway on the Studio's premises. Where a Studio takes the voice assistant, Carnelian supplies and configures an analogue-to-SIP gateway device that is installed at the Studio's own premises in the United Arab Emirates and bridges the Studio's existing telephone line to the voice platform (clause 9.1.2). Call audio passes through that device in real time. It is Carnelian-supplied equipment operated on the Studio's site; it is not a third party and not a Sub-processor, and it is not a storage location — it holds no call recording, no transcript and no guest record. It is listed here because it is a device in the audio path and a Studio is entitled to know that a Carnelian-configured device sits on its own network.

11.5.1 Title, warranty, return and exit — stated by cross-reference, because this page is not where they live. Title to the gateway device, the point at which it passes, risk, the equipment warranty, the return or exchange window, any replacement charge, and the position on the device when a subscription ends are stated in the Order Form, at its own clause 12, and in the Master Subscription Agreement, and those documents govern. This page describes only the device's place in the processing chain. Nothing on this page is to be read as a statement of who owns the hardware, or as a waiver of any proprietary interest, retention of title, return obligation or transfer restriction stated in those documents. The Order Form's equipment terms govern, and clauses 11.5 and 9.1.2 are conformed to the executed Order Form — including where title passes when the Voice Line Kit fee is waived under a promotion rather than charged, and the disclosure of any delivery or installation charge — in the next published revision. Whatever the position on title, it does not carry with it the right to reconfigure the SIP credentials or to repoint the device, which remain administered under clause 11.5.2, and it does not make the Studio a Sub-processor or a Processor of anything.

11.5.2 Credentials and on-device logs. Who holds the gateway's administrative credentials after installation, and whether the Studio is given them; and whether any call audio, call-detail record, SIP trace or other log is written to the device or retained on it beyond the life of the call, are stated on this page in the next published revision. The second limb is the one that matters for this page: a device that retains a call-detail record is a storage location on a Studio's own premises, and clause 11.5 would be corrected accordingly.

12. Parties no longer in the live path

12.1 The following parties are no longer in the live processing path for ABS Twin: no Personal Data is sent to them, and they perform no function in the Service today. They are recorded here because they held data historically, and because the record of when a processor was removed is part of the evidence this page exists to provide.

12.1.1 The honest limit on clause 12.1 — storage is processing. Removal from the live path is not the same as deletion. Until deletion of the historical data in each account is confirmed and dated, each party below may still hold Personal Data — including Guest conversation content — and to that extent remains a current processor, not merely a former one. Where that is the position, the party's own retention and its processing country apply, and clause 15.1 and Annex B are to be read as covering it. The rows added for these parties in clause 15.1 and in Annex B are removable, and this clause is reducible to a simple historical record, only once the confirmations below are recorded.

12.1.2 The contracting entity and the processing country of each of the two parties above are stated on this page in the next published revision, for so long as either is treated under clause 12.1.1 as still holding Personal Data.

12.2 A retired dependency is not removed from this page. It moves to this clause, and its removal date is recorded in Annex A.

13. Written agreements, and the assurance Carnelian can give

13.1 Carnelian's requirement is that each Tier 1 Sub-processor is bound by a written agreement that: (a) restricts the party to processing for Carnelian's purposes and on Carnelian's instructions, save where that party acts as an independent controller as disclosed in Table 6.1; (b) imposes data-protection obligations no less protective than those Carnelian owes a Studio under the Data Processing Agreement; (c) imposes confidentiality obligations; (d) requires appropriate technical and organisational security measures; and (e) requires deletion or return of the data on termination, subject to the residual realities in clause 20.

13.1A What that requirement does and does not deliver — the honest limit, stated with the requirement rather than after it. Limbs (a) to (e) are what Carnelian requires; they are not a description of what Carnelian has obtained. They apply so far as the relevant Sub-processor's own terms permit. Where a Sub-processor's terms are non-negotiable — which is the position with most of the parties on this page — Carnelian relies on those terms to the extent they go and does not represent more protection than they give, and Annex B records the instrument that in fact governs that party. This is the same position as clause 13.7.1 of the Data Processing Agreement, and that Agreement governs (clause 1.5).

One party is a disclosed exception rather than an unresolved gap. Telegram (Table 6.1 row 16 and clause 7.14A) is not covered by a negotiated data-protection agreement and none is expected from that vendor. Clause 13.1 is stated subject to that disclosed exception, and clause 7.14A states the three consequences — including that where the applicable data-protection law requires processing involving more than one processor to be governed by a written agreement clearly defining the roles, failing which the processors are jointly liable, nothing on this page limits that exposure.

13.2 Equal protection. Where clause 13.1 is satisfied for a party by an instrument actually concluded with it, Carnelian's position is that the party affords Personal Data protection materially equivalent to that promised in the Privacy Policy. That statement is made about the instrument, not about the party's performance: it is not a warranty of any Sub-processor's performance (clause 22.3), and it is not available at all for a party whose row in Annex B is open or which is within the disclosed exception in clause 13.1A. Annex B records, per Sub-processor, whether the written agreement is executed.

13.3 The honest limit on clause 13.2. Where Annex B shows a written agreement is not yet executed, clause 13.2 is not yet available for that party, and this page says so rather than implying otherwise.

13.4 The transfer mandate, described as it actually operates. Under the general authorisation in the Data Processing Agreement — including the Studio's express consent to the sharing described on this page, given at clause 13.9 of that Agreement in addition to the general data-protection authorisation — Carnelian concludes such data-protection and transfer terms with Sub-processors as it is able to conclude, in its own name and for the Studio's benefit, so that a Studio does not have to paper eighteen vendors itself. Where a vendor's terms are non-negotiable, Carnelian accepts those terms and does not represent more protection than they give. This clause describes a mandate exercised, not a papering completed. The extent to which recipients have in fact accepted Carnelian's own form of transfer terms is recorded in the instrument-status record at Annex 4 of the Data Processing Agreement, which governs.

13.5 Tier 2 is different, and this page says so. Carnelian has no direct contractual relationship with a Tier 2 Onward Sub-processor. Its obligations are owed to the Tier 1 Sub-processor that engaged it. Carnelian's assurance in relation to Tier 2 is limited to requiring each Tier 1 Sub-processor to impose equivalent obligations on its own sub-processors and to remain responsible for them. Clause 14(d) and clause 18 state the practical consequence.

14. Training and model improvement

14.1 This clause is layered deliberately. Each layer is independently verifiable, and the fourth is hedged because the honest position today requires it.

(a) Carnelian. Carnelian does not use Customer Data or Guest Data to train AI models, and does not train, tune or evaluate any model across Studios. Carnelian does not build cross-tenant benchmarks or industry datasets from a Studio's operational data, and does not sell Personal Data. A transfer of Carnelian's business or assets, in which Personal Data passes to a successor that is bound to the same obligations, is not a sale of Personal Data for the purposes of this paragraph and is dealt with in the Privacy Policy.

(b) The primary model provider (Anthropic). That provider's published commercial terms state that it does not train on business API content. The operative training term is the one in the executed agreement. The statement in this paragraph is made from that provider's published terms and is not yet evidenced from an executed instrument — Annex B row 1 is open, and an unexecuted agreement cannot be the source of a contractual bar. Until it is executed, this paragraph is to be read as a statement about published terms and not as a contractual restriction Carnelian has secured.

(c) The secondary model provider (OpenAI). That provider's published terms state that it does not train on data submitted through its API absent an explicit opt-in. Whether the API training opt-in is on or off is a fact about Carnelian's own account settings, not about the provider's terms; it is checked and the configuration evidenced in our internal records, and the negative is not published here until it has been. Until then this paragraph states what that provider's terms say and nothing about Carnelian's setting.

(d) The voice layer — the hedge, and why it exists. The providers beneath the voice platform are named on this page: Soniox for speech-to-text (model stt-rt-v5), ElevenLabs for text-to-speech, and OpenAI's gpt-4.1 for the in-call turn, each verified against the live voice configuration on 23 August 2026 (clause 8.1.2). Speech vendors in this market commonly have retention or training on content as their default, and the opt-outs are variously enterprise-tier, per-request, or dependent on an executed agreement; the arrangement that displaces the default is not yet evidenced for either speech provider in our path. The voice platform itself expressly declines to police its providers' compliance. Carnelian therefore states, and states only, that it configures the retention and training controls available to it and contracts to restrict such use where the provider offers it.

Carnelian does not state that Guest voice data is never used to train AI models, and this page does not state it. That statement becomes available only once (i) the speech providers in the live path are identified, (ii) an opt-out, zero-retention arrangement or executed data-protection agreement is in place with each, and (iii) that is evidenced in our internal records. Limb (i) is now satisfied and the providers are named. Limbs (ii) and (iii) are not. Until they are, the position is the one stated in the paragraph above and nothing more.

(e) The messaging platform. Carnelian does not use WhatsApp Business Solution data to create, develop, train or improve AI systems. This is both a platform obligation and Carnelian's practice.

(f) A restriction that runs the other way. Studios may not use ABS Twin, its outputs or its voices to build a competing model, dataset or service, or to extract raw model access. See the Master Subscription Agreement and the Acceptable Use Policy.

14.2 Aggregate and anonymised data. Carnelian does not today produce cross-Studio benchmarks or aggregate insights from Customer Data. If it ever does, it will do so only on data that is anonymised such that no individual is identifiable in any way whatsoever, only with the Studio's express agreement obtained before the data is collected for that purpose, and only with an easy withdrawal route. The disclosure of the results of processing is separately restricted by the Data Processing Agreement.

15. Where data is processed, and on what basis it crosses borders

15.1 Named destination countries. Personal Data processed through ABS Twin is or may be processed in the following countries, by the parties named in clauses 6 and 8:

15.2 Residency, stated plainly — including what genuinely is in the European Union. Four parts of this stack are in the EU and are stated as such rather than played down: the conversation database is in Ireland (eu-west-1), so the message bodies themselves — every WhatsApp and Instagram message in both directions, the conversation turn records, the AI usage records, the support tickets, the client-import ledger and the waitlist — are stored in the European Union; outbound transactional email is sent from Ireland (eu-west-1); inbound mail to Carnelian is received in Ireland (eu-west-1); and the marketing-site analytics run on the vendor's EU cloud, ingested and stored in the European Union. Carnelian's billing entity is Irish.

Those are real, and they still do not make ABS Twin an EU-resident or a UAE-resident platform, and this page does not claim that they do. What remains outside the European Union is named rather than glossed: the operational database — Guest identity and contact details, bookings and visit history, staff records, payments, voice call records including the full transcripts, the Digital Twins and the audit log — is in the United States; the AI providers that read a message and draft a reply process in the United States or on a global setting; the entire live voice chain — the orchestration platform, the speech-to-text provider (Soniox), the in-call language model (OpenAI gpt-4.1) and the text-to-speech provider (ElevenLabs) — is in the United States; and the hosting, the file storage (including uploaded client books), the encrypted backups and the identity provider are in the United States.

ABS Twin therefore does not offer UAE data residency, and it does not offer EU data residency for the platform as a whole. One model vendor's UAE processing region is available and is not used. A Studio evaluating ABS Twin against an in-country or in-region processing requirement should treat that requirement as not met, and should read clause 15.1 for the destination of each specific data set rather than relying on one answer for the whole platform.

15.3 The basis for the transfers, and whose basis it is. For Guest Data the Studio, as Controller, determines the basis on which a transfer outside the United Arab Emirates is made (clauses 3.1 and 19.1). Carnelian does not settle that question for a Studio and does not represent that it has. What Carnelian does is implement the transfer under the mandate in clause 13.4 and conclude the terms it is able to conclude with recipients. The basis most commonly available on these facts is the necessity of the transfer for the performance of the contract with, or in the interest of, the data subject — a booking made by an individual with a Studio — supported by contractual measures binding each recipient, and by express consent where a Studio obtains it. Carnelian is the Controller, and therefore determines the basis itself, only for the categories in clause 3.2. The full statement is in the Privacy Policy and in the international-transfer clause of the Data Processing Agreement.

15.3.1 What those contractual measures are drafted to contain — and what Carnelian does not call them. The terms Carnelian concludes with recipients are drafted to include the element the UAE regime requires and which a European clause set does not contain: a provision identifying how appropriate measures may be imposed on the parties through a competent supervisory or judicial authority in the recipient's country. Carnelian does not describe those terms as "standard contractual clauses": the United Arab Emirates has issued none, and there is no adequacy list to rely on. Where a vendor relies on European clauses for its own European transfers, that is that vendor's mechanism and not Carnelian's, and this page does not present it as Carnelian's. The transfer assessment behind this clause is held in our internal records, and the extent to which these terms have actually been accepted by recipients is the open item noted at clause 13.4.

15.4 A transfer risk assessment covering these destinations is maintained internally and refreshed on the review cycle in clause 24.

15.5 Health information is a separate regime, and clause 15.3 does not cover it. The basis stated in clause 15.3 is the general personal-data basis. Health information in the United Arab Emirates does not sit under the general personal-data regime at all: it is carved out of it and governed by the federal law on the use of information and communications technology in the health fields, which prohibits storing, processing, generating or transferring health data outside the United Arab Emirates save under the exceptions and authorisations that regime provides — an authorisation route operated through the competent emirate Health Authority and the federal health ministry. Three consequences are stated here rather than left to be inferred:

(a) No transfer mechanism on this page cures it. A contractual transfer measure, a consent, a vendor's data-protection agreement and a European clause set are all instruments of the general regime. None of them is an authorisation under the health regime, and none of them makes an offshore transfer of regulated health information lawful. This is an architecture question, not a drafting question.

(b) The ABS Twin stack is irreducibly offshore, and is therefore not built to receive regulated health information. Clause 15.1 names the destinations; none of the parties handling conversation content, transcripts or call audio processes in the United Arab Emirates. That is precisely why the prohibition in clauses 3.5 and 9.3, in the Acceptable Use Policy and in the Restricted / Health Data Addendum exists, why the detection-and-response path in clause 3.5.1 exists, and why the response on detection is to stop the flow and remove the content rather than to paper the transfer.

(c) Carnelian holds no health-sector authorisation and does not offer a localised health tier today. Carnelian is not a licensed health facility, holds no Health Authority approval, and does not represent that ABS Twin as published on this page may lawfully receive regulated health information. A Studio that is a licensed health facility, or that intends the Assistant to handle regulated health information, must not use ABS Twin for that purpose on these terms; the only route contemplated is the separate, localised mode described in the Restricted / Health Data Addendum, which is not offered today and which would require in-country processing and the applicable authorisation before it could be.

15.6 What follows for a Studio's own assessment. A Studio carrying out the assessment described in clause 22.4 should treat clause 15.5 as a scope boundary rather than a risk to be weighed: the question is not whether the offshore transfer of health information can be justified on these terms, but whether health information is entering the Service at all. Clause 3.5.1 states what Carnelian does when it finds that it is.

16. How Carnelian notifies a change to this list

16.1 Subject to clause 16.4 (emergency substitution), Carnelian will notify a Studio before a new Sub-processor begins processing Personal Data. Carnelian will use each of the following channels, because a Studio should not have to rely on any single one:

(a) This page. The new entry is published in clauses 6 or 8 and recorded in Annex A with its Added on date. The page carries a version number and an effective date, and every superseded version stays accessible.

(b) Email. Carnelian maintains a change-notification subscription at https://abstwin.com/legal/sub-processors/subscribe. Notice sent to a subscribed address, or to the Studio's subscribed notice address under the Data Processing Agreement, is valid notice. It is the Studio's responsibility to keep a monitored address subscribed, and to update it when staff change.

(c) In the Console. A notice is shown to the Studio's owner role in the ABS Twin Console, so that notice does not depend on email deliverability — which itself runs through a Sub-processor.

16.1.1 Practice and validity are two different things, and this clause keeps them apart. Carnelian's practice is to use all three channels for every change, and a failure to use one of them is a departure from that practice which the Studio may raise. Validity is governed by clause 13.4 of the Data Processing Agreement, not by this page: the contractual notice channels are the ones that Agreement names, and where this page and that Agreement differ, that Agreement governs (clause 1.5). This page does not assert that publication alone discharges the notice obligation — a Studio that never receives a pushed notice would have no practical way to exercise the fifteen-day objection window in clause 17.1, which would make the objection right illusory. What publication under paragraph (a), together with the Annex A entry, does give is the dated, Carnelian-controlled evidence of when notice was given, which is the role clause 24.2 assigns it. A Studio that wants a second channel it controls should keep a monitored address subscribed under paragraph (b). Nothing in this clause shortens the notice period in clause 16.2, which runs from the earliest of the channels used.

16.2 The notice period — stated honestly. Subject to clause 16.4 (emergency substitution), Carnelian gives at least thirty (30) days' advance notice of a new or replacement Sub-processor where the relevant Sub-processor gives Carnelian equivalent advance notice, and otherwise as soon as reasonably practicable and in any event before that Sub-processor begins processing Personal Data.

16.3 Why the notice period is conditional. Carnelian cannot pass on a notice period it does not receive. The upstream reality is uneven: some vendors commit to 30 days, others to 14 or 15 days or 10 business days, one gives a 5-day objection window with no stated advance notice, and one of the most important vendors in the stack commits to no advance notice period at all. A flat "30 days" promise would be a promise Carnelian could not keep, and an unkeepable promise is worth less to a Studio than an accurate one.

16.4 Emergency substitution. Where a Sub-processor fails, is suspended, terminates its service or its agreement with Carnelian, or must be replaced urgently for a security, legal or regulatory reason, Carnelian may replace it immediately and give notice as soon as reasonably practicable afterwards, recording the change in Annex A. The objection route in clause 17 then applies to the replacement from the date of that notice.

16.5 Changes that are not additions. A change of a Sub-processor's corporate name or group ownership, and the removal of a Sub-processor, are recorded in Annex A and notified in the same way, but do not by themselves start a new objection window unless the change is materially adverse to the protection of Personal Data.

16.5.1 Two changes that are always treated as material, and always start a fresh window. A change to a Sub-processor's processing country or region, and a change to a Sub-processor's contracting entity where that changes the transfer route or the transfer instrument that applies, are treated as material changes: each is notified under clause 16 and starts a fresh objection window under clause 17. These two are carved out of clause 16.5 because they are the two facts this page treats as decisive everywhere else — a processing country is what clause 19.1.1 says a Studio in several regional jurisdictions must disclose by name in advance, and a contracting entity is what clause 7.1.1 identifies as determining the transfer route. A change a Studio would have to re-assess against its own approved-destination list or classification policy is not a change that should turn on Carnelian's own assessment of whether it is adverse.

17. Objection

17.1 The right. A Studio may object to a new or replacement Sub-processor within fifteen (15) days of the notice, on reasonable, documented data-protection grounds, by written notice to Carnelian's data-protection address.

17.1.1 Why the window is fifteen days and not thirty. The window is deliberately shorter than the notice period, and shorter than the thirty days some larger vendors publish, because it sits inside the notice period rather than running after it: the notice period in clause 16.2 is thirty days, so a fifteen-day objection window means an objection is raised, and can be dealt with, before the Sub-processor begins processing Personal Data. A thirty-day window inside a thirty-day notice period would let a Studio object only after processing had already begun, which is worth less to the Studio than the shorter window is. The period is the same fifteen days as clause 13.5 of the Data Processing Agreement, and the two must be amended together.

17.2 What Carnelian does with an objection. On a valid objection Carnelian will, at its option: (a) propose a commercially reasonable alternative; (b) explain the safeguards applied; or (c) make a change to the configuration that addresses the objection. These are the same three options as in clause 13.5 of the Data Processing Agreement, and are to be read as identical to it.

17.3 The remedy if it is not resolved. If the objection is not resolved within thirty (30) days of Carnelian's receipt of it, the Studio's sole and exclusive remedy is to terminate the affected part of the Service on written notice, with a pro-rata refund of recurring fees prepaid for the terminated part for the unexpired period, except where applicable law does not permit this to be the sole remedy. The "affected part of the Service" is identified by the Applies to column for the Sub-processor objected to (clause 2.2.1): objecting to a party that applies only to the voice assistant terminates the voice assistant, not the whole subscription.

17.3.1 Two limits on that remedy, said here rather than discovered on exercise. First, for a party whose "Applies to" entry is "All Studios" the affected part is the whole Service, so the remedy is termination of the entire subscription. On this page that is the position for Anthropic, Airtable, Supabase, Vercel, Stripe, Upstash, Resend, Amazon SES, Cloudflare and Telegram. Clerk is not an "All Studios" entry — its "Applies to" is the Console and the Staff App — but because every Studio uses the Console, an objection to Clerk terminates the Console and, with it, in practice the whole subscription. A Studio should understand before it objects that an objection to one of those parties is not a partial exit. Second, the refund is of recurring Fees prepaid for the unexpired period only. It does not extend to One-Off Charges — including the Voice Line Kit fee described at clause 11.5 — and termination under clause 17.3 does not release Fees already accrued. The Master Subscription Agreement governs both.

17.3.2 How a party named only in a cross-cutting register is treated. The destination table at clause 15.1, the vendor-cap table at clause 18.3, the deletion-tail table at clause 20.2 and Annexes A and B are registers rather than party listings and carry no Applies to column. Where a Studio objects to a party named in one of them, the affected part of the Service is identified from that party's row in Tables 6.1 and 6.2, in clause 8 or in clause 12; a party in clause 12 that is treated under clause 12.1.1 as still holding Personal Data is treated for this purpose as applying to All Studios, because that is the footing on which it held the data.

17.4 What an objection is not. An objection is not a right to require Carnelian to change its technology stack or to retain an incumbent provider; not a breach of contract by Carnelian; and, to the fullest extent permitted by applicable law and without prejudice to clauses 22.1 and 22.2, gives rise to no claim in damages. The general authorisation to engage Sub-processors, given by a Studio in the Data Processing Agreement, is not withdrawn by an objection. Carnelian may proceed with the change during the objection process where necessary to maintain the Service, without prejudice to the Studio's remedy in clause 17.3. This clause states the same position as clause 13.6 of the Data Processing Agreement and is to be read as identical to it.

17.5 A note for Guests. The objection right in this clause belongs to the Studio, which is the Controller of Guest Data. A Guest who is concerned about a Sub-processor should contact the Studio; Carnelian will assist the Studio in responding. See clause 21.

18. Carnelian's responsibility for its Sub-processors

18.1 The general position. Carnelian remains responsible to a Studio for the performance of a Tier 1 Sub-processor's data-protection obligations, as set out in the Data Processing Agreement.

18.2 The limit, stated plainly — and it has a floor. Carnelian's liability to a Studio for the acts and omissions of a Sub-processor is limited to the greater of: (i) the amounts Carnelian actually recovers, or is entitled to recover, from that Sub-processor in respect of the same event; and (ii) the aggregate liability cap that would otherwise apply under the Master Subscription Agreement or, for a matter within the enhanced cap in the Data Processing Agreement, that enhanced cap — in each case inclusive of, and not additional to, that cap. This limit applies to the fullest extent permitted by applicable law.

18.2A Why the floor is there, and what it means for a Studio. Clause 18.3 publishes what every vendor in this chain caps its own liability to Carnelian at, and several of those figures are nominal. A limit measured only by an upstream recovery would therefore reduce a Studio's remedy for the most likely category of loss — a data incident at the database, the host or a speech vendor — to a nominal sum, and every other liability limb in the ABS Twin document set has a floor for exactly that reason. The effect of clause 18.2 is that a Studio's remedy is never less than the ordinary contractual cap, and is more than that cap where Carnelian recovers more upstream.

18.2.1 What Carnelian owes in return — the limit is a channelling of the claim, not a disclaimer of it. A limit measured by a recovery is only fair if the recovery is actually pursued. Carnelian therefore undertakes, in respect of any event for which clause 18.2 is relied on:

(a) on the Studio's reasonable written request, to pursue the relevant Sub-processor for the loss diligently and at Carnelian's own cost, and to keep the Studio informed of the progress and the outcome. Nothing in this paragraph requires Carnelian to commence proceedings that a reasonable litigant would not commence, or to pursue a claim after the Studio has been paid for the same loss;

(b) to account to the Studio for the sums recovered from that Sub-processor that are attributable to the Studio's loss, and to pay them to the Studio to that extent. Because paragraph (a) puts the cost of recovery on Carnelian, no deduction is made from the recovery for Carnelian's costs of pursuing it;

(c) to tell the Studio, on request and within a reasonable time, whether it is pursuing the claim and, if it is not, why; and

(d) where Carnelian does not pursue the claim itself, or where the claim cannot be pursued by Carnelian, to assign that claim against the Sub-processor to the Studio, or to hold it on the Studio's behalf, at the Studio's request and so far as that Sub-processor's terms and applicable law permit — and, where those terms do not permit assignment, to give the Studio reasonable assistance, at the Studio's cost, in pursuing the claim in Carnelian's name.

18.2.1A How clause 18.2.1 stands against the Data Processing Agreement, stated accurately rather than as a flat identity. Paragraphs (a) and (d) restate clause 13.7.2A of the Data Processing Agreement and are to be read as identical to it. Paragraphs (b) and (c) go further than clause 13.7.2A as presently drafted: that clause contains no counterpart to the duty to account for and pay over recovered sums without deduction of Carnelian's costs of recovery, and none to the duty to say, on request, whether the claim is being pursued and if not why. They are undertakings Carnelian is content to give. Until the Data Processing Agreement carries them, clause 1.5 applies: where this page and that Agreement differ, that Agreement governs, and paragraphs (b) and (c) take contractual effect only when it carries them. Clause 18.2.2's disapplication is correspondingly limited by clause 18.2.2(d) below.

18.2.2 What happens if Carnelian does not do it — a proportionate consequence, not a detonator. Where Carnelian materially fails to comply with clause 18.2.1 in respect of an event, and does not remedy that failure within thirty (30) days of the Studio's written notice describing the failure, clause 18.2 does not apply to the extent of that unremedied material failure, and the ordinary liability position in the Master Subscription Agreement and the Data Processing Agreement applies instead to that extent. For the avoidance of doubt:

(a) a failure is material if it deprives the Studio of a substantial part of the benefit of clause 18.2.1 in respect of the event — a late or incomplete answer to a request under clause 18.2.1(c), or a delay that causes the Studio no prejudice, is not by itself material;

(b) the disapplication operates only in respect of the event concerned, and only to the extent of the failure; it does not disapply clause 18.2 generally, for other events, or for other Sub-processors; and

(c) nothing in this clause requires Carnelian to do what paragraph 18.2.1(a) expressly does not require it to do, and a decision not to pursue a claim that is taken and explained under paragraphs (a) and (c) is not a failure to comply; and

(d) for so long as clause 13.7.2A of the Data Processing Agreement carries no counterpart to paragraphs 18.2.1(b) and (c) (clause 18.2.1A), a failure of either of those two paragraphs alone does not disapply clause 18.2 as a matter of contract, because clause 1.5 makes that Agreement govern. The disapplication in this clause operates on the duties that Agreement in fact imposes; it is stated in this form so that the page does not publish a trigger the executed agreement cannot fire.

18.3 Why. Every vendor in this chain caps its own liability to Carnelian at a low figure. Publishing those figures is uncomfortable, and it is the honest basis for clause 18.2:

18.3.1 Provenance of the figures in the table above. Every figure in clause 18.3 is taken from the relevant party's own publicly published terms as at the version date of this page. No figure is reproduced from a confidential agreement, a negotiated order form, a quotation or any other document subject to a duty of confidence, and none is reproduced verbatim from another party's text. Each figure is stated as a summary of a publicly available term, is subject to change by that party without notice to Carnelian (clause 22.3), and is re-checked on the review cycle in clause 24.3. Where a cap is ever established only by a confidential or negotiated document, it is not published here; the row is marked as withheld and the position is recorded in our internal governance register instead. On accuracy toward the party named: each figure is stated as a good-faith summary of that party's publicly available terms as at the version date, is not attributed to that party as its own words, and is corrected promptly on notice from that party or on Carnelian's own review under clause 24.3.

18.4 What clause 18.2 does not do. It does not limit Carnelian's liability for its own acts and omissions, including its selection, configuration and supervision of a Sub-processor. It does not limit any liability that cannot lawfully be limited. It is subject to clause 22, and it operates as a contractual term only through the Master Subscription Agreement and the Data Processing Agreement, where it sits inside — and does not create a separate tower above — the liability provisions of the Master Subscription Agreement.

18.5 Tier 2. For the reasons in clause 13.5, Carnelian's responsibility in relation to a Tier 2 Onward Sub-processor is limited to the requirement it imposes on the Tier 1 Sub-processor that engaged it. This clause states the position between Carnelian and a Studio only. It does not limit, waive or qualify any obligation Carnelian owes to a Platform Provider — including any obligation under a platform's own terms to remain responsible for its service providers' compliance in respect of that platform's data — and it is not to be read as a disclaimer of any such obligation. Those obligations are owed to the platform, they are separate from what is owed to a Studio, and both can be true at once.

19. Platform and store requirements this page satisfies

19.1 Whose duty this page serves. The obligation to tell a Guest which establishments, inside and outside the United Arab Emirates, that Guest's data is shared with, and what safeguards apply to a transfer, is a Controller's duty. For Guest Data that Controller is the Studio, not Carnelian (clause 3.1). This page exists so that a Studio can discharge that duty — a Studio cannot name destinations it has not been told, and a generic reference to "service providers" in a Studio's own privacy notice does not satisfy the duty, whereas a named list incorporated from this page does. Carnelian owes the same duty directly, in its own right, only for the categories in clause 3.2 for which Carnelian is itself the Controller, and for those categories this page serves that duty too. Carnelian's own obligations as Processor — to disclose its Sub-processors to the Studio, to notify changes and to support the Studio's transparency — are the separate reason the page is published to Studios rather than only to Guests.

19.1.1 A Studio established elsewhere in the GCC has its own, additional duty. ABS Twin is sold across the Gulf Cooperation Council. Several regimes in the region require a controller to disclose the destination countries by name in advance of a transfer, and at least one operates a list of approved destinations rather than a case-by-case assessment. A Studio established in Kuwait, Bahrain, the Kingdom of Saudi Arabia or elsewhere in the region should assume it carries that named-destination duty in its own right, in addition to anything the UAE regime requires. Clause 15.1 is drafted to serve that duty: it names countries rather than describing regions, so that a Studio can lift the names into its own notice.

19.1.2 A Studio established outside the United Arab Emirates — the constraint is different in each jurisdiction, and this page signposts rather than answers. Clause 19.1.1 addresses one duty only. The regimes in the region differ in kind, not merely in detail, and a Studio should take its own advice on the one that applies to it. In outline, and without stating any of them as settled law:

• Kingdom of Saudi Arabia — an extraterritorial regime; a transfer is permitted only on that jurisdiction's own standard clauses, on binding corporate rules (which reach intra-group transfers only and therefore do nothing for a vendor chain), or under an accreditation route; a transfer risk assessment is mandatory; sensitive data is barred on the service-to-data-subject route; and safeguards are re-assessed on a stated cycle.
• Dubai International Financial Centre — the autonomous-systems regime applies to a system of this kind. On that regime a Studio would be the Deployer and Carnelian the Operator, and the Operator carries direct duties of its own, including notice content, a system register, design principles, and certification and an appointed officer for higher-risk processing. The allocation of those roles as between a Studio and Carnelian is a matter for the Data Processing Agreement, not for this page.
• Abu Dhabi Global Market — registration and an annual fee, with Commissioner-adopted clauses for exports.
• Bahrain — an approved-country list: every destination in clause 15.1 must be checked against it, and a foreign processor using means in that jurisdiction may need a local representative.
• Oman — a permit for sensitive-data processing, a data protection officer, and an Arabic notice.
• Qatar — prior authorisation for sensitive personal data, which expressly includes health data.
• Kuwait — a data-classification policy with in-country processing obligations for higher tiers; the jurisdiction in the region where localisation risk is highest.

Carnelian will execute the applicable transfer instrument for a Studio's own jurisdiction on request, so far as the counterparties in the chain permit it (clauses 13.1A and 13.4).

19.2 It also exists because the platforms ABS Twin depends on require it:

19.2.1 What the windows in the table above actually oblige. The shortest stated window sets the maintenance standard Carnelian applies to Annex B and the internal records: Annex B is maintained continuously so that it can be produced within the windows those platforms require, including at any time and for a year after the relevant platform relationship ends. A register that has to be reconstructed from vendor emails when a request arrives does not meet that standard, which is why Annex B is maintained continuously rather than assembled on demand. This paragraph states the standard Carnelian applies to its own records; it is not a production undertaking given to a Studio, and the obligations Carnelian owes a platform are owed to that platform (clause 18.5).

19.3 The internal records that support this page — the record of processing activities, the security measures (Annex 2 of the Data Processing Agreement), our internal retention and deletion schedule and our internal transfer assessment — are producible to the UAE Data Office, to a platform exercising an audit right within the window in clause 19.2, or to an enterprise buyer on request.

20. Deletion and retention across the chain

20.1 The honest position, stated first. Retention periods for ABS Twin's own systems are set by our internal retention and deletion schedule, which governs. The period for each class — conversation content, voice transcripts, Digital Twins, audit records, backups, studio applications, the waitlist and support tickets — is published in the retention table of the Privacy Policy, which states which periods are in force and which are still proposed; this page does not restate them.

20.2 Deletion does not complete instantly across a chain. When a Studio's data is deleted, residual copies persist in Sub-processors' own systems and backups for their own cycles. The known tails are:

20.3 What that means for any deletion period stated to a Studio or a Guest. A deletion period stated anywhere in relation to ABS Twin means deletion within that period from Carnelian's own systems, with residual copies persisting in Sub-processors' systems and backups until purged on those Sub-processors' own cycles as set out in clause 20.2, and subject to any legally required retention or any trust-and-safety hold applied by a party acting as an independent controller. A bare "deleted within 30 days" would not describe what happens across this chain.

20.4 A cross-system note. The operational database is shared with tooling beyond the Console and is the restore target for backups. A deletion therefore has effects beyond one surface, and identity records use tombstones rather than row deletion so that historical bookings do not lose their subject. The Data Processing Agreement and our internal retention and deletion schedule describe how a deletion request is executed in practice.

21. Questions, and how to exercise rights

21.1 If you are a Guest — an individual who booked with, messaged or called a studio that uses ABS Twin — the studio is the controller of your data. Contact the studio first. Carnelian's practice, if you contact Carnelian instead, is to forward the request to the studio, to assist the studio in responding, and to tell you that it has done so. That is a description of Carnelian's practice, not an undertaking given to you (clause 22.5); the obligations Carnelian owes in respect of a data-subject request are the obligations in the Data Processing Agreement, and they are owed to the Studio as Controller.

21.1.1 Complaints. A Guest may complain to the studio, and may complain directly to the UAE Data Office — the supervisory authority for the UAE data-protection law — and to any other supervisory authority with jurisdiction over that Guest's data. The route, and the other rights a Guest has, are set out in the complaints section of the Privacy Policy. The Data Office's complaint route and contact details are the ones that Office publishes; the complaints section of the Privacy Policy carries them and governs, and any further supervisory authority is named there.

21.2 If you are a Studio, contact Carnelian at the data-protection address below for anything on this page, including an objection under clause 17.

21.3 Contacts.

Which address, and why. Every address in the table below delivers. Inbound routing on the contact. subdomain was verified by test on 21 August 2026: info@, privacy@, dpo@, legal@ and security@contact.abstwin.com each received the test message, as did support@carnelian.tech. (An earlier check on the same day appeared to show that only support@carnelian.tech delivered; that check was made too early and the re-check corrected it. No address is published here that no monitored mailbox can honour.) support@carnelian.tech — the mailbox of Carnelian Technologies L.L.C-FZ, the company behind ABS Twin — remains valid for every purpose in the table and is the alternative route if an ABS Twin address is for any reason unavailable. The bare apex domain carries no mailbox: no @abstwin.com address is printed as a contact route on this page — the routed domain is the contact. subdomain, and an ABS Twin address is written in the form name@contact.abstwin.com exactly as printed below. Where a row below gives an attention line, using it speeds the routing and nothing turns on it: a notification under clause 16, an objection under clause 17, a security report and a data-protection enquiry are each received, recorded and acted on whether or not the line is used, and none may be refused, deferred or treated as out of time because it was not marked.

21.3.1 Who publishes this page — the identity block. This page is published by the company identified below. The full identity notice, including the licensed activities, the authorised representative, the tax registration and the licence-verification route, is the Legal Notice / Imprint, which is the master record for every field in this block. Where this block and that notice differ, that notice governs, and the two are amended in the same revision.

21.3.2 Why this block is on this page and not only in the imprint. A sub-processor list is read by people who arrive at it directly — a compliance reviewer following a link from a Studio's own privacy notice, a platform reviewer, an enterprise buyer — and it is a public document in its own right. The identification requirements that apply to a business trading by modern technological means in the United Arab Emirates, and to a supplier in electronic commerce, apply to each public page rather than to the site as a whole, and the platforms that verify Carnelian compare the strings published on a page against the licence document. A page that names eighteen other companies and not its own publisher is the wrong way round. The values are held once, in the Legal Notice / Imprint, and reproduced here; they are never entered independently.

21.4 Data protection officer. Carnelian's Data Protection Officer is Syed Sharique Ali, Manager of Carnelian Technologies L.L.C-FZ, appointed with effect from 21 August 2026. He is reached directly at dpo@contact.abstwin.com, and at privacy@contact.abstwin.com marked "Attn: Data Protection Officer" — the data-protection address in clause 21.3. Delivery on both was verified by test on 21 August 2026. A data subject may communicate with the officer directly and Carnelian will not filter or refuse that contact, which is a right of access to the officer and not a promise that Carnelian will itself decide or fulfil a data subject's rights request (clause 16.4.1 of the Data Processing Agreement); the direct box exists precisely so that the right of access does not depend on a marked general mailbox. The Privacy Policy carries the same two addresses. The officer's contact details will be notified to the UAE Data Office through that Office's notification channel. The appointment is made, not conceded: whether an appointment is required on the processing this page describes — an artificial-intelligence assistant handling conversation and voice content, a maintained Digital Twin, and health-adjacent free text (clause 3.5) — is assessed internally against the UAE data-protection law's appointment duty, which is engaged where processing involves high risk arising from new technologies, systematic and comprehensive assessment including profiling and automated processing, or a large volume of sensitive data. An officer is appointed whatever that assessment concludes, and this clause does not state that the duty is engaged.

21.5 Identity verification note. Some Guest records originate on Instagram and, because that platform does not provide a user's telephone number, have no phone number on file. Those records cannot be verified by telephone. The verification method for a request on such a record is specified in the Data Processing Agreement; a Studio must follow it before disclosing anything.

22. Savings clause and limits

22.1 Nothing on this page excludes or limits any liability, right or obligation that cannot lawfully be excluded or limited. Where any statement on this page would otherwise have that effect, it applies only to the maximum extent permitted by applicable law, and is to be read down to the minimum extent necessary to make it lawful and enforceable rather than treated as void.

22.2 Nothing on this page excludes or limits liability for fraud or fraudulent misrepresentation, for death or personal injury caused by negligence, or for any pre-contractual disclosure duty that applicable law does not permit to be excluded.

22.3 This page is disclosure. It is not an entire-agreement statement, a warranty of any Sub-processor's performance, or a representation about any Sub-processor's terms beyond what that Sub-processor itself publishes. Facts stated about a Sub-processor are stated as at the version date of this page and are subject to change by that Sub-processor without notice to Carnelian.

22.4 This page does not discharge a Studio's own obligations. A Studio remains the Controller of Guest Data and remains responsible for its own compliance. Reading this page is not the Studio's own transfer risk assessment, does not discharge any obligation the Studio owes as Controller — including its own notice, lawful-basis, records, security and transfer-assessment obligations — and does not make a Studio compliant with any law applicable to it. Carnelian publishes this page so that a Studio has the facts it needs to carry out its own assessment; the assessment remains the Studio's to make, and a Studio should take its own advice on it. This clause states a division of responsibility, not an exclusion of Carnelian's own obligations as Processor, which are in the Data Processing Agreement.

22.5 No third-party rights. Subject to clauses 22.1 and 22.2, and to any right that applicable law confers on a person and that cannot be excluded by agreement:

(a) nothing on this page confers, or is intended to confer, any right, benefit or remedy on any person other than a Studio, and a Studio may rely on it only through, and to the extent provided by, the Master Subscription Agreement and the Data Processing Agreement;

(b) this page is not a stipulation, undertaking or promise for the benefit of a Guest or of any other third party, and is not intended to be enforceable by a Guest, by an Authorised User, by a Sub-processor, by a Platform Provider or by any other person. A Guest's rights in respect of Guest Data are owed by the Studio as Controller and are exercised through the Studio (clauses 3.1 and 21.1), supported by whatever rights the applicable data-protection law confers on that Guest directly; and

(c) the statements on this page that describe what Carnelian does or does not do — including the no-sale and no-training statements in clause 14, the push-payload rule in clause 7.12, the alerting rule in clause 7.14A, the analytics boundary in clause 7.15, the operations-runner configuration statement in clause 11.3 and the data-subject-request practice described in clause 21.1 — are descriptions of Carnelian's practice as at the version date, given to Studios as disclosure, and are not undertakings given to any Guest or other third party.

22.6 Express benefit for the persons who act for Carnelian. Clauses 22.1 to 22.5, clause 18 and clause 10 are given for the benefit of, and may be relied on by, Carnelian, its affiliates, and its and their officers, directors, employees, contractors and agents, to the fullest extent permitted by applicable law. Nothing in clause 22.5 prevents any such person from relying on them. Carnelian may vary or waive this page without the consent of any such person.

22.6.1 Sub-processors take no benefit from this clause, and none is intended. Clause 22.6 does not extend to a Sub-processor. Nothing on this page limits, reduces or excludes any liability of a Sub-processor to any person, and this page confers no immunity and no defence on any Sub-processor. A person's rights against a Sub-processor are that person's own, against that party, on whatever basis the law gives; clause 18 limits what Carnelian owes a Studio for a Sub-processor's acts, and it is not a cap on what the Sub-processor itself owes anybody.

22.7 Read down first, sever only if reading down is impossible. If any provision of this page is held invalid or unenforceable, it is first to be modified and read down to the minimum extent necessary to make it valid and enforceable while preserving its commercial purpose; only if it cannot be so modified is it severed, and the remainder of this page is then unaffected. If any limitation in clause 18 is held unenforceable, the remaining limitations continue to apply, and the limitation held unenforceable is deemed replaced by the highest limitation of liability that is lawful and enforceable in the circumstances.

23. Governing law, forum and data-protection regime

23.1 Governing law. This page and any dispute or claim arising out of or in connection with it, including any non-contractual dispute or claim, are governed by the federal law of the United Arab Emirates and the laws of the Emirate of Dubai as applicable in it.

23.2 Forum. The courts of Dubai have non-exclusive jurisdiction. This clause is without prejudice to any mandatory right of recourse, forum, or consumer or regulatory complaint route that applicable law confers and that cannot be varied by agreement.

23.2.1 Clauses 23.1 and 23.2 are subordinate to the agreement between Carnelian and a Studio. Where a dispute or claim concerning this page — including a claim founded on a statement made on it, whether framed in contract, in misrepresentation, in tort or otherwise — arises under or in connection with the Master Subscription Agreement or the Data Processing Agreement, the governing law and the forum of that agreement apply to it, and clauses 23.1 and 23.2 do not. This page is disclosure published in support of those agreements (clauses 1.2 and 1.5); it is not a second contract, and it is not intended to give a Studio a second law or a second forum in which to bring a claim that belongs to the agreement it has signed. Clauses 23.1 and 23.2 therefore govern only a dispute with a person who is not a party to either agreement.

23.2.2 Nothing in clause 23.2.1 deprives any person of a right that cannot be varied by agreement, including the mandatory routes preserved by clause 23.2 and the savings in clauses 22.1 and 22.2, and nothing in it confers on any person a right this page does not otherwise give (clause 22.5). Where a Studio has not yet entered into the Master Subscription Agreement or the Data Processing Agreement — a prospective Studio reading this page before signature — clause 23.1 and clause 23.2 apply to it until it does.

23.3 Data protection is a separate question from forum. The applicable data-protection regime for Personal Data processed in connection with ABS Twin is the UAE Personal Data Protection Law, together with any other data-protection law that applies by reason of a Studio's establishment, the location of processing or the residence of the data subjects. Choosing a forum does not choose a data-protection regime, and no forum clause anywhere in the ABS Twin document set displaces the applicable data-protection law.

23.4 The studio contract stack differs, and here is how. The Master Subscription Agreement and its addenda carry their own governing-law and forum clause, which is not the same as this one. They are governed by the law of the Dubai International Financial Centre, expressly extended to non-contractual claims, and the DIFC Courts have exclusive jurisdiction over disputes under them by an express opt-in worded to satisfy the current Dubai jurisdiction law, with a Small Claims Tribunal election available in the Order Form. This public page stays on the onshore track: clauses 23.1 and 23.2 govern it, and clause 23.2.2 preserves every right that cannot be varied by agreement, including for a prospective Studio reading this page before signature.

23.5 No arbitration and no collective-action waiver. This page contains neither, and neither will be introduced into it.

24. Changes to this page, and version discipline

24.1 This page is never silently edited. Every change produces a new version number and effective date, and every superseded version stays accessible at a stable URL with its own effective date.

24.2 Annex A is the record. A Sub-processor addition, removal, replacement or material change is recorded in Annex A with the date it took effect. The dated change log — not the current tables — is the evidence that notice was given. A Studio's claim that it was never told is answerable only from Annex A.

24.3 Review cycle. Carnelian re-reads each Tier 1 Sub-processor's terms, data-protection agreement and published sub-processor list at least annually, and on any change notified by that Sub-processor, and republishes this page. Each review also re-checks every outbound link in Table 6.2.

24.4 Version and integrity. The version number, effective date and a content hash of the published text are recorded with each version, so that the text in force on a given date can be proved.

24.5 Relationship to changes in the contract stack. Because the Data Processing Agreement authorises the Sub-processors published at this URL and defines "Sub-processor" by reference to this page (clause 1.2), a change to this page changes the list of Sub-processors that Agreement authorises — and it does so through the notice and objection mechanism in clauses 16 and 17, not otherwise. Beyond that, a change to this page does not vary the Master Subscription Agreement, the Data Processing Agreement or any other agreement and does not change any other term of them. Where a Sub-processor change is materially adverse to a Studio, the Studio's remedies are those in clause 17 and in the Data Processing Agreement.

26. Arabic version

26.1 An Arabic version of this page is published alongside the English version, at the same URL and reached by a language toggle — there is no separate Arabic address. Publication in English only is not permitted. Either version is available on request.

26.2 In the event of a conflict between the Arabic and English versions of this page, the Arabic version prevails, to the fullest extent permitted by applicable law.

Annex A — Sub-processor change register (Added on / Removed on)

Annex A is maintained as an append-only record — never rewritten and never re-sorted. On first publication every current entry is seeded with the publication date; thereafter one row per event, newest first. The notification method and date stay in the row, because they are what proves that the obligation in clause 16 was performed.

Annex B — Written-agreement and data-protection status register

Annex B is the evidence behind clause 13 and behind the equal-protection statement in the Privacy Policy. It is also what a messaging platform exercising its audit right (clause 19.2) and an app store requesting evidence will ask for, which is why clause 19.2.1 sets its maintenance standard. It is maintained continuously, with each executed document filed and dated. "Not yet evidenced" means that no executed instrument has been filed and dated in this register for that party; clause 13.3 states the consequence — the equal-protection assurance in clause 13.2 is not available for that party until it is.

Document: Public Sub-processor List · Version: 0.9 · Effective date: on publication Publisher: Carnelian Technologies L.L.C-FZ · Legal form: Limited Liability Company · Licensed under the Meydan Free Zone regulations · Trade licence no. 2415615.01 (expires 25/01/2027) Registered address: Meydan Grandstand, 6th floor, Meydan Road, Nad Al Sheba, Dubai, U.A.E. Telephone: +971 56 498 4007 (staffed; no hours band published) · Website: https://abstwin.com · https://carnelian.tech · Full identity notice: Legal Notice / Imprint (see clause 21.3.1) Contact: info@contact.abstwin.com — general enquiries (clause 21.3) · Legal notices: legal@contact.abstwin.com, "Attn: Legal" · Security reports: security@contact.abstwin.com, "Attn: Security" · Data protection, sub-processor questions and clause 17 objections: privacy@contact.abstwin.com, "Attn: Data Protection Officer" (legal@contact.abstwin.com is equally valid) · Data Protection Officer: Syed Sharique Ali, Manager, appointed 21 August 2026 — direct: dpo@contact.abstwin.com · Company contact and alternative route: support@carnelian.tech. Delivery on all six addresses was verified by test on 21 August 2026; no address on the bare apex domain abstwin.com is a contact route Next review: within twelve months of the effective date, or on issuance of the UAE PDPL Executive Regulations, or on any notified change by a Tier 1 Sub-processor, whichever is earliest. Annual re-read of every Tier 1 vendor's terms is mandatory (clause 24.3).