Data Processing Addendum

Version 2.30 · effective 2026-10-29 · in force

This Data Processing Addendum (the "DPA") forms part of the Terms of Service & Acceptable Use (the "Terms") between RunMyB, Inc., a Delaware corporation ("RunMyB", "we"), and the customer holding the account under the Terms (the "Customer", "you"). It applies wherever RunMyB processes personal data on the Customer's behalf within the scope of Regulation (EU) 2016/679 (the "GDPR") or equivalent data-protection law. Terms defined in the GDPR (controller, processor, personal data, personal data breach, and so on) have the same meaning here.

1. Scope and roles

RunMyB acts in three distinct capacities:

RunMyB as independent controller. For the platform's own account, identity, billing, credit-ledger, and security/operational data — the direct relationship between RunMyB and the people who use the platform — RunMyB is an independent controller. This DPA does not govern that processing; it is described in the Privacy Policy. The same holds for the records the platform keeps of visits to the Customer's hosted products — its load balancer's request logs and its audience beacon's records, with the statistics counted from them, as the Privacy Policy's Section 4 describes: RunMyB keeps them for its own purposes as an independent controller, and they are not Customer Personal Data. The same holds for the records that keep the e-mail the platform sends for the Customer's applications within its limits — for each address, a daily count of the address-verification and password-reset messages sent to it for each application and for all applications together, a daily count of each application's own messages sent to it, and a record that the address is paused after repeated bounces, each identifying the address only by a hash made with a secret key, and, for each application, the record of each time its own messages are switched off or back on, with the reason and who decided — as the Privacy Policy's Section 2 describes: RunMyB keeps them for its own purposes as an independent controller, and they are not Customer Personal Data. The same holds for the record that keeps the messages the platform receives for the Customer's applications within its limits — for each application and each reply address given to it, a daily count of the messages the application's contact form handed the platform with that address, and, for each application and each address that sends it e-mail, a daily count of the e-mails from that address the platform delivered to it, each identifying the address only by a hash made with a secret key — as the Privacy Policy's Section 2 describes: RunMyB keeps it for its own purposes as an independent controller, and it is not Customer Personal Data. The same holds for the platform's records of the notices it e-mails the Customer's administrators (and, for an application that only one member of the account can see in the console, that member) — which notice, to which sign-in address, about which event, and whether and when it was sent — of the choices the Customer's users make about which of those notices they receive, of the delivery of each message it sends the Customer's users and the users of the Customer's applications, of the messages to them that it refuses to send, with the reason, and of the look-ups the Customer's users make in those records, as the Privacy Policy's Section 2 describes: RunMyB keeps them for its own purposes as an independent controller, and they are not Customer Personal Data. The same holds for the record of the addresses confirmed for, or unsubscribed from, each of the Customer's applications — for each application and address, each time the address is recorded as confirmed, as unsubscribed or as no longer unsubscribed, with how that arose, the identifier of the platform's link and when it was issued where a link gave rise to it, and when it was recorded, identifying the address only by a hash made with a secret key and keeping nothing about the browser or device — as the Privacy Policy's Section 2 describes: RunMyB keeps it for its own purposes as an independent controller, and it is not Customer Personal Data. The same holds for the automated check RunMyB makes of each photo the Customer's users add to its applications, for content the platform's rules prohibit or restrict, and for the record of that check and of any decision RunMyB takes on the photo, as the Privacy Policy's Sections 2.8 and 8 describe: RunMyB makes the check and keeps those records for its own purpose — not hosting such content — as an independent controller, not on the Customer's instructions, and those records are not Customer Personal Data. From the records of the e-mail the platform sends and refuses to send (above), RunMyB shows the Customer's users who can see one of the Customer's applications in the console what became of the messages the platform sent, or refused to send, for that application — for example that one was delivered, bounced or reported as spam by the person it went to, or why one was not sent — never the address a message went to; and, for one address such a user types, which of those messages went to that address and what became of each, including that the person reported one as spam, matching the address by its hash and keeping neither the address typed nor its hash. RunMyB does so as an independent controller, in its own legitimate interest and the Customer's in the delivery of the application's mail, not on the Customer's instructions; what the Customer learns from it, the Customer holds as the controller of its application's end-users' data.
RunMyB as the Customer's processor — end-user data. For personal data that the Customer's applications, ventures, and workspaces process about the Customer's own end-users, and about the people shown in the material the Customer adds to them — such as the photos its users add to an application (Section 2) — the Customer (or the Customer's own client) is the controller and RunMyB is the Customer's processor. RunMyB processes that data only to provide the service, on the Customer's documented instructions.
RunMyB as the Customer's processor — team-member workspace data. Where the Customer admits employees, contractors, or other collaborators to its account, the Customer is the controller of the team-workspace data about those people and RunMyB is the Customer's processor: the Customer's administrators decide admission, roles, disablement, and — through the platform's affordances — what is retained, and RunMyB processes on those instructions.

Boundary with RunMyB's own controllership. Even within a Customer's team, RunMyB remains an independent controller — not the Customer's processor — for each member's own legal-acceptance and consent records, login identity, and the platform's security and operational logs: compliance evidence RunMyB must keep in its own right, recorded append-only.

Capacities 2 and 3 together define the "Customer Personal Data" this DPA governs.

2. Details of processing

Subject matter. The personal data processed through the Customer's use of the platform: the Customer's applications and their data stores, venture and workspace content, and the team workspace.
Duration. For the life of the Customer's account. After termination or a deletion request, processing continues only through the offboarding grace window stated when the request is filed, followed by deletion under Section 3(g), subject to the retention outer bounds stated there.
Nature and purpose. Hosting, building, verifying, operating, and backing up — other than the files the Customer's applications keep (Section 6) — the Customer's applications and workspace — including publicly serving the Customer's applications where the Customer publishes them, whatever their shape: static pages, full-stack applications with their own databases, and applications with their own end-user accounts, and sending, when such an application asks for it, the platform-worded address-verification and password-reset messages its end-user accounts need, to the address the application gives, each message carrying the platform's own link in place of the application's, which then opens the application's link, and an unsubscribe — a password reset only to an address confirmed for the application, the platform sending an address not yet confirmed its own message asking for it to be confirmed instead, and no message to an address unsubscribed from the application (the records that keep that mail within its limits, and the record of the addresses confirmed for or unsubscribed from the application, are RunMyB's own, Section 1), and sending, when such an application asks for it, messages of the application's own to its end-users, each rendered by the platform as plain text, and also as a formatted (HTML) version where the template carries one, from a template the application carries and the values the application supplies — the platform checking the form of both, never their wording, and rebuilding a formatted version from formatting it allows, with no image and nothing loaded from elsewhere, and sending it only beside the plain text — with the platform's own last lines and an unsubscribe, and sent to the one address the application gives only if that address is confirmed for the application, the platform sending an address not yet confirmed its own message asking for it to be confirmed instead, no message to an address unsubscribed from the application, and none of these messages while the application's own messages are switched off, and keeping no copy of a message's text or of its formatted version (the application's templates are kept with each version of the application prepared for publication, for as long as the application exists; the records that keep those messages within their limits, and those switches, are RunMyB's own, Section 1), and, from a preview of a Customer's application that a member of the Customer's account starts from the console, sending any of the messages above — an address verification, a password reset or one of the application's own — only to the address that member signs in to the platform with, without first asking that address to confirm itself, without the platform's own link in place of the application's and without an unsubscribe, and none to an address unsubscribed from the application, and relaying, where such an application offers its end-users sign-in with a sign-in provider the platform offers for it — today Google or GitHub — through a sign-in app the Customer registered with that provider for the application, the application's own exchange with the provider that completes that sign-in (the end-user's browser goes to the provider itself): RunMyB presents the Customer's sign-in app credentials to the provider on the application's behalf, receives the identity the provider returns — verifying the provider's signed identity token where it issues one — and passes that identity to the application — its signed identity token where the provider issues one, and the end-user's identifier at that provider, name, e-mail address, whether the provider has verified that address, and picture — with, in place of the provider's access token, a short-lived handle of RunMyB's own, valid for at most ten minutes, that the application cannot read: the application never receives the provider's access token or any refresh token, and RunMyB uses that access token, where needed, alone and in transit, to read the identity, and keeps it nowhere; all in transit only, keeping none of it (RunMyB's record of each relayed step names the application, the provider, the step and its outcome, never the end-user — one of the platform's security and operational records, Section 1); the provider acts under the Customer's own registration with it and is not RunMyB's sub-processor (Section 4), and running the background jobs such an application declares in the version of it that the platform serves: RunMyB calls the application's own address for each run — at the times the application's declared schedule sets, soon after the application asks for a run or at the time it names for one, or when the Customer's user starts one in the console — waking the application to do so if it is asleep, within the limits the Terms state (their Section 15, item 9), and, while it verifies a version before that version is accepted, runs each job the version declares once, on the platform's own running copy of the application, with the example data the declaration carries or none; it checks the form of each declaration, never what a job does; for each run of the hosted application it keeps a record — when the run was due, its state, its attempts and how each ended — and the data the application hands for the run, at most 16 KiB, which it gives to no one but the application itself, when the application's route begins the run, and removes from the run's record as soon as the run succeeds; and it deletes each finished run, with its record and any data it still holds, 30 days after the run ended (the daily counts of each application's runs, which hold no data the application handed, are RunMyB's own records, the substrate of its limits and of its metering, Section 1); and receiving the messages people write in such an application's contact form, where the application's own server hands them to the platform (an application the platform hosts with a server of its own may do so, and only one whose form does receives any): RunMyB keeps each message — its text, the address the writer gave for a reply, the name they gave, if any, and when it arrived — in the platform's own database, provided through the AWS sub-processor listed in Section 4; shows it in the console, as plain text with any link shown as text and with that name and address as the writer gave them, to the Customer's users who can see the application, or, for an application that only one member of the Customer's account can see in the console, to that member alone; checks each message only for its shape — that it is text within the platform's length, with one well-formed reply address — never who wrote it or what it says: not for viruses or spam, and not whether the name and address are the writer's own; sends nothing to the address the writer gave; lets no AI model, and none of the platform's assistants, read a message, and acts on nothing a message says; takes messages for an application only within the platform's daily limits, for the application and for each reply address, and none while the Customer's user has switched the application's inbox off, while the Customer's account is suspended or terminated, or from a preview of the application, keeping nothing of a message it refuses; keeps a record of each time the inbox is switched off or on, who did it and when, for as long as the application exists; and deletes each message after 90 days, and sooner when the Customer's user deletes it or the application or the account is erased (the daily counts of those messages, for each application and for each reply address, the latter identifying the address only by a hash made with a secret key, are RunMyB's own records, the substrate of its limits, Section 1); and receiving the e-mail sent to such an application's own address on the platform, made from its address on runmyb.app: RunMyB receives it through the AWS sub-processor listed in Section 4 (Amazon Simple Email Service), which scans it for viruses and spam; holds it, as it was received, in the platform's private storage only until the platform has delivered it or counted it as not delivered; delivers it only if that scan found neither, if it is within the platform's size limit and if its sender's address passes the e-mail authentication of the sender's domain, or of a domain related to it, which shows the mail service the e-mail came through, never who wrote it, and leaves the name the sender gives unchecked, and only while the Customer's user has the application's inbox switched on, while the Customer's account is neither suspended nor terminated, and within the platform's daily limits, for the application and for each sender's address; keeps, of an e-mail it delivers, in the same database and with when it arrived, the sender's address and name as the e-mail gives them, its subject, its text, as plain text with any link written out as text and cut at a set length, the list of its attached files and which of those authentications its sender's address passed, and keeps, in that private storage, only the attached files of a few kinds — PDF, PNG, JPEG, GIF, WebP and plain text — whose contents match the kind they state, and only a set number from one e-mail, never opening or running them; shows and deletes such e-mail as it does a message from the form, above, and gives a kept file to the Customer's users who can see the application only as a download, under a name the platform chooses from the kind it verified; deletes each kept file with its e-mail — after 90 days and when the Customer's user deletes that e-mail — and, when the application or the account is erased, by a separate deletion step that the platform records; keeps, of an e-mail it does not deliver, only a count for the application, by day and reason, that names no sender; sends nothing to the address an e-mail came from, not even word that it was not delivered; and lets no AI model, and none of the platform's assistants, read an e-mail or a kept file, and acts on nothing either says (the daily counts of the e-mails from each address, identifying the address only by a hash made with a secret key, are RunMyB's own records, the substrate of its limits, Section 1); providing the team workspace (admission and access control, per-member environment, attributed collaboration); e-mailing the Customer's administrators (or, for a notice about an application that only one member of the Customer's account can see in the console, that member instead), and no one outside RunMyB, the platform's notices about the account's work, whose only workspace content is the text the console names their subject by, such as a card's title (the records of those notices are RunMyB's own, Section 1); and providing the platform features the Customer invokes — including the activity narrator: the Customer instructs RunMyB to operate it for each venture where it is on (it is on unless the Customer's user turns it off on the venture's Modules card), composing a written account of that venture's work for the Customer from the venture's own records, through the AI model routing sub-processor listed in Section 4 (Privacy Policy, Section 2.2); and the avatar director: when a conversation asks the console's chat avatar to act out a short action that neither the Customer's library of learned actions nor the avatar's built-in actions answers, RunMyB sends a short description of the action through the same sub-processor to have a new animation written, checks it before it plays, and keeps it in the Customer's library of learned actions (Privacy Policy, Section 2.3); and the avatar author: when a Customer's user creates their own avatar from a description, RunMyB screens the description with the platform's automated content-safety check and, unless it is refused, sends it through the same sub-processor to have it restated as one short sentence and drawn, and keeps the drawing the user uses as the user's avatar and the drawings not yet used for the user to come back to (Privacy Policy, Section 2.4); and the field survey: before a plan, where it is on for a venture (it is on unless the Customer's user turns it off on the venture's Modules card or asks to skip it), RunMyB studies the leading public services of the product's type and any service, link, description or file the Customer's user names, captures pages of those services from their public websites, with screenshots, and keeps them and the comparison it writes with the venture (Privacy Policy, Section 2.5) — personal data about other people that the public material studied happens to carry is processed by RunMyB as an independent controller, as that section states, and is not Customer Personal Data; and the remembered language: RunMyB keeps, for each of the Customer's users, the language that user last used, as a short language code with where and when it was seen, so that the platform's assistants answer that user in it and the ideas offered to that user suit that user's market (Privacy Policy, Sections 2.6 and 2.7); and the Ideas stream: RunMyB writes ideas for products for the Customer's users, ranks them for each user by the ideas that user was shown, reacted to and launched and by the areas and the line about themselves that user may choose to add, sends a user's areas and line (or, for ideas from one of the Customer's ventures, the venture's name, one-line description and audience) through the AI model routing sub-processor listed in Section 4 to have ideas written, and keeps them with the user's reactions for the life of the account (Privacy Policy, Section 2.7) — personal data about other people that the public material an idea is written from happens to carry is processed by RunMyB as an independent controller, as that section states, and is not Customer Personal Data; and the photos: the Customer's user may add photos to one of the Customer's applications, in the console, for the application to show, once that user has confirmed, for that application, the statement the console shows — that the Customer may use the photos added there, including on the application's public site, and that everyone who can be recognised in them has agreed to appear in it (for a child, their parent or guardian has agreed) — of which RunMyB keeps the record in its own right, as its evidence of what was confirmed, as the Privacy Policy's Section 8 states; RunMyB has each photo scanned for malicious software in the platform's private storage before anything else reads it, opens a photo in which the scan finds no such software — one the scan cannot judge included — only in an isolated process within fixed limits, and prepares from its pixels alone copies in several sizes and formats for the web, without the original file and without the location, camera or other data embedded in it, keeping the original only until RunMyB's own check of the photo has passed it, or, for a photo that check holds, for as long as the hold lasts (a file in which the scan finds such software is never opened by the platform, used or shown, and is kept until the Customer's user removes it or the application is erased); uses a photo in the application, and shows it to anyone outside the Customer's account other than RunMyB's operating team, only once RunMyB's automated check of one of those copies for content the platform's rules prohibit or restrict — sexually explicit content, any sexual depiction of a person who may be a minor, and graphic violence — has passed it, a check RunMyB makes through the AI model routing sub-processor listed in Section 4 as an independent controller, for its own purpose and not on the Customer's instructions (Section 1); keeps, unused, a photo that check holds or sends to RunMyB's operating team — a photo the check held, until the Customer's user removes it or the application or the account is erased; a photo sent to RunMyB's operating team before anything is decided, and a photo RunMyB holds because of a notice or because the law requires it to preserve it, which the Customer's user cannot remove and while which neither the application nor the account can be erased, until RunMyB decides on it and for as long as the law requires, RunMyB aiming to decide on such a photo within 14 days (Privacy Policy, Section 2.8; Terms, Section 10.5); suggests a description of each photo the check has passed, for people who cannot see it, by sending one of those copies, at most 1280 pixels wide, with the application's language and the platform's instructions, through the AI model routing sub-processor listed in Section 4, each request carrying a routing instruction under which that sub-processor sends it only to a route it records as retaining no request data, the model being instructed to name no one and to guess at no one's identity, health, origin, beliefs or other sensitive trait; uses in the application only a photo whose description the Customer's user has confirmed, as suggested or as edited, or has marked as decoration, and gives the application's build those photos and descriptions, which the application then serves as part of itself; keeps the copies, the descriptions and any suggestion not yet confirmed with the application, until the Customer's user removes the photo or the application is erased; and, when the Customer's user removes a photo, deletes it from the platform's store of photos at once and removes it from the application at the application's next update, while the earlier versions of the application that RunMyB keeps — those published, kept so that the application can be restored to one of them, and those prepared for previews — and RunMyB's copy of the application's code history keep it until the application is erased, unless the Customer instructs RunMyB, on the request of a person shown in the photo, to erase it from them, which RunMyB's operating team then does, without undue delay (Section 3(a) and (e)), and the platform's backups of its file store keep a copy for 35 days (Privacy Policy, Section 2.8). In building, verifying and repairing the Customer's applications, RunMyB takes pictures of their screens — their pages at computer and phone width, the screens its checks walk through, and the design variants it offers — which may show what an application holds about its end-users, and sends them, as part of the workspace content, to the AI models that design, verify, review, repair and change the application, and to the console's assistant when the Customer's user asks it about a build, through the sub-processors listed in Section 4; for an application whose files hold photos, a request that carries, or may carry, such a picture or an image from those files also carries a routing instruction under which the AI model routing sub-processor sends it only to a route it records as retaining no request data, or goes without the picture or image (Section 4, the OpenRouter row; Privacy Policy, Section 2). From its own usage-metering records, from the ventures' records of when they were created and when their approvals were asked for and decided, and from the launches recorded in the accounts' Ideas streams, RunMyB derives, as an independent controller, the ranges of cost and time and the counts of launches shown on idea cards — aggregates over at least five launches (three for a count) that name no Customer, user or venture, as the Privacy Policy's Sections 2 and 2.7 state. RunMyB has each file one of the Customer's applications stores for its end-users — those they upload and those the application creates — scanned for malicious software soon after it is stored, through the AWS sub-processor listed in Section 4 (Amazon GuardDuty), which reads the file in the platform's own storage, in the United States, and deletes its copy once the scan is done; keeps the scan's verdict with the file, on the file and in the platform's record of it, and deletes it with them; serves a file until the scan has judged it, and serves unscanned a file the scan cannot judge, such as one protected with a password, telling the Customer's administrators once for each application, without naming any file, that the application stores such files, unless they have turned that notice off (Terms, Section 4); where a scan could not be completed, has the file scanned again, at most three times and at least twenty minutes apart, the application being told meanwhile that the file is still being checked, and then serves it unscanned if it still has not been judged; and withholds a file in which the scan finds such software, under Section 15, item 8 of the Terms — keeping it, deleting nothing because of the scan, giving the application no further access to it and e-mailing the Customer's administrators the statement of reasons unless the law requires, or a public authority asks, RunMyB to delay it — until RunMyB's operating team, which may examine the file to review the decision, deletes it or releases it; the team deletes it when the Customer asks for that, or for the application or the account to be erased — an erasure that waits until the file is deleted — unless Section 15, item 4 of the Terms or a legal demand to preserve it requires RunMyB to keep it, for as long as the law requires. The record GuardDuty keeps of a file it finds malicious — which stored file, and what it found — is one of RunMyB's security and operational records (Section 1), and GuardDuty keeps it for 90 days. RunMyB does not use Customer Personal Data for advertising and does not itself train machine-learning models on it, and does not permit its sub-processors to do so on its behalf (Section 7).
Categories of data subjects. The Customer's end-users, the people who write to its applications through their contact forms or by e-mail to their own addresses among them; the people shown in the material the Customer adds to its applications, such as the photos its users add to them (Privacy Policy, Section 2.8); the Customer's team members (employees, contractors, collaborators); and, before acceptance, the third parties whose e-mail addresses the Customer's administrators invite.
Categories of personal data. (a) For end-user data: whatever personal data the Customer's applications are designed to process — determined and controlled by the Customer, including end-user account data where the Customer's application operates its own accounts, the address of each message of its own that the application has the platform send and the values it supplies for it, the data it hands the platform for a run of one of its background jobs — kept in the platform's own database, provided through the AWS sub-processor listed in Section 4, only as long as this Section's nature and purpose states — the messages people write in its contact form, with the address each writer gave for a reply and the name they gave, if any, and the e-mail people send to its own address, with the address it came from, the sender's name, its subject and the list of its attached files — kept in the same database, as this Section's nature and purpose states, and included in the account's data export (Section 3(e)) — the files of the kinds the platform keeps that are attached to such an e-mail — kept in the platform's private storage, provided through the AWS sub-processor listed in Section 4, as this Section's nature and purpose states, and not included in that export (Section 3(g)) — and, where its end-users sign in with a sign-in provider the platform offers for it — today Google or GitHub — the identity that provider returns for them — its signed identity token where it issues one, and the identifier at that provider, name, e-mail address and whether the provider verified it, picture — which RunMyB relays to the application without keeping it (never the provider's access token, which RunMyB uses, where needed, alone and in transit, and keeps nowhere, and no refresh token); where the application has a database, that data lives in the product's own isolated database (the per-product isolation measure in Section 6, provided through the Neon sub-processor listed in Section 4), and the files the application keeps — those its end-users upload and those it creates — live in the product's own storage area in a private storage bucket the platform keeps for the hosted products' files, in the United States (the per-product separation measure in Section 6, provided through the AWS sub-processor listed in Section 4). (b) For team-member data: membership records (role, status, display name, inviter, timestamps); invitation records (invited e-mail address, role offered, expiry — invitation tokens are stored hash-only, and expired or revoked invitation records are purged after a short fixed period); per-member environment and preferences; the language each user last used, as a short language code with where and when it was seen (Privacy Policy, Section 2.6); each user's idea interests and reactions — the ideas the user was shown, reacted to and launched, the areas and the line about themselves the user chose to add, and the ideas written for the user (Privacy Policy, Section 2.7); authorship attribution in the Customer's shared conversation records; the content of the Customer's shared conversation turns, as processed for the activity narrator (Privacy Policy, Section 2.2); venture assignments; member-to-member messages within the workspace, and each user's answers by e-mail to the platform's notices, which the platform keeps as messages to that user (Privacy Policy, Section 2); the Customer's library of learned avatar actions — the short descriptions of the actions asked of the avatar in its users' conversations, the animations written for them, and which user asked for and kept each one, by the user's sign-in identifier (Privacy Policy, Section 2.3); and each user's chosen avatar and the characters chosen for the Customer's agents — the platform's assistant and the other agents that work in the Customer's account — for each, a gallery identifier, whose avatar it is, and which user chose it, by the user's sign-in identifier, and when (Privacy Policy, Section 3.1); and each user's avatars created from a description — the description the user writes, as sent to be drawn (it is not kept with the avatars; the only copy kept is in the record of the platform's content-safety check, one of the platform's own security and operational records under Section 1, retained as the Privacy Policy's Sections 8 and 9 state), the one-sentence restatement the platform wrote, the drawing, which model drew it, which earlier drawing it was changed from, whose it is, by the user's sign-in identifier, and when — and the user's drawings not yet used (Privacy Policy, Section 2.4). (c) For the people shown in the material the Customer adds to its applications: their images in the photos the Customer's users add to an application, the copies the platform prepares from those photos — without the original files and the data embedded in them — and the descriptions of the photos, as the platform suggests them and as the Customer's user confirms them, kept on the platform's own storage, provided through the AWS sub-processor listed in Section 4, as this Section's nature and purpose states (Privacy Policy, Section 2.8).
Special categories of data. None are required or requested by the platform. Special-category data is present only if the Customer chooses to put it there, and the Customer is responsible for ensuring a lawful basis for it. A photo the Customer adds may reveal such data about a person shown in it — about their health or beliefs, for example; RunMyB does not use the photos to recognise or identify anyone, and does not use them to infer such data about a person; the description it suggests is instructed to state none, and its own check of each photo (Section 1) assesses the photo as a whole — including whether a person in it may be a minor and whether it is sexual — only to decide whether the photo may be used in the application, and records a label about the photo, never a trait of a person; no decision about the people shown follows from it.

3. Processor obligations (Article 28(3) GDPR)

RunMyB will:

(a) Documented instructions. Process Customer Personal Data only on the Customer's documented instructions, including with regard to international transfers. The Terms, this DPA, and the Customer's configuration and use of the platform's features and settings constitute the complete documented instructions. RunMyB will inform the Customer if, in its opinion, an instruction infringes the GDPR or other applicable data-protection law, and may suspend the instruction until it is confirmed or withdrawn.
(b) Confidentiality. Ensure that the persons authorised to process Customer Personal Data — limited to RunMyB's operating team — are bound by confidentiality obligations.
(c) Security. Implement and maintain the technical and organisational measures described in Section 6, taking into account the state of the art, the costs of implementation, and the nature, scope, context, and purposes of processing (Article 32 GDPR).
(d) Sub-processing. Engage sub-processors only under Section 4.
(e) Data-subject-request assistance. Assist the Customer, insofar as possible, in fulfilling its obligation to respond to data-subject requests. The platform's built-in machinery is the primary form of this assistance: the self-service data-export flow produces a structured bundle of an account's data, with a manifest that lists every store the platform keeps and, for each store the bundle does not include, why; the in-platform data-request flow records access, portability, and erasure requests and tracks the statutory response clock; and each team member can export the data held about them through the same self-service flow. Requests that concern a member's personal data inside the Customer's shared records are directed to the Customer as controller, and RunMyB assists the Customer through the export and erasure machinery. If a data subject contacts RunMyB directly about processing under this DPA, RunMyB will redirect the request to the Customer and will not respond on the merits except on the Customer's instruction or where required by law. This redirection applies only to processing under this DPA: for the categories where RunMyB is an independent controller (Section 1, capacity 1 and the boundary paragraph — for example login identity, acceptance records, security logs, and the aggregate statistics described in the Privacy Policy), RunMyB answers data subjects directly.
(f) Breach notification and Articles 32–36 assistance. Notify the Customer without undue delay after becoming aware of a personal data breach affecting Customer Personal Data — and in any case early enough for the Customer to meet its own 72-hour obligation under Article 33 GDPR; RunMyB's working target is notification within 48 hours, stated as an aim — providing the information reasonably available at that time (nature of the breach, categories and approximate volumes affected, likely consequences, measures taken or proposed) and supplementing it as investigation proceeds. RunMyB maintains a structured incident register that tracks each incident against the 72-hour clock of Article 33 GDPR, so the Customer's own notification window is preserved. RunMyB will further assist the Customer, taking into account the nature of the processing and the information available to it, with data-protection impact assessments and prior consultations under Articles 35–36. Notification of a breach is not an acknowledgement of fault or liability.
(g) Deletion and return. At the end of the services, at the Customer's choice, delete or return Customer Personal Data. The account offboarding flow queues the deletion with a grace window stated when the request is filed (during which the deletion may be called off and the account reinstated on the Customer's request, through the account surface where it remains accessible or through the platform's contact points); the platform's map-driven, tiered erasure engine then deletes content, while the narrow set of records RunMyB must retain to comply with applicable law (billing, ledger, and acceptance evidence) is retained in pseudonymised, access-restricted form for the legally required period (Article 17(3) GDPR) and deleted thereafter. Return is available through the self-service data export before the deletion request is filed, and on request during the grace window. The data that one of the Customer's applications keeps in its own database or in its files (Section 2, categories of personal data (a)) is not in that export: it is returned on the Customer's request — made through the platform's contact points (for example privacy@runmyb.com) before the deletion request is filed or during the grace window — as a copy of that database that RunMyB's operating team makes with PostgreSQL's standard tools and delivers to the Customer within 30 days of the request, together with a copy of those files — other than a file withheld under Section 15, item 8 of the Terms, or one in which the scan for malicious software (Section 2) has found such software — and a manifest that lists them and names each file left out; that database, and the storage area that holds those files, are deleted only after the copy is delivered. The copy is made by RunMyB's operating team within the platform's cloud infrastructure (AWS) in the United States (Section 5), held there encrypted only until it is delivered to the Customer, and then deleted; it is sent to no sub-processor other than those listed in Section 4. The files attached to e-mail sent to the Customer's applications that the platform keeps (Section 2) are in neither that export nor that copy: the Customer's users who can see an application can download them in the console while they are kept.
(h) Audit and information. Make available the information necessary to demonstrate compliance with Article 28 and allow for and contribute to audits. Audits proceed reports-first: RunMyB provides written descriptions of its controls (Section 6) and responds to reasonable written security questionnaires, no more than once annually. Where that information is demonstrably insufficient for the Customer's compliance needs or a supervisory authority requires it, the Customer may conduct (itself or through an independent auditor that is not RunMyB's competitor) an audit of the relevant processing: at most once per year, on reasonable advance notice, during business hours, under confidentiality, at the Customer's cost, and scoped so as not to endanger other customers' data or the platform's security. RunMyB does not hold third-party certifications such as SOC 2 or ISO 27001, and none are implied; audit rights under the Standard Contractual Clauses, where they apply, remain unaffected.

4. Sub-processors

Authorization and the published list. The Customer grants RunMyB general written authorization to engage the sub-processors below. Each is engaged under the provider's standard data-protection terms, which impose data-protection obligations consistent with this DPA; RunMyB remains liable to the Customer for its sub-processors' performance. The table in this document is the published sub-processor list:

Sub-processor	Function	Notes
Amazon Web Services (AWS)	Cloud infrastructure and hosting	Compute, storage, database, and networking for the hosted platform, the scan for malicious software of the files the Customer's applications keep and of the photos its users add to them (Amazon GuardDuty), and the sending of the platform's e-mail and the receiving, with its scan for viruses and spam, of the e-mail sent to the Customer's applications' own addresses and to the reply addresses of the platform's notices (Amazon Simple Email Service)
Anthropic PBC	AI model provider	Runs the AI assistants and build agents that process workspace content, for every platform role configured to use it; where a role is configured to route through OpenRouter instead — today among them the automated content-safety checks the Privacy Policy's Section 9 describes — the OpenRouter row states how the provider that serves it is chosen, and names today's providers for the models the platform configures
Neon, Inc.	Hosted-product databases	An isolated, dedicated Postgres database (one Neon project per product) for each data-bearing Customer product, holding that product's data, including any personal data the product processes (US region)
Stripe, Inc.	Payments and billing	Partially an independent controller for payment data (card data is collected and held by Stripe, not RunMyB)
Cloudflare, Inc.	DNS and edge services	Domain name resolution and edge delivery; no workspace content, except the voice assistant's test sessions of RunMyB's own administrators through a Cloudflare tunnel
ElevenLabs (Eleven Labs Inc.)	Speech-to-text for voice dictation; speech engine and voice for the voice assistant	For dictation: engaged only when the Customer's user uses the voice-dictation feature with an ElevenLabs engine; audio is sent under RunMyB's own account and key, and the browser never holds that key; the platform's own handling of the audio is transient (Privacy Policy, Section 6). For the voice assistant: engaged only when the Customer's user opens a spoken conversation with the platform's assistant while the platform has the ElevenLabs engine configured for it; the user's browser sends the audio directly to ElevenLabs' speech engine over a connection the platform sets up for that session under RunMyB's own account and key — the browser never holds the key, only an address valid for that session — and the speech engine sends the platform the transcript of what the user said, never the audio, the platform asking it on every session not to record the audio and to retain the conversation's transcript for zero days; the platform sends ElevenLabs' voice model the text the assistant speaks (including workspace content) and relays the voice it returns to the user's browser as it plays, without storing it (Privacy Policy, Section 6.1)
OpenAI (OpenAI OpCo, LLC)	Speech model for the voice assistant	Engaged only when the Customer's user opens a spoken conversation with the platform's assistant while the platform has the OpenAI engine configured for it (the default), or while the platform has the ElevenLabs engine configured for it and that engine cannot serve the user's session when the session starts — such a session runs on the OpenAI engine until it ends; the user's browser exchanges audio directly with OpenAI over an encrypted connection the platform sets up under RunMyB's own account and key — the browser never holds the key; OpenAI also automatically sends the platform, over the platform's own control connection to the session, a copy of the session's audio (the user's microphone input and the assistant's spoken replies), which the platform receives only transiently in working memory and discards without it being decoded — it is not analysed, stored, logged, recorded or forwarded; the platform sends OpenAI the text the assistant speaks (including workspace content) and receives the transcripts, kept as the conversation's records; OpenAI's session storage is switched off for every session (Privacy Policy, Section 6.1); OpenAI also serves, as OpenRouter's own provider, the avatar author, the phrasing of the voice assistant's notes on its ElevenLabs engine and the other platform roles configured to one of OpenAI's models, the console's chat assistants among them — those routes are OpenRouter's, not RunMyB's own OpenAI account (the OpenRouter row)
OpenRouter, Inc.	AI model routing	Engaged for platform-side engine tasks where a platform role is configured to route through it — among them the activity narrator and the avatar director, for each of which OpenRouter routes each request to the provider of the model configured for that role, Google LLC today, which serves that role's model as OpenRouter's own provider (Privacy Policy, Sections 2.2 and 2.3), the check of each photo a Customer's user adds to one of the Customer's applications, which RunMyB makes as an independent controller (Section 1; Privacy Policy, Sections 2.8 and 9), for which OpenRouter routes each request — one prepared copy of the photo, at most 1280 pixels wide and without its location, camera or other embedded data, which may show people, with the platform's instructions for the check — to the one provider the platform names for the classifier model it asks, Microsoft Corporation (its Azure service) today for OpenAI's model, which the platform asks first, in the European Union where the platform names Azure's endpoint there and otherwise wherever Azure serves the request, which may be the United States, and Deep Infra Inc. today for the classifier models of other makers that the platform asks next, in a fixed order, when that one cannot answer, each serving that model as OpenRouter's own provider, each request carrying a routing instruction that allows that one provider only, only where OpenRouter records it as neither using request data for training nor retaining it, and never another provider in its place, the other automated content-safety checks the Privacy Policy's Section 9 describes, for which OpenRouter routes each check's request — the text the check examines (for the check of a public web address a user chooses for a product, that address and, where the user gave one, the user's own description of what the product is), with the platform's instructions for it — to the provider of the model configured for the checks, Google LLC today, which serves that model as OpenRouter's own provider, each request carrying a routing instruction that allows that one provider only, only where OpenRouter records it as neither using request data for training nor retaining it, and never another provider in its place, the voice assistant's reaction model on its ElevenLabs engine, Jev, for which OpenRouter routes each request — the words the speech engine transcribed, the assistant's last reply, the conversation's language, whether a change awaits confirmation and the words set aside in the last few seconds — to TypeSafe AI, Inc. today, which serves Jev as OpenRouter's own provider, each request carrying a routing instruction that allows that one provider only, only where OpenRouter records it as not using request data for training, and never another provider in its place (Privacy Policy, Section 6.1), the avatar author and the phrasing of the voice assistant's notes on its ElevenLabs engine — the platform's own notes, which may carry the user's display name and the values of a change, and the conversation's language, never the transcript — for each of which OpenRouter routes each request to the provider of the model configured for that role, OpenAI (OpenAI OpCo, LLC) today, which serves that model as OpenRouter's own provider under OpenAI's terms with OpenRouter, or — where OpenRouter routes a request to another provider of that model, for example when OpenAI's own service is unavailable — Microsoft Corporation (its Azure service) or Amazon Web Services, Inc. (its Amazon Bedrock service) today, each under its own terms with OpenRouter, each request carrying a routing instruction that excludes providers whose terms allow the use of request data for model improvement (Privacy Policy, Sections 2.4 and 6.1), and every other platform role so routed — among them the build roles, the console's chat assistants, the roles that research the market and plan a product, the idea author (Privacy Policy, Section 2.7) and the photo describer, whose requests carry one prepared copy of a photo the Customer's user added to one of the Customer's applications — at most 1280 pixels wide and without its location, camera or other embedded data, which may show people — with the application's language and the platform's instructions, which also carry a routing instruction under which OpenRouter sends them only to a route it records as retaining no request data (Privacy Policy, Section 2.8) — for which OpenRouter routes each request to a provider of the model configured for that role, or chosen for a conversation, which serves it as OpenRouter's own provider under its own terms with OpenRouter, each request carrying a routing instruction that excludes providers whose terms allow the use of request data for model improvement, and each request that concerns an application whose files hold photos and carries, or may carry, a picture the platform took of that application or an image from its files also carrying a routing instruction under which OpenRouter sends it only to a route it records as retaining no request data, the picture or image being left out where the model has no such route or the request cannot carry that instruction (Section 2; Privacy Policy, Section 2): for OpenAI's models, today, OpenAI (OpenAI OpCo, LLC), Microsoft Corporation (its Azure service) or Amazon Web Services, Inc. (its Amazon Bedrock service); for Google's Gemini model, today, Google LLC; for DeepSeek's model, which platform roles, among them the build roles, the general worker and the development executor (`build-ui`, `build-core`, `worker` and `dev-executor` on the account's Models card), may be configured to, a provider of that model that OpenRouter chooses among those whose published data policy, as OpenRouter records it, does not use request data for training — for example Deep Infra Inc., Parasail, Inc. or the provider OpenRouter lists as InferenceNet — the routing instruction excluding DeepSeek's own endpoint while OpenRouter records its policy as allowing the use of request data for training (DeepSeek's published privacy policy states that it uses the personal data it collects to train and improve its models); the requests routed to DeepSeek's model carry no instruction that requires a zero-data-retention policy, except as this row states for a request that concerns an application whose files hold photos and as Section 7 states for the data received through the Customer's Google connections — and, from 2026-09-15 until 2026-10-18, the build roles' requests carried no such routing instruction, RunMyB's OpenRouter account permitted routing to providers whose terms allow the use of request data for model improvement and OpenRouter was instructed to prefer DeepSeek's own endpoint (Hangzhou DeepSeek Artificial Intelligence Co., Ltd.), so that the Customer's build content routed in that period was disclosed to DeepSeek or, where that endpoint could not serve, to another of OpenRouter's providers for that model, as Section 7 records; for SpaceXAI's Grok model, which platform roles, among them the general worker and the development executor (`worker` and `dev-executor` on the account's Models card), may be configured to, SpaceXAI LLC (xAI) or Amazon Web Services, Inc. (its Amazon Bedrock service), each request also carrying a routing instruction under which OpenRouter sends it only to a route it records as retaining no request data — SpaceXAI's zero-data-retention service, or Amazon Bedrock; for Anthropic's Claude models, Anthropic PBC or another of OpenRouter's providers for those models; and, for a model of another maker that the Customer's user chooses for a conversation, or that the Customer's administrators configure for a role on the account's Models card, a provider of that model (the model by the Customer's own choice, the provider by OpenRouter's routing) that RunMyB does not name in advance — and, when the Customer's user selects the Microsoft engine for voice dictation, to route the recording to Microsoft's MAI-Transcribe model; OpenRouter is the sub-processor for each such task, the model's provider is OpenRouter's own provider for it (Microsoft Corporation for that engine), and RunMyB has no account and no contract with Google, DeepSeek, Microsoft, TypeSafe, SpaceXAI or any other provider OpenRouter routes to, other than Anthropic, OpenAI and AWS, whose own agreements with RunMyB (their rows) do not cover any route through OpenRouter
Zoho Corporation	E-mail correspondence	Mailboxes for the platform's support, privacy, and legal contact addresses (EU data centre)

Changes to the list. RunMyB will give at least 30 days' advance notice of the addition or replacement of a sub-processor by updating the published list in this document and recording the change in this document's changelog, which is the notice mechanism. In addition, each such change is also notified by e-mail to the Customer's administrators when it is published, as a platform notice — a notice from RunMyB that the platform e-mails to the administrators of every account and that no account setting turns off while the account exists; the e-mail adds to the notice mechanism and does not replace it. The Customer may object on reasonable data-protection grounds within 14 days of the notice; the parties will then discuss in good faith. If the objection cannot be resolved, the Customer's remedy is to stop using the affected feature or terminate the affected service or account before the change takes effect; continued use after the change takes effect constitutes acceptance of the new sub-processor.

Services the Customer connects are not sub-processors. Services that the Customer connects to its account under the Customer's own credentials or authorization — git providers, Google Drive, Gmail, and Google Calendar via the Customer's OAuth grant, Trello, Notion, and AI providers used under the Customer's own keys — are recipients chosen and instructed by the Customer, not RunMyB sub-processors. RunMyB transmits data to them only at the Customer's direction, within the scope the Customer authorized; the Customer's own relationship and terms with each such service govern that processing. The same holds for a sign-in provider the platform offers for the Customer's applications — today Google or GitHub — with which the Customer registers its own sign-in app for an application (Section 2): RunMyB presents the Customer's own sign-in app credentials to the provider on the application's behalf, within that registration, and relays the identity the provider returns to the application without keeping it; the end-user's account with the provider is the end-user's own relationship with it, and the Customer's own terms with the provider govern the Customer's app. The team feature introduces no additional sub-processor: team-member data rides the same infrastructure listed above.

5. International transfers

Processing takes place in the United States: the platform's cloud infrastructure (AWS), the hosted-product databases (Neon), the AI providers (Anthropic, OpenRouter, OpenAI), and the payment processing (Stripe) all process there. ElevenLabs, the voice-dictation engine and the engine of the voice assistant where it serves the session, transfers personal data to the United States for storage and publishes hosting locations in the United States, the Netherlands, and Singapore; the Clauses below cover its processing wherever it takes place. E-mail correspondence is hosted in the EU: Zoho hosts the platform's mailboxes in an EU data centre (with the Clauses below covering any extra-EEA access). DeepSeek, the provider preferred for the build roles while their exception ran, from 2026-09-15 until 2026-10-18 (Section 4, the OpenRouter row), states in its published privacy policy that it stores data in the People's Republic of China; the leg to it was OpenRouter's onward transfer (below). The providers for DeepSeek's model (Section 4, the OpenRouter row) are headquartered where OpenRouter records them — in the United States for Deep Infra Inc. and Parasail, Inc., for example; the leg to them is OpenRouter's onward transfer (below). TypeSafe AI, Inc., OpenRouter's onward provider for the voice assistant's reaction model, states that its services are hosted in the United States; the leg to it is OpenRouter's onward transfer (below). For the check of the photos the Customer's users add to its applications (Section 4, the OpenRouter row), Microsoft's Azure service processes the request in the European Union where the platform names Azure's endpoint there, and otherwise wherever Azure serves it, which may be the United States, and Deep Infra Inc. is headquartered in the United States as OpenRouter records it; the leg to each is OpenRouter's onward transfer (below). SpaceXAI LLC, OpenRouter's onward provider for SpaceXAI's Grok model, which platform roles, among them the general worker and the development executor, may be configured to (Section 4, the OpenRouter row), states that it may process personal data on a global basis, including in the United States; the leg to it is OpenRouter's onward transfer (below). For personal data subject to the GDPR, the UK GDPR, or the Swiss FADP, transfers to RunMyB and onward to its sub-processors are protected as follows:

Standard Contractual Clauses. The 2021 EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914) are incorporated into this DPA by reference: Module Two (controller-to-processor) where the Customer is a controller, and Module Three (processor-to-processor) where the Customer acts as a processor for its own client — together with the UK Addendum and the Swiss amendments where those regimes apply. Sections 2 and 6 of this DPA serve as the processing and security annexes.
Data Privacy Framework. Transfers to sub-processors certified under the EU–US Data Privacy Framework — AWS, Stripe, Cloudflare, and ElevenLabs — additionally rest on that certification, with the Standard Contractual Clauses in each provider's terms as the contractual fallback.
SCCs only. Transfers to Anthropic, OpenRouter, OpenAI, Neon, and Zoho rest on the Standard Contractual Clauses incorporated in those providers' data-protection terms. For OpenAI the instrument is OpenAI's Data Processing Addendum, which OpenAI's API terms apply to every API customer and which incorporates the Clauses (Module Two where the Customer is a controller, Module Three where it is a processor) together with the UK Addendum; OpenAI is not a Data Privacy Framework participant, so no transfer to it rests on that framework. For OpenRouter the instrument is OpenRouter's Data Processing Agreement, which OpenRouter's Terms of Service incorporate by reference for organisations and for commercial use of its service and which incorporates the Clauses (Module Two, with the UK Addendum and the Swiss amendments); OpenRouter is not a Data Privacy Framework participant, so no transfer to it rests on that framework. Where ElevenLabs processes voice-dictation audio, or a voice session's audio and the text of the assistant's replies, outside the United States, the transfer rests on the Standard Contractual Clauses incorporated in ElevenLabs' Data Processing Addendum (with the UK Addendum where it applies). Voice-dictation audio that OpenRouter routes to Microsoft's MAI-Transcribe model is an onward transfer under OpenRouter's terms; Microsoft Corporation is itself certified under the EU–US Data Privacy Framework. The activity narrator's and the avatar director's requests, and the requests of the platform's automated content-safety checks, that OpenRouter routes to Google's Gemini model (Privacy Policy, Sections 2.2, 2.3 and 9) are likewise an onward transfer under OpenRouter's terms; Google LLC is itself certified under the EU–US Data Privacy Framework, with its UK and Swiss extensions, and the Standard Contractual Clauses named in Google's published data-processing terms are the contractual fallback. The requests of the voice assistant's reaction model, Jev, that OpenRouter routes to TypeSafe AI, Inc. (Privacy Policy, Section 6.1) are likewise an onward transfer under OpenRouter's terms with TypeSafe, which RunMyB does not hold; TypeSafe states that its services are hosted in the United States, and its published Data Processing Addendum incorporates the Clauses (Module Two, and Module Three where its customer acts as a processor) with the UK Addendum; TypeSafe AI, Inc. is not a participant in the EU–US Data Privacy Framework, so no part of that transfer rests on it. The avatar author's requests, and the requests that put the voice assistant's notes into the assistant's words, that OpenRouter routes to OpenAI's model (Privacy Policy, Sections 2.4 and 6.1) are likewise an onward transfer under OpenRouter's terms with OpenAI, which RunMyB does not hold; OpenAI states that its Data Processing Addendum, which incorporates the Clauses, applies to every customer of its API — on this route, OpenRouter — and, as stated above, OpenAI is not a Data Privacy Framework participant, so no part of that transfer rests on that framework. Where OpenRouter routes such a request to Microsoft's Azure service or to Amazon Web Services' Amazon Bedrock service instead, that too is an onward transfer under OpenRouter's terms with that provider, which RunMyB does not hold; Microsoft Corporation, as stated above, is itself certified under the EU–US Data Privacy Framework, and Amazon Web Services, Inc. is covered by the certification of Amazon.com, Inc. under that framework. The requests of the check of the photos the Customer's users add to its applications that OpenRouter routes to Microsoft's Azure service or to Deep Infra Inc. (Section 4, the OpenRouter row) are likewise an onward transfer under OpenRouter's terms with that provider, which RunMyB does not hold and which the Clauses incorporated in OpenRouter's Data Processing Agreement (Module Two, Clause 9) oblige OpenRouter to make under equivalent protections; Microsoft Corporation, as stated above, is itself certified under the EU–US Data Privacy Framework, and Deep Infra Inc. is not a participant, so no part of the transfer to it rests on that framework. Every other request that OpenRouter routes for a platform role or for a conversation (Section 4, the OpenRouter row) is likewise an onward transfer under OpenRouter's terms with the provider that serves it, which RunMyB does not hold; where that provider is Anthropic PBC, OpenAI, Microsoft Corporation, Amazon Web Services, Inc. or Google LLC, what is stated above for that provider applies to it. The requests that OpenRouter routes to SpaceXAI's Grok model, which platform roles, among them the general worker and the development executor, may be configured to (Section 4, the OpenRouter row), are such an onward transfer, under OpenRouter's terms with SpaceXAI LLC, which RunMyB does not hold; SpaceXAI's published Data Processing Addendum incorporates the Clauses (Module Two, or Module Three where its customer acts as a processor) with the UK Addendum and the Swiss amendments; SpaceXAI LLC is not a participant in the EU–US Data Privacy Framework, so no part of that transfer rests on it. The requests that OpenRouter routes to DeepSeek's model (Section 4, the OpenRouter row) are likewise an onward transfer under OpenRouter's terms with the provider that serves them, which RunMyB does not hold — a provider of that model that OpenRouter chooses among those whose published data policy, as OpenRouter records it, does not use request data for training, headquartered where OpenRouter records it, in the United States for Deep Infra Inc. and Parasail, Inc., for example; RunMyB claims no certification under the EU–US Data Privacy Framework for any provider so chosen (neither Deep Infra Inc. nor Parasail, Inc. is a participant), so no part of that transfer rests on it. From 2026-09-15 until 2026-10-18, the build agents' requests left RunMyB for OpenRouter under OpenRouter's Standard Contractual Clauses, and the onward leg from OpenRouter to the provider that served them — DeepSeek, preferred, or another of OpenRouter's providers for the model — was governed by OpenRouter's terms with that provider, which RunMyB does not hold; DeepSeek states in its published privacy policy that it stores data in the People's Republic of China and names no transfer instrument there, and the EU–US Data Privacy Framework is open to United States organisations only, so no transfer to DeepSeek rested on it.

6. Technical and organisational measures

RunMyB implements the following measures for Customer Personal Data:

Tenant isolation. Per-tenant row-level-security isolation enforced at the database layer on the control plane's tenant-scoped tables, with the platform's own registers (tables owned and written by the platform rather than scoped to a tenant) protected by role-scoped database grants instead. A separate, isolated database per data-bearing Customer product. A separate storage area per product for the files it keeps: the hosted products hold no credentials for that storage and open a stored file only through a time-limited link signed by the platform's file gateway, which signs links for a product to its own files alone. The files a product keeps are not backed up: a file the product deletes, or that is deleted under Section 15 of the Terms or at the product's or the account's erasure, cannot be restored. A product's background jobs are kept apart as its database and its files are: every run, and the data handed for it, is keyed on that product's identity as the platform itself records it — never one the product names; the platform calls only that product's own address for a run, and gives a run's data only to that product. A message written in a product's contact form is kept apart in the same way: it is keyed on that product's identity as the platform itself records it, never one the message names, and the console shows it only to the Customer's users who can see that product. An e-mail sent to a product's own address is delivered only to the product whose address it was sent to, as the platform's own records of the hosted products and of their addresses on runmyb.app resolve it, and the files kept from it are stored under that product's own part of the platform's private storage for received e-mail, which only the console and the platform's recorded deletion step reach, and which is not backed up: a kept file deleted with its e-mail cannot be restored.
Stored files scanned for malicious software. Each file a Customer's application stores is scanned soon after it is stored, within the platform's own cloud account and region, by Amazon GuardDuty under a role that reaches that storage alone; from the scan's verdict the storage itself refuses every download link to a file found to contain malicious software, and the platform withholds the file (Section 2); none of the platform's own services can change a file's verdict; and no file is deleted automatically because of the scan.
Encryption. TLS for data in transit; managed-cloud encryption at rest; and an encrypted-at-rest credential vault with application-layer encryption for Customer secrets and connection tokens, with write-only intake and by-name references so that secret values do not appear in logs, prompts, or URLs.
Voice-session audio. On the voice assistant's OpenAI engine, the copy of a voice session's audio that the speech-model sub-processor sends over the platform's control connection to the session is received only transiently in working memory and discarded without being decoded; it is never stored, logged or recorded (the Privacy Policy's Section 6.1 states the one use of the assistant's own voice the platform may begin, and its conditions). On its ElevenLabs engine, the user's audio passes from the browser to ElevenLabs and never reaches the platform; the assistant's voice is relayed by the platform to the user's own browser over a separate, access-controlled connection as it plays, and is never stored, logged or recorded; words set aside as meant for someone else in the room are never stored. On either engine, the platform's event stream to the user's browser carries no audio.
Photos the Customer adds. Each photo is scanned for malicious software before anything else reads it, is opened only in an isolated process within fixed limits of time and memory, and is published only as copies prepared from its pixels alone, so that no original file, and no location, camera or other data embedded in it, is published; the original is kept only until RunMyB's check of the photo has passed it, or with a hold, and a file in which the scan finds such software is kept, never opened by the platform, until it is removed or the application is erased; a photo is used in the application only once that check has passed it; the photos and their descriptions are kept per application, under the tenant isolation above.
Messages to the Customer's applications. A message written in an application's contact form, or e-mailed to its own address, is shown only as plain text, with any link shown as text and never opened by the platform; the database roles through which the platform's assistants read data hold no access to the messages, and no AI model receives one; the platform sends nothing to the address a writer gave; and each message is deleted after 90 days. An e-mail is delivered only after the AWS sub-processor's scan has found neither a virus nor spam in it and its sender's address has passed the e-mail authentication of its domain, or of a domain related to it; as it was received, it is held in private storage, encrypted at rest, only until it is delivered or counted as not delivered; an attached file is kept only when it is of one of a few kinds and its contents match the kind it states, is never opened or run by the platform, and reaches the Customer's users only as a download through the console, under a name the platform chooses from the kind it verified and with headers that tell the browser to save it rather than open it; and the platform sends no reply, and no notice that an e-mail was not delivered, to anyone who writes.
Access control. Edge authentication on the hosted console (managed identity provider with fail-closed session verification); access to Customer Personal Data limited to RunMyB's operating team on a need-to-know basis.
Least-privilege egress. Deny-by-default outbound network controls for build and agent sandboxes; outbound calls to connected services pass through enforced, host-restricted chokepoints; the sign-in relay calls only the provider addresses the platform itself pins, never an address an application or the Customer supplies, follows no redirect, and, where the provider issues a signed identity token, verifies it before relaying it; the Customer's sign-in app secret is held in the platform's custody, encrypted at rest, read by the relay alone and never given to the application.
Integrity and accountability. Append-only acceptance, audit, safety-decision, and ledger records; structured incident tracking against the 72-hour clock of Article 33 GDPR.
Data-subject-rights capability. Self-service data export and the in-platform data-request flow; map-driven, tiered erasure across every registered data store, with the legal-retention carve-out applied in pseudonymised form.
Backups. Automated backups of the platform's durable stores: the managed control-plane database is encrypted at rest and its automated backups inherit that encryption; the platform's own file store — not the storage area that holds the files a product keeps (tenant isolation, above) — rides daily automated backups with a bounded retention window, and the infrastructure gate refuses a change that would disable them.
Infrastructure change control. Cloud infrastructure changes are applied through a gated, policy-checked deployment process — a codified policy check runs against every planned change before it is applied — and releases are versioned and recorded. Cloud IAM follows least-privilege: platform roles carry narrow, named grants rather than administrative access.

RunMyB reviews and updates these measures as the platform evolves; changes will not materially reduce the overall level of protection.

7. No use of Customer Data for AI/ML training

Stated in its own clause so it is findable: RunMyB does not use Customer Personal Data — or Customer content more broadly — to create, train, or improve any machine-learning or artificial-intelligence model, whether RunMyB's own or a third party's, and does not permit its sub-processors to do so on RunMyB's behalf. Every request RunMyB sends through OpenRouter on its own account, for every platform role, carries a routing instruction that excludes providers whose terms allow the use of request data for model improvement (Section 4, the OpenRouter row). An AI provider the Customer uses under its own key is a recipient the Customer chooses, not a sub-processor of RunMyB (Section 4). This clause restates, in one place, what Section 2 of this DPA and Section 10 of the Terms of Service & Acceptable Use provide about RunMyB's own use; it does not change without the Customer's express opt-in. Data received through the Customer's Google connections (the Privacy Policy, Sections 5.2 and 5.3) is sent to an AI model only in a request RunMyB sends on its own account, under the routing instruction above, a provider's own terms that exclude training or the setting of RunMyB's account with the provider that excludes it (the Privacy Policy, Section 6), never on an AI key of the Customer's — what an application the Customer builds carries in its own code and prompts being the Customer's product content — never to DeepSeek's own service, and to a model made by DeepSeek only as served by a provider other than DeepSeek under the routing instruction above, a further instruction that excludes DeepSeek as a provider and a further instruction under which OpenRouter sends the request only to an endpoint that it lists as having a zero-data-retention policy (the Privacy Policy, Section 5.3), and is sent to a model for no platform purpose other than the features that need it. This narrowing of the clause is published on 2026-10-28 with the edition of the Privacy Policy that requires the Customer's renewed acceptance (7.0), which is the express opt-in this clause requires.

The build roles' exception, ended. From 2026-09-15 until 2026-10-18, the platform's build roles (build-ui and build-core on the account's Models card) were the one exception to this commitment: the Customer's build content — the accepted specification and the artifacts the build reads, the product's code in the venture workspace, the venture's knowledge pages, lessons and library index as the build reads them, and the owner's own words and corrections the build agents are given — was routed through OpenRouter, under a setting of RunMyB's OpenRouter account that permitted routing to providers whose terms allow the use of request data for model improvement, to a provider of the configured model, OpenRouter being instructed to prefer the model's own first-party endpoint, DeepSeek (Hangzhou DeepSeek Artificial Intelligence Co., Ltd.), whose published privacy policy states that it uses the personal data it collects to train and improve its models and that it stores data in the People's Republic of China; where that endpoint could not serve, another of OpenRouter's providers for that model served the request (Section 5 for the transfer). The build content routed in that period was therefore disclosed to DeepSeek, or to such another provider, under its own published terms; RunMyB has no contract with DeepSeek or with any such provider. The exception was published on 2026-09-17 in this clause, with the edition of the Privacy Policy that required the Customer's renewed acceptance (5.0), which was the express opt-in this clause then required from that publication on; nothing here claims an opt-in for the days before it. It ended on 2026-10-18, when RunMyB's OpenRouter account stopped permitting routing to such providers; the build roles' requests now carry the routing instruction above, as every other request on that account does.

8. Liability

Each party's liability arising out of or related to this DPA, including under the Standard Contractual Clauses, is subject to the exclusions and limitations of liability set out in the Terms of Service & Acceptable Use, except where the Standard Contractual Clauses or applicable data-protection law provide otherwise. Nothing in this DPA or the Terms limits either party's liability toward data subjects or supervisory authorities where such liability cannot lawfully be limited.

9. Precedence and duration

This DPA forms part of the Terms. In the event of a conflict concerning the processing of personal data, this DPA prevails over the Terms, and the Standard Contractual Clauses prevail over this DPA for the transfers they govern. This DPA takes effect with the Terms and remains in force for as long as RunMyB processes Customer Personal Data, surviving termination of the Terms until that processing ends under Section 3(g).

Version history (the document's changelog)

1.0 — initial draft outline. 2.0 — the operative tenant-facing DPA replacing the 1.0 outline: full Article 28(3) obligation set, processing details, published sub-processor list with change-notice and objection mechanics, technical and organisational measures annex, SCC/DPF transfer terms; the employee/team-member (third-hat) rider folded in; final in-force edition (0529). 2.1 — corrections and strengthenings (non-material for the Customer; effective on posting): Neon, Inc. added to the Section 4 sub-processor table — this corrects an omission: the vendor was already in use for hosted-product databases and should have been listed when that feature went live; the Section 4 notice-and-objection machinery applies to this addition from this posting; the Section 5 processing-locations statement corrected to name locations truthfully and to cover Neon (SCCs); the Section 6 tenant-isolation measure restated accurately (RLS on tenant-scoped tables, role-scoped grants on platform-owned registers) and the annex extended with the verifiable backup, IAM, and change-control measures; Section 3(f)'s self-imposed 48-hour figure re-expressed as a stated aim inside the without-undue-delay duty, with the Customer's 72-hour window expressly protected; Section 4 commits to additional e-mail notice of sub-processor changes once the platform operates its transactional mailer; Section 3(e) carves out the categories where RunMyB is independent controller; the no-AI-training commitment promoted into its own headed clause (Section 7). 2.2 — SUB-PROCESSOR CHANGE under Section 4 (non-material for the Customer as a document change), published on 2026-09-11 and effective the same day: Google LLC (voice-dictation transcription relay) is REMOVED from the Section 4 table — the Google-based dictation relay is retired; ElevenLabs (Eleven Labs Inc.) is ADDED as the speech-to-text provider for the voice-dictation feature (the after-you-stop mode when the Customer's user selects that engine, and the live mode), engaged under RunMyB's own account and key, with the account's use of submitted content for model improvement switched off; OpenRouter, Inc.'s function is WIDENED from auxiliary AI model routing to also route voice-dictation audio to Microsoft's MAI-Transcribe model when the user selects that engine — OpenRouter is the sub-processor for that engine, Microsoft Corporation is OpenRouter's own provider for it, and RunMyB has no account and no contract with Microsoft. Section 5 places ElevenLabs in the Data Privacy Framework group in Google's stead, names the Standard Contractual Clauses in ElevenLabs' Data Processing Addendum as the basis for any of its processing outside the United States, and states the Microsoft onward transfer under OpenRouter's terms. The Section 4 notice period (30 days) and objection window (14 days) were waived for this change on 2026-09-11 by the platform's sole Customer, its operator; no other Customer existed on that date, so no Customer's notice or objection right was shortened by this change taking effect on posting. The Section 4 mechanism itself is unchanged and applies in full to every future addition or replacement of a sub-processor. What is otherwise unchanged: the voice-dictation feature remains optional and off unless used; the platform keeps no audio beyond the transient handling the Privacy Policy's Section 6 describes; Section 7 (no use of Customer Data for AI/ML training) is unchanged and continues to bind RunMyB, which engages each sub-processor under that provider's data-protection terms. 2.3 — SUB-PROCESSOR CHANGE under Section 4 (non-material for the Customer as a document change), published on 2026-09-12 and effective the same day: OpenAI (OpenAI OpCo, LLC) is ADDED to the Section 4 table as the provider of the speech model behind the platform's voice assistant — an optional spoken conversation the Customer's user opens deliberately; engaged under RunMyB's own account and key, with the user's browser exchanging audio directly with OpenAI over an encrypted connection the platform sets up (the browser never holds the key, and no audio passes through the platform); the platform sends OpenAI the text the assistant speaks and receives the transcripts, which it keeps as the conversation's records; OpenAI's session storage is switched off for every session; OpenAI's own terms state that it does not use API content to develop, improve or train its models unless the customer explicitly agrees, and RunMyB has not agreed and will not. Section 5 adds OpenAI to the processing-in-the-United-States sentence and to the Standard-Contractual-Clauses group, naming OpenAI's Data Processing Addendum (Modules Two and Three with the UK Addendum) as the instrument; OpenAI is not a Data Privacy Framework participant. The Section 4 notice period (30 days) and objection window (14 days) were waived for this change on 2026-09-12 by the platform's sole Customer, its operator; no other Customer existed on that date, so no Customer's notice or objection right was shortened by this change taking effect on posting. The Section 4 mechanism itself is unchanged and applies in full to every future addition or replacement of a sub-processor. What is otherwise unchanged: the voice features remain optional and off unless used; the platform keeps no audio in any mode beyond the transient dictation handling the Privacy Policy's Section 6 describes; Section 7 (no use of Customer Data for AI/ML training) is unchanged and continues to bind RunMyB. 2.4 — SUB-PROCESSOR CHANGE under Section 4 AND a narrowing of Section 7, published on 2026-09-17 and effective the same day (the Section 7 change is put to the Customer for renewed acceptance through Privacy Policy 5.0, which is MATERIAL): (a) OpenRouter, Inc.'s function is WIDENED to name the onward provider for the platform-side engine tasks it routes — for the activity narrator, the module that composes a written account of a venture's work for the Customer from the venture's own records (on for every venture unless the Customer's user turns it off on the venture's Modules card), the model's provider is Google LLC, which serves the narrator's configured model as OpenRouter's own provider; OpenRouter is the sub-processor, engaged under RunMyB's own account and key, RunMyB has no account and no contract with Google for it, and what leaves the platform for the narrator is a digest of the venture's records, cleaned by shape before sending (web addresses, identifiers and hashes, dollar figures and qualified model names removed; file paths shortened to their last parts; money, model, identifier and token-count fields dropped from structured records; every text field bounded — a name, an address or a secret typed into a message is not recognised by those checks), together with bounded, cleaned excerpts of the venture's conversations with the platform's assistant — the turns of the Customer's users, whoever authored them, and the assistant's replies — never a whole conversation; RunMyB's OpenRouter account permits routing to providers whose terms allow the use of request data for model improvement (a setting kept for other platform roles), and the narrator's requests carry a routing instruction that excludes such providers, so that only a provider whose published policy states that request data is not used for training may serve them (Privacy Policy, Section 2.2); (b) for the build roles (build-ui and build-core), OpenRouter routes the build agents' requests to a provider of the configured model, preferring DeepSeek's own first-party endpoint (Hangzhou DeepSeek Artificial Intelligence Co., Ltd.), whose published privacy policy states that it uses the personal data it collects to train and improve its models; where that endpoint cannot serve, another of OpenRouter's providers for the model may serve the request — a provider RunMyB does not name in advance — and RunMyB's OpenRouter account is set to permit routing to providers whose terms allow the use of request data for model improvement; RunMyB has no account and no contract with DeepSeek or any such provider; that routing has run since 2026-09-15 under the account setting and is disclosed by this entry on 2026-09-17 — the Customer's renewed acceptance of Privacy Policy 5.0 is the express opt-in Section 7 requires from that disclosure on, and nothing here claims an opt-in for the days before it; the Anthropic PBC row is corrected to the roles configured to use it. Section 2 states the narrator's operation as the Customer's instruction among the purposes of processing, adds the content of the Customer's shared conversation turns, as processed for the narrator, to the categories of personal data, and points its training sentence at Section 7. Section 5 states the onward transfers under OpenRouter's terms: to Google (Google LLC's Data Privacy Framework certification, with the Standard Contractual Clauses in Google's published terms as the fallback) and, for the build agents' requests, what is held: RunMyB's transfer to OpenRouter under OpenRouter's Standard Contractual Clauses; the onward leg under OpenRouter's terms with its provider, which RunMyB does not hold; DeepSeek's stated storage in the People's Republic of China with no transfer instrument named; the Data Privacy Framework open to US organisations only — with the People's Republic of China named among the processing locations. Section 7 is NARROWED by an express exception for the build roles — the routing to DeepSeek described above, stated with how the Customer may end it (no per-venture switch exists; the account's Models card, or a written instruction to RunMyB) — a change to an in-force Customer commitment, published with Privacy Policy 5.0, whose renewed acceptance is the express opt-in Section 7 requires. The Section 4 notice period (30 days) and objection window (14 days) were waived for this posting on 2026-09-17 by the platform's sole Customer, its operator; no other Customer existed on that date, so no Customer's notice or objection right was shortened by this change taking effect on posting. The Section 4 mechanism itself is unchanged and applies in full to every future addition or replacement of a sub-processor. What is otherwise unchanged: the voice features remain optional and off unless used; the platform keeps no audio in any mode beyond the transient dictation handling the Privacy Policy's Section 6 describes; RunMyB engages each sub-processor under that provider's data-protection terms. 2.5 — NON-MATERIAL clarification (effective on posting, 2026-09-17): Section 5 names the instrument for the transfer to OpenRouter — OpenRouter's Data Processing Agreement, which OpenRouter's Terms of Service incorporate by reference for organisations and for commercial use of its service and which incorporates the Clauses (Module Two, with the UK Addendum and the Swiss amendments) — and states that OpenRouter is not a Data Privacy Framework participant (the public registry, read 2026-09-17). No sub-processor is added or replaced, so Section 4 is not engaged; nothing else changes. 2.6 — a correction (NON-MATERIAL for the Customer; effective on posting, 2026-09-26): the Section 4 OpenAI row said that during a voice session no audio passes through the platform, which never holds it. That was inaccurate from the entry that added OpenAI (2.3) on: OpenAI's service automatically sends the platform, over the platform's own control connection to the session, a copy of the session's audio — the Customer's user's microphone input, whether or not the assistant is listening at that moment, and the assistant's spoken replies — and offers no setting that switches it off. The platform's handling of that copy has been the same since the first voice session: received only transiently in working memory and discarded without being decoded — never analysed, stored, logged, recorded or forwarded. The row is corrected to say so; Section 6 gains a matching measure (voice-session audio), which adds a restriction on RunMyB and reduces none; the Privacy Policy's Section 6.1 (edition 5.2) states the same, together with the conditions under which the platform may begin to use the assistant's own voice — never the user's — to time the speech of its on-screen face. No sub-processor is added or replaced and OpenAI's function is unchanged, so Section 4's notice-and-objection mechanism is not engaged; Section 7 is unchanged. The statements in the 2.3 and 2.4 entries that the platform keeps no audio in any mode beyond the transient dictation handling remain true of what is kept — nothing of the voice-session copy is kept — but the voice-session copy is also handled transiently, as this entry records; those entries are left as written. 2.7 — a disclosure (NON-MATERIAL for the Customer; effective on posting, 2026-09-27): the avatar director is stated in Section 2 among the platform features the Customer invokes. When a conversation asks the console's chat avatar to act out a short action that neither the Customer's library of learned actions nor the avatar's built-in actions answers, RunMyB sends a request through the AI model routing sub-processor listed in Section 4 to have a new animation written, checks the animation before it plays, and keeps it in the Customer's library of learned actions, shared by the Customer's users and showing which user asked for and kept each action by the user's sign-in identifier (today the e-mail address the user signs in with, or the identifier the sign-in provider supplies instead), until a user drops it (which deletes it from the library; the action as it played remains in the conversation's records), the platform discards it because it no longer passes the platform's checks, or the account is erased; there is no setting that turns the director off — it runs only when a conversation asks the avatar for an action that nothing learned or built-in answers. What leaves the platform for each attempt (at most three for one request) is the short description of the action — reduced to lower-case letters, digits and spaces and limited in length; it may carry words from a user's message — an optional short mood phrase, treated the same way, a description of what the avatar can do, the short descriptions of the actions the Customer has kept and of the built-in actions, and, on a repeated attempt, the director's previous answer with the reasons it was refused; never the user's message itself, the rest of the conversation or the user's account details. The director's requests carry the same routing instruction as the activity narrator's, so that only a provider whose published policy states that request data is not used for training may serve them (Privacy Policy, Section 2.3). Section 2 adds the library of learned actions to the categories of personal data. Section 4's OpenRouter row names the avatar director beside the activity narrator, with Google LLC as the model's provider today, as for the narrator; Section 5's onward-transfer sentence covers the director's requests. No sub-processor is added or replaced and no new onward provider is named — Google LLC is already named as OpenRouter's provider for the activity narrator — so Section 4's notice-and-objection mechanism is not engaged; Section 7 is unchanged and binds this processing. 2.8 — a disclosure (NON-MATERIAL for the Customer; effective on posting, 2026-09-27): Section 2's categories of team-member personal data add each user's chosen avatar and the characters chosen for the Customer's agents — the platform's assistant and the other agents that work in the Customer's account. A user may choose, in the account settings, a character from the platform's gallery to stand for them in the Customer's workspace; it is shown to the Customer's other active users, and a disabled user's choice is retained but no longer shown. An administrator of the Customer may choose a character for each of the Customer's agents, shown to every user. For each, the record holds a gallery identifier, whose avatar it is, and which user chose it, by the user's sign-in identifier, and when; choosing another character replaces the record, choosing the default deletes it, and the records are erased with the account (Privacy Policy, Sections 3.1, 3.4 and 8). No sub-processor is added or replaced: the records are held on the hosting infrastructure listed in Section 4 like all other team-member data and are sent to no provider, so Section 4's notice-and-objection mechanism is not engaged; Section 7 is unchanged. The Privacy Policy's edition 5.4 makes the matching disclosure. 2.9 — SUB-PROCESSOR CHANGE under Section 4 (non-material for the Customer as a document change), published on 2026-09-28 and effective the same day: OpenRouter, Inc.'s function is WIDENED to route a new platform role, the avatar author, and OpenAI (OpenAI OpCo, LLC) is named as OpenRouter's onward provider for it, and Microsoft Corporation (its Azure service) and Amazon Web Services, Inc. (its Amazon Bedrock service) as the other providers of the same model to which OpenRouter may route a request, for example when OpenAI's own service is unavailable, if the provider meets the routing instruction below — each an onward provider for a new purpose. OpenAI is already a sub-processor in its own right for the voice assistant, under RunMyB's own account and key; for the avatar author OpenAI serves OpenRouter under OpenAI's terms with OpenRouter, and RunMyB's own agreement with OpenAI does not cover that route. Likewise, Amazon Web Services is already a sub-processor in its own right for the platform's hosting, and Microsoft Corporation is already OpenRouter's provider for the Microsoft voice-dictation engine; for the avatar author each serves OpenRouter under its own terms with OpenRouter, RunMyB's own agreement with Amazon Web Services does not cover that route, and RunMyB has no contract with Microsoft. The avatar author is stated in Section 2 among the platform features the Customer invokes: when a Customer's user creates their own avatar from a description, RunMyB first screens the description (and any change the user asks for) with the platform's automated content-safety check and, unless it is refused, sends it through the AI model routing sub-processor to have it restated as one short sentence and drawn in the same request — at most three attempts for one drawing, a repeated attempt carrying the author's previous answer and the reasons it was refused; for a change the request carries the user's instruction with the drawing and the sentence being changed, for another try the sentence the platform wrote, and to offer ideas nothing the user wrote — only the language of the user's browser and the platform's own instructions, with a random value that varies the ideas from day to day; never the user's name, e-mail address or other account details. The author's requests carry the same routing instruction as the activity narrator's and the avatar director's, so that only a provider whose published policy states that request data is not used for training may serve them (Privacy Policy, Section 2.4). RunMyB keeps, for each drawing, the platform's sentence, the drawing as the platform's checks accepted it, which model drew it, which earlier drawing it was changed from, and whose it is, by the user's sign-in identifier, and when — never the user's description, whose only kept copy is in the record of the content-safety check; the drawing the user uses becomes the user's avatar, shown to the Customer's other active users with its sentence, and replaces the previous one, which is deleted together with the drawings not used; a drawing not used is deleted when the user creates again once it is more than a day old, no more than ten being kept; the rest is kept until the user replaces or deletes it or the account is erased. Section 2 adds the user's created avatars and unused drawings, and the descriptions as sent to be drawn, to the categories of personal data, stating that the only kept copy of a description is in the record of the platform's content-safety check, one of the platform's own security and operational records under Section 1, retained as the Privacy Policy's Sections 8 and 9 state. Section 4's OpenRouter row names the avatar author with OpenAI as the model's provider today and Microsoft Corporation and Amazon Web Services, Inc. as the other providers OpenRouter may route it to, and the OpenAI row points to it; Section 4's Anthropic PBC row states that Anthropic today also runs the platform's automated content-safety checks, which receive the text they check — already true of the checks on build requests, and now stated; no sub-processor is added or replaced by that statement; Section 5 states the onward transfers to OpenAI, Microsoft Corporation and Amazon Web Services, Inc. under OpenRouter's terms. The Section 4 notice period (30 days) and objection window (14 days) were waived for this change on 2026-09-28 by the platform's sole Customer, its operator; no other Customer existed on that date, so no Customer's notice or objection right was shortened by this change taking effect on posting. The Section 4 mechanism itself is unchanged and applies in full to every future addition or replacement of a sub-processor. What is otherwise unchanged: creating an avatar is optional and nothing is sent for it unless the Customer's user opens the place where avatars are created; Section 7 (no use of Customer Data for AI/ML training) is unchanged and binds this processing. The Privacy Policy's edition 5.5 makes the matching disclosure. 2.10 — SUB-PROCESSOR CHANGE under Section 4 (non-material for the Customer as a document change), published on 2026-10-03 and effective the same day: (the platform's configuration had already named the new route before this posting; its call records show no check's request served through it before the posting) the processing of the automated content-safety checks the Privacy Policy's Section 9 describes — the screening of the Customer's users' build requests, of imported content, and of the descriptions and changes a user writes for an avatar (Privacy Policy, Section 9) — moves from Anthropic PBC to OpenRouter, Inc.: OpenRouter's function is WIDENED to route the checks' requests, and Google LLC is named as OpenRouter's onward provider for them — an onward provider already named for the activity narrator and the avatar director, now for a new purpose — so the sub-processor that receives the checked text is replaced for that purpose. RunMyB has no account and no contract with Google for it. Each check's request carries the text it checks with the platform's instructions for the check — never the user's name, e-mail address or the account's identifiers — and a routing instruction that allows that one provider only, only where OpenRouter records it as neither using request data for training nor retaining it, and never another provider in its place; if that provider cannot serve, no other provider receives the text and the check is treated as needing review. Section 4's Anthropic PBC row no longer states that Anthropic runs the checks and names them, as the automated content-safety checks the Privacy Policy's Section 9 describes, among the roles routed through OpenRouter; Anthropic remains a sub-processor for every platform role configured to use it. Section 4's OpenRouter row names them in the same words, with Google LLC as their provider today and their routing instruction; Section 5's onward-transfer sentence for the requests OpenRouter routes to Google covers the checks' requests. The checks the Privacy Policy's Section 9 describes include, as that section now discloses (correcting an omission), the screening of a public web address a user chooses for a product before that address is reserved, whose request carries the address and, where the user gave one, the user's own description of what the product is; that check is routed as the other checks are, and Section 4's OpenRouter row says what its request carries. The Section 4 notice period (30 days) and objection window (14 days) were waived for this change on 2026-10-03 by the platform's sole Customer, its operator; no other Customer existed on that date, so no Customer's notice or objection right was shortened by this change taking effect on posting. The Section 4 mechanism itself is unchanged and applies in full to every future addition or replacement of a sub-processor. What is otherwise unchanged: what the checks record and for how long (the record is one of the platform's own security and operational records under Section 1, retained as the Privacy Policy's Sections 8 and 9 state); Section 7 (no use of Customer Data for AI/ML training) is unchanged and binds this processing. The Privacy Policy's edition 5.7 makes the matching disclosure. 2.11 — SUB-PROCESSOR CHANGE under Section 4 (non-material for the Customer as a document change), published on 2026-10-07 and effective the same day: the voice assistant may run on a second engine, which the platform's administrators choose for the platform — never the Customer's user — beside the speech model OpenAI provides, which stays the default. (a) ElevenLabs (Eleven Labs Inc.)'s function is WIDENED from speech-to-text for voice dictation to the speech engine and voice of the voice assistant when that engine is configured: the user's browser sends the audio directly to ElevenLabs' speech engine, which transcribes it, detects the end of each turn and sends the platform the text, over a connection the platform sets up for each session under RunMyB's own account and key, the platform asking for no recording of the audio and for the conversation's transcript to be retained for zero days; ElevenLabs' voice model turns the text of the assistant's replies, which the platform sends it — workspace content included — into the assistant's voice, which the platform relays to the user's browser as it plays, without storing it. (b) OpenRouter, Inc.'s function is WIDENED to route the voice assistant's reaction model on that engine, Jev, and TypeSafe AI, Inc. is named as OpenRouter's onward provider for it — a new onward provider. For each turn the platform sends the words the speech engine transcribed, the assistant's last reply, the conversation's language, whether a change awaits confirmation and the words set aside in the last few seconds, so that Jev chooses the assistant's short reaction, names the language and judges whether the thought is complete and whether the words were meant for the assistant. Each request carries a routing instruction that allows that one provider only, only where OpenRouter records it as not using request data for training, and never another provider in its place. Words judged meant for someone else are not stored. RunMyB has no account and no contract with TypeSafe. (c) OpenRouter, Inc.'s function is also WIDENED to route, on that engine, the model that puts the platform's own notes into the assistant's words — the greeting, which carries the user's display name, and notes such as a card awaiting confirmation with the values of the change, a result, a fault or the end of the session — a model the platform configures for the whole platform, which receives each note and the conversation's language, never the transcript; OpenAI (OpenAI OpCo, LLC) serves that model today, or — where OpenRouter routes a request to another provider of that model — Microsoft Corporation (its Azure service) or Amazon Web Services, Inc. (its Amazon Bedrock service), all three already OpenRouter's onward providers for the avatar author and now engaged for this new purpose, each request carrying a routing instruction that excludes providers whose terms allow the use of request data for model improvement. Section 4's Cloudflare row names the voice assistant's test sessions of RunMyB's own administrators through a Cloudflare tunnel as an exception to its "no workspace content"; Section 4's ElevenLabs row states the widened function, the OpenAI row is scoped to the OpenAI engine and names the phrasing of the assistant's notes among the routes it serves as OpenRouter's provider, and the OpenRouter row names Jev with TypeSafe AI, Inc. as its provider today and the phrasing of the assistant's notes with the avatar author's providers. Section 5 states that ElevenLabs' processing of a voice session's audio and of the text of the assistant's replies outside the United States rests on the Clauses in ElevenLabs' Data Processing Addendum, and states the onward transfers under OpenRouter's terms to TypeSafe and, for the phrasing of the assistant's notes, to the avatar author's providers; Section 6's voice-session audio measure gains the ElevenLabs engine. Before this posting the ElevenLabs engine served only voice sessions opened by the platform's administrators. The Section 4 notice period (30 days) and objection window (14 days) were waived for this change on 2026-10-07 by the platform's sole Customer, its operator; no other Customer existed on that date, so no Customer's notice or objection right was shortened by this change taking effect on posting. The Section 4 mechanism itself is unchanged and applies in full to every future addition or replacement of a sub-processor. What is otherwise unchanged: the voice features remain optional and off unless used; Section 7 (no use of Customer Data for AI/ML training) is unchanged and binds this processing; the activity narrator's kept history of its earlier notes and finished items, which the Privacy Policy's edition 5.8 discloses, is held on the hosting infrastructure listed in Section 4 and engages no provider, so it needs no change here. The Privacy Policy's edition 5.8 makes the matching disclosure. 2.12 — a disclosure (NON-MATERIAL for the Customer; effective on posting, 2026-10-07): Section 4's OpenAI row states that OpenAI, whose speech model is the voice assistant's default engine, is also engaged for a session of the Customer's user that the voice assistant's ElevenLabs engine, where the platform has configured it, cannot serve when the session starts; such a session runs on the OpenAI engine until it ends, and what Sections 4, 5 and 6 state of that engine applies to it. Section 5 names ElevenLabs as the engine of the voice assistant where it serves the session. No sub-processor is added or replaced and OpenAI's function is unchanged, so the Section 4 notice mechanism is not engaged; for certainty, the Section 4 notice period (30 days) and objection window (14 days) were nonetheless waived for this change by the platform's sole Customer, its operator, on 2026-10-07; no other Customer existed on 2026-10-07, so no Customer's notice or objection right was shortened by this change taking effect on posting. The Section 4 mechanism itself is unchanged and applies in full to every future addition or replacement of a sub-processor. The Privacy Policy's edition 5.9 makes the matching disclosure. 2.13 — two disclosures (NON-MATERIAL for the Customer; effective on posting, 2026-10-10): Section 2's nature and purpose add the field survey — before a plan, where it is on for a venture, RunMyB studies the leading public services of the product's type and any service, link, description or file the Customer's user names, captures pages of those services from their public websites, with screenshots, and keeps them and the comparison it writes with the venture — and state that personal data about other people that the public material studied happens to carry is processed by RunMyB as an independent controller, as the Privacy Policy's Section 2.5 states, and is not Customer Personal Data; and they add the remembered language — for each of the Customer's users, the language that user last used, as a short language code with where and when it was seen, so that the platform's assistants answer that user in it — which Section 2's categories of team-member personal data now list. The study's requests go to the AI providers already listed in Section 4 for the platform's roles, and the language code travels only with the instructions of their models; no sub-processor is added or replaced and no sub-processor's function changes, so the Section 4 notice mechanism is not engaged; for certainty, the Section 4 notice period (30 days) and objection window (14 days) were nonetheless waived for this change by the platform's sole Customer, its operator, on 2026-10-10; no other Customer existed on 2026-10-10, so no Customer's notice or objection right was shortened by this change taking effect on posting. The Section 4 mechanism itself is unchanged and applies in full to every future addition or replacement of a sub-processor. The Privacy Policy's edition 6.0 makes the matching disclosures. 2.14 — SUB-PROCESSOR CHANGES under Section 4 (non-material for the Customer as a document change), published on 2026-10-12 and effective the same day. (a) OpenRouter, Inc.'s function is stated for every platform role configured to route through it beyond the roles Section 4 names one by one — among them the console's chat assistants and the roles that research the market and plan a product: OpenRouter routes each request to a provider of the model configured for that role, or chosen for a conversation, which serves it as OpenRouter's own provider under its own terms with OpenRouter, each request carrying a routing instruction that excludes providers whose terms allow the use of request data for model improvement; the providers today are named by the model's maker — OpenAI (OpenAI OpCo, LLC), Microsoft Corporation (its Azure service) or Amazon Web Services, Inc. (its Amazon Bedrock service) for OpenAI's models, Google LLC for its Gemini model, and Anthropic PBC or another of OpenRouter's providers for Anthropic's Claude models — and, for a model of another maker that the Customer's user chooses for a conversation or that the Customer's administrators configure for a role, a provider of that model, chosen by OpenRouter's routing, that RunMyB does not name in advance. (b) SpaceXAI LLC (xAI) is named as OpenRouter's onward provider for SpaceXAI's Grok model, which the general worker and the development executor are configured to today, with Amazon Web Services, Inc. (its Amazon Bedrock service) where OpenRouter routes a request to it instead, each such request sent only to a route OpenRouter records as retaining no request data — SpaceXAI's zero-data-retention service, or Amazon Bedrock; SpaceXAI is a new onward provider; SpaceXAI states that it may process personal data on a global basis, including in the United States, and its published Data Processing Addendum incorporates the Clauses. The platform's configuration named SpaceXAI's model for those two roles before this edition posted, and the hosted platform's call records show no request served through it before the posting. (c) The console's chat assistants have run only on models reached through OpenRouter since the platform's console moved to its current engine, which serves no other kind (on the hosted platform, from 2026-09-09), where before they ran on models Anthropic PBC runs; their default today is one of OpenAI's models. The processing of the chat's content thereby moved from Anthropic PBC to OpenRouter and its providers for the models configured or chosen for the chat — today those named in (a) — a change made before this entry recorded it. Section 4's Anthropic row now says that the OpenRouter row states how the provider that serves such a role is chosen and names today's providers for the models the platform configures, where it said that the OpenRouter row names the provider that serves it, which was not true of the roles (a) covers; the OpenAI row names the other roles OpenAI serves as OpenRouter's provider; the OpenRouter row states (a) and (b); Section 5 states SpaceXAI's processing locations and that every other request OpenRouter routes is an onward transfer under OpenRouter's terms with the provider that serves it, with SpaceXAI's transfer basis. Section 7 (no use of Customer Data for AI/ML training) is unchanged and binds this processing: the routing instruction in (a) and (b) applies to every such request on RunMyB's account. For certainty, the Section 4 notice period (30 days) and objection window (14 days) were waived for these changes by the platform's sole Customer, its operator, on 2026-10-12; no other Customer existed on 2026-10-12, so no Customer's notice or objection right was shortened by these changes taking effect on posting. The Section 4 mechanism itself is unchanged and applies in full to every future addition or replacement of a sub-processor. The Privacy Policy's edition 6.1 makes the matching disclosures. Also in 2.14, the Ideas stream — SUB-PROCESSOR CHANGES under Section 4: OpenRouter, Inc.'s function is widened to a new platform role, the idea author, which writes ideas for products for the Customer's users and from the Customer's ventures (Privacy Policy, Section 2.7); OpenRouter routes each of its requests to a provider of the model configured for it, as the OpenRouter row states for every other platform role so routed, each request carrying the routing instruction that excludes providers whose terms allow the use of request data for model improvement, and the onward providers the row names for that model's maker are engaged for this new purpose. Section 2's nature and purpose add the Ideas stream — RunMyB writes ideas for products for the Customer's users and ranks them for each user by the ideas that user was shown, reacted to and launched and by the areas and the line about themselves that user may choose to add, sends a user's areas and line, or the name, one-line description and audience of one of the Customer's ventures, through that sub-processor to have ideas written, and keeps them with the user's reactions for the life of the account — and state that personal data about other people that the public material an idea is written from happens to carry is processed by RunMyB as an independent controller and is not Customer Personal Data; the remembered language's purpose adds that the ideas offered to a user suit that user's market; Section 2's categories of team-member personal data add each user's idea interests and reactions; Section 2 states that RunMyB derives the cost and time ranges and the launch counts shown on idea cards from its own metering records, the ventures' approval timings and the recorded launches as an independent controller, over at least five launches (three for a count), naming no Customer, user or venture; and the OpenRouter row names the idea author among the other platform roles it routes. Section 7 (no use of Customer Data for AI/ML training) is unchanged and binds this processing. For certainty, the Section 4 notice period (30 days) and objection window (14 days) were waived for this change too by the platform's sole Customer, its operator, on 2026-10-12. 2.15 — a correction (NON-MATERIAL for the Customer; effective on posting, 2026-10-16): Section 3(e) now says that the self-service data-export flow produces a structured bundle of an account's data, with a manifest that lists every store the platform keeps and, for each store the bundle does not include, why, where it said that the flow produces a complete, structured bundle of an account's data; records about an account that no bundle selects stay outside it. RunMyB's obligation to assist the Customer with data-subject requests, and the rest of Section 3(e), are unchanged. No sub-processor is added or replaced and no sub-processor's function changes, so the Section 4 notice mechanism is not engaged; for certainty, the Section 4 notice period (30 days) and objection window (14 days) were nonetheless waived for this change by the platform's sole Customer, its operator, on 2026-10-16; no other Customer existed on 2026-10-16, so no Customer's notice or objection right was shortened by this change taking effect on posting. The Section 4 mechanism itself is unchanged and applies in full to every future addition or replacement of a sub-processor. The Privacy Policy's edition 6.2 makes the matching correction. Also in 2.15, a clarification (NON-MATERIAL for the Customer; effective on posting, 2026-10-16): Section 1's capacity 1 now states that the records the platform keeps of visits to the Customer's hosted products — its load balancer's request logs and its audience beacon's records, with the statistics counted from them — are RunMyB's own processing as an independent controller, as the Privacy Policy's Section 4 describes, and not Customer Personal Data; Section 3(e) already named the security logs and the aggregate statistics among the categories for which RunMyB answers data subjects directly. No sub-processor is added or replaced, so the Section 4 notice mechanism is not engaged. The Privacy Policy's edition 6.2 makes the matching correction of its Section 4. 2.16 — a correction (NON-MATERIAL for the Customer; effective on posting, 2026-10-17): Section 3(g) now says that the data one of the Customer's applications keeps in its own database is not in the self-service data export and is returned on the Customer's request — made through the platform's contact points before the deletion request is filed or during the grace window — as a copy of that database that RunMyB's operating team makes with PostgreSQL's standard tools and delivers to the Customer within 30 days of the request, and that database is deleted only after the copy is delivered; the copy is made by RunMyB's operating team within the platform's cloud infrastructure (AWS) in the United States, held there encrypted only until it is delivered and then deleted, and sent to no sub-processor other than those listed in Section 4 — new restrictions on RunMyB; Section 3(g) said that return is available through the self-service data export before the deletion request is filed, and that export has never included an application's own database. Return of everything the self-service data export does carry is unchanged, as are RunMyB's obligation to delete or return Customer Personal Data at the Customer's choice and the rest of Section 3(g). No sub-processor is added or replaced and no sub-processor's function changes, so the Section 4 notice mechanism is not engaged; for certainty, the Section 4 notice period (30 days) and objection window (14 days) were nonetheless waived for this change by the platform's sole Customer, its operator, on 2026-10-17; no other Customer existed on 2026-10-17, so no Customer's notice or objection right was shortened by this change taking effect on posting. The Section 4 mechanism itself is unchanged and applies in full to every future addition or replacement of a sub-processor. The Privacy Policy and the Terms of Service & Acceptable Use are unchanged. 2.17 — a disclosure and a clarification (NON-MATERIAL for the Customer: it describes two new records and where they sit, reduces no right and adds no obligation; effective on posting, 2026-10-18): Section 1's capacity 1 now states that the records that keep the e-mail the platform sends for the Customer's applications within its limits — for each address, a daily count of the address-verification and password-reset messages sent to it for each application and for all applications together, and a record that the address is paused after repeated bounces, each identifying the address only by a hash made with a secret key — are RunMyB's own processing as an independent controller, as the Privacy Policy's Section 2 describes, and not Customer Personal Data. Section 2's statement of nature and purpose names the sending of those messages on the Customer's application's request, which the platform has performed since the feature went live. No sub-processor is added or replaced and no sub-processor's function changes, so the Section 4 notice mechanism is not engaged; for certainty, the Section 4 notice period (30 days) and objection window (14 days) were nonetheless waived for this change by the platform's sole Customer, its operator, on 2026-10-18; no other Customer existed on 2026-10-18, so no Customer's notice or objection right was shortened by this change taking effect on posting. The Section 4 mechanism itself is unchanged and applies in full to every future addition or replacement of a sub-processor. Section 4's sub-processor row for AWS names the sending of the platform's e-mail through Amazon Simple Email Service: a description of an existing sub-processor's function, which the platform already uses, not a new or changed sub-processor, so the change notice is not engaged. The Privacy Policy's edition 6.3 makes the matching disclosure; the Terms of Service & Acceptable Use's edition 5.3 corrects an unrelated cross-reference in its Section 10.2. 2.18 — a SUB-PROCESSOR CHANGE under Section 4 (non-material for the Customer as a document change) AND the end of Section 7's exception (a change in the Customer's favour, so no renewed acceptance is required), published on 2026-10-19 and effective the same day. (a) Section 7 no longer carries the exception for the build roles (build-ui and build-core): it ended on 2026-10-18, when RunMyB's OpenRouter account stopped permitting routing to providers whose terms allow the use of request data for model improvement, and the build roles' requests now carry, like every request RunMyB sends through OpenRouter on its own account, a routing instruction that excludes such providers; Section 7 states the commitment without exception, states that an AI provider the Customer uses under its own key is a recipient the Customer chooses and not a sub-processor of RunMyB, and records the exception as it stood from 2026-09-15 to 2026-10-18: the build content routed in that period was disclosed to DeepSeek (Hangzhou DeepSeek Artificial Intelligence Co., Ltd.), whose published privacy policy states that it uses the personal data it collects to train and improve its models and that it stores data in the People's Republic of China, or, where its endpoint could not serve, to another of OpenRouter's providers for that model. (b) OpenRouter, Inc.'s function is unchanged; its row lists the build roles among the other platform roles it routes and names, for DeepSeek's model, which platform roles, among them the build roles, the general worker and the development executor (worker and dev-executor), may be configured to, today's providers — Deep Infra Inc. or Parasail, Inc., each serving as OpenRouter's own provider under its own terms with OpenRouter and named here for the first time, such providers having served the build roles before as providers RunMyB did not name in advance — with the routing instruction excluding DeepSeek's own endpoint while OpenRouter records DeepSeek's policy as allowing the use of request data for training, DeepSeek's published privacy policy stating that it trains on what it collects; these requests carry that routing instruction but no instruction requiring a zero-data-retention route. (c) The row's sentence on SpaceXAI's Grok model says that platform roles, among them the general worker and the development executor, may be configured to that model, where it said that those two are configured to it today; Section 5's two sentences on SpaceXAI LLC — its processing location and the onward transfer to it — are worded the same way, naming it as OpenRouter's onward provider for SpaceXAI's Grok model rather than for those two roles; SpaceXAI LLC (xAI) stays named as OpenRouter's onward provider for that model, on the same terms. Section 5 states DeepSeek's processing location as the past leg it was, that today's providers for DeepSeek's model are headquartered in the United States as OpenRouter records them, and the leg to them as an onward transfer under OpenRouter's terms; Section 2's training sentence points at Section 7 alone. For certainty, the change to Section 7 was instructed in writing by the platform's sole Customer, its operator, on 2026-10-18 — that the platform route only to providers that do not train on the data it sends — so that it has the Customer's express opt-in even on a reading of Section 7's last sentence that reaches a change in the Customer's favour. The Section 4 notice period (30 days) and objection window (14 days) were waived for the change in (b) by the platform's sole Customer, its operator, on 2026-10-18; no other Customer existed on 2026-10-18, so no Customer's notice or objection right was shortened by this change taking effect on posting. The Section 4 mechanism itself is unchanged and applies in full to every future addition or replacement of a sub-processor. The Privacy Policy's edition 6.4 and the Terms of Service & Acceptable Use's edition 5.4 make the matching changes. 2.19 — a disclosure, and the e-mail notice Section 4 promised put into effect (NON-MATERIAL for the Customer: it adds a notice the Customer was promised, describes processing and records and where they sit, reduces no right and adds no obligation; effective on posting, 2026-10-19): Section 4 now states that each addition or replacement of a sub-processor is also notified by e-mail to the Customer's administrators when it is published, as a platform notice — a notice from RunMyB that the platform e-mails to the administrators of every account and that no account setting turns off while the account exists — and that the e-mail adds to the notice mechanism and does not replace it; Section 4 had said that this e-mail notice was stated in advance and would take effect when the platform operated its transactional mailer, and from this edition the platform sends it. Section 2's statement of nature and purpose names the e-mailing of the platform's notices about the account's work to the Customer's administrators, and no one outside RunMyB, whose only workspace content is the text the console names their subject by, such as a card's title. Section 1's capacity 1 states that the platform's records of those notices, of the choices the Customer's users make about which of them they receive, and of the delivery of each message it sends the Customer's users, are RunMyB's own processing as an independent controller, as the Privacy Policy's Section 2 describes, and not Customer Personal Data. No sub-processor is added or replaced and no sub-processor's function changes — the messages are sent through Amazon Simple Email Service, which Section 4's AWS row already names — so the Section 4 notice mechanism is not engaged; for certainty, the Section 4 notice period (30 days) and objection window (14 days) were nonetheless waived for this change by the platform's sole Customer, its operator, on 2026-10-19; no other Customer existed on 2026-10-19, so no Customer's notice or objection right was shortened by this change taking effect on posting. The Section 4 mechanism itself applies in full to every future addition or replacement of a sub-processor, now with its e-mail notice. Also recorded in 2.19, for the sub-processor changes published as this document's editions 2.2 (2026-09-11), 2.3 (2026-09-12), 2.4 (2026-09-17), 2.9 (2026-09-28), 2.10 (2026-10-03), 2.11 (2026-10-07), 2.14 (2026-10-12) and 2.18 (2026-10-19): the platform's transactional mailer, which sends the invitations and the notices about data requests and account deletion, was in place before the first of those dates, but none of those changes was also notified by e-mail — until this edition that mailer had no message with which to notify the Customer's administrators of a sub-processor change — each change was notified by its entry in this changelog, which is the notice mechanism, and the platform's sole Customer on each of those dates, its operator, waived the notice period and the objection window for it (the entries above), so no Customer went without notice of any of those changes or lost the chance to object to it. This dated entry discharges, so far as Section 4 then owed it, the e-mail notice of those changes, in place of a message sent now. The Privacy Policy's edition 6.5 and the Terms of Service & Acceptable Use's edition 5.5 make the matching disclosures. 2.20 — the sign-in relay (NON-MATERIAL for the Customer: it describes processing the Customer itself enables, reduces no right and adds no obligation, and keeping nothing of what it relays is a new restriction on RunMyB; effective on posting, 2026-10-19): Section 2's nature and purpose names the platform's relay of an application's own exchange with a sign-in provider the platform offers for it — today Google or GitHub — through a sign-in app the Customer registered for the application: the Customer's sign-in app credentials presented on the application's behalf, the provider's signed identity token verified where it issues one, and the identity the provider returns for the end-user — its signed identity token where it issues one, and the end-user's identifier, name, e-mail address, verified flag and picture — passed to the application in transit only and never kept, with, in place of the provider's access token, a short-lived handle of RunMyB's own (valid for at most ten minutes) that the application cannot read, no refresh token, and the access token used by RunMyB, where needed, alone and in transit, to read the identity and kept nowhere, the record of each relayed step naming the application, the provider, the step and its outcome and never the end-user; category (a) names what is relayed; Section 4's paragraph on the services the Customer connects names the sign-in provider; Section 6's egress measure names the relay's pinned provider addresses and the custody of the Customer's sign-in app secret. No sub-processor is added or replaced and no sub-processor's function changes — the sign-in provider acts under the Customer's own registration and is a recipient the Customer chooses, not a sub-processor (Section 4) — so the Section 4 notice mechanism is not engaged; for certainty, the Section 4 notice period (30 days) and objection window (14 days) were nonetheless waived for this change by the platform's sole Customer, its operator, on 2026-10-19; no other Customer existed on 2026-10-19, so no Customer's notice or objection right was shortened by this change taking effect on posting. The Section 4 mechanism itself is unchanged and applies in full to every future addition or replacement of a sub-processor. Section 7 (no use of Customer Data for AI/ML training) is unchanged and binds this processing. The Privacy Policy's edition 6.7 makes the matching disclosure. 2.21 — a new restriction on RunMyB (NON-MATERIAL for the Customer: it adds a commitment by RunMyB, reduces no right and adds no obligation; effective on posting, 2026-10-19): Section 7 states that data received through the Customer's Google connections is sent to an AI model only in a request RunMyB sends on its own account, under the routing instruction, a provider's own terms that exclude training or the setting of RunMyB's account with the provider that excludes it, never on an AI key of the Customer's, and is sent to a model for no platform purpose other than the features that need it. No sub-processor is added or replaced and no sub-processor's function changes, so the Section 4 notice mechanism is not engaged. The Privacy Policy's edition 6.8 makes the matching statement. 2.22 — a disclosure and a new restriction on RunMyB (NON-MATERIAL for the Customer: it describes a new record and where it sits, restricts which of the messages an application asks for RunMyB sends, reduces no right and adds no obligation; effective on posting, 2026-10-22): Section 1's capacity 1 now states that the record of the addresses confirmed for, or unsubscribed from, each of the Customer's applications — for each application and address, each time the address is recorded as confirmed, as unsubscribed or as no longer unsubscribed, with how that arose, the identifier of the platform's link and when it was issued where a link gave rise to it, and when it was recorded, identifying the address only by a hash made with a secret key and keeping nothing about the browser or device — is RunMyB's own processing as an independent controller, as the Privacy Policy's Section 2 describes, and not Customer Personal Data. Section 2's statement of nature and purpose now states that each address-verification and password-reset message the platform sends for an application carries the platform's own link in place of the application's, which then opens the application's link, and an unsubscribe; that a password reset goes only to an address confirmed for the application, the platform sending an address not yet confirmed its own message asking for it to be confirmed instead; and that no message goes to an address unsubscribed from the application. No sub-processor is added or replaced and no sub-processor's function changes, so the Section 4 notice mechanism is not engaged. The Privacy Policy's edition 6.10 makes the matching disclosure. 2.23 — a disclosure and a new restriction on RunMyB (NON-MATERIAL for the Customer: it describes a new feature's processing on the Customer's instructions and the records RunMyB keeps for it, restricts which of the messages an application asks for RunMyB sends, reduces no right and adds no obligation — the obligations attached to the feature are in the Terms' edition 8.0, Section 15, item 7; effective on posting, 2026-10-22): Section 2's statement of nature and purpose now includes sending, when a Customer's application asks for it, messages of the application's own to its end-users, each rendered by the platform as plain text from a template the application carries and the values the application supplies, the platform checking the form of both and never their wording, with the platform's own last lines and an unsubscribe, and sent to the one address the application gives only if that address is confirmed for the application, the platform sending an address not yet confirmed its own message asking for it to be confirmed instead, no message to an address unsubscribed from the application, and none of these messages while the application's own messages are switched off, and keeping no copy of a message's text; the application's templates are kept with each version of the application prepared for publication, for as long as the application exists; and the categories of end-user data now name the address of each such message and the values the application supplies for it. Section 1's capacity 1 now names, among the records that keep the e-mail the platform sends for the Customer's applications within its limits, a daily count of each application's own messages sent to an address, identifying the address only by a hash made with a secret key, and, for each application, the record of each time its own messages are switched off or back on, with the reason and who decided, as RunMyB's own processing as an independent controller, as the Privacy Policy's Section 2 describes, and not Customer Personal Data. No sub-processor is added or replaced and no sub-processor's function changes — the messages are sent through Amazon Simple Email Service, within the AWS row of Section 4 — so the Section 4 notice mechanism is not engaged. The Privacy Policy's edition 6.11 makes the matching disclosure. This edition is also a disclosure and new restrictions on RunMyB (NON-MATERIAL for the Customer: it states where the files the Customer's applications keep are stored, how they are kept apart and that they are not backed up, and extends to those files the return of an application's data on request, which reduces no right and adds no obligation): Section 2's categories of personal data (a) now state that the files an application keeps — those its end-users upload and those it creates — live in the product's own storage area in a private storage bucket the platform keeps for the hosted products' files, in the United States, provided through the AWS sub-processor listed in Section 4. Section 3(g) now states that the data an application keeps in its files is, like the data in its own database, not in the self-service data export and is returned on the Customer's request, the copy of that database being delivered within the same 30 days together with a copy of those files — other than a file withheld under Section 15, item 8 of the Terms — and a manifest that lists them, and that the storage area that holds those files, like that database, is deleted only after the copy is delivered. Section 6's tenant-isolation measure now adds a separate storage area per product for the files it keeps: the hosted products hold no credentials for that storage and open a stored file only through a time-limited link signed by the platform's file gateway, which signs links for a product to its own files alone, and states that the files a product keeps are not backed up: a file the product deletes, or that is deleted under Section 15 of the Terms or at the product's or the account's erasure, cannot be restored. No sub-processor is added or replaced and no sub-processor's function changes — the files are stored by Amazon Web Services, already listed for the hosted platform's storage — so the Section 4 notice mechanism is not engaged. The Terms of Service & Acceptable Use's edition 8.0 states how RunMyB may act on a single stored file (Section 15, item 8); the Privacy Policy's edition 6.11 makes no change for those files. Section 4's OpenRouter row and Section 5 describe the providers that serve DeepSeek's model by the rule that chooses them, those whose published data policy, as OpenRouter records it, does not use request data for training, naming Deep Infra Inc., Parasail, Inc. and the provider OpenRouter lists as InferenceNet as examples in the row, and the first two in Section 5, where they had named those two as today's providers; OpenRouter routed the build roles' requests to a third such provider, the one it lists as InferenceNet, on 2026-10-21, which the named pair did not state; this is a correction, a disclosure made accurate, and no sub-processor is added or replaced, OpenRouter remaining the sub-processor, so the Section 4 mechanism is not engaged. Section 7 states that what an application the Customer builds carries in its own code and prompts is the Customer's product content, and that data received through the Customer's Google connections is never sent to a model made by DeepSeek, whichever provider would serve it (the Privacy Policy, Section 5.3). 2.24 — a disclosure and new restrictions on RunMyB (NON-MATERIAL for the Customer: it describes a new feature's processing on the Customer's instructions, bounds how long RunMyB keeps the data an application hands it for that feature and to whom RunMyB gives that data, and adds a measure, which reduces no right and adds no obligation — the conditions attached to the feature are in the Terms' edition 9.0, Section 15, item 9; effective on posting, 2026-10-23): Section 2's statement of nature and purpose now includes running the background jobs a Customer's application declares in the version of it that the platform serves: RunMyB calls the application's own address for each run, at the times the application's declared schedule sets, soon after the application asks for a run or at the time it names for one, or when the Customer's user starts one in the console, waking the application to do so if it is asleep, within the limits the Terms state, and, while it verifies a version before that version is accepted, runs each job the version declares once, on the platform's own running copy of the application, with the example data the declaration carries or none; it checks the form of each declaration, never what a job does; for each run of the hosted application it keeps a record — when the run was due, its state, its attempts and how each ended — and the data the application hands for the run, at most 16 KiB, which it gives to no one but the application itself, when the application's route begins the run, and removes from the run's record as soon as the run succeeds; and it deletes each finished run, with its record and any data it still holds, 30 days after the run ended, the daily counts of each application's runs, which hold no data the application handed, being RunMyB's own records, the substrate of its limits and of its metering, under Section 1. Section 2's categories of end-user data (a) now name the data an application hands the platform for a run of one of its background jobs, kept in the platform's own database, provided through the AWS sub-processor listed in Section 4, only as long as Section 2's statement of nature and purpose states. Section 6's tenant-isolation measure now states that a product's background jobs are kept apart as its database and its files are: every run, and the data handed for it, is keyed on that product's identity as the platform itself records it, never one the product names; the platform calls only that product's own address for a run, and gives a run's data only to that product. No sub-processor is added or replaced and no sub-processor's function changes — the runs are kept in the platform's own database and the application is called by the platform's own services, all on the infrastructure the AWS row of Section 4 already lists — so the Section 4 notice mechanism is not engaged. The Terms of Service & Acceptable Use's edition 9.0 states the jobs' limits and how RunMyB may pause them (Section 15, item 9), and the Privacy Policy's edition 6.12 names the e-mail notice of such a pause. 2.25 — a disclosure (NON-MATERIAL for the Customer: it describes a new feature's processing on the Customer's instructions and restricts to whom RunMyB sends the messages an application asks for from a preview, reduces no right and adds no obligation; effective on posting, 2026-10-25): Section 2's statement of nature and purpose now includes sending, from a preview of a Customer's application that a member of the Customer's account starts from the console, the address-verification and password-reset messages and the messages of the application's own that the application asks for only to the address that member signs in to the platform with, without first asking that address to confirm itself, without the platform's own link in place of the application's and without an unsubscribe, and none to an address unsubscribed from the application. No sub-processor is added or replaced and no sub-processor's function changes, so the Section 4 notice mechanism is not engaged. The Privacy Policy's edition 6.13 makes the matching disclosure. 2.26 — SUB-PROCESSOR CHANGE under Section 4 (non-material for the Customer as a document change), published on 2026-10-25 and effective the same day: OpenRouter, Inc.'s function is widened to two new platform roles — the photo describer, which suggests a description of each photo the Customer's user adds to one of the Customer's applications, and the check of each such photo for content the platform's rules prohibit or restrict, which RunMyB makes as an independent controller (Section 1) — and Microsoft Corporation (its Azure service) and Deep Infra Inc. are engaged, as OpenRouter's own providers, for the new purpose of that check: OpenRouter routes each of the check's requests — one prepared copy of the photo, at most 1280 pixels wide and without its location, camera or other embedded data, which may show people, with the platform's instructions for the check — to the one provider the platform names for the classifier model it asks, Microsoft Corporation (its Azure service) today for OpenAI's model, which the platform asks first, in the European Union where the platform names Azure's endpoint there and otherwise wherever Azure serves the request, which may be the United States, and Deep Infra Inc. today for the classifier models of other makers that the platform asks next, in a fixed order, when that one cannot answer, each request carrying a routing instruction that allows that one provider only, only where OpenRouter records it as neither using request data for training nor retaining it, and never another provider in its place; and the photo describer's requests — one such copy, with the application's language and the platform's instructions — go to a provider of the model configured for it, as the OpenRouter row states for every other platform role so routed, each carrying the routing instruction that excludes providers whose terms allow the use of request data for model improvement and a routing instruction under which OpenRouter sends it only to a route it records as retaining no request data. Section 4's OpenRouter row also states that each request that concerns an application whose files hold photos and carries, or may carry, a picture the platform took of that application or an image from its files carries a routing instruction under which OpenRouter sends it only to a route it records as retaining no request data, the picture or image being left out where the model has no such route or the request cannot carry that instruction, and that the requests routed to DeepSeek's model carry no instruction that requires a zero-data-retention policy except as the row states for such a request. Section 1's first capacity now names the check of the photos, and the records of that check and of RunMyB's decisions on a photo, as RunMyB's own processing as an independent controller, not on the Customer's instructions, those records not being Customer Personal Data; Section 1's second capacity and Section 2's categories of data subjects now include the people shown in the material the Customer adds to its applications, such as the photos its users add to them. Section 2's nature and purpose add the photos: once the Customer's user has confirmed, for an application, the statement the console shows — that the Customer may use the photos added there, including on the application's public site, and that everyone who can be recognised in them has agreed to appear in it (for a child, their parent or guardian has agreed), a record RunMyB keeps in its own right as its evidence of what was confirmed — RunMyB has each photo scanned for malicious software in the platform's private storage before anything else reads it, opens a photo in which the scan finds no such software, one the scan cannot judge included, only in an isolated process within fixed limits, and prepares from its pixels alone copies in several sizes and formats for the web, without the original file and without the location, camera or other data embedded in it, keeping the original only until RunMyB's own check of the photo has passed it, or for as long as a hold lasts, a file in which the scan finds such software being never opened by the platform, used or shown and kept until the Customer's user removes it or the application is erased; uses a photo in the application, and shows it to anyone outside the Customer's account other than RunMyB's operating team, only once that check — for sexually explicit content, any sexual depiction of a person who may be a minor and graphic violence — has passed it; keeps, unused, a photo the check holds or sends to RunMyB's operating team — a photo the check held until the Customer's user removes it or the application or the account is erased, and a photo sent to RunMyB's operating team before anything is decided, or held by RunMyB because of a notice or because the law requires it to preserve it, which the Customer's user cannot remove and while which neither the application nor the account can be erased, until RunMyB decides on it and for as long as the law requires, RunMyB aiming to decide on such a photo within 14 days; suggests a description of each photo the check has passed through that sub-processor, under the zero-retention routing instruction, the model being instructed to name no one and to guess at no one's identity, health, origin, beliefs or other sensitive trait; uses in the application only a photo whose description the Customer's user has confirmed, or has marked as decoration, and gives the application's build those photos and descriptions, which the application then serves as part of itself; keeps the copies, the descriptions and any suggestion not yet confirmed with the application until the Customer's user removes the photo or the application is erased; and, when the Customer's user removes a photo, deletes it from the platform's store of photos at once and removes it from the application at its next update, the earlier versions of the application that RunMyB keeps — those published, kept so that the application can be restored to one of them, and those prepared for previews — and RunMyB's copy of the application's code history keeping it until the application is erased, unless the Customer instructs RunMyB, on the request of a person shown in the photo, to erase it from them, which RunMyB's operating team then does, without undue delay, and the platform's backups of its file store keeping a copy for 35 days. Section 2's nature and purpose also state that, in building, verifying and repairing the Customer's applications, RunMyB takes pictures of their screens — their pages at computer and phone width, the screens its checks walk through and the design variants it offers — which may show what an application holds about its end-users, and sends them, as part of the workspace content, to the AI models that design, verify, review, repair and change the application and to the console's assistant when the Customer's user asks it about a build, through the sub-processors listed in Section 4, a request about an application whose files hold photos that carries, or may carry, such a picture or an image from those files carrying the zero-retention routing instruction or going without the picture or image. Section 2's categories of personal data add (c), for the people shown in the material the Customer adds: their images in the photos, the copies the platform prepares from them and the descriptions of the photos, kept on the platform's own storage, provided through the AWS sub-processor listed in Section 4. Section 2's special categories state that a photo the Customer adds may reveal such data about a person shown in it, that RunMyB does not use the photos to recognise or identify anyone and does not use them to infer such data about a person, that the description it suggests is instructed to state none, and that RunMyB's own check of each photo assesses the photo as a whole, including whether a person in it may be a minor and whether it is sexual, only to decide whether the photo may be used in the application, recording a label about the photo, never a trait of a person, no decision about the people shown following from it. Section 5 states where the check's providers process the request and that the leg to each is OpenRouter's onward transfer, which the Clauses incorporated in OpenRouter's Data Processing Agreement (Module Two, Clause 9) oblige OpenRouter to make under equivalent protections, Microsoft Corporation being certified under the EU–US Data Privacy Framework and Deep Infra Inc. not being a participant. Section 6 adds a measure for the photos the Customer adds: published only as copies prepared from their pixels alone, the original kept only until RunMyB's check of the photo has passed it, or with a hold, a file in which the scan finds such software kept, never opened, until it is removed or the application is erased, and a photo used in the application only once that check has passed it. Section 7 (no use of Customer Data for AI/ML training) is unchanged and binds this processing. For certainty, the Section 4 notice period (30 days) and objection window (14 days) were waived for this change by the platform's sole Customer, its operator, on 2026-10-25; no other Customer existed on 2026-10-25, so no Customer's notice or objection right was shortened by this change taking effect on posting. The Section 4 mechanism itself is unchanged and applies in full to every future addition or replacement of a sub-processor. The Privacy Policy's edition 6.14 makes the matching disclosure, and the Terms of Service & Acceptable Use's edition 10.0 states the confirmation the Customer's user gives and what a hold of a photo means (their Section 10.5). Also in 2.26 (NON-MATERIAL for the Customer: a disclosure and a new measure): Section 2's nature and purpose state that RunMyB has each file one of the Customer's applications stores for its end-users scanned for malicious software soon after it is stored, through the AWS sub-processor (Amazon GuardDuty), which reads the file in the platform's own storage in the United States and deletes its copy once the scan is done; keeps the scan's verdict with the file and its record and deletes it with them; serves a file until the scan has judged it, and a file the scan cannot judge unscanned, telling the Customer's administrators once for each application, without naming any file, unless they have turned that notice off (Terms, Section 4); has a file whose scan could not be completed scanned again, at most three times and at least twenty minutes apart, the application being told meanwhile that the file is still being checked; and withholds a file in which the scan finds such software under Section 15, item 8 of the Terms, deleting nothing because of the scan and e-mailing the Customer's administrators the statement of reasons unless the law requires, or a public authority asks, RunMyB to delay it, until RunMyB's operating team deletes or releases it, deleting it when the Customer asks for that or for the application or the account to be erased, an erasure that waits until the file is deleted, unless Section 15, item 4 of the Terms or a legal demand to preserve it requires RunMyB to keep it; and that GuardDuty's record of a file it finds malicious is one of RunMyB's security and operational records, kept by GuardDuty for 90 days. Section 3(g) leaves out of the return copy a file in which the scan has found such software, as it leaves out a withheld file, the manifest naming each file left out. Section 6 gains the measure: stored files scanned for malicious software, the storage itself refusing every download link to a file found to contain it, no service of the platform's own able to change a file's verdict, and no file deleted automatically because of the scan. Section 4's row for Amazon Web Services names the scan (Amazon GuardDuty); AWS was already listed, so no sub-processor is added or replaced, and the notice this edition sends under Section 4 names it too. Section 7 is unchanged and binds this processing: RunMyB has instructed Amazon Web Services not to use or store the content GuardDuty scans to develop or improve its services. 2.27 — a disclosure (NON-MATERIAL for the Customer: it describes a new feature's processing on the Customer's instructions — receiving, keeping, showing and deleting the messages people write in the contact forms of the Customer's applications — reduces no right and adds no obligation; effective on posting, 2026-10-27, published with the Terms' edition 10.2 and the Privacy Policy's edition 6.15): Section 2's statement of nature and purpose now includes receiving the messages people write in the contact form of a Customer's application, which the application's own server hands the platform: keeping each — its text, the reply address and the name the writer gave, if any, and when it arrived — in the platform's own database; showing it in the console, as plain text with any link shown as text, to the Customer's users who can see the application, or, for an application that only one member of the Customer's account can see in the console, to that member alone; checking each message only for its shape, never who wrote it or what it says; sending nothing to the writer's address; letting no AI model or assistant read a message and acting on nothing a message says; taking messages only within the platform's daily limits and none while the inbox is switched off, while the account is suspended or terminated, or from a preview; keeping a record of each time the inbox is switched off or on; and deleting each message after 90 days, and sooner when the Customer's user deletes it or the application or the account is erased; and the platform's notices about the account's work go, for an application that only one member of the Customer's account can see in the console, to that member instead of the administrators. Section 1 names, among RunMyB's own records as an independent controller, the daily count of those messages for each application and reply address, which identifies the address only by a hash made with a secret key, and the records of the notices e-mailed to that member. Section 2's categories of data subjects and of personal data name the people who write and their messages, kept in the platform's own database and included in the account's data export, and Section 6 states the measures that keep the messages apart and keep every AI model and assistant from them. No sub-processor is added or replaced and no sub-processor's function changes, so the Section 4 notice mechanism is not engaged. 2.28 — a disclosure, a clarification and a change in your favour (NON-MATERIAL for the Customer: it names among RunMyB's own records, which were never processed on the Customer's instructions, the record of the messages the platform refuses to send and the look-ups made in those records, states that the delivery records cover the users of the Customer's applications, and describes a view of those records the Customer now has, reducing no right and adding no obligation; effective on posting, 2026-10-27, published with the Privacy Policy's edition 6.16): Section 1's capacity 1 names, among RunMyB's own records as an independent controller, the delivery of each message the platform sends the Customer's users and the users of the Customer's applications, the messages to them it refuses to send, with the reason, and the look-ups the Customer's users make in those records, and states that RunMyB shows the Customer's users who can see one of the Customer's applications in the console what became of the messages the platform sent or refused to send for it, never the address they went to, and, for one address such a user types, which of those messages went to that address and what became of each, including that the person reported one as spam, matching the address by its hash and keeping neither the address typed nor its hash, as an independent controller in its own legitimate interest and the Customer's and not on the Customer's instructions, the Customer holding what it learns as the controller of its application's end-users' data. No sub-processor is added or replaced and no sub-processor's function changes, so the Section 4 notice mechanism is not engaged. 2.29 — a narrowing of Section 7 (MATERIAL for the Customer: Section 7 no longer excludes every model made by DeepSeek for the data received through the Customer's Google connections; as Section 7 does not change without the Customer's express opt-in, the change is put to the Customer for renewed acceptance through the Privacy Policy's edition 7.0, which is MATERIAL; effective on posting, 2026-10-28; no sub-processor is added or replaced, OpenRouter remaining the sub-processor, so the Section 4 notice mechanism is not engaged): Section 7 states that the data received through the Customer's Google connections is never sent to DeepSeek's own service, and reaches a model made by DeepSeek only as served by a provider other than DeepSeek under the routing instruction Section 7 states, a further instruction that excludes DeepSeek as a provider and a further instruction under which OpenRouter sends the request only to an endpoint that it lists as having a zero-data-retention policy (the Privacy Policy, Section 5.3), where it had stated that such data was never sent to a model made by DeepSeek, whichever provider would serve it; Section 4's OpenRouter row excepts that data, as Section 7 states, from its statement that the requests routed to DeepSeek's model carry no instruction that requires a zero-data-retention policy. This edition also carries a disclosure about e-mail to the Customer's applications and its users' answers to the platform's notices, NON-MATERIAL for the Customer on its own (published with the Privacy Policy's edition 7.0 and the Terms' edition 10.3): Section 2's statement of nature and purpose now includes receiving the e-mail sent to a Customer's application's own address on the platform — through the AWS sub-processor (Amazon Simple Email Service), which scans it for viruses and spam; holding it as received only until it is delivered or counted as not delivered; delivering it only if that scan found neither, if it is within the platform's size limit and if its sender's address passes the e-mail authentication of its domain or of a domain related to it, which shows the mail service it came through, never who wrote it, and only while the inbox is on, the account neither suspended nor terminated and within the platform's daily limits; keeping, of an e-mail delivered, the sender's address and name, the subject, the text as plain text, the list of attached files and which authentication passed, and only attached files of a few kinds whose contents match the kind they state, never opened or run by the platform and given to the Customer's users only as a download under a name the platform chooses; deleting the kept files with their e-mail, and at an erasure by a separate deletion step the platform records; keeping of an e-mail not delivered only a count by day and reason, and sending its sender nothing; and letting no AI model or assistant read an e-mail or a kept file. Section 1 names among RunMyB's own records the daily count of the e-mails from each address delivered to each application, identifying the address only by a hash made with a secret key. Section 2's data subjects and categories of personal data name the people who e-mail the Customer's applications, their e-mail, kept in the platform's own database and included in the account's data export, the files kept from it, kept in the platform's private storage and not included in that export, and each user's answers by e-mail to the platform's notices, kept as messages to that user; Section 3(g) states that those files are in neither the export nor the copy and can be downloaded in the console while they are kept; Section 6 states the measures that keep an e-mail with the product whose address it was sent to and that govern the e-mail and its files, which are not backed up. Section 4's row for Amazon Web Services names the receiving of that e-mail, with its scan for viruses and spam, through Amazon Simple Email Service: a description of an existing sub-processor's function, AWS being already listed, so no sub-processor is added or replaced and the Section 4 notice mechanism is not engaged by this part either. 2.30 — a disclosure and new restrictions on RunMyB (NON-MATERIAL for the Customer: it describes a new feature's processing on the Customer's instructions — a formatted version of an application's own messages — and restricts what such a version can hold and how it is sent, reducing no right and adding no obligation; effective on posting, 2026-10-29; no sub-processor is added or replaced, so the Section 4 notice mechanism is not engaged): Section 2's statement of nature and purpose states that each message of an application's own is rendered by the platform as plain text, and also as a formatted (HTML) version where the template carries one, the platform rebuilding a formatted version from formatting it allows, with no image and nothing loaded from elsewhere, and sending it only beside the plain text; and that the platform keeps no copy of a message's formatted version, as it keeps none of its text.