Staff App Privacy Notice

Plain-language summary

The ABS Twin Staff App is a work tool. Your employer — the studio — subscribes to ABS Twin and gives you an account so you can see your own appointments for the day, start and complete them, record a rating, request leave, and keep your profile up to date.

Five things worth knowing before you read the detail:

1. Your account was created by your studio, not by you. The studio decides who gets an account, what you can see, and when your access ends. If you want your account removed, three routes operate today: a Delete my account control inside the app, at the bottom of the Me screen; a request from outside the app, made by email — the public page at https://abstwin.com/legal/delete-account tells you how; and asking your studio. Clause 12 describes all three, in the present tense, because they exist.
2. Deleting your account is not the same as deleting the studio's records. Your login and your personal profile go. The studio's bookings, its client records, and its employment records about you stay — they belong to the studio, not to us and not to you. We explain the split honestly in clause 12, because promising more than we can do would itself be wrong.
3. We deliberately show you very little about the client. The app is only ever given a client's first name. Not the full name, not the phone number, not the payment history. That is built into the server, not left to the screen design.
4. We do not track you, and we do not sell anything about you. There are no advertising tools, no attribution tools and no data brokers in this app. Nothing you do here is linked to anything about you anywhere else.
5. We do not use your data, or your studio's clients' data, to train AI models. That is our own conduct and it is unqualified. What our providers do is a separate question, and clause 9 answers it provider by provider — including the places where their published terms say one thing and we have not yet finished checking the contract behind them. We would rather show you the seam than paint over it.

One more thing, because it is not a privacy point and you should not have to find it in clause 19. The app is licensed to you, not sold, and the licence — which is where the limits on what you can claim from us live — is something you are asked to accept, not something you are taken to have agreed by installing anything. You can read it in full before you accept it, and the licence itself says — honestly — what the record of your acceptance is today (its clause 4).

If you want the full picture of everything ABS Twin does with personal data — including what happens to clients' WhatsApp conversations and phone calls — read the Privacy Policy at https://abstwin.com/legal/privacy. This notice covers the Staff App only.

An Arabic version of this notice is prepared for publication alongside the English version, on the rule in clause 20.3.

1. Who we are, and what this notice covers

1.1 Who we are. The Staff App is provided by Carnelian Technologies L.L.C-FZ ("Carnelian", "we", "us"), a Limited Liability Company licensed in Dubai, United Arab Emirates by the Meydan Free Zone. Our full identity details — legal name, licence, registered address and contact routes — are published in the Legal Notice at https://abstwin.com/legal/imprint. ABS Twin is the name of our product; Carnelian is the company.

1.1.1 What ABS Twin is. ABS Twin is a booking and customer-communications system that a Studio uses to serve its own customers — it takes appointment requests, checks availability, confirms and changes bookings, answers questions about the Studio's own services, hours and prices, and keeps the Studio's records of those interactions. It is not a general-purpose AI assistant, it is not sold to consumers, and it is not offered as a tool for anyone to converse with about anything. Every conversation it holds is held in a Studio's name, about that Studio's own business, with that Studio's own customers. The Staff App is the part of that system a member of a Studio's staff uses to run their own working day.

1.1.2 Our licence. Carnelian Technologies L.L.C-FZ holds trade licence 2415615.01, issued by the Meydan Free Zone, Dubai, United Arab Emirates, and valid until 25 January 2027. Our registered address is Meydan Grandstand, 6th floor, Meydan Road, Nad Al Sheba, Dubai, U.A.E. These are the same details published in the Legal Notice.

1.2 What this notice covers, and what it ranks above — which is narrower than it sounds. This notice describes how we handle personal data in the Staff App: the web application at staff.abstwin.com — and its staging deployment at staff-staging.abstwin.com, which is the same application and is covered by the same rules — and the native iOS and Android builds of that application. Because "this notice governs" is a sentence that can be read far wider than it was meant, we split it by subject matter:

1. For descriptions of processing — the categories of data, where they come from, the purposes, the lawful bases, retention, and how you exercise your rights — where this notice and the Privacy Policy differ on a point about the Staff App, this notice governs for the Staff App.
2. For the way the app is to be used — the duties summarised at clause 18 — this notice, the Acceptable Use Policy and the licence at clause 19 are cumulative, and where they differ the most restrictive requirement applies to you. We do not want the published summary to license conduct the contract forbids.
3. For liability, limitations, exclusions, remedies, the licence grant, termination and forum, the licence governs as between you and us, and the Master Subscription Agreement governs as between your Studio and us. Nothing in this notice varies either of them, and nothing in it increases the liability they limit (clause 20.6).
4. On every other point, and for every definition not given below, the Privacy Policy and the Master Subscription Agreement govern.

1.3 What this notice does not cover. It does not cover the Console at app.abstwin.com (owner, reception, manager and Carnelian administration surfaces), the marketing website abstwin.com, or what the ABS Twin Assistant does in conversations with Guests over WhatsApp, the telephone, or Instagram. The Instagram channel is built, gated behind a feature flag, and is NOT enabled in production. That is stated flatly rather than left open: it must not be described as live, available or operating in this notice, in any store listing, in any tier sheet, deck or sales conversation, until the flag is on for the Studio concerned (the Restricted / Health Data Addendum states the same bar across our documents). An internal tier sheet that markets it as live is an error to be corrected, not a competing view. Those are covered by the Privacy Policy and, for the Assistant, by the AI & Recording Disclosure.

1.4 Capitalised terms. Capitalised terms not defined in this notice have the meaning given to them in the Master Subscription Agreement and the Privacy Policy. Because you have seen neither of those documents, the ones this notice actually uses are defined here:

• Studio — the business that subscribes to ABS Twin and employs or engages you.
• Authorised User — an individual the Studio permits to use the Console or the Staff App. That is you.
• Guest — an individual who books with, or contacts, a Studio.
• Guest Data — personal data about a Guest that we process on a Studio's behalf: the appointment record, the contact details the Studio holds, and the Guest's conversations with the Assistant. In the Staff App you are shown a very small part of it (clause 2.3).
• Restricted Data — has the meaning given in clause 2.2 of the Restricted / Health Data Addendum, which governs. Reproduced here so you can read it without opening another document, it is: clinical, diagnostic or treatment information of any kind; biometric identifiers; payment-card numbers; government identification numbers; and special-category data not required for appointment scheduling — the limb this notice previously omitted, which covers things such as health status, religious belief, ethnic origin, trade-union membership and sexual life. The whole category is subject to that addendum's closing carve-out: except to the extent that the particular item of data is objectively necessary to book, schedule or deliver the specific service the Guest has requested, and is limited to what that purpose objectively requires. The Studio's own entity identifiers — its trade licence number and the like — are not Restricted Data. Clause 3.1.3 and clause 18 both use the term and they use it in this sense.

1.5 Current status of the app — stated plainly, including the parts that are not built. This clause exists so that a reader can tell, from the notice itself, which of the things it describes are operating today. Five items:

1. The Staff App is live as a web application at staff.abstwin.com.
2. The native iOS and Android builds are built and running on real devices in pre-release testing — the iOS build through Apple's own pre-release channel, TestFlight — and have not yet been submitted for public release on either store: no public store listing exists, and this item is updated when one does.
3. Push notifications are live — for the web application and in the native builds. Your device registration and the notifications described in clause 7 are processed today exactly as clause 7 says, on the web application and in the native iOS and Android builds alike: the Apple and Google push credentials are in place, and delivery to real devices has been verified on both platforms. An earlier version of this item said the native credentials were not yet in place; that was true when it was written, and it is corrected in this version because it stopped being true.
4. The self-service deletion routes in clause 12 exist and operate. The in-app control — Delete my account, at the bottom of the app's Me screen — performs the deletion clause 12.2 describes and signs you out immediately. The public page at https://abstwin.com/legal/delete-account is published and works as an email route: it tells you what to send and to whom, and carries no web form, which it also says itself. And asking your Studio works as it always has (clause 2.1). Clause 12 is no longer written in the conditional.
5. Because the web application is already running, four things are done for that live surface now — ahead of, and independently of, any store submission: (i) this notice is published, marked as applying to the web application until the native builds ship; (ii) its address is put in the Studio invitation template and on the sign-in screen (clause 1.6); (iii) the licence at clause 19 is published and accepted at sign-in, on its own screen — with clause 19.1, and the licence's own clause 4, stating honestly what the record of that acceptance is today; and (iv) the duties at clause 18 are carried by the licence presented at that acceptance (its clause 6), the full text one tap away before anything is agreed. A gate that only fires at store submission protects nobody who is using the app this morning.

An earlier version of this clause stated item 4's predecessor as flatly as the rest: that neither self-service route existed, and that this notice would not be published, nor the app submitted to any store, until both existed and behaved as clause 12 describes — because an inaccurate deletion claim is itself the wrong, both under the law and under the app-store rules, and it is the single claim a store reviewer tests by clicking. That gate has now been satisfied and released: the routes exist, they behave as clause 12 describes, and this notice describes them in the present tense. What remains outstanding is item 2 — public store availability — and this clause changes again when it changes.

This clause is updated when any of the five items changes, and the version and date at the foot of this notice change with it.

1.6 Where you can read this notice, and when — because "before" means before. The law requires us to tell you these things before the processing starts, not at your first sign-in. Your name, work email address, role and branch reach us at the moment your Studio creates your invitation, and our authentication provider processes them again when you set your credentials — both of which happen before any screen inside the app can be shown to you. A first-run screen therefore cannot carry this obligation on its own. So this notice is made available at three points, and all three are conditions of publishing it:

1. in the invitation email your Studio sends you — a link, before you do anything at all. Your Studio owes us that under clause 2.1.1;
2. on the sign-in screen itself — a link, visible before you enter a credential; and
3. inside the app — on the first-run screen inside the app, and from a permanently visible place thereafter.

If you have reached this notice only after signing in because one of those links was missing, that is a defect in how we have published it rather than a detail: tell us at the address in clause 15 and we will put the link where it should have been.

2. The three things that shape everything else

2.1 Your account belongs to the Studio, not to you and not to us. Access to the Staff App is invitation-only. There is no public sign-up. Your Studio's owner or manager creates the invitation in the Console, and the Studio's owner or manager can suspend, reactivate or remove your access at any time. When your access is removed, the app is built to stop serving you: every request re-reads your access status from our records and refuses a user whose access has been suspended or removed (clause 10.1), rather than waiting for your next sign-in.

2.1.1 The Studio's duty, and why it matters to you. Under its agreement with us (the Master Subscription Agreement), the Studio is responsible for deciding who receives an account, for keeping that list accurate, for removing access promptly when a person leaves or changes role, for not issuing an account to anyone under 18 (clause 16.1), and for including a link to this notice in the invitation it sends you, so that you can read it before you set your credentials and before anything is processed about you (clause 1.6). We provide the controls and enforce them on every request (clause 10.1); we do not decide who should hold an account. If you believe someone who should no longer have access still does, tell your Studio, and tell us at the address in clause 15.

2.2 We are not the same party for every kind of data in this app. Two different roles apply, and the difference decides who you ask about what:

2.2.1 The allocation is under review, and we tell you what applies while it is. Whether we are the sole Controller of your account data or a joint Controller with your Studio is being settled. We say so rather than present the table above as settled, because the row, the routing in clause 13.2 and the deletion promise in clause 12 all turn on it.

1. If the allocation is joint, then (i) the first row of the table becomes "Carnelian and the Studio, jointly"; (ii) a request about your login may be made to either of us, and we and the Studio must agree between us who answers, with the answer given to you either way; and (iii) the deletion in clause 12 becomes something we perform with the Studio, and clause 12.2 is re-drafted to say what each of us deletes.
2. Until an allocation is written down and signed, treat us as answerable together. Under the UAE Personal Data Protection Law, where more than one party is involved in processing without a written allocation between them, they can be held responsible together. That is the position today: no written allocation for Authorised User account data exists yet with any Studio. It is not a comfortable thing to publish, and it is a better answer than a table that implies a division nobody has agreed.

2.3 We show you the minimum the job needs. The Staff App is served only the fields a therapist actually needs. The server builds each response field by field, so a field the Staff App is not given is not included in what is sent — the control is in what the server assembles, not in what the screen chooses to display. On that build, the app is given a Guest's first name and not a full name, a telephone number, payment history, or the Guest's conversation with the Assistant.

3. What the Staff App collects, and where it comes from

3.1 Data you give us, or your Studio gives us about you

3.1.1 Your employment record, enumerated. Your Studio maintains a staff record about you inside ABS Twin. We hold it as the Studio's Processor — we did not ask for it, we do not decide what goes in it, and the Studio decides what it is used for. You are entitled to know what it can contain, so we list the categories rather than describe them:

3.1.2 What the Staff App is actually served, as distinct from what the Studio holds. The two are not the same thing, and the difference is the whole point of clause 2.3. The server builds the app's response field by field, so the categories in clause 3.1.1 that the app is not given never enter the app at all. As at the date of this notice the app's own account response is understood to carry: your first name; your role, app-access status and employment status; your branch and studio name and the branch time zone; your hire date; your remaining leave allowance; whether you may switch branch; your visa expiry date; and your health-authority certification expiry date together with the derived flag saying whether that certification is current. It is understood not to carry your salary, commission, bank details or payroll-system number, and not to carry your nationality.

The word "understood" in that paragraph is doing real work and we are not going to hide it: the exact list is being enumerated endpoint by endpoint before this notice is published, and until it is, this clause describes our understanding of the build rather than a verified list. The treatment of the certification date is under review for a second reason as well — health information in the United Arab Emirates is governed by its own legislation rather than by the general data-protection law, and whether a practitioner's own licensure record falls inside that legislation is a question we have asked rather than answered.

3.1.3 Free text in this app, and the hard line on it. When you complete one of your own appointments you record a satisfaction rating alone — the app deliberately collects no free-text note with it. An earlier design had one; the decision was taken, and built, to ship stars only, because a free-text box next to a Guest's appointment is exactly where clinical detail creeps in, and the safest field is the one that does not exist. The one free-text field the Staff App does have is the reason you can attach to a leave request (clause 3.1's leave-requests row). That field is for the leave request and nothing else, and the hard line on it is this: never use it to record Restricted Data about a Guest or a colleague as clause 1.4 defines it — no condition, no allergy, no pregnancy, no medication, no diagnosis, no treatment detail, no health observation about another person of any kind. About yourself, write no more than the leave itself needs — "sick leave" is enough; a diagnosis is not required, not asked for, and better left unwritten. This is the same prohibition that binds your Studio under its own agreement with us (the Acceptable Use Policy and the Restricted / Health Data Addendum) and that clause 18 makes your obligation too. Clause 17.3 explains what happens if clinical content is found in that field anyway.

3.1.4 Who owns what you write in the app, and what we take. The rating you record against your own appointment, and the reason you can attach to a leave request, are the only content you create in the Staff App, and it is worth saying whose they are, because clause 17.3 gives us a right to quarantine or delete one and that right should not turn on an argument about ownership.

1. They are the Studio's operational records. You make them in the course of your Studio's business, which is why clause 12.3 says they survive the deletion of your login and why a request to change or erase one goes to your Studio under clause 13.2.
2. We claim no ownership of them. We take only a non-exclusive, royalty-free, worldwide licence, limited to the purposes in clause 4.1, to host, store, transmit, display, back up and — where you or your Studio asks for support — read that content. It is worldwide because the platform runs on international cloud services and clause 8.1 says so; it is sub-licensable only to the providers named in clause 6.2, and only so that they can perform the functions described there; and it runs for as long as your Studio subscribes, plus the short tail that our encrypted backups take to age out, and, for anything retained on a ground in clause 11.3, for as long as that ground applies and for that ground only. That last limb exists so that we are not holding a note under a legal hold with no permission to hold it.
3. That licence carries no training right. It does not permit us, or any provider, to use what you write to train, fine-tune or improve any AI model. Clause 9 says so and nothing in this clause qualifies it.
4. It is also what lets us act under clause 17.3 — restricting, quarantining or deleting clinical content found in that field — without needing anyone's permission first, and without that being a claim over your words.

3.2 Data the app or our servers generate when you use it

3.2.1 What is stored on your own device. The Staff App is a web application, and the native builds wrap that same web application. Like any web application it keeps a small amount of information on the device itself, and you are entitled to know what:

The marker rows above — the session, the language preference, the push registration, the first-run record, and the two choice markers — have been checked against the build for what each holds and whether it survives sign-out. What remains stated as intention rather than assertion is the caching row: exactly which cached screens sign-out clears in each shell is still being confirmed, and that row keeps the word "intended" until it is.

None of this is used for advertising, for cross-site or cross-app tracking, for building a profile of you, or for measuring you against anyone else. There is no advertising cookie, no tracking pixel, no attribution identifier and no third-party analytics cookie in the Staff App. To clear it: sign out, which ends the session and clears the cached screens; or clear the app's storage in your device settings, or the site data for staff.abstwin.com in your browser. Our general treatment of cookies and similar device storage across all of our surfaces — including the marketing website, which does carry analytics that this app does not — is set out in the Cookie & Tracking Notice at https://abstwin.com/legal/cookies.

3.2.2 Pre-release builds. Where a build of the native app is distributed to testers before release — for example through Apple's TestFlight — the store's own pre-release channel shares crash data and usage data about that build with us as its developer, by default and under the store's terms rather than ours. That is a collection we would otherwise not make, so we disclose it rather than let it sit outside this notice. It applies to pre-release builds only, not to a build installed from the public store listing, and the terms of that pre-release channel are the store's rather than ours. Whether pre-release distribution is limited to internal testers or offered to pilot Studios is an open decision; this clause is narrowed to whichever it turns out to be before any tester installs a build.

3.3 Data about a Guest that the app shows you. For each of your own appointments, the app shows the Guest's first name, the service, the time, the branch, and the status of the appointment. That is data belonging to your Studio; we hold it as the Studio's Processor.

3.4 What the Staff App does not collect. We state these as commitments, not as an absence of features we happen not to have built:

3.5 Guest conversation content is not shown in the Staff App today. The Assistant's conversations with Guests — WhatsApp messages, voice-call transcripts, and Instagram messages if and when that channel is enabled (it is not, today — clause 1.3) — are visible to a Studio's owner in the Console, not in the Staff App. If that ever changes, this clause is rewritten and both store declarations are updated before the release that changes it ships.

4. What we use it for, and our lawful basis

4.1 Purposes.

4.1.1 What we use your work email address for, and what we do not. We use it only to run your account and to give you the notices this document promises: your Studio's invitation; verification of a request under clause 12.6; the acknowledgement, reference number and completion notice for a request under clause 13.2A; a copy of any disclosure or licence wording you accept, once the acceptance record the licence describes at its clause 4 is in operation; and notice of a change to this notice under clause 20.1. We do not send you marketing, product news, promotions, surveys or research invitations, and we do not pass your address to anyone who does. If that ever changes we will say so in this notice first, ask you before the first message rather than after it, put a working one-click stop in every message — and only where the law then permits it at all, because UAE consumer law frames non-use of a consumer's data for promotion and marketing as a right rather than as something consent can unlock, and if that framing reaches you then no permission you give us would make the route available. Your right to object to direct marketing does not depend on our having asked and is not something you have to give a reason for.

4.2 Lawful bases under the UAE Personal Data Protection Law. The law gives a closed list of bases and — unlike the regimes this kind of document is often modelled on — it has no "legitimate interests" basis at all. So we say which basis carries which data, rather than listing four and leaving you to guess.

Two things this clause deliberately does not say. It does not rely on your Studio's subscription agreement as a contract basis, because you are not a party to it — the basis requires a contract with you, and steps taken at your request, not at your employer's. And it does not treat your employer's request as a substitute for your own. Where the Studio's own employment-law obligations are the reason a record exists, that is the Studio's basis to state as your employer, not ours to borrow.

For the Studio's records shown to you in the app, the lawful basis is the Studio's to determine as Controller; we process on its documented instructions.

4.2.1 The two sensitive fields, specifically. Clause 3.1.2 records that the app is understood to be served two fields that are sensitive on any reading — your visa expiry date and your health-authority certification expiry date with the flag derived from it. That understanding is being verified field by field before publication, and this clause is written on the footing that it is right. A general statement of lawful bases does not answer for those fields, so we answer separately.

1. Both are fields in your Studio's staff record. The Studio is their Controller. The lawful basis for holding them and for using them is the Studio's to determine, and the Studio must be able to explain it to you as your employer — including the condition on which it holds a category of data the law treats as sensitive.
2. Our basis is the Studio's documented instruction, given under the Data Processing Agreement and, where the Restricted / Health Data Addendum applies to that Studio, under that addendum.
3. For the certification date we go one step further and decline to state a basis at all yet. Health information in the United Arab Emirates is carved out of the general data-protection law and governed by separate health legislation with its own rules, including rules about where such data may be held. Whether a practitioner's own licensure record is caught by that legislation is genuinely open, and the honest answer is that a general data-protection analysis is the one answer that is certainly incomplete. It is being settled, and what follows for a field held outside the country is being settled with it.
4. What we add on our own account is a limit, not a purpose. Those two dates are served to the app for exactly two reasons — your own profile screen shows them to you, and the certification date drives the assignment rule described in clause 4.5(2). They are not used for anything else, are not sent to any provider beyond those listed in clause 6.2, and never appear in a notification.
5. Where to take a question about them. Why your Studio holds them, and on what basis, is a question for your Studio under clause 13.2. Whether we are handling them as limb 4 says is a question for us.

4.3 We do not rely on your consent for the things the app must do to work. Asking for consent for something you cannot refuse and still do your job would be a fiction. Where consent genuinely applies — push notifications, and any optional feature — you are asked separately, you may refuse, and you may withdraw. Clause 14 explains how.

4.4 We do not use this app to monitor you — and here is what your employer can actually see. We build no productivity score, behavioural profile or performance ranking from your use of the app, we do not rank you against colleagues, and we supply nothing about you to anyone for that purpose. There is no such feature and no such analysis. The more useful question is what your employer can see, so:

1. Your Studio sees its own operational records that you create in the app — the appointments you started and completed, the ratings you recorded, and the leave you requested — with any reason you gave — and its decision (clause 3.1.4); your access status and your staff record, which it maintains (clause 3.1.1); and the accountability trail of writes, which records the actor, the action, the target, the result and the actor's IP address (clause 10.5). Separately, things you do can raise a notification to other people at your branch — a leave request notifies your branch's managers, and marking a service started or done notifies its reception desk (clause 7.2). Whether your Studio has any way to see and end your individual sessions is not established, and until it is we do not tell you that it does.
2. It cannot see, through us, anything about you from outside the app: your location, which is not collected at all (clause 3.4); your contacts, photos, camera or microphone; your device's own activity; how long a screen was open; or anything you do on your phone outside this app.
3. We build nothing about you from any of it. The accountability trail is not turned into a performance measure, a score, a profile or a ranking, and we do not offer your Studio a product that does. It exists so a change can be traced when someone asks what happened. What your employer decides on the basis of records it holds is its decision to explain to you as your employer; our part is not to build the instrument.

4.5 Decisions made about you by machine.

1. Carnelian makes no decision about you by solely automated means that produces a legal effect for you or similarly significantly affects you. We do not decide whether you keep your job, what you are paid, what you are assigned, or whether your access continues. Those are your Studio's decisions.
2. Two things in the app are decided by rule rather than by a person. Whether you may be assigned a service the Studio's catalogue flags as medical is derived from whether your health-authority certification is recorded as current — an out-of-date or missing certification blocks the assignment, by rule and not by judgement. And whether your login works is read from the access status your Studio sets, on every request. Neither is a decision we take: the first applies a date your Studio entered against a rule its own regulator imposes; the second applies your Studio's instruction. Both are visible to you, and both are corrected by correcting the underlying record.
3. Your Studio, as your employer, may use the records in clause 3.1 for its own purposes — rostering, performance, pay, renewals. What it decides, and how, is the Studio's to explain to you; it is not something we can answer for it.
4. You may ask for a human to look at any of this. For anything touching your account, ask us; for anything touching your employment, ask your Studio, and we will support the Studio in answering (clause 13.2).

5. Artificial intelligence, and what happens to data in the app

5.1 The Staff App itself does not send your data to an AI model. The screens described in clause 3 — your appointments, your leave, your profile — are served from our database. No AI model is called to render them.

5.2 AI is used elsewhere in ABS Twin. Within the Studio's own conversations with its own customers — WhatsApp, the telephone line, and Instagram if and when that channel is enabled (it is in testing and is not available in production today; it is planned, and it will be announced when it is available — clause 1.3) — AI models read and reply about bookings and about the Studio's own services, transcribe voice notes, summarise conversations for the Studio's records, and draft support replies for a human to approve. The Assistant works on one Studio's business, in that Studio's name, with that Studio's own customers. It is not a general-purpose assistant and it is not available to be used as one. That processing is not part of the Staff App and is not described here: it is set out in the Privacy Policy and the AI & Recording Disclosure, and the providers are named in the Sub-processor List. Those documents also carry the Assistant's AI self-identification rule, which is a standing rule of the product rather than a per-Studio option.

5.3 Where the two meet. The only AI-touched data that reaches the Staff App is the ordinary appointment record — an appointment the Assistant may have created during a conversation with a Guest. You see the appointment, not the conversation.

5.3.1 What that means for an appointment in front of you. The Assistant books, changes and cancels appointments on its own, without a person checking first — it is not making suggestions for you to approve. It works from what the Studio has configured and from what the Guest told it, and, like any system of its kind, it can be wrong: it can mishear a name on a call, take down the wrong service, misread a time, or record something the Guest said imprecisely. Do not treat what the app shows you as verified. Check the service, the time and anything that matters clinically or commercially with the Guest in front of you before you act on it, and correct it in the app or tell reception if it is wrong. Nothing the Assistant produces is a clinical, diagnostic or suitability judgement, and it must not be relied on as one (clause 17).

Two things sit alongside that, and stating them is not a way of shifting the work onto you. What the Assistant is: an assistive booking-and-administration tool, operated on the Studio's own configuration and the Studio's own data, in the Studio's name. It is not a guarantee of any booking outcome, and the Studio is responsible for what is confirmed in its name and for the accuracy of the configuration it maintains. Who owes the oversight: the duty of human oversight of the Assistant is your Studio's, under its agreement with us (the Master Subscription Agreement). Your part in it is the verification above — checking what is in front of you before you act on it — and nothing more than that.

5.4 If that ever changes, you will be asked first. If a future release of the Staff App sends anything you enter, or anything shown to you, to a third-party AI provider — for example to summarise a note or to suggest text — we will say so in this notice, name the provider in the Sub-processor List, disclose it in the app before the feature is used, and obtain your explicit permission for it. We will not repurpose data collected for one of the uses in clause 4.1 for a new purpose without a fresh basis and, where consent is the basis, fresh consent.

6. Who we share data with

6.1 We do not sell personal data. We have never sold personal data and we do not permit any of our providers to sell it. We do not share it for advertising, and we do not transfer it to data brokers.

6.1A The recipient you are most likely to care about is your own Studio. A clause headed "who we share data with" that lists nine technology companies and not your employer would be answering the easy half of the question. So, before the providers: your Studio, and named people in it, receive data about you — including data of which we are the Controller.

Everything else your Studio holds about you it holds as Controller in its own right, and this notice does not govern what it does with it (clause 4.5(3)).

6.2 The providers behind the Staff App — named, not merely categorised. The list is short enough to publish, so we publish it. Every provider below is named again, with its role, its location and the date it was added, in the public Sub-processor List at https://abstwin.com/legal/sub-processors, which is the authoritative and current list — with one deliberate exception, marked in the table: the app stores in their capacity as distributors of the native builds are not sub-processors and the Sub-processor List expressly says why it leaves them out. If this clause and the Sub-processor List ever differ, the Sub-processor List is the one that has been kept up to date.

6.3 Equal protection — in two tiers, because one of them is not in our gift. Apple's guideline on this asks for an affirmative statement that every third party receiving user data affords equal protection. Here is the honest version of it.

1. Where we contract directly with a provider — the authentication provider, hosting and edge, the database, the push provider, transactional and inbound email, the caching and scheduling layer, the webhook delivery service and any diagnostics provider — we require a written agreement giving that data protection equivalent to what this notice promises: a duty of confidentiality, security measures, restrictions on onward transfer, deletion or return at the end of the engagement, and a prohibition on using the data for the provider's own purposes.
2. Two participants in the chain are not parties we can contract with on those terms: the operating-system push transports and the app stores. They process under their own published terms, clause 6.2 says so on their rows, and no amount of drafting on our side changes it. Where any provider's terms are non-negotiable, we record the same commitments as our own, assess the gap, and keep that assessment on our internal cross-border transfer record — and we call that what it is, an assessed risk, rather than a term we obtained.
3. What this statement is worth depends on work that is not finished. The agreements in limb 1 are being collected and checked against the five elements above, one provider at a time, and the result is recorded per provider in the Sub-processor List. Until that is done for a provider, we do not represent that it is bound; we represent that we require it. The open item is stated plainly: executed data-processing agreements, checked against each of the five elements, are not yet on file for every provider in limb 1, and the contracting entity for the push provider is taken from that provider's published terms rather than from an executed agreement we have read to the end. Both are recorded provider by provider in the Sub-processor List as each is completed.

6.4 We also disclose personal data where the law requires it — to a court, a regulator or a law-enforcement authority acting under a lawful power — and where it is necessary to establish, exercise or defend a legal claim. We do not volunteer data to anyone, and where we are lawfully able to tell you or your Studio about a request, we will.

6.5 If our business changes hands. If Carnelian is acquired or reorganised, personal data may transfer as part of that transaction, subject to the same protections and to the applicable data-protection law. Your Studio is notified under the Master Subscription Agreement — and you are notified too, by the route in clause 20.1.1, for the data of which we are the Controller. Telling only your employer about a transfer of records we control, and not you, would be an odd way to run a notice that says clause 2.2's first row is ours.

7. Push notifications

7.1 What we send, and when. Two events reach your device, and we name them rather than describing notifications in general — a trigger that does not exist is as much a mis-description as one we failed to mention:

1. A Guest arrives for one of your appointments. That notification carries the Guest's first name and the service name.
2. Your leave request is decided. That one carries the dates only — no names and no notes.

No notification carries a Guest's full name or a telephone number. The code that builds a notification is written so that the payload is assembled from that short list of fields rather than from the underlying record, so the omission is a property of the builder and not of the sender's discretion.

7.2 How your device is addressed. Our push provider delivers to named "interests" — labels a device subscribes to — and ABS Twin uses three of them: one per member of staff, derived from your own staff identifier, and two per branch, one for that branch's managers and one for its reception desk.

The Staff App subscribes your device to your own staff interest only. The two branch-level interests address a group rather than an individual, and they are subscribed to by the Console — the manager and reception surfaces at app.abstwin.com, which clause 1.3 excludes from this notice — not by the app on your phone. So a notification sent to your staff interest reaches your device and no one else's; a notification sent to a branch interest reaches whoever is signed in to the manager or reception console for that branch, and does not reach the Staff App at all.

Something you do in the Staff App can raise a notification on a branch interest. Filing a leave request notifies your branch's managers, and marking a service started or done notifies your branch's reception desk. Those carry the minimum needed — for a leave request, your first name, the dates and the number of days; for a service, a Guest's first name and the service name. Which interests a device actually subscribes to, and the exact contents of every payload, are confirmed against the shipped builds before submission.

7.3 Who is in the chain. A notification passes from our servers to our push provider, and then through Apple's Push Notification service or Google's Firebase Cloud Messaging to your device. Those transports see the notification text and your device token. That is exactly why clause 7.1 keeps the payload as short as it is — and why we are actively considering removing personal data from it altogether, so that a notification says only that something has happened and the app fetches the detail after it has authenticated you.

7.4 Notifications are optional and you control them. You are asked before we register your device, and you can turn notifications off at any time in your device's own settings — the operating system's control, which nothing in the app overrides; the app shows you the state of that permission but deliberately carries no switch of its own. We do not withhold any feature, content or benefit because you declined notifications.

7.5 Where push is live. Push is live for the web application and for the native iOS and Android builds: if you have turned notifications on, your device registration and the notifications above are processed today exactly as this clause describes, whichever build you use. The Apple and Google push credentials are in place, and delivery to real devices has been verified on both platforms. An earlier version of this clause said the native builds' credentials were not in place; it was true when written, and this clause changed in the version that made it false — which is the promise its last sentence made.

8. Where your data is held, and transfers outside the UAE

8.1 The honest position. ABS Twin runs on international cloud services. Some of them process data outside the United Arab Emirates, and we do not claim otherwise. The Sub-processor List states, per provider, where processing takes place and where the position is still being confirmed.

8.2 Our basis for transfers — the mechanism described, not merely named. Saying that we rely on "the transfer conditions available under the law" tells you nothing you could check, and the law itself requires the protection measures to be described. So here is what they are, strongest first.

1. Necessity. Your account exists so that we can provide, to your Studio and to you, the service your Studio has contracted for. The transfers described here are the ones required to perform that arrangement and to serve the interests of the people it is about. For a booking system that runs on international cloud services, that is the everyday and honest basis, and it is the one we lead with.
2. Written contracts with the recipients we can contract with — and a candid account of the ones we cannot. The providers in clause 6.3(1) are required to be bound by an agreement obliging them to apply the protections, measures, controls and requirements the UAE Personal Data Protection Law imposes on us. Where a provider will negotiate, we also seek a term identifying the supervisory or judicial route in that provider's own country through which those measures can actually be imposed on it — the authority or court before which the obligation can be enforced. That element is unusual: a standard international data-transfer contract does not contain it. We therefore seek it and obtain it where we can, and we do not claim to have it where we have not — which of our providers carry it is recorded, provider by provider, in the Sub-processor List. For the rest, and for the two participants in clause 6.3(2) whose terms are not negotiable at all, we record the same commitments as our own, assess the gap, and keep that assessment on our internal cross-border transfer record. An assessed gap is not a term we obtained, and we are not going to describe it as one.
3. What we do not rely on: adequacy. The law also allows transfers to a country the competent UAE authority has determined offers an adequate level of protection. No such determination has been published, so we treat no destination as adequate and we use the grounds in (1) and (2) for every transfer. We would rather tell you that route is unavailable than imply we are using it.

Our full assessment — which destinations, which recipients, which risks and what we concluded — is recorded internally in our cross-border transfer assessment and summarised in the Privacy Policy.

8.3 What we will not say. We will not tell you that your data is held in the UAE, or in the EU, when parts of the platform are not. Where a specific location matters to your Studio, it is stated in the Sub-processor List, provider by provider, with the items still marked for confirmation left visibly marked.

Four of these are now answered in clause 6.2 rather than deferred to a list. The authentication provider processes in the United States; the serverless platform is United States primary with a general right to process globally; inbound mail is configured in Ireland (eu-west-1) and outbound email sends from Ireland (eu-west-1) with the provider's primary processing stated as the United States; and the caching and scheduling layer is globally replicated and not fixed to one country. Two remain open, and they are the two that hold the most about you. The operational database provider (Airtable — Formagrid, Inc.) publishes the United States as its location; we state that from its published position, not from a residency term we have obtained, and it is confirmed against the executed terms in the release that completes the verification described at clause 6.3(3). The push provider publishes United Kingdom, European Union and United States infrastructure, but the region in which device registrations are held is not stated in its own agreement, so it stays open and is marked open in the Sub-processor List until that provider confirms it.

9. Training AI models — what we can and cannot promise

We state this in layers, because a single sentence would be either useless or untrue.

9.1 Carnelian does not use your data, your Studio's data or Guest Data to train, fine-tune or improve AI models, and does not train any model across the data of different Studios.

9.2 Our principal AI provider (Anthropic) publishes commercial terms stating that customer content is not used to train its models.

9.3 Our transcription provider (OpenAI) publishes terms stating that data submitted through its API is not used to train its models unless the customer opts in, and we have not opted in. The API/interface distinction matters and we make it deliberately: that provider's consumer interface trains by default, and only the API carries the no-training default. We use the API.

9.3.1 What clauses 9.2 and 9.3 are, and are not. They report what those providers' published terms say. They are not a statement that we have completed the contractual verification behind them, because we have not — the executed terms are being collected and checked provider by provider, and we would rather show you that seam than state as settled a fact about somebody else's contract that we have not yet read to the end. When the verification is complete these clauses are restated against the evidence, either way, in the release that completes it. A change to any AI provider's terms is a standing trigger for that review, among the review triggers in our internal change-control discipline. Executed terms are not yet on file for every provider that receives Staff App or Guest content, and the training and retention position is evidenced provider by provider in the Sub-processor List as each check is completed.

9.4 For the voice layer — the provider that runs telephone conversations and the speech services beneath it — we configure the retention and training controls that provider makes available, and contract to restrict such use where the provider offers that control. We name those providers in the Sub-processor List. We do not make an absolute no-training statement for that layer, because we cannot yet evidence it for every provider in the chain, and we would rather hedge visibly than promise something we cannot prove. The same verification that clause 9.3.1 describes covers this layer, and this clause is upgraded only when it is evidenced.

9.5 We do not use data collected for one purpose for a different purpose without a fresh basis and, where consent is the basis, fresh consent.

9.6 We never sell personal data, and we do not permit any provider to use data we send it for that provider's own product development beyond what our contract with it allows.

10. How we protect the Staff App

We describe controls we actually operate. We hold no security certification, and we claim none.

10.1 Access is proved on every request, not once at sign-in. A Staff App session is a distinct class of credential. Every call re-reads your access status from our records and refuses a user whose access has been suspended, or who has left the Studio — the check runs per request rather than once at sign-in, so a revocation does not wait for your next sign-in to take effect.

10.2 The server decides what you can see. Every Staff App response is assembled field by field on the server, so a field the Staff App is not given is not included in what is sent. Responses are marked private and not to be stored by caches, and browser access is restricted to the Staff App's own origins.

10.3 Tenant isolation. Every read and write is scoped to your Studio by a single adapter, and a request that cannot resolve a Studio is refused rather than answered broadly. After the database query, a second check drops any record belonging to another Studio.

10.4 Encryption. All traffic is encrypted in transit using HTTPS. Our own scheduled snapshot of the operational database is encrypted before it is stored, using a strong authenticated encryption algorithm, and that backup job does not run at all if its encryption key is absent. We name the system rather than saying "our backups", because a provider's own internal backups are the provider's and are covered by clause 6.3 rather than by this sentence.

10.5 Accountability. Writes made through the platform are recorded with the actor, the action, the target, the result and the actor's IP address, so that a change can be traced.

10.6 Your sign-in — what it uses, and what it does not. You sign in with the credentials set up from your Studio's invitation, held by our authentication provider. You sign in with a password and an emailed one-time code — a device-verification step our identity provider enforces and that cannot be switched off. We are deliberate about what we call it: it is not multi-factor authentication, and we do not describe it as such, because true multi-factor authentication is not available on our current identity-provider plan. A password plus a mandatory emailed code is materially better than a password alone, and it is not the thing a security questionnaire means by "MFA".

Two compensating controls stand behind that, and they are the reason the position is tolerable rather than merely disclosed: your access status is re-read on every request rather than once at sign-in (clause 10.1), and when your Studio removes your access your sessions are ended rather than left to expire. It is also why clause 18 puts "keep your credentials to yourself" as a duty rather than as advice, and why clause 18.3 attaches a consequence to it. Enabling a genuine second factor is an open item and is treated as a submission gate rather than an improvement.

10.7 If something goes wrong. Our incident and personal-data-breach procedure is documented in our internal breach-response procedure and is being brought into operation; it is a procedure we are committing to, not yet an established operating routine with a rehearsed call-out. We put it that way round because a claim to "operate" a control that is still a draft is the same defect as claiming a certification we do not hold. Under that procedure: where a personal-data breach affects Guest Data, the Studio is the Controller and we notify the Studio without undue delay and in any event within 24 hours of becoming aware, so that it can meet its own notification duties; where it affects your account data, we are the Controller. We notify the competent authority without undue delay and in any event within 24 hours of becoming aware, and immediately where the law says immediately. We notify affected individuals without undue delay, against an internal target of 24 hours from the decision to notify — and the decision is not deferred in order to stop the clock starting. *(The trigger differs deliberately between the two limbs and it is stated rather than glossed: the authority clock runs from awareness, the individual clock from the decision to notify, which is the formulation our breach-response procedure performs and which governs. Where any regime fixes a shorter period, that period governs; that procedure's rule is that where more than one regime applies, the shortest clock governs the operational response.)* We publish the number because "without undue delay" is not a period anyone can hold us to, and because the same number appears in our breach-response procedure and in the Data Processing Agreement so that the three documents do not differ.

The procedure is being brought into operation. The date it is adopted and in operation, the person accountable for it and a reachable out-of-hours route are stated in the next revision of this notice. Until that revision states them, this clause is a documented commitment and not an established operating routine, and we would rather say so than let the sentence above be read as more than it is.

10.8 We assess this processing, and we write the assessment down. The processing described in this notice is covered by a written risk assessment, kept internally and made available to a regulator on request. That assessment does not exist today, so this sentence is a commitment until it does, and the date on which it is created, dated and owned is stated in the revision that records it.

11. How long we keep things

11.1 The rule. We keep personal data only as long as it is needed for the purpose it was collected for, or as long as the law requires. The full schedule is our internal retention schedule and is summarised in the Privacy Policy.

11.2 The Staff App specifically.

One thing about this table you are entitled to know. The periods in it are the ones our internal retention schedule sets. Account deletion now runs — the routes in clause 12 exist and operate, and the first row of this table is enforced by them. Retention enforcement for the other rows is still being brought into operation, so a period stated for those rows is, for now, a period we are committing to apply rather than one a job already applies — and we say so rather than let a table imply a scheduler that does not yet run.

11.3 When we keep something for longer. We keep personal data beyond its normal period only where one of these grounds applies, and only for as long as it applies:

1. a law requires it — including tax and commercial record-keeping;
2. it is needed to establish, exercise or defend a legal claim, or a dispute is live;
3. a court, a regulator or a lawful hold requires it;
4. it is still being used for security and fraud prevention — which is a live purpose rather than an extension of one that has finished, and it is used for nothing else;
5. an incident investigation is open, during which deletion is suspended so that evidence is not destroyed.

These are the only grounds on which data we control survives a deletion request. Records your Studio controls are a separate matter and are dealt with at clause 12.3 — deleting your login does not delete them, and it never did. The five grounds are stated in the Privacy Policy and on the deletion page in the same words, with the same scope limb.

12. Deleting your account and your data

12.1 Three routes. All three operate today, and we say exactly what each one is. None of them requires you to email us and hope: the first is a control in the app that performs the deletion itself; the second is a documented request route that runs on email and needs neither the app nor a login; the third runs through your Studio. Earlier versions of this clause were written in the conditional, because the first two routes did not yet exist. They exist now, and the conditional is gone.

12.1.1 What the in-app control is. It is reachable in a few taps from the app's main navigation — the Me tab, at the bottom of the screen — labelled as deletion, and it performs the deletion described in clause 12.2 after a single confirmation step. It is not a "contact support" form, not an email link, and not a deactivation switch — none of which would satisfy either the app-store rules or your rights under the law. One deliberate property worth stating: it works even if your access has been suspended — a suspended person with a live session can still delete their account, because the right to leave should not depend on being in good standing.

12.2 What deletion actually removes. Your login identity at our authentication provider — and with it your credentials, your sessions and your signed-in devices, which cannot survive the identity they belong to — and the app-access record that linked that login to your staff record: your access status, your app role, and the dates you were invited and activated. Notifications stop in two ways at once: your device clears its own notification subscriptions as you are signed out — a best-effort tidy-up — and, the part that is the actual guarantee, from the moment your access ends our servers refuse to send any notification addressed to you: every staff notification is checked against your live access status before anything is sent. What we do not delete is the push provider's own device registration, because it is held on that provider's side; it stops receiving anything because nothing is sent to it, and it ages out on that provider's schedule. We say that rather than write "your push registration is deleted", because the second sentence would be tidier and less true.

12.3 What deletion does not remove — stated plainly, because promising otherwise would be untrue. Deleting your account does not delete your Studio's records. The Studio's bookings, its Guest records, its roster and leave history, and its employment record about you belong to the Studio as Controller, and are kept under the Studio's instructions and the retention schedule. If you want those records changed or erased, the request goes to your Studio; we will help the Studio act on it, and we will act on the Studio's instruction.

12.4 What is kept regardless. The grounds in clause 11.3 — legal and tax record-keeping, live or anticipated legal claims, a lawful hold, security and fraud prevention, and an open incident investigation. Data kept on one of those grounds stays protected, is used only for the ground that justifies it, and is deleted when that ground ends.

The accountability record of writes made through the platform is one of these. It is retained under clause 11.3(1) and (4), and it survives the deletion of your login. It records that an action was taken from your account — the actor, the action, the target, the result and the address the request came from. It is not a profile about you, it is not used for any other purpose (clause 4.4(3)), and it is the record that answers "who changed this?" when someone asks months later. Deleting a login should not be a way of deleting the trail of what that login did, and we say so here rather than let a deletion request quietly destroy the evidence that a deletion request is sometimes made to destroy.

12.5 How long it takes. Through the in-app control, the deletion in clause 12.2 is performed immediately — the control confirms on-screen when it is done, and no email is sent about it, because you are watching it happen. Through the web (email) route, we acknowledge the request without undue delay, complete the deletion within 30 days of verifying who you are unless a ground in clause 11.3 applies, and email you when it is done. Either way, our identity provider's own deletion tail — up to 90 days — runs after ours, and copies inside encrypted backups disappear as those backups age out. We print the provider's tail alongside our own period rather than quoting a single figure, because a chain we do not fully control cannot honestly be compressed into one number; the tail is a proposed figure until it has been verified against the executed agreement with that provider, which is the rule our internal data-subject-rights procedure applies to any vendor tail.

The deletion service level we publish for the email route is the 30 days stated in this clause, and it is the only service level we publish — the in-app route is not a service level, it is an action the app performs while you watch.

12.5A The rules of the deletion window, published because whoever handles a request has to follow some. An in-app deletion has no window: it completes immediately, and the only things that follow it are the provider tails in clause 12.5. A request through the web (email) route takes days, and things happen during those days: you sign in, your Studio re-invites you, the confirmation email bounces, your Studio objects. A rule decided quietly inside a process is how a published deletion promise drifts away from what actually happens, so we publish the rules, and we follow these and no others:

1. Your access ends when the request is verified, not when the deletion finishes. The rest of clause 12.2 completes on the timetable in clause 12.5. A request made from inside the app is verified by the fact that you are signed in — there is nothing further to check, and nothing further to wait for: the deletion is performed there and then. Rules 2 and 4 below, which are about the confirmation email, apply to the email route only.
2. Signing in does not cancel your request. If you change your mind, cancel it — reply to our acknowledgement, or tell us at the address in clause 15. We would rather you had to say so than have a request you meant be undone by a habit.
3. If your Studio re-invites you during the window, the request still stands. We complete the deletion of the old account and the new invitation creates a new one, with a new login identity. You and your Studio are both told — the one exception to rule 5's no-notice position, and it says only what this rule says.
4. If the confirmation email bounces, or is never confirmed, we do not act. We cannot delete an account on an unverified request. We try the address once more, and where you have told us you have lost access to that mailbox we ask your Studio to confirm instead (clause 12.6). If nothing is confirmed within 30 days, we close the request without deleting anything and tell you at the address we have.
5. Your Studio cannot veto the deletion of your login. It does not need to, and clause 12.8 explains why: its own records are unaffected either way. What the Studio sees, and when: we do not send the Studio a notice about your deletion. From the moment your access ends, the Console shows your account's app access as "No access" — that is how the Studio learns it, for the in-app route and the email route alike. No reason, no content, no copy of anything you said.

These same five rules appear on the account-deletion page at https://abstwin.com/legal/delete-account, in the same terms.

12.6 How we check it is really you. Because a deletion request from the wrong person is itself a security incident, we verify a request before acting on it — normally by sending a confirmation link to the account's work email address through the transactional-email provider named in clause 6.2, and where necessary by asking your Studio to confirm. We ask for the least information that will do the job, and we do not use it for anything else.

12.7 Deactivation is not deletion, and we do not present it as such. Suspending access freezes a login; it is a different thing from deletion and we label it differently in the app.

12.8 What if the Studio objects? Your account is provisioned by the Studio for its business, and the Studio may need to know that its staff member's access has ended. Deleting your account ends your access to the Studio's data; it does not release you from any obligation you owe your employer, and it does not oblige the Studio to delete its own records. An objection by the Studio does not stop the deletion of your login — clause 12.5A(5) states the mechanic and what the Studio sees, and the reason it can be stated so simply is that the Studio loses nothing it is entitled to: every record it controls survives under clause 12.3.

13. Your rights

13.1 Under the UAE Personal Data Protection Law you have rights to be informed, to obtain a copy of your data, to have inaccurate data corrected, to have data erased in the circumstances the law provides, to restrict processing, to object to certain processing, to receive data in a portable form, and to human review of a decision taken solely by automated means that produces a legal effect for you. Two more, which are easy to leave off a list and are not: a right to require us to stop processing your data for direct marketing, including profiling connected with it, and for statistical surveys — a right you do not have to give a reason for (clause 4.1.1); and, where processing of your data has been restricted and we later lift the restriction, our duty to tell you before we do.

13.2 Who to ask.

This routing assumes the allocation in clause 2.2 as drafted. If that allocation is determined to be joint, clause 2.2.1 governs and you may bring an account request to either of us.

13.2A How to make one — a route, not just an address. It would be an odd result if erasure were the only right with a front door while access, correction and portability were left at "write to us and hope somebody files it". So the page at https://abstwin.com/legal/delete-account covers any request about your data, not only deletion: a copy of it, correction of something wrong, erasure of one specific item without closing your account, restriction, objection, portability of what you gave us by automated means, and human review under clause 4.5(4). The page carries no web form — the route it documents is email, to privacy@contact.abstwin.com — and it tells you what to include so the request can move on first contact.

Every request runs the same way: the same verification under clause 12.6, an acknowledgement with a reference number you can quote to ask where a request has got to, and a completion notice. A request about a record your Studio controls is routed to the Studio, not refused — we tell you that is what we have done, and we support the Studio in answering it. You may write to the address in clause 15 instead and it is treated identically; the page exists so that you do not have to find that address first.

13.3 What it costs and how long it takes — and one thing you should know about the law. Exercising a right is free. We respond without undue delay, and in any event within the periods set out below.

We should be straight with you about what that period currently is. The UAE Personal Data Protection Law is in force, but its Executive Regulations — the instrument that will set the detailed procedures and the response deadlines — have not been issued, and no date for issuing them has been announced. So rather than point you at an internal document, here are the periods we actually apply:

• we acknowledge within 5 business days;
• we may take up to 10 business days to verify who you are;
• we give a substantive response within 30 calendar days of verifying you;
• and where a request is genuinely complex we may take one further 30 calendar days, telling you why before the first period runs out, not after.

What those numbers are. They are our own service commitment, applied to every request while the Executive Regulations are unissued. They are not a statutory period, and a delay we tell you about in advance is not a breach of a legal deadline that does not yet exist. When the Executive Regulations are issued we apply whatever they require, and this notice and our internal data-subject-rights procedure are reviewed against them — a standing trigger among the review triggers in our internal change-control discipline.

13.4 If you are not satisfied. Contact us first, at the address in clause 15 — we would rather fix it. You also have the right to complain to the competent UAE data-protection authority, the UAE Data Office, which was established by federal decree-law. You may complain to it at any time. We will give you its current contact route on request, and we will publish it at this clause once we have confirmed it is operational — the complaint procedure is among the matters the unissued Executive Regulations are expected to set, and we will not print a contact route we have not checked answers. Whether an individual complaint channel is operational there is one of the things we have not been able to confirm, which is why this clause names the authority and the route to us, rather than a route to it that we have not tested.

13.5 Nothing in this notice reduces a right you have under the law. Where this notice and a mandatory legal right conflict, the right prevails.

13.5A If your Studio is registered in the DIFC or in ADGM, a different law applies to its records about you. The United Arab Emirates is one country and, for data protection, three regimes. The federal Personal Data Protection Law applies to us. But the Dubai International Financial Centre and Abu Dhabi Global Market each have their own data-protection law and their own Commissioner of Data Protection, and a spa, salon or wellness operator registered in one of those centres is an entirely ordinary customer for this product.

Where your Studio is so registered, the law governing your Studio's records about you — your staff record, your roster, your leave history, the appointment records — is that centre's data-protection law and not the federal one; the regulator you may complain to about them is that centre's Commissioner; and the courts of that centre are the ones open to you, including, in the DIFC, a direct right to bring a claim without complaining to the Commissioner first. Clauses 13.1, 13.3 and 13.4, and the forum in clause 20.4, are written for the federal regime and are the wrong map for that half of your data.

And there is a second limb of that regime this notice does not yet answer, stated here rather than left to be discovered. The DIFC has its own regulation for personal data processed through autonomous and semi-autonomous systems. It requires a notice at first access, with its own prescribed content, and it would make your Studio the deployer of the Assistant and us its operator. Clause 5 of this notice does not presently give that content, and we would rather say so than leave a DIFC reader to assume it does. That is the same gap as the event-triggered addendum at clause 10.4.1 of the Support & Service Levels — the obligation arises the moment a DIFC- or ADGM-registered Studio is onboarded, and it is triggered by an event rather than by a review date, so it must not be policed by the next-review field. Neither document may be published as answering it until the required content is drafted, and the two are drafted together because they answer the same regulation for the same deployment.

Ask your Studio where it is registered if you are unsure. If you ask us, we will tell you.

13.6 If you work outside the United Arab Emirates, this clause is not written for you yet — and we say so rather than let you rely on it. Clauses 13.1, 13.3 and 13.4 name UAE law, the UAE Data Office and, at clause 20.4, the Dubai Courts, because the app is issued to staff of Studios in the United Arab Emirates. Another Gulf State's data-protection regime may reach the processing of the data of a person residing there whoever is doing the processing and wherever they are — with its own regulator, its own complaint route, its own rules about transfers abroad, and in some cases its own mandatory assessment before data leaves the country. If that is your position, the law that protects you is that country's, not the one named here, and the complaint route in clause 13.4 is not yours. Store availability is restricted at launch for exactly that reason: we would rather narrow where the app is listed than hand a reader a regulator who cannot help them.

14. Consent, and how to withdraw it

14.1 Where we ask for consent. Push notifications, and any optional feature that collects something beyond what the app needs to function.

14.2 How we ask. Before we collect, in the app, in plain language, describing what is collected and what it is used for, with a clear affirmative action — a tap or a checkbox. Navigating past a screen is not consent. The disclosure is not bundled with unrelated notices, and it comes before the operating system's own permission prompt.

14.3 How to withdraw. Turn the feature off in the app's settings, or in your device settings, at any time. Withdrawal takes effect for the future; it does not undo processing that was lawful when it happened.

14.4 Refusing costs you nothing in the app. No feature, content, or benefit is withheld because you declined an optional permission.

15. Contact, and support

15.1 Contact us about this notice or about your data

15.1.1 Our Data Protection Officer. The Personal Data Protection Law requires a Data Protection Officer to be appointed in defined cases, and requires the appointment to be notified to the UAE Data Office. We have appointed one. Our Data Protection Officer is Syed Sharique Ali, who is a Manager of Carnelian Technologies L.L.C-FZ, appointed with effect from 21 August 2026. The law permits the role to be held by someone inside the company. You can write to the officer directly, and you do not have to go through your studio or anyone else to do it: use dpo@contact.abstwin.com, or the data-protection contact above, which also reaches him. Both are company mailboxes rather than personal ones, and both are monitored every working day.

One thing we would rather tell you than leave you to find out: we have not yet notified the officer's contact details to the UAE Data Office, which the law requires us to do; it is outstanding and we are doing it.

15.2 Support. Support for the Staff App runs through your Studio in the first instance, because the Studio administers your account. Your Studio's support route with us is set out in the Support & Service Levels policy. Anyone may reach us at https://abstwin.com/contact.

15.3 Security reports, and what we will and will not promise a researcher. If you believe you have found a security problem, please report it at https://abstwin.com/legal/security.

If you keep to the following, we will not bring or support a civil claim against you in respect of the research itself: test only against your own account and only against systems we operate for ABS Twin; do not access, copy, retain or publish anyone else's personal data; stop at proof of concept — do not go further than you need to demonstrate the issue; do not degrade, overload or interrupt the service, and do not attempt denial of service; do not use social engineering against our people or our providers' people; report promptly, and give us a reasonable period to fix the issue before disclosing it publicly.

Two things we cannot promise, and will not pretend to. We cannot waive anybody else's rights — a Studio's, a Guest's, or a provider's. And unauthorised access and interception are criminal matters in their own right, so we cannot control what a public authority does. What we can do is not come after a researcher who behaved well, and we will not.

16. Children

16.1 The Staff App is not directed to children, and no account may be issued to anyone under 18. Accounts are issued by a Studio to the people it employs or engages, and under its agreement with us (the Master Subscription Agreement) the Studio must not issue a Staff App account to a person under 18, and warrants to us that it has not. We state it as a rule the Studio owes us rather than as a description of who happens to use the app, because a Studio's hiring is its own to describe and not ours to assume. Both app stores' child-safety declarations rest on this sentence, and a declaration should rest on a rule.

A rule we do not enforce is not a safeguard, so the rule is being backed by a control at the point the invitation is created rather than left to the warranty alone.

16.2 Guests who are minors. A Studio may book an appointment for a minor. Where it does, the data about the minor is supplied by the accompanying adult, and the Studio is responsible for having a lawful basis for it. The Staff App shows a first name and an appointment; it is not used to collect data directly from a child. We set no platform-level rule of our own on Guest records for under-18s, or on a minimum age for a booking a Studio flags as age-restricted: those are the Studio's to set as Controller, under its own regulatory obligations. Where we adopt a platform-level rule, it is stated at this clause.

17. The Staff App is not a medical device

17.1 ABS Twin, including the Staff App, is an appointment, roster and communication tool for a business. It is not a medical device. It does not diagnose, treat, cure or prevent any medical condition, and it gives no clinical, diagnostic or suitability advice. Nothing shown in the app is a medical record or a clinical instruction, and nothing in it should be relied on as one. Where a Guest's health matters to a service, the Studio's qualified professionals decide — not the app and not the Assistant. If you or a Guest have a question about a health condition, a medication, a reaction or a treatment's suitability, that is a question for a qualified healthcare professional, and nothing in this app is a substitute for asking one.

17.2 Studios are contractually prohibited from entering clinical, diagnostic or treatment records into ABS Twin (the Acceptable Use Policy and the Restricted / Health Data Addendum), and staff must not enter them either.

17.3 What happens when clinical content is found anyway — because a prohibition alone does not deal with it. A rule that says "do not type this here" does not stop it being typed, and once we know that regulated health information is sitting in a field, the fact that our contract forbade it stops being an answer. Health information in the United Arab Emirates is regulated in its own right, including as to where it may be stored and processed, and a prohibition we do not enforce is not a safeguard. So we state what actually happens:

1. Where it can arise in this app. One place: the leave-request reason (clause 3.1.3). Nothing else the Staff App writes is free text.
2. Reducing the surface first. The primary control is not detection but design, and it has been exercised: the appointment flow's free-text note did not ship — the satisfaction rating is stars only, decided and built — so the field where clinical detail about a Guest was most likely to land does not exist. A field that cannot receive clinical text does not need a clinical-text response path. What remains is the leave-request reason, and this clause is written for it.
3. If clinical content is found in that field — whether we find it, your Studio finds it, or you tell us — then we delete it, and we tell your Studio that we have. Not "may": do. The reason is short and you can act on it. Health information in the United Arab Emirates is governed by its own law, which restricts where it may be held and processed, and this system is not built to hold it — it runs on international cloud services, so the moment clinical text lands in that field it is already being stored somewhere that law does not contemplate. Once we know it is there, continuing to store it is not a thing we have discretion about, and a contract that forbade it is not an answer to the fact that it is sitting in a database.

The only qualification is evidential: where deleting immediately would destroy the evidence of a live incident, we quarantine it — access removed, retained only for that investigation, under clause 11.3(5) — and delete it when the investigation closes. We do not copy it onward and we do not send it to any AI provider, and we say that as an additional limit rather than as the remedy, because it is not one. We record what happened, because a pattern is a product problem rather than an individual one. Where the content indicates the Studio is operating a clinical service outside the scope we accept, the Restricted / Health Data Addendum governs what happens next, up to declining to continue processing it.

4. The Service is not offered for the processing of health data. Whether a licensed health facility, or clinical processing of any kind, falls outside the scope of what we accept is governed by the Restricted / Health Data Addendum and by the scope stated in the Master Subscription Agreement — not by this notice, which describes the app rather than the terms of acceptance.
5. You should tell us. If you realise clinical detail has gone into that field — yours or a colleague's — say so under clause 15.3 or to your Studio. Nobody is penalised by us for reporting it.

18. How the app is to be used — a summary, with the duties themselves in the licence

18.1 Where the duties actually live, and why not here. Because the app shows you another person's personal data — a Guest of your Studio — using it carries duties. This notice does not impose them. A privacy notice is a unilateral transparency document; it tells you what we do, and it cannot make you promise anything. The duties are in two places that can: the licence at clause 19, which you are asked to accept, and the Acceptable Use Policy. What follows is a summary of them so that you are not asked to accept something you have only ever seen elsewhere — the licence text governs, and where the licence, the Acceptable Use Policy and this summary differ, the most restrictive applies to you (clause 1.2(2)).

The licence expresses those duties as the method of use of the Staff App — the way the app is to be used, set out before you use it. That framing matters for a plain reason: where a loss is caused or made worse by a party's own act or omission, UAE law reduces the compensation recoverable accordingly, and the method is what such an act or omission is measured against. There is a second, narrower route as well — damage arising from use contrary to a documented method of use may fall outside a consumer's statutory compensation right — but that route depends on a consumer characterisation that is not settled, so it is stated as an additional limb and never as the basis.

18.2 The summary. In using the Staff App you must:

1. use it only for your Studio's business, and only for the appointments and records your role covers;
2. keep your credentials to yourself and not share your login or your device session — which matters more than it might sound, because clause 10.6 tells you plainly what stands behind your password today: a mandatory emailed one-time code, materially better than a password alone and still not what a security questionnaire means by multi-factor authentication;
3. not photograph, copy, export or forward a Guest's details to anyone outside your Studio's lawful processes;
4. not attempt to reach data belonging to another Studio, another member of staff, or a Guest who is not yours to serve;
5. not enter Restricted Data, as clause 1.4 defines it, into any free-text field in the app;
6. report a lost or stolen device, or a suspected compromise, to your Studio and to us immediately.

18.3 One thing worth knowing about duty (3), stated for deterrence and not for effect. Disclosing confidential information that you obtained in the course of your employment can be a criminal offence under UAE law — independently of this notice, independently of your contract with your Studio, and independently of anything we decide to do about it. We tell you because a Guest's details leaving a studio on a member of staff's phone is the most likely privacy incident this product will ever have, and because the deterrent only works on someone who knows it is there.

18.4 What happens if these duties are breached. Your access is your Studio's to grant and to end (clause 2.1), and decisions about your employment are your Studio's alone. Separately from that, and only where it is necessary, we may restrict, suspend or end your individual access to the Staff App where you breach the duties in clause 18.2 or where your account presents a security or legal risk — a shared credential, an attempt to reach another Studio's records, the export of Guest data outside your Studio's lawful processes, or a compromised device. That right is granted to us by your Studio in its own agreement with us (the Master Subscription Agreement) as well as by the licence, which is what allows us to exercise it over an account the Studio controls without acting against the Studio's instructions. Four conditions attach, and they are as much a part of this clause as the right is:

1. It is graduated. Where the facts allow, we restrict before we suspend and suspend before we end, and we do the least that answers the risk.
2. Notice. Where the risk is not urgent, we tell you and your Studio first and give an opportunity to put it right. Where it is urgent, we act first and tell you both immediately afterwards, with the reason.
3. Your Studio's service is not affected. We do not suspend the Studio's subscription, another user's access, or the Studio's own data because of one account.
4. It is a security measure, not a disciplinary one. We are not your employer, we take no view on your employment, and we say so to your Studio when we tell it what we have done.

The same right, in the same graduated form, appears in the licence.

19. The licence under which you use the app

19.1 You are asked to accept it — it is not something you are taken to have agreed by installing anything. Your use of the Staff App is licensed, not sold, on the terms of the ABS Twin Staff App End User Licence Agreement, which you are asked to accept when you first sign in, on its own screen, before the first screen that shows data — and which is published at https://abstwin.com/legal/app-eula, in English, and in Arabic from the date its legally reviewed Arabic text is published, on the same rule as clause 20.3.1. You can read it in full before you accept it. What the record of your acceptance is — including the part of it that is still being built — the licence itself states honestly, at its clause 4, and we would rather point you at that statement than repeat a tidier version of it here. If the wording later changes in a way that matters, you are asked again rather than treated as having agreed by continuing to use the app.

We are explicit about this because the licence is where the limits on what you can claim from us live. A limitation in a document nobody has been asked to agree to limits nothing, and putting a link at the bottom of a screen is not the same as asking.

19.2 Under that licence: your Studio is the account holder and the party that contracts with us for the service; you use the app as an Authorised User under your Studio's Master Subscription Agreement; the Studio's instructions govern the data you see; the Staff App is supplied to you at no charge — your Studio pays for the service, you do not pay us anything and are not asked to; and the app carries no purchase, subscription or pricing function of any kind.

19.3 If we have not supplied our own licence terms to an app store, that store's standard end-user licence applies by default. Our position is to supply our own; we keep an internal record of why, and of what that licence must contain.

20. Changes, language, and law

20.1 Changes to this notice. We may update this notice. The version and date at the foot of the page always show the current text; the foot of the page also names the version this one replaces, so the archive can be walked backwards rather than searched, and carries a content hash of the published text, so that a version can be shown to be the one that was actually published rather than merely described. We keep an accessible archive of previous versions with the dates they applied, and we never silently edit a published page — a change to the text is a new version with its own date, supersedes line and hash. For a change that materially affects how we handle your personal data, we give notice in the app and, where we hold your email address, by email, before the change takes effect. We do not make a material change effective by silence. Where a change requires consent, we ask again.

20.1.1 Where that notice goes. We send it to the work email address on your account, and we show the same notice in the app alongside it, so that neither channel is relied on alone. In-app notice on its own is not enough for a material change, and we never treat your continuing to use the app as your agreement to a change; where consent is the basis, clause 14 applies and we ask. The deemed-receipt and re-send mechanics that go with all of this are contract terms and sit in the licence, where they can actually bind, rather than being asserted in a notice that cannot.

20.2 Store declarations change with it. Where a change alters what the app collects or shares, the Apple App Privacy labels and the Google Play Data safety declaration are updated in the same release cycle as this notice. That discipline is set out in our internal change-control record.

20.3 Language. This notice is prepared in English and Arabic together, and the Arabic text is reviewed by an Arabic-qualified UAE lawyer and by a native Gulf-Arabic reviewer before it is published, because Arabic that reads as a machine translation defeats the purpose of the notice: a disclosure a person cannot naturally parse is not a disclosure. An earlier version of this clause said the notice would not be published at all until the reviewed Arabic text existed, on the analysis that English-only publication of a consumer-facing notice risks a breach in the criminal penalty band. The interim course actually taken — English first, with the reviewed Arabic to follow and to prevail from its own publication date (clause 20.3.1) — has been put to our reviewing counsel expressly rather than adopted in silence, and this clause records that it was a considered release of the earlier rule, not a lapse of it.

20.3.1 When this rule starts to operate. From the date printed on the published Arabic text of this notice, in the event of a conflict between the two versions the Arabic version prevails to the fullest extent permitted by applicable law, because this is a notice addressed to individuals in the United Arab Emirates and the Arabic text is the text a UAE court will read. Before that date this clause has no operation, the English text is the only text, and no Arabic text is published alongside a clause saying it prevails — a prevalence clause pointing at a text that does not exist is worse than none. The review precondition itself — no Arabic text is published before an Arabic-qualified review — is carried by clause 20.3 above, in its amended form.

20.4 Governing law and forum. This notice, and any non-contractual obligation arising out of it, is governed by the federal law of the United Arab Emirates as applied in the Emirate of Dubai. The courts of Dubai have non-exclusive jurisdiction over any dispute arising out of it. This is without prejudice to any mandatory right or forum available to you under the law applicable where you live or work, and to your right to complain to the competent data-protection authority. And it is expressly without prejudice to clause 13.5A: if your Studio is registered in the Dubai International Financial Centre or in Abu Dhabi Global Market, that centre's data-protection law, its Commissioner and its courts are the ones that govern its records about you, and nothing in this clause narrows that.

Where the app is listed is a legal decision, not a listing decision, and it is taken in our internal publication and store-availability checklist: availability at launch is restricted to the United Arab Emirates, because a listing in another territory is the act that makes another country's data-protection regime apply to us and would hand a reader there a law, a regulator and a court that are not theirs.

20.5 Nothing here excludes what cannot be excluded. Nothing in this notice excludes or limits any liability or obligation that cannot lawfully be excluded or limited. Where any provision is found unenforceable, it is modified to the minimum extent necessary to make it enforceable, and the rest of the notice is unaffected.

20.6 What this notice is, and what it is not. This document describes how we handle personal data and sets out the rights the law gives you. It is not a contract, and it does not create rights beyond those the law gives you.

• Where you use the Staff App, the terms of that use — including the limits on our liability towards you — are in the Staff App End User Licence Agreement (clause 19).
• Where your Studio's rights are engaged, they are in the Master Subscription Agreement.
• Nothing in this notice increases the liability those documents limit, and nothing in it excludes any liability that cannot lawfully be excluded (clause 20.5).

20.6.1 Parts of what we describe depend on people we do not control. The Staff App runs on the providers named in clause 6.2 — authentication and identity, hosting and the edge, the database, the push provider and the operating-system push transports, transactional and inbound mail, caches and scheduling, and the app stores. We choose them, we configure them, and we are answerable for those choices. What we do not control is their availability, their own policies, their rate limits, or an action they take on an account. Where one of them prevents us doing something this notice describes within the period stated — a deletion, a notice, a completion email — we tell you, and we complete it as soon as we can. This is a description of where the edges of the system are, not an exclusion of anything, and it does not apply to a failure of ours dressed up as one of theirs.

Version v0.9 · Effective date: on publication

Supersedes: v0.8 — an unpublished working draft, so this v0.9 is the first published version of this notice, and the archive obligation in clause 20.1 begins at it; every later version names the version it replaces here. The changes from that draft are factual corrections, made because the build overtook the text: the native builds exist and run on real devices (clause 1.5(2)); push is live in the native builds (clauses 1.5(3), 3.2, 3.2.1, 7.5); the in-app deletion control and the email request route exist and operate, so clauses 12 and 13.2A now speak in the present tense and the self-imposed publication gate in clauses 1.5 and 12 is recorded as satisfied and released; clause 12.2's description of what deletion removes, clause 12.5's timing, clause 12.5A(5)'s account of what the Studio sees, and clause 6.1A's matching row were corrected to what the system verifiably does; clause 19.1 now points at the licence's own honest statement of the acceptance record instead of overstating it; device-storage rows for the first-run marker and the two choice markers were added at clause 3.2.1; clauses 3.1.3, 3.1.4 and 17.3 were corrected to the shipped build (the satisfaction rating is stars only — the appointment free-text note did not ship — and the app's one free-text field is the leave-request reason); clause 7.4 and the clause 11.2 push row were corrected to the device-settings truth about turning notifications off; and clause 20.3's language rule was restated as a considered English-first release, put to counsel expressly.

Publisher: Carnelian Technologies L.L.C-FZ, a Limited Liability Company licensed by the Meydan Free Zone, Dubai, United Arab Emirates. Trade licence 2415615.01, valid to 25 January 2027. Registered address: Meydan Grandstand, 6th floor, Meydan Road, Nad Al Sheba, Dubai, U.A.E. Telephone: +971 56 498 4007.

Contact: info@contact.abstwin.com (general) · legal@contact.abstwin.com (legal notices) · support@carnelian.tech (corporate; alternative) · Data protection: privacy@contact.abstwin.com · DPO direct: dpo@contact.abstwin.com · Support: https://abstwin.com/contact

Published at: https://abstwin.com/legal/staff-app-privacy · Language: English now; the legally reviewed Arabic text is published when its review completes, and it prevails, to the fullest extent permitted by applicable law, from that date and not before (clauses 20.3 and 20.3.1).

Content hash: SHA-256 of the published text, computed at publication and stored with the publication record.

Next review: on every Staff App release; on any change to the sub-processor stack; on issuance of the UAE PDPL Executive Regulations; and in any event within twelve months.