AssemblyWright AI — Data Processing Addendum
Effective date: October 29, 2026
This Data Processing Addendum ("DPA") forms part of the Agreement between Evadaroo & Company, LLC, a Pennsylvania limited liability company trading as AssemblyWright AI ("AssemblyWright", the "Processor"), and the customer that accepted the Terms ("Customer", the "Controller"). It applies where AssemblyWright processes Customer Personal Data on Customer's behalf in providing the Service, including personal data the Service reads from, or writes to, a Connected Org on Customer's instruction. How this DPA ranks against the other documents of the Agreement is set out in Section 16.2 of the Terms; within this DPA, the SCCs and the UK Addendum prevail (Section 7.5).
1. Definitions
"Terms" means the AssemblyWright AI Terms of Service. "Agreement", "Service", "Workspace", "Customer Account", "Customer Content", "User", "Connected Org", "Connected Service", "Build", "Deliverable", "Wright", "Maintenance Workflow", "Order" and "AUP" have the meanings given in the Terms. Words such as "controller", "processor", "personal data", "processing", "data subject" and "supervisory authority" have the meanings given in the GDPR.
"Data Protection Laws" means, as applicable, the EU General Data Protection Regulation 2016/679 ("GDPR"); the UK GDPR and the Data Protection Act 2018 ("UK GDPR"); the Swiss Federal Act on Data Protection ("FADP"); the California Consumer Privacy Act, as amended by the California Privacy Rights Act, and its regulations ("CCPA"); and other US state privacy laws.
"Customer Personal Data" means personal data that AssemblyWright processes on Customer's behalf under the Agreement: personal data in Customer Content, including personal data in the configuration, history and records of a Connected Org that the Service reads, transforms or writes on Customer's instruction (for example, a contact's details in a record a Wright reads during a Build, the prior values captured before a bulk update, or the names of Customer's own administrators in the setup history a Process Documentation Build reads); in the membership and role records of Customer's Workspaces; in the audit, Build, usage, notification and device records attributable to Customer's Workspaces; in the events a Workspace's own Paddle account sends to the Service, which name that Workspace's buyers; and in the audiences, suppression lists and recipients of email Customer prepares or approves through the Service. It does not include the data described in Section 2.2.
"Personal Data Breach" means a breach of AssemblyWright's security, or of a sub-processor's, leading to the accidental or unlawful destruction, loss, alteration or unauthorized disclosure of, or access to, Customer Personal Data. It does not include (a) unsuccessful attempts or activities that do not compromise the security of Customer Personal Data, such as pings, port scans, blocked sign-in attempts or denial-of-service attacks; (b) access through an account, credential, invitation, connection or link that Customer or its Users created or handed out, or failed to protect, where the Service worked as designed; (c) anything done in a Connected Org or a Connected Service through credentials Customer supplied, on an instruction given under Section 7.4 of the Terms, including a write a User approved, a write made in autonomous mode in a sandbox Customer enabled it for, a post Customer's User approved, or a Deliverable Customer chose to publish, where the Service worked as designed; or (d) a breach of a Connected Org, a Connected Service or Customer's CRM vendor that is not a breach of AssemblyWright's systems. On request, AssemblyWright will give Customer the records it holds about a case under (b), (c) or (d), as assistance under Section 3.6.
"SCCs" means the Standard Contractual Clauses annexed to Commission Implementing Decision (EU) 2021/914. "UK Addendum" means the International Data Transfer Addendum to the SCCs issued by the UK Information Commissioner, version B1.0.
2. Roles and scope
2.1 Controller and processor. Customer is the controller (or a processor acting for a third-party controller) of Customer Personal Data, and AssemblyWright is its processor (or sub-processor). Under the CCPA, AssemblyWright is a service provider, and under other US state privacy laws it is a processor. Where Customer is itself a processor — a consultancy or systems integrator working in a client's Connected Org — Customer is responsible for having its client's authority to engage AssemblyWright as a sub-processor and to connect that client's org, and the instructions in Section 3.1 are Customer's whether or not Customer's client gave them.
2.2 AssemblyWright's own processing. AssemblyWright is an independent controller of: (a) the sign-in account itself (email address, name, password or social sign-in and sign-in sessions), which its identity provider, Clerk, holds for it and which follows a person across every Workspace they belong to, for authentication and account security; (b) the Customer Account, Customer's billing and contract relationship, the entitlements and prices recorded against it, and the record of who accepted the Agreement's documents where the Service keeps one; (c) security, fraud and abuse prevention, including rate-limit counters, the structured request log and the web server's access log, browser crash reports, the ledger of every identity that reached its operator area, the record that a person was removed from a Workspace, and its email provider's account-level list of addresses that bounced or complained; (d) its own administrative audit trail of operator acts (Section 3.11), the notes its operator keeps about a Customer Account, and the aggregated, de-identified usage statistics described in Section 3.2 (Service data, as Section 5.3A of the Terms defines it) — the personal data in a Workspace's own audit trail, Build timelines and usage records (who acted, and from where) is Customer Personal Data under Section 1 and Annex I.B, processed for the purposes in Section 3.2, and only the statistics derived from them, which identify nobody, are AssemblyWright's own; (e) the requests sent through the Request access form on its website; (f) the Help assistant described in Section 8.3; and (g) compliance with law. That processing is described in the Privacy Policy and is outside this DPA.
2.3 The Annexes. The details of the processing are in Annex I, the security measures in Annex II, and the sub-processors and other recipients in Annex III.
2.4 A Connected Org, and a Connected Service, is Customer's own system. AssemblyWright reaches a Connected Org only with credentials Customer supplies, only within the permissions those credentials carry, and only as the Agreement and Customer's configuration instruct (Section 3.1). Customer's relationship with its CRM vendor (Salesforce, Microsoft, HubSpot), with a social network, with Google, Atlassian or GitHub, with Profusia AI under Customer's own agreement with it, and with Customer's own Paddle account, is Customer's own; none of them is AssemblyWright's sub-processor, and what they hold they hold under Customer's terms with them (Annex III). The records that stay in an org are never in AssemblyWright's custody; what the Service holds of them is in Annex I.
3. AssemblyWright's obligations
3.1 Instructions. Customer's documented instructions are the Agreement, this DPA, and the configuration and use of the Service by Customer and its Users. That includes: the orgs and services Customer connects and the credentials it supplies for them; the execution mode a Workspace administrator chooses for writes to a Connected Org (read-only, gated or autonomous — Section 8.5); each write a User approves at a review gate, and every write the Service makes in autonomous mode in a sandbox org Customer enabled it for; each Build a User starts, each question a User asks a Wright or the Guide, and each Maintenance Workflow Customer schedules; each post Customer's User approves in the Content Desk and each email Customer's User approves; the responses Customer asks AssemblyWright to switch on for the events its own Paddle account sends; and whether Customer connects a Profusia workspace and whether it leaves automatic publishing switched on. A Wright holds tools, and what it reads — a record in a Connected Org, a Knowledge Base entry, a Deliverable, a web page — can steer what it does next; everything a Wright does within the permissions Customer configured is Customer's act under the Terms, as Section 6.6 of the Terms describes. AssemblyWright does not review a Deliverable, a write, a post or an email before a User approves it, and carrying out an instruction given through the Service is processing on Customer's instructions. By entering into the Agreement, Customer also instructs AssemblyWright to process Customer Personal Data to enforce the Agreement and the AUP, including suspending a Customer Account (which, as Section 3.11 describes, closes every Workspace in it) or a Workspace, as the Agreement describes; to keep the backups described in Annex II once they run; and to preserve and disclose it as Section 9.6 describes. AssemblyWright processes Customer Personal Data only on these instructions, or where the law requires it, in which case AssemblyWright will tell Customer first unless the law forbids it.
3.2 No sale or sharing; limited purposes. AssemblyWright will not sell or share Customer Personal Data (as the CCPA defines those terms). It will not retain, use or disclose that data outside its direct business relationship with Customer, or for any purpose other than the business purposes in the Agreement and this DPA, and will not combine it with personal data from other sources except as the CCPA permits. Those purposes are: providing, securing, supporting and maintaining the Service; improving the Service and measuring which features are used, only from usage records (what was done, when, by which account, with which model and at what cost), never from the contents of Deliverables, Knowledge Base entries or Connected Orgs, and never to build a profile of anyone for another business; enforcing the Agreement and the AUP; billing and capacity planning; and complying with law. AssemblyWright may create aggregated, de-identified statistics from usage records, will keep them de-identified, and will not attempt to re-identify them. AssemblyWright will comply with the obligations that apply to it under the CCPA and will give Customer Personal Data the level of privacy protection the CCPA requires. AssemblyWright will tell Customer if it determines that it can no longer meet its obligations under the CCPA, and Customer may then take reasonable and appropriate steps to stop and remediate unauthorized use of Customer Personal Data, including by ending the affected processing. AssemblyWright certifies that it understands and will comply with these restrictions.
3.3 No training on Customer data. AssemblyWright will not use Customer Personal Data or Customer Content to train, fine-tune or improve any machine-learning model. The Bench — what a Wright keeps from Customer's own Builds and reviews — is part of Customer's Workspace, is used only inside it, and is not a model. AssemblyWright will not send Customer Content to an AI provider tier whose terms permit the provider to use it for training. AI providers process content only as Section 8 and Annex III set out.
3.4 People and access. As of the date of this DPA, AssemblyWright has no employees. It is operated by one person, its principal, who is the only person with administrative access to the production machine, its database, its storage and, once they run, its backups, and can read them. Customer Personal Data is not encrypted from AssemblyWright. AssemblyWright will ensure that everyone it authorizes to process Customer Personal Data is bound by confidentiality. AssemblyWright's operator console shows Customer Account and Workspace-level records — the names of Customer Accounts and their Workspaces; how many members each has; the package, trials, grants, switch-offs and any agreed price; usage by feature, Builds, model spend and cost; the ledger of identities that reached the operator area; the requests sent through its website; and the notes AssemblyWright's operator keeps about the Customer Account — and, on its Workspaces page, each Workspace's members as the identifier their sign-in carries (an account id or an email address) with their role — but no Deliverable, Knowledge Base entry, CRM record, credential or Build request. The Service has no mode that opens a Workspace as its members see it (the "View as customer" switch in the operator's own account only hides the operator's controls); the operator's own account passes every Workspace's role checks, so the product does not wall the operator out of a Workspace, and AssemblyWright will not open Customer Content except (a) at the request of Customer, or of a User about content that User can already see, to provide support; (b) to investigate a suspected security incident or a reported breach of the AUP; (c) where the law requires; (d) to keep the Service running, or to recover the Service or Customer's data after a failure (Section 9.5), where that cannot be done without it; or (e) to preserve or disclose it as Section 9.6 describes; and in each case it will open only what is necessary. There is no consented support-access mode: support means asking Customer. The AI coding tools AssemblyWright builds the Service with (Anthropic's Claude Code) see the Service's source code and documentation, are given no credential for the production machine, its database or its storage, and are not used by AssemblyWright to read Customer Personal Data; the production machine fetches and deploys the code they write only after the automated gate in Annex II has passed it. Beyond what this Section and Section 3.11 describe, no screen, listing or export shows Customer Personal Data to anyone at AssemblyWright, and AssemblyWright does not read it. To keep the Service running, AssemblyWright does look at operational records, such as counts, sizes, timestamps, error records, request logs and configuration.
3.5 Security. AssemblyWright will implement and maintain the measures in Annex II, which are appropriate to the risk, taking account of the state of the art, the costs of implementation, and the nature, scope, context and purposes of the processing.
3.6 Assistance. Taking account of the nature of the processing and the information available to it, AssemblyWright will assist Customer with data subject requests (Section 6); with Customer's own security obligations and breach notifications (Section 3.7); and with data protection impact assessments and prior consultations with supervisory authorities, chiefly by providing this DPA's Annexes, the descriptions at assemblywright.ai/trust and assemblywright.ai/privacy, its written security questionnaire where it has provided one, and answers to Customer's reasonable questions. Where Customer's assessment concerns a Connected Org, AssemblyWright will describe what the Service reads from and writes to it, what it keeps and for how long (Annex I), and the controls on writes (Section 8.5 and Annex II); Customer, which holds the org and knows what it contains, carries out the assessment. Assistance under this Section 3.6 and Section 6 is subject to the time allowance in Section 6.2.
3.7 Personal Data Breach. AssemblyWright will notify Customer without undue delay after becoming aware of a Personal Data Breach, and where feasible within 72 hours. AssemblyWright becomes aware when it has a reasonable degree of certainty that a Personal Data Breach has occurred; for a breach at a sub-processor, when the sub-processor tells AssemblyWright. The notice goes to the email address on file for the Workspace owner(s) (Section 12.5) and, where Customer has given AssemblyWright an additional address for this purpose by writing to legal@assemblywright.ai, to that address as well. Notice to the owner's address on file is sufficient notice under this Section. It describes, so far as then known: the nature of the breach, including the categories and approximate number of data subjects and records concerned; the likely consequences; the measures taken or proposed to address it and to limit its effects; and a contact point. Where AssemblyWright cannot give all of that at once, it will give it in phases as facts emerge. AssemblyWright will take reasonable steps to contain and investigate the breach, which may include disconnecting a Connected Org or Connected Service, revoking stored credentials, or suspending the Customer Account (Section 3.11) while it does so. A notice is not an acknowledgment of fault or liability. Customer is responsible for any notice it must give to supervisory authorities, to its own clients or to data subjects, and for any action in a Connected Org (such as rotating the credentials it supplied), and AssemblyWright will give the information and help it reasonably can.
3.8 Return and deletion. AssemblyWright will make Customer Personal Data available for export and will delete it as Section 9 describes.
3.9 Demonstrating compliance. AssemblyWright will make available the information needed to demonstrate compliance with this DPA, and allow for audits, as Section 10 describes.
3.10 Unlawful instructions. AssemblyWright will tell Customer if, in its opinion, an instruction infringes Data Protection Laws.
3.11 Operator acts. Under the Agreement, AssemblyWright's operator can: assign, change or remove a Customer Account's package, a trial, a grant or a switch-off of a feature (a switch-off is recorded with its reason); record a price agreed with Customer; set, change or remove a Customer Account's AI allowance (Annex II); set which Salesforce orgs a Customer Account may connect (Section 4(f)); suspend a Customer Account, which closes every Workspace in it to its members at once while holding, not erasing, its content (Section 9.2(c)), and reinstate it; delete a Customer Account that holds no Workspace; create a Workspace, and add a person to one or remove a person from one, by the operator's own route — where Customer asks for that instead of self-service, or to restore control to an owner whose identity AssemblyWright has verified (Section 16.18 of the Terms); a removal is recorded as a removal on purpose, as Section 6.2 describes; switch on, at Customer's request, an email response to the events Customer's own Paddle account sends (only the operator may switch one on, because the email leaves from AssemblyWright's own domain, and every such email is still approved one at a time by Customer's User); delete a request sent through the website; configure the platform's own model credentials and which model serves each feature; take a database backup and, if the Service fails, restore it from one; and run, by hand, the erasure of a closed Workspace once its window has passed (Section 9.2(b)). AssemblyWright uses these acts only for support, security, recovering the Service, legal compliance or enforcement of the Agreement. The operator console has no control that takes down a single Deliverable, disconnects one of Customer's Connected Orgs or issues a sign-in credential: a Deliverable is deleted only by Customer's Users or with the whole Workspace; a Connected Org is disconnected only by a Workspace administrator, or when the Workspace is closed or its credentials are revoked under Section 3.7; sign-in, password reset and multi-factor settings are managed with Clerk under Customer's Users' own accounts. Each operator act that changes something is recorded in AssemblyWright's own administrative audit trail — the same kind of trail every Workspace has (Annex II), kept to its newest 2,000 entries — stamped with the operator's own scope rather than Customer's, naming the operator (or "via HQ" where it was taken through Evadaroo HQ); an act on a Workspace's membership names the Workspace and the person; none of it appears in Customer's own Workspace trail, which records what Customer's Users and the Service do inside it — unless the operator took the act while working inside that Workspace as one of its members (Section 16.18 of the Terms), in which case it is recorded in that Workspace's trail instead, naming the operator, where Customer can read it. Evadaroo HQ keeps its own log of every act taken through it. AssemblyWright does not record: viewing records in the operator console or through Evadaroo HQ, because only acts that change something are recorded; a restore, which is carried out with the hosting provider's own tools; and reading or changing the database or the machine directly with the hosting provider's own tools and its administrative access, which AssemblyWright's credentials allow. AssemblyWright uses that direct access, by hand, for the requests that no product act or operator act serves — supplying records the export leaves out (Section 6.2), erasing or de-identifying one person's records at Customer's request (Section 6.2), erasing a Workspace after its window or early at an owner's request (Sections 9.2 and 9.3), disconnecting a Connected Org or Connected Service or revoking stored credentials to contain a Personal Data Breach where that is needed (Section 3.7), removing a removal record once its Workspace is erased (Section 9.4), and running the written recovery procedure — and those are recorded only in AssemblyWright's correspondence about the request. AssemblyWright's internal operations console, Evadaroo HQ, can view whatever the operator console shows and take the operator acts above through signed single-use requests, including setting the platform's model credentials and routing, creating a Customer Account, adding or removing a member by the operator's route and setting the push-notification key; it cannot export, close or connect anything in AssemblyWright's own Workspaces, start a Build, or reach any route outside the operator area. Where AssemblyWright suspends Customer's Customer Account, switches a feature off for it, or revokes its stored credentials under Section 3.7, AssemblyWright will tell the Workspace owner by email as soon as practicable, unless the act was taken at the request of an owner, or the law, a person's safety or the integrity of an investigation prevents it. AssemblyWright's operator writes and sends that email; the Service does not send it. Taking a backup and restoring the Service from one are platform-wide acts, taken only to recover the Service or to test that it can be recovered; AssemblyWright does not notify each Workspace of them, but will tell Customer if a restore lost or changed Customer Personal Data or an erasure could not be re-applied (Section 9.5).
4. Customer's obligations
Customer will:
(a) have a lawful basis for the personal data it puts into the Service, and for the personal data in each Connected Org that the Service reads, transforms or writes on its instruction, including the records a Wright reads during a Build, the prior values the Service captures before a bulk update, the test data the Service inserts and removes, the screens the Service photographs during a verification, and the names of Customer's own administrators in the setup history a Process Documentation Build reads — and for AssemblyWright's processing of all of it;
(b) provide the notices and obtain the consents Data Protection Laws require of it, including to its own staff and clients whose data is in a Connected Org, to the people an email campaign prepared in the Service would address (the Service records the lawful basis Customer's User states for each send plan, and does not supply one), and to the buyers whose events Customer's own Paddle account sends to the Service and to whom Customer approves a service email;
(c) give instructions that comply with Data Protection Laws, and keep the email address on file for each Workspace owner current — in the Service, and in the owner's sign-in account (Section 12.5) — because every notice under this DPA goes there;
(d) connect only a Connected Org or Connected Service it is authorized to connect, and to change where it allows writes (Section 7.3 of the Terms and Section 1 of the AUP) — Customer confirms, each time it supplies credentials for an org, that the person supplying them holds that authority from the org's owner, that the credentials may lawfully be handed to a processor for the work Customer will instruct, and that Customer will withdraw them when that authority ends. Where Customer is working in a client's org, Customer holds that authority from its client in writing;
(e) minimize what it connects, and narrow what the Service can reach: supply an integration user whose permissions cover only the objects, fields and operations the work needs (Section 7.2 of the Terms); scope the credentials away from any field or object that holds the data described in Section 3 of the AUP; and remember that a Wright's read tools can return record values into a Deliverable and a Build's timeline: what the credentials can read, the Service can read. Least privilege is a control Customer holds, and AssemblyWright cannot apply it for Customer;
(f) exercise new workflows, deploys, bulk operations and test-data seeding in a sandbox, scratch or Developer Edition org before a production org (Section 7.5 of the Terms), tag each saved connection with its environment, and keep autonomous mode for sandboxes. The Service enforces sandbox-only autonomy and test-data seeding on the server from the org's own data; screen verification is gated by the environment tag Customer typed on the connection (an untagged connection counts as production) unless a Workspace administrator opts the Workspace into production, so tagging honestly is Customer's control; a release aimed at a production-tagged connection requires a typed confirmation, and its deploy sheet warns on a production tag without stopping it (Section 7.5 of the Terms); a bulk update, and a metadata deploy a Wright proposes inside a Build, read no environment tag and carry no production warning — each pauses for a person before it runs, and the approval card for a write a Wright proposes does not name the target org (Section 7.4 of the Terms), so the person who approves is the only stop. Separately, AssemblyWright sets, per Customer Account, which kinds of Salesforce org it may connect at all — by default Developer Edition and scratch orgs only, sandboxes too for a pilot under a signed Order, and production only by agreement with Customer — and the Service is designed to refuse an org outside that policy: when an org is connected it reads the org's kind from the org's own record and address, before any credential is stored, and when a saved connection is switched back on it reads the kind from that connection's stored address, honoring a production tag; Dynamics 365 and HubSpot connections are not checked against it. The org policy is an aid; the sandbox-first rule in this paragraph remains Customer's obligation everywhere;
(g) instruct each write to a Connected Org deliberately: choose the execution mode for each Workspace knowing what it permits (Section 8.5), assign roles so that only intended people can approve a write or start a Build (once Customer's Users act by their own role — Annex II), review what a gate proposes before approving it, and treat a standing choice — autonomous mode, a scheduled release, an automatic Build response to a Paddle event, automatic publishing to Profusia — as an instruction it gave in advance for everything the Service then does under it;
(h) not put into the Service, and not let a Wright read from a Connected Org into it, the data described in Section 3 of the Acceptable Use Policy — protected health information subject to HIPAA, payment card data subject to PCI DSS, and the rest of that list — through any door: a Build request, a Knowledge Base entry, an uploaded file, a connected org whose credentials reach it, a bulk update, a data snapshot, a verification walk or an email audience. The Service is not designed or certified for that data, and AssemblyWright does not accept it;
(i) where its ordinary business records incidentally contain special categories of personal data (for example, a support case noting a customer's disability, or an HR object a widely-scoped integration user can read), decide for itself whether the measures in Annex II are adequate before connecting them, narrow the credentials where they are not (paragraph (e)), and remain responsible for its lawful basis for them. The Service has no controls designed for those categories. Such incidental content is not a breach of (h);
(j) make sure its Users do not put Customer Personal Data or other confidential Customer Content into the Help assistant while it is switched on (Section 8.3), or into the "Draft in Claude" hand-off, which opens the person's own Claude account outside the Service;
(k) decide for itself what it publishes to a Profusia workspace, posts to a social account or sends to any other Connected Service through the Service, under its own terms with each of them, and keep its own copies of anything in a Connected Org it cannot afford to lose, because rollback restores what Section 7.6 of the Terms says and no more.
Customer will defend AssemblyWright against any third-party claim, including a claim by a data subject, by Customer's client, by a CRM vendor or by the owner of a Connected Org, and an investigation or proceeding by a supervisory authority, arising from Customer's breach of this Section 4, and pay the damages, settlement amounts and reasonable legal fees and costs that result. This obligation is part of Customer's obligations under Section 13.2 of the Terms and follows the procedure in Section 13.3 of the Terms.
5. Sub-processors
5.1 General authorization. Customer authorizes AssemblyWright to engage the sub-processors listed in Annex III, and others on the terms of this Section. An AI provider listed there receives Customer Content only as Section 8.3 allows.
5.2 Notice of change. AssemblyWright will post any new or replacement sub-processor in the list at assemblywright.ai/privacy (or a successor address it announces), which the Privacy Policy also carries, at least 30 days before that sub-processor begins processing Customer Personal Data, and will email each Workspace owner at the address on file. Customer may also ask, by writing to legal@assemblywright.ai, to be emailed about every change to the list. Where a sub-processor must be replaced urgently to keep the Service secure or available, or because a sub-processor stops providing its service, AssemblyWright may, to the extent the SCCs allow, make the change sooner and will give notice as soon as practicable; Customer's right to object under Section 5.3 still applies. A change of AI model within a provider already listed, a change in which of the listed providers that are connected (Section 8.1) the chain in Section 8.1 sends a request to, or in what order, or a change of the Google Cloud region in which the Service runs that keeps it within the United States, is not a new sub-processor; moving hosting outside the United States, or moving the processing of a request that Anthropic or Google Vertex AI answers outside the United States, is a change under this Section.
5.3 Objection. Customer may object to a new or replacement sub-processor on reasonable data protection grounds within 30 days after the notice. The parties will discuss the objection in good faith. If AssemblyWright cannot offer a reasonable alternative, Customer may, without penalty, either end its subscription (and, if it wishes, the Agreement, by closing its Workspaces) and receive a refund of the fees prepaid for the remaining days of the term, or, where the new sub-processor serves only some features, move to a package without them and receive the difference in price for the remaining days, as Section 5 of the Refund Policy describes. Refunds are issued through Paddle, AssemblyWright's reseller and Merchant of Record.
5.4 Flow-down and responsibility. AssemblyWright engages each sub-processor under that sub-processor's own published data-protection terms, which apply to AssemblyWright's use of its service (or which AssemblyWright signs, where the sub-processor requires a signature), and will have them in place before a new sub-processor first processes Customer Personal Data. AssemblyWright will use only sub-processors whose terms impose data-protection obligations meeting the requirements of Article 28(3) GDPR for the processing they perform, as Article 28(4) requires. AssemblyWright has not negotiated individual agreements with them. AssemblyWright remains responsible to Customer for its sub-processors' performance as Data Protection Laws require, subject to Section 11. On request, AssemblyWright will provide a copy of, or a link to, those terms.
5.5 AssemblyWright's own company. Profusia AI, Uiia and Evadaroo HQ are not separate companies: each is a service or system of Evadaroo & Company, LLC, the same legal person as AssemblyWright. A Profusia workspace Customer connects is Customer's own Profusia account, opened under the Profusia AI Terms and DPA Customer accepted there and reached with a Profusia access key Customer supplies; the Service treats it as a Connected Service (Section 2.4), publishes to it only what Customer's configuration instructs, and Customer's rights over what lands there arise under that agreement. Because Profusia and AssemblyWright are one legal person, publishing to Profusia is not a transfer to a sub-processor: the act of publishing is AssemblyWright's processing under this DPA, and what lands in Customer's Profusia workspace is held under the Profusia AI DPA Customer accepted there, which gives Customer the same rights and the same notice and objection terms as this Section. Where another document of the Agreement, or a page of AssemblyWright's, describes Profusia as a sub-processor, it means this arrangement and nothing wider. The Help assistant, answered by Uiia, is AssemblyWright's own processing under Section 2.2(f) and is switched off as of the effective date (Section 8.3). Evadaroo HQ is the company's internal operations console (Section 3.11), not a recipient outside the company. Annex III describes what each receives. None of this reduces the notice, objection or responsibility terms of this Section: if any of them is ever moved to a separate legal entity, or begins to receive Customer Personal Data it does not receive today, that is a new sub-processor under Section 5.2.
6. Data subject requests
6.1 Assistance. Taking account of the nature of the processing, AssemblyWright will assist Customer, by appropriate technical and organizational measures, in responding to requests from data subjects to exercise their rights.
6.2 Product acts first, and the time allowance. Many requests can be served by acts in the product:
- Access and portability. The Workspace export provides, in one archive, the current version of every Deliverable the exporting person can see (as Markdown), the Knowledge Base, a list of Builds with the first 2,000 characters of each request and the names of the Workspace's workflows, Wrights and connections; each Deliverable can also be exported on its own as a Word file; and once role enforcement is on, a Workspace admin can read the newest entries of the audit trail in the product; AssemblyWright provides the trail as kept on a Workspace owner's or admin's written request within 30 days, not more than once a quarter for each Workspace (and once after termination), unless the law requires more, as Section 11.5(d) of the Terms provides. The Workspace export does not include items in the trash, earlier versions of Deliverables, the rest of the Workspace's configuration (workflow stages, Wright skills and prompts, document types and settings), Build timelines, the drafts and critiques behind a second-opinion or two-approaches stage, Wright chat and notes, Bench memory, briefs, verification screenshots and video, usage and cost records, notifications, device registrations, the events a Workspace's own Paddle account sent, email campaign items and suppression lists, Content Desk items, or the other records listed in Annex I.B. AssemblyWright will provide the personal data in those records on Customer's written request, gathering it by hand (Section 3.11). Personal data that the Service read from a Connected Org and did not keep is in the org, where Customer can reach it directly.
- Rectification. Deliverables, Knowledge Base entries and delivery-board content are corrected by editing them; a person's name and email address live in their Clerk account, for which the app has no screen today, so AssemblyWright corrects them in Clerk on request. AssemblyWright will correct other records on request where Data Protection Laws require it. The Service does not correct a record in a Connected Org except as a write Customer instructs.
- Erasure. Deliverables and Knowledge Base entries are deleted to the trash and permanently deleted from it with a type-to-confirm step, which removes every version; an owner can remove a member from a Workspace, which deletes their membership and keeps a record that they were removed, so that an identity-provider synchronization does not quietly add them back; an owner can close the whole Workspace (Section 9.2). While the role enforcement described in Annex II is switched off, these acts stay open to a User recorded as the Workspace's owner (removing a member, closing the Workspace) or as its owner or admin (permanently deleting from the trash), but moving an item to the trash does not; AssemblyWright performs any of them at a Workspace owner's written request to legal@assemblywright.ai, within the time this Section states, and confirms in writing. Removing a member does not remove what they wrote, which stays as the Workspace's content, nor their name from the audit trail, the Build timeline, a device registration, a connected social account's record of who connected it, or a decision they recorded. There is no self-service act that erases one person from everything. On Customer's written request naming the person, AssemblyWright will, by hand (Section 3.11), delete or de-identify that person's identifiers in the records Annex I.B lists for Customer's Workspaces, except what Section 9.4 keeps or Section 9.6 preserves, and will confirm completion in writing; AssemblyWright will complete such a request within 30 days of a sufficiently specific instruction from a Workspace owner's address on file. Content that person wrote — a Build request, a chat turn, a comment in a Deliverable — is Customer's content, and Customer decides whether it is deleted or kept with the author removed. A person may ask legal@assemblywright.ai to delete their own sign-in account, which AssemblyWright handles as controller under Section 2.2(a), by hand and with Clerk.
Where a request needs data no product act reaches, AssemblyWright will assist at Customer's written request within a reasonable time. Assistance under this Section and Section 3.6 is free for the first four hours of AssemblyWright's time in any 12-month period. Beyond that, AssemblyWright will give Customer an estimate and may charge for the further work at a reasonable rate, and is not obliged to begin it until Customer has agreed, unless the request arises from AssemblyWright's breach of this DPA or Data Protection Laws require AssemblyWright to act without charge.
6.3 Requests made to AssemblyWright. If a data subject contacts AssemblyWright directly about Customer Personal Data — including a person whose record is in Customer's Connected Org, or a buyer whose details Customer's own Paddle account sent — AssemblyWright will not respond substantively; it will refer them to Customer and tell Customer promptly. A User's request about their own sign-in account is AssemblyWright's own under Section 2.2(a).
7. International transfers
7.1 EU transfers. AssemblyWright is established in the United States, and the Service runs there: its application and database on one Google Cloud machine in us-central1, its browser runner on Google Cloud in the United States. Model inference happens wherever the provider that answers a request processes it (Section 8.1; Annex III): in the United States for a request Anthropic's API answers, which is held to US-only processing, and for a request Gemini 3.8 Flash or 3.5 Flash-Lite answers on Google Vertex AI, in Google's United States multi-region; Google's image model, and any other Vertex model, run in the Google Cloud region the Service's deployment is configured for; and a request routed to Cloudflare Workers AI or OpenAI is processed where that provider processes it, which can be outside the United States. Where Customer Personal Data protected by the GDPR is transferred to AssemblyWright, the SCCs are incorporated into this DPA by reference and apply as follows:
- Module Two (controller to processor) where Customer is a controller; Module Three (processor to processor) where Customer is itself a processor, including a consultancy working in its client's Connected Org.
- Clause 7 (docking) applies. Clause 9: Option 2 (general written authorization), with the notice period in Section 5.2. Clause 11: the optional independent dispute-resolution body is not used. Clause 13: as set out in Annex I.C. Clause 17: governed by the law of Ireland. Clause 18(b): the courts of Ireland.
- Annexes I.A and I.B of the SCCs are populated by Annex I of this DPA, Annex II by Annex II of this DPA, and Annex III (sub-processors) by Annex III of this DPA.
7.2 United Kingdom. For transfers subject to the UK GDPR, the UK Addendum is incorporated into this DPA: Table 1 is populated by the parties' details in Annex I.A; Tables 2 and 3 by Section 7.1 and the Annexes; and under Table 4, neither party may end the UK Addendum as set out in its Section 19.
7.3 Switzerland. For transfers subject to the FADP, the SCCs apply as Section 7.1 sets out, with these changes: references to the GDPR are to the FADP; the Swiss Federal Data Protection and Information Commissioner is the competent supervisory authority for those transfers; and "Member State" includes Switzerland, so that data subjects habitually resident in Switzerland may bring claims there under Clause 18(c).
7.4 Transfer mechanisms, assessments and representation. AssemblyWright is not certified under the EU-U.S. Data Privacy Framework or its UK or Swiss extensions, and relies on the SCCs and the UK Addendum for transfers to it. It has not appointed a representative in the EU or the UK under Article 27 of the GDPR or the UK GDPR. It offers no choice of region. On request, AssemblyWright will give Customer the information it reasonably needs for its own transfer impact assessment, including the measures in Annex II, the sub-processors and locations in Annex III, and the information in Section 7.6. A Connected Org is wherever Customer's CRM vendor hosts it; connecting it to the Service transfers to the United States whatever the Service reads from it (Annex I), and what a feature sends to an AI provider goes on to wherever that provider processes it (Section 8.1).
7.5 Conflict. Where the SCCs or the UK Addendum conflict with this DPA, the SCCs or the UK Addendum prevail.
7.6 Government access. To the extent the law allows, AssemblyWright will promptly tell Customer about any legally binding request from a public authority for Customer Personal Data. AssemblyWright will review the lawfulness of the request, and will challenge it where, after careful assessment, it concludes that there are reasonable grounds to consider it unlawful, as Clause 15 of the SCCs requires. It will disclose only the minimum the request requires. Where the law forbids it to tell Customer, AssemblyWright will use reasonable efforts to obtain a waiver. On request, and to the extent the law allows, AssemblyWright will tell Customer whether it has received any such request, including a national-security order, concerning Customer Personal Data.
8. AI processing
8.1 What is available, and where it runs. The Service is AI-powered throughout: every Build stage and review gate, a second-opinion or two-approaches stage where Customer switches Model effort on, a conversation with a Wright, the Guide's "Ask" lane, a Maintenance Workflow, the questions the Service asks before a Build, the workflow builder, Content Desk drafting and a Build started in response to a Paddle event each send content to an AI provider and keep what comes back. Image generation inside a Build sends the image prompt to the image model set for Customer's Workspace, which is Google's image model on Vertex AI unless another is named: the model the Service names by default was retired by Google on 30 June 2026, so image generation works only where a current image model is set. AssemblyWright, or, once role enforcement is on, Customer's Workspace administrator, may name a model of another provider Annex III lists as able to receive Customer Content, and the prompt goes to it only where that provider is connected. Which provider answers every other request is decided by a chain — an ordered list of models — that AssemblyWright's operator configures for the whole Service and, where the operator chooses, for one feature or one Wright, and can change at any time; only its entries from the providers Annex III lists as able to receive Customer Content — Anthropic, Google Cloud Vertex AI, Cloudflare Workers AI and OpenAI — that are connected are ever called, and the Service skips any other entry (Section 8.3). A provider is connected when a credential for it is held or, for Google Cloud Vertex AI, which takes no credential, when the Service is configured with a Google Cloud project for it. If the provider that would answer is unavailable, the request goes to the next in the chain (Section 8.2), except in the features that call a model directly, below. As of the effective date, the chain every feature and Wright uses unless the operator has given it its own is Anthropic's Claude Sonnet 5.5 first, then Google Cloud Vertex AI's Gemini 3.8 Flash, then its Gemini 3.5 Flash-Lite. The Solution Architect and Data Architect Wrights use Claude Opus 5.5, then Claude Sonnet 5.5, then the same two Gemini models. The Wrights whose work is documentation and other writing — the Trainer, Release Manager, Project Manager, Executive Sponsor, FinOps Analyst, Knowledge Agent, Foreman, Social Media Manager, Email Marketer, Support Lead and Customer Success Manager — and the Service's own AI features — the questions the Service asks before a Build and its workflow fit check, the Guide, a conversation with a Wright outside a Build, Maintenance Workflows (other than one an architect Wright runs), Content Desk drafting, the advisors, the Knowledge Agent, Bench routing and question triage (the check the Service runs on a question a Wright raises before it stops a Build) — use Claude Haiku 5.5, then the same two Gemini models; the workflow builder follows the default chain. The features that call a model directly — the questions the Service asks before a Build, the workflow fit check, the advisors, the Knowledge Agent and Bench routing — each use the first usable model of their own chain or, where none of it can be used, the first of the default chain (Claude Sonnet 5.5 as of the effective date), and if that call fails, the request is sent to no other model. Anthropic's Claude models are reached over Anthropic's own API, and every request to them is held to processing in the United States; a Claude model that cannot be held there is never called: the request goes to the next model in the chain or, in a feature that calls a model directly, is not sent. Where a newer Claude Opus, Sonnet or Haiku in the Service's catalogue costs no more than the one a chain names and can be held to processing in the United States, the Service may call it in that one's place; it is a model of the same listed provider, under the same terms. Cloudflare Workers AI and OpenAI are connected, but are in none of those chains as of the effective date; each answers only where the operator routes a feature or a Wright to it, a second-opinion or two-approaches stage picks one of its models, or a Workspace's image model is one of its models. Google Cloud Vertex AI also answers where a Workspace picks a Gemini model for a second-opinion or two-approaches stage, and for the image prompt, where Google's image model is the Workspace's image model. A Workspace that switches Model effort on may pick a second model from those providers that are connected, within any list the operator allows for it. Each of those providers is under terms that do not permit it to use what is sent to train its models. Where a request is processed depends on the provider that answers it: Anthropic's API processes it in the United States, and Google Vertex AI processes a request to Gemini 3.8 Flash or 3.5 Flash-Lite in Google's United States multi-region; Google's image model and any other Vertex model run in the Google Cloud region the Service's deployment is configured for; Cloudflare Workers AI processes a request on Cloudflare's global network, and OpenAI in its own processing locations under its terms — either of which can be outside the United States, because nothing in the Service holds a request to them to a region. A listed provider other than Google Cloud Vertex AI that is not connected on the effective date, and any provider not listed in Annex III, begins to receive Customer Content only after the notice in Section 5.2, and only if its terms meet Section 8.3; Google Cloud Vertex AI, which runs within Google Cloud, the platform that already hosts the Service (Annex III), may receive it on the occasions this Section describes whether or not the Service was connected to it on the effective date. AssemblyWright may change models within a listed provider, and which of the connected listed providers the chain uses and in what order, at any time; it will not move the processing of a request that Anthropic or Google Vertex AI answers outside the United States without the notice in Section 5.2.
8.2 What is sent, and what is kept. When a feature runs, the content it needs is sent to the AI provider that answers, in the request that produces the answer. For a Build stage that can include the Build request and intake answers; the Knowledge Base and the configuration imported from a Connected Org (sent without a size cap today); the Deliverables of earlier stages; the Wright's Bench slice and briefs; the results of any tool the Wright used, which can include records read from a Connected Org; the stage's own instructions and skills, including any Customer edited; and, for a second-opinion or two-approaches stage, the draft being reviewed. A conversation with a Wright sends the earlier turns of that conversation; the Guide sends the question, the current page and a capped snapshot of the Workspace (workflow names, the Wright roster, connection status, the last three Builds and the Knowledge Base's size). If the provider that would answer is unavailable, the same request may be sent to the next provider AssemblyWright has configured, within the rule in Section 8.3. The full prompt is not kept. AssemblyWright keeps what comes back — Deliverables, drafts and critiques, review verdicts, chat replies, briefs and proposals — in Customer's Workspace as Customer Content, with the events of each Build (including what each tool was asked to do and whether it succeeded — not the data it returned, except a failed call's error message, of up to 200 characters, and the result of the check run on the org before a metadata deploy — and the text of each human gate) in the Build's timeline, and the token counts, model and cost of each call in Customer's usage records. A conversation with a Wright is kept to its newest 200 turns; the Guide's conversation stays in the User's browser and is not stored. No User's conversation is shown to AssemblyWright by any screen, and AssemblyWright opens one only as Section 3.4 allows.
8.3 No training tiers for Customer Content; the one exception. AssemblyWright will send Customer Content only to an AI provider account whose terms do not permit the provider to use it to train or improve its models. Several providers' free tiers do permit that. The Service's own catalogue of providers records, for each, whether its terms may permit training, and in production — which the Service recognizes by its Vertex AI configuration — a provider so marked is never selected: not as the first model, not as a failover, not for a feature, not for a Wright, not from a saved choice; if no other provider can answer, the request fails rather than being sent. That check can be switched off only by a deliberate setting on the production machine, which AssemblyWright will not set for a deployment serving customers. AssemblyWright's development and test environments use other model tiers, including Google AI Studio's free tier, with test data only and never Customer Content. Annex III states, for each provider, whether it receives Customer Content as of the effective date, and on what occasions; any other provider becomes eligible to receive it only after the notice in Section 5.2, as Section 8.1 describes, and a provider whose terms permit training is never eligible. The one exception is the Help assistant — the "Help" control in the app, answered by Uiia, another service of AssemblyWright's own company (Section 5.5). It is switched off as of the effective date. While it is on, it reads only AssemblyWright's approved help articles, the questions typed into it with the last few turns of that conversation, and, if the person asks to be contacted, their email address; the Service never sends it Deliverables, Build content, Knowledge Base material or anything from a Connected Org; and it may answer on a provider tier that keeps and trains on what it is sent. What a person types into it is AssemblyWright's own processing under Section 2.2(f), outside this DPA, and Customer will not use it for Customer Personal Data or other confidential Customer Content (Section 4(j)).
8.4 Provider terms. Each AI provider processes the content of a request under its own API terms, which may allow it to keep that content for a limited period, for example to detect abuse, before deleting it. No AI provider is currently engaged under zero-data-retention terms. AssemblyWright has not negotiated separate terms with any provider, and does not control, and does not warrant, a provider's retention beyond what that provider's terms say. The Service calls providers through an open-source client library that runs on AssemblyWright's own machine and sends each request only to the provider that answers.
8.5 Wrights hold tools, and what they may do to a Connected Org is Customer's setting. A Wright can read from a Connected Org during a Build, and, where Customer allows it, write to one; what it reads can steer what it does next (Section 6.6 of the Terms). Writes are governed by one Workspace-wide setting a Workspace administrator chooses: read-only (no writes; the write tools are not offered), gated (the default — every write pauses at a human checkpoint for a User to approve), or autonomous (writes run without stopping, only in a Salesforce org the Service has positively identified as a sandbox, scratch or Developer Edition org from Salesforce's own address or the org's own type captured at connection — never from a label a person typed; an org it cannot classify is treated as production; and a "production" tag a person applied wins even over a sandbox address). In every mode but read-only, every write to a Dynamics 365 or HubSpot environment, every bulk data update and its undo, and every email send pauses for a person. A Maintenance Workflow holds no tools and activates nothing. A Build started automatically in response to an event from Customer's own Paddle account runs under the same setting and, in an autonomous Workspace, asks first anyway. The models hold no credentials of their own: every call to a Connected Org is made by the Service, with the credentials Customer supplied, within the permissions they carry, and is recorded in the Build's timeline; what the Service captures before a write, and what that capture can and cannot restore, is stated in Section 7.6 of the Terms and Annex II. AssemblyWright does not use AI to make decisions that produce legal or similarly significant effects on data subjects, and Customer will not use the Service to do so: a Deliverable is a draft for Customer's review, and a write to an org is a change Customer's User instructed.
8.6 Outputs may be inaccurate. AssemblyWright makes no representation that AI output is accurate, complete or fit for Customer's purpose. A Deliverable may misstate a record, misname a person, or describe a Connected Org's configuration wrongly, and a proposed write may be wrong; Customer is responsible for reviewing output before relying on it, deploying it to an org, sending it to a person or publishing it. The Service's review gates, pre-flight advisories and provenance labels (which mark what came from the org, what was inferred and what needs a person's input) assist that review and do not replace it.
9. Return and deletion
9.1 Export. While a Workspace is open, Customer may export its Deliverables (the current version of each), its Knowledge Base, its list of Builds and the names of its workflows, Wrights and connections, using the product's own export, on every package, without charge; and each Deliverable singly as a Word file. Once role enforcement is on, a Workspace admin can also read the newest entries of the audit trail in the product. AssemblyWright will provide other records on written request, as Section 6.2 describes — the audit trail as kept within 30 days, and earlier versions, Build timelines, chat and the rest of the Workspace's configuration within a reasonable time — not more than once a quarter for each Workspace (and once after termination), unless the law requires more, as Section 11.5(d) of the Terms provides. Where Customer keeps Deliverable text or rollback payloads in its own Salesforce org under the custody choice in Section 7.7 of the Terms, those are already in Customer's hands.
9.2 When the Service ends.
(a) Cancelling a subscription is not termination. Section 4.11 of the Terms applies at the end of the paid term, and nothing is deleted at cancellation; Customer Personal Data stays until it is deleted under this Section.
(b) An owner closes a Workspace. Closing is an owner's act, confirmed by typing the Workspace's name (or, while Annex II's role enforcement is switched off, AssemblyWright's act at an owner's written request), and it takes effect at once: every stored credential for every Connected Org and Connected Service is erased immediately, so the Service can no longer reach any of them, and nobody — the owner included — can open the Workspace. For 30 days an owner can reopen it, which puts everything but the erased credentials back; during those 30 days it cannot be opened to take an export, so Customer exports first, or reopens to export. After the window, AssemblyWright erases the Workspace's rows and files; that erasure is run by a person, not by a scheduled job, so it may happen some days after the window closes, and AssemblyWright does not promise a date, but does not reopen a Workspace once the window has passed except as Section 9.5 describes for a restore. Erasure waits while the Customer Account is suspended or held ((c)) and for 30 days after that ends. Closing a Workspace removes nothing from a Connected Org — changes deployed there are in Customer's own system — and nothing already published to a Profusia workspace or posted to a network. Sections 9.4 to 9.7 still apply.
(c) AssemblyWright suspends the Customer Account, or either party terminates the Agreement. A Customer Account AssemblyWright has suspended, or must preserve for an investigation or legal process (Section 9.6), is held, not erased: none of its Workspaces is erased — not after a closure under (b), not on a request under Section 9.3, and no permanent deletion from its trash is carried out by AssemblyWright — until the suspension or hold ends, except a Workspace being erased after the Agreement was terminated and the export window below has passed, which only a legal hold delays (Section 16.13 of the Terms); when it ends, nothing it held is erased until that erasure's own waiting period has passed again, counted from that day (30 days for a closed Workspace, during which an owner can reopen it). Apart from those erasures waiting, a hold changes nothing in the Workspace; what Customer's Users could delete before, they still delete themselves once the Workspace is reopened to them. Records that expire by age (Section 9.5) go on expiring meanwhile, unless AssemblyWright keeps them, or a copy of them, under Section 9.6. When either party terminates the Agreement, each of Customer's Workspaces is closed as in (b), with its credentials erased in the same way. For 30 days after termination, a Workspace owner may ask legal@assemblywright.ai for an export, and AssemblyWright will either reopen the Workspace long enough for an owner to use the product's own export, after disabling anything that was the reason for the termination, or provide the export itself by a secure method it chooses. Reopening reopens the whole Workspace to its members, so AssemblyWright chooses it only where that is safe. AssemblyWright will do one or the other unless doing so would be unlawful or would create a security risk. AssemblyWright will not provide material that is unlawful to hold or return, material taken down on a valid legal notice, or anything an authority directs it to withhold. After that window, AssemblyWright erases the Workspace in the way (b) describes, without a further reopening period, unless it must preserve it under Section 9.6; a legal hold delays that erasure, and once the hold ends it waits 30 days more.
(d) A Workspace nobody uses. As of the effective date, AssemblyWright does not close or erase a Workspace for inactivity. If it introduces such a rule, it will give the notice in Section 12.3(c) and will tell the Workspace's owners by email at least 30 days before closing it (Section 4.11 of the Terms); it will never apply to a Workspace with a live subscription or on a signed Order, and a closure under it will follow (b), with the 30 days in which an owner can reopen.
(e) A Customer Account with no Workspace. AssemblyWright's operator may delete a Customer Account only once it holds no Workspace. The billing, entitlement and operator records against it are AssemblyWright's own (Section 2.2) and are kept as Section 9.4 describes.
9.3 Earlier erasure, and confirmation. An owner may ask, by writing to legal@assemblywright.ai from an owner's address, for a closed Workspace to be erased before the 30-day window in Section 9.2(b) ends. Where reasonably practicable, AssemblyWright will do so within ten business days of confirming that the request came from an owner. The Service has no control for this, so AssemblyWright does it by hand (Section 3.11), and not while the Customer Account is suspended or held (Section 9.2(c)). On Customer's written request, AssemblyWright will confirm in writing that erasure has taken place, noting what Section 9.4 keeps. Cancel any subscription that covers only that Workspace first; if one is still running when the Workspace is erased, it runs to the end of its term without a refund, as Section 11.5(b) of the Terms provides.
9.4 What remains after erasure. After erasure, AssemblyWright keeps Customer Personal Data only: (a) in database backups, which expire as Section 9.5 describes; (b) in the record that a person was removed from a Workspace (the Workspace's id and the person's account id or email address), kept so that the person is not silently re-added, and which AssemblyWright holds as its own record under Section 2.2(c) and removes on request once the Workspace is erased; (c) as an email address on its email provider's account-level list of addresses that bounced or complained, so that the Service never writes to it again; and (d) where the law requires, or as Section 9.6 describes, for as long as that requires and while continuing to protect it. Copies already delivered to the sub-processors in Annex III, or to systems Customer directed — a Connected Org, a Profusia workspace, a social network, Google Docs, Jira, Confluence, GitHub, or the people Customer emailed — are held under their own terms, and AssemblyWright cannot recall them. AssemblyWright also keeps, as its own records: the Customer Account's billing records and the log of billing events from Paddle (the provider's event ids, types and outcomes, never a payload); the package, trials, grants and prices the Customer Account had; the ledger of identities that reached its operator area, which names the people who did; its own administrative audit trail of operator acts and the notes its operator kept about the Customer Account; the requests sent through its website on their own 12-month clock; and the structured request and web-server logs on the machine, which name a signed-in account and Workspace by id and have no fixed limit yet (Annex I). None of these carries Deliverable, Knowledge Base or CRM content, except that the operator's notes and a switch-off's recorded reason may describe the matter concerned.
9.5 Backups and operational records. The Service's database holds the Service's records — Deliverables and every version, Knowledge Base entries, Build timelines, chat, Bench memory, captured prior values held in AssemblyWright's custody, credentials (encrypted), usage, audit and the rest of Annex I — on the disk of one Google Cloud machine, which Google encrypts at rest. Scheduled off-server copies of that database to Google Cloud Storage are being set up and are not yet verified as running: a copy procedure exists and verifies each copy is complete before upload, the schedule was installed on the production machine on 12 October 2026, the storage bucket it writes to answered an anonymous probe on 21 October 2026 as an existing private bucket does (on 9 October 2026 it had answered that it did not exist), and AssemblyWright will state here and in the Privacy Policy, once it has seen copies land and has timed a restore from one on the production machine, that they run and for how long each copy is kept. Until then, Customer should assume that a loss of that machine's disk may be unrecoverable, and keep its own exports (Section 9.1). A restore from a copy was rehearsed on a separate machine on 18 August 2026, not yet on the production one, and the hosting provider's disk-snapshot schedule has not been confirmed. Once copies run, erased database records will remain in them until the copies age out, for the period then stated, and AssemblyWright will use them only to recover the Service from a failure and to test that recovery works, except as Section 9.6 allows. Any copy AssemblyWright takes by hand — a dump it downloads, or an export it makes before a restore — is kept only on a device or in an account under AssemblyWright's control, and is deleted once that recovery or test is complete, and in any case within 30 days of being taken, unless AssemblyWright keeps it under Section 9.6, for as long as that purpose requires. If AssemblyWright restores from a copy, it re-applies the erasures made since that copy was taken, as far as the records it still holds identify them, and tells Customer if any could not be re-applied, or if a failure leaves it unable to tell what was erased since then, so that Customer can check and erase again. Verification screenshots and video are stored as files on that machine, on a storage volume outside the database that survives a replacement of the application's container, are kept for 30 days and up to 512 MB per Workspace by default, and are not in any database copy; Customer should treat them as evidence to download, not an archive. Deliverable bodies and rollback payloads Customer keeps in its own Salesforce org under its custody choice are never in AssemblyWright's copies. The operational records listed in Annex I expire on the cycles stated there and in the Privacy Policy's retention schedule, which also says which records have no age-based expiry.
9.6 Preservation and disclosure. Where the law requires it, including the duty to report and preserve child sexual abuse material, or where reasonably necessary for an investigation of a breach of the AUP, for legal process, or to establish, exercise or defend a legal claim, AssemblyWright may preserve Customer Personal Data and related records beyond the periods in this DPA, for as long as that purpose requires, and holds a Customer Account it must preserve as Section 9.2(c) describes. It discloses them only as Section 16.13 of the Terms allows — for example to law enforcement, the National Center for Missing & Exploited Children or a court. For Customer Personal Data transferred under the SCCs or the UK Addendum, AssemblyWright discloses to a public authority only as Section 7.6 and Clause 15 of the SCCs allow, except where the law requires a report, such as a report to the National Center for Missing & Exploited Children, or where Data Protection Laws permit a disclosure to protect a person's vital interests. AssemblyWright will tell the Workspace owner where it is lawful and safe to do so, will continue to protect what it preserves, and will use it only for that purpose.
9.7 Deletion rather than return for derived records. For a Wright's Bench memory, its chat and notes, its briefs, the Service's checkpoints of the Knowledge Base, the drafts and critiques behind a second-opinion or two-approaches stage, Build timelines and verification evidence, Customer chooses deletion rather than return, under Article 28(3)(g) GDPR and Clause 8.5 of the SCCs: when a Workspace is erased they are erased with it and are not returned. Until then, AssemblyWright will provide the personal data in them on Customer's written request, as Section 6.2 describes.
10. Audit
10.1 Information. AssemblyWright will make available to Customer the information reasonably necessary to demonstrate compliance with this DPA, including the descriptions in Annexes II and III, the public trust and privacy pages (assemblywright.ai/trust and assemblywright.ai/privacy, and the Privacy Policy), its written security questionnaire, the dated output of its dependency vulnerability scans, and, on request and under confidentiality, its written internal policies (access review, incident response, change management, data classification and retention, and vendor management). Those pages and policies describe AssemblyWright's practice on the date they show; they are not part of this DPA, and where they differ from it, this DPA governs. Two of those policies were written before the Service's current isolation and access controls shipped and are being brought current; until they are, Annex II, not the policy text, is AssemblyWright's statement of what is in place, and AssemblyWright will say so when it supplies them. Its first periodic access review has not yet been run, and its incident-response plan has not yet been exercised.
10.2 Questionnaire. For a Customer on a paid package or a signed Order, once in any 12-month period, AssemblyWright will complete Customer's reasonable written security or privacy questionnaire at no charge, and may answer any question by reference to this DPA, assemblywright.ai/trust or its own written questionnaire where they answer it. For a Customer on a trial or paying nothing, the descriptions in Section 10.1 are AssemblyWright's answer.
10.3 Audit. Where that information is not sufficient for a Customer subject to Data Protection Laws, Customer may audit AssemblyWright's compliance with this DPA once in any 12-month period, on 30 days' written notice, and also after a Personal Data Breach or where a supervisory authority requires it. Audits are remote and document-based: AssemblyWright has no premises of its own, and its infrastructure is operated by its sub-processors, whose own audit reports satisfy any audit of their facilities. The auditor must be Customer or an independent auditor who is not a competitor of AssemblyWright and who signs a confidentiality agreement reasonably acceptable to AssemblyWright. Audits take place during business hours and without unreasonable disruption. Customer bears its own costs. AssemblyWright may charge for its own time at a reasonable rate agreed in advance — for a Customer on a trial or paying nothing, all of it, and otherwise its time beyond eight hours for any one audit — unless the audit finds a material breach of this DPA by AssemblyWright. The parties agree that audits under this Section satisfy Clause 8.9 of the SCCs. This Section does not limit a supervisory authority's right to audit.
10.4 No certifications. AssemblyWright holds no SOC 2 report, ISO 27001 certificate, HIPAA attestation or third-party penetration test, and none is in progress. This is stated plainly rather than implied otherwise; a customer whose procurement requires one should raise it before contracting.
11. Liability
11.1 One cap. Each party's total liability arising out of or relating to this DPA, the SCCs and the UK Addendum (to the extent the SCCs and the UK Addendum permit a limitation between the parties), taken together with the rest of the Agreement, is subject to the exclusions in Section 14.1 of the Terms, the single aggregate cap in Section 14.2 of the Terms and the exceptions in Section 14.3 of the Terms. This DPA does not create a separate or additional cap, and claims under it count toward that same cap. Loss or alteration of data in a Connected Org through a write Customer instructed, and loss of data in a Connected Org that rollback does not cover (Section 7.6 of the Terms), are within that cap and those exclusions.
11.2 A data-protection claim is not a confidentiality claim. For the purposes of Section 14.3 of the Terms, a breach of this DPA or of Annex II, and any Personal Data Breach, is subject to the cap and is not treated as a breach of Section 10 (Confidentiality) of the Terms, except to the extent it results from a party's willful misconduct (as Section 14.3 of the Terms defines it) or fraud.
11.3 Fines. Each party bears any fine or penalty a supervisory authority imposes on it for its own infringement of Data Protection Laws, and may not recover that fine from the other party, except that Customer will reimburse AssemblyWright for a fine or penalty imposed on AssemblyWright to the extent it results from Customer's breach of Section 4 (for example, processing without a lawful basis, connecting an org without authority, an unlawful instruction, or putting into the Service — or letting it read from a Connected Org — data that AUP Section 3 excludes). That reimbursement is part of Customer's obligations under Section 13.2 of the Terms; otherwise, Section 13.2 of the Terms does not apply to such fines. This does not limit Customer's obligation under Section 4 to defend AssemblyWright against, and pay the reasonable legal fees and costs of, an investigation or proceeding by a supervisory authority arising from Customer's breach of Section 4.
11.4 Leaving after a Personal Data Breach. If a Personal Data Breach caused by AssemblyWright's breach of this DPA affects Customer Personal Data, Customer may terminate the Agreement by written notice within 60 days of AssemblyWright's notice of it and receive a pro-rata refund of the fees prepaid for the unused term, as Section 14.5 of the Terms and Section 5 of the Refund Policy provide. A refund under this Section counts toward the cap in Section 14.2 of the Terms.
11.5 What this Section does not limit. Nothing in this DPA limits a data subject's rights against either party under Data Protection Laws or the SCCs, or any liability that cannot lawfully be limited.
12. Term, execution and changes
12.1 Term. This DPA takes effect when Customer accepts the Agreement and continues until AssemblyWright has ceased all processing of Customer Personal Data, including in backups once they run (Section 9.5). After the Agreement ends, the free questionnaire in Section 10.2 and the free time in Section 6.2 no longer apply; AssemblyWright's other obligations continue for the Customer Personal Data it still holds.
12.2 Execution. This DPA is incorporated into the Agreement by reference. By accepting the Agreement, each party is treated as having signed this DPA, the SCCs and the UK Addendum, including their Annexes, as of that date. AssemblyWright will countersign a copy on request to legal@assemblywright.ai.
12.3 Changes. AssemblyWright posts each version of this DPA with its effective date and keeps every earlier version, which it will send on request. AssemblyWright may update this DPA: (a) at any time, to reflect a change in Data Protection Laws, a decision of a competent authority or new standard contractual clauses, or to address a security risk or an active harm, giving notice as soon as practicable; (b) by posting it, where the update is not material; or (c) otherwise, by email to the Workspace owner at least 30 days before it takes effect, provided it does not materially reduce the protection of Customer Personal Data. If Customer objects to a material update under (c), Customer may cancel before it takes effect and AssemblyWright will refund, through Paddle, the fees prepaid for the unused term, as Section 16.3 of the Terms provides. Changes to the list of sub-processors follow Section 5 rather than this Section. An update recording that off-server backups run, and for how long each copy is kept (Section 9.5), adds protection and is made under (b).
12.4 Governing law and disputes. The SCCs keep the law and courts they name in Section 7.1, and the UK Addendum keeps the law and courts of England and Wales. Otherwise, this DPA is governed by the law that governs the Terms, and disputes under it are resolved as Section 15 of the Terms provides.
12.5 Notices. Notices to AssemblyWright under this DPA go to legal@assemblywright.ai, with a copy to Evadaroo & Company, LLC, 502 W 7th St, Ste 100, Erie, PA 16502, USA. Notices to Customer go to the email address on file for the Workspace owner(s) — the address the Service holds for them or, where it holds only an account id, the address in the sign-in account its identity provider holds for AssemblyWright (Section 2.2(a)) — which Customer will keep current.
12.6 Successors. This DPA binds and benefits the parties and their successors and permitted assigns, and it goes with the Agreement whenever the Agreement is assigned under Section 16.4 of the Terms.
Annex I — Details of processing
A. List of parties
- Data exporter / controller: the Customer that accepted the Agreement. Contact: the Workspace owner's email address on file. Role: controller (or processor acting for a third-party controller, such as a consultancy working in its client's Connected Org). Activities: using the Service described in the Agreement. Signature and date: by acceptance of the Agreement, on the date of acceptance (Section 12.2).
- Data importer / processor: Evadaroo & Company, LLC, a Pennsylvania limited liability company trading as AssemblyWright AI, 502 W 7th St, Ste 100, Erie, PA 16502, USA. Contact: legal@assemblywright.ai. Role: processor. Activities: providing the AssemblyWright AI service described in the Agreement — running governed, AI-drafted and AI-reviewed Builds that produce Deliverables for CRM delivery work, grounded in the configuration of a Connected Org, and, on Customer's instruction, reading from and writing to that org with prior-state capture; work tracking; the connections Customer elects. Signature and date: by Customer's acceptance of the Agreement (Section 12.2); a countersigned copy on request.
B. Description of transfer
| Item | Detail |
|---|---|
| Categories of data subjects | Customer's Users (owners, admins, operators and viewers) and the people Customer invites; Customer's own staff, clients, prospects, partners and end users whose records, cases, activities or contact details exist in a Connected Org and are read, captured or written by the Service; Customer's own CRM administrators and developers, named in the org's setup history a Process Documentation Build reads; individuals named in Build requests, intake answers, Deliverables, Knowledge Base entries, delivery-board content or Wright chat; people whose screens or names appear in verification screenshots and video; buyers whose events Customer's own Paddle account sends to the Service; the people in an email campaign's audience or suppression list; and any person a Content Desk post names. |
| Categories of personal data | Membership data: each User's role in the Workspace with the account id and email address their sign-in carries, and who joined through which identity-provider organization (the record that a person was removed is AssemblyWright's own record under Section 2.2(c), listed in the row below). Content data: whatever appears in Build requests and intake answers; Knowledge Base, Lore and delivery-board entries; the configuration imported from a Connected Org (objects, fields, automation, profile and permission-set names, naming conventions and dependency graphs — not record data); the records a Wright's read tools return during a Build, which can be quoted in a Deliverable (the Build's timeline records what each tool was asked to do — which can include a record id, the text of a query and the field values a write sets — and whether it succeeded, not the data it returned, except a failed call's error message, of up to 200 characters, and the result of the check run on the org before a metadata deploy); Deliverables and every version, with the drafts, critiques and review verdicts behind them, including the appendix of the org's 180-day setup history with the names of the administrators who made each change; Bench memory; Wright chat and notes; briefs; a role profile a User writes for a Wright (which the Service strips of the person's name, employer and dates); rollback artifacts (prior metadata) and the prior record values captured before a bulk update or targeted snapshot, in AssemblyWright's custody unless Customer chose its own org; the ledger of every test record the Service inserted (synthetic values only, with unreachable email and phone patterns); verification plans, screenshots and video of the org's screens as walked; Content Desk items and the label and account identifier of each connected social account with who connected it; email campaign items (subject, body and the CRM query that defines the audience — never a resolved address list) and the Workspace's suppression list (address and reason); the events Customer's own Paddle account sends (type, ids, the buyer's email address and name, a consent flag, product and amount facts, a hash of the message — never the raw payload); and the Workspace's links to documents published in a Profusia workspace. Usage data: the audit trail, which names the acting person by email address or account id and the network address the request came from, with the action, the ids, names and counts it concerns, and the names of the fields a change touched (never a credential's value, though the new value of some non-secret settings, such as a retention period or a custody mode, is recorded); each Build's timeline; usage and cost records (Build, stage, Wright, the model that actually answered, tokens and cost); in-app notifications (a Workspace event, naming no recipient); device registrations for the iPhone app (the account id and email address, the device's push token, platform, name and app version); and the record of who approved or decided each post, email or Paddle-event response. Credentials Customer supplies (encrypted at rest, never returned): for each Connected Org and Connected Service, and the social-account tokens the Content Desk holds, which are Customer's secrets rather than personal data but are listed here because they identify Customer's accounts. |
| AssemblyWright's own records, listed for transparency | These are processed by AssemblyWright as controller under Section 2.2, not under this DPA: the sign-in account at Clerk; the Customer Account, its package, trials, grants, switch-offs, agreed price, billing records and the log of billing events from Paddle (ids, types and outcomes, never a payload); the record of who accepted the Agreement's documents, where the Service keeps one; rate-limit counters (network addresses, in memory); the structured request log and the web server's access log (method, path including any query string, status, timing, and the signed-in account and Workspace by id — never a request body); browser crash reports (the message and the browser's user-agent string); the ledger of identities that reached the operator area; the record that a person was removed from a Workspace (the Workspace's id and the person's account id or email address, kept so that an identity-provider synchronization does not re-add them — Section 9.4(b)); the requests sent through the Request access form (name, work email, company, platform, what they asked for, a sandbox confirmation, free text, team size, how they heard of AssemblyWright and the page they came from — no network address); the operator's notes and AssemblyWright's own administrative audit trail of operator acts; and what a person types into the Help assistant while it is switched on. |
| Special categories | None intended. Customer must not put into the Service, or let it read from a Connected Org, the data described in AUP Section 3. Ordinary CRM records may incidentally contain special categories of personal data, as Section 4(i) describes; the Service has no controls designed for those categories, and Customer narrows the credentials it supplies to keep them out. |
| Frequency | Continuous, for the duration of the Agreement; reads from and writes to a Connected Org occur when a Build, a bulk operation, a verification, an import or a scheduled release runs. |
| Nature and purpose | Hosting and storage; running the Build pipeline and its review gates with AI providers (Section 8); importing a Connected Org's configuration to ground that work; reading records from a Connected Org where a Wright's tools are allowed to; writing to a Connected Org on instruction, with prior-state capture and rollback; inserting and removing test data; walking an org's screens for verification and training captures; work tracking; audit; metering; email the Service sends for the Workspace (notifications to the owner, and service email Customer approves to its own buyers); push notifications to phones Customer's Users register; scheduled Maintenance Workflows; optional publication to a Profusia workspace, posting to social accounts, export to Google Docs, Jira, Confluence or GitHub, and Paddle-event responses, each only where Customer connects and instructs it; database backups once they run; support; and enforcement of the Agreement (suspension). Account, billing and website-request processing is AssemblyWright's own (Section 2.2). |
| Retention | As the Privacy Policy's retention schedule states. In summary: Deliverables, their versions, Knowledge Base entries and delivery-board content until deleted by Customer or until the Workspace is erased, and Deliverables also through the trash until permanently deleted (a Workspace can set its own clocks for Deliverable retention, versions kept and trash purging; they ship off); Builds, their timelines and usage and cost records until the Workspace is erased (Customer cannot delete these singly); Bench memory until the Workspace is erased; a Wright's chat to its newest 200 turns and its briefs to the newest 100; Knowledge Base checkpoints to the newest 25; Bench items archived when their confidence decays, pinned items never; rollback artifacts to the newest 50; deploy packages to the newest 50 and deploy attempts to the newest 200; captured prior values 30 days by default (configurable per Workspace, 0 to 3,650 days, in either custody), the receipt that a capture existed and was destroyed kept after it; bulk-update jobs to the newest 200 and targeted snapshots to the newest 100; test-data ledgers for the newest 200 fully-removed batches, and a batch whose records are still in the org for as long as they are; verification evidence 30 days and 512 MB per Workspace by default; the audit trail to the newest 2,000 entries per Workspace; crash reports to the newest 500; in-app notifications until the Workspace is erased; device registrations until the app signs out on the device or a person removes it (a dead token is switched off, not deleted); Paddle-account events 180 days; email campaign items until the Workspace is erased, and suppression entries until a person removes them; Content Desk items until the Workspace is erased (a posted item cannot be deleted); stored credentials until disconnected, and all of them at once when the Workspace is closed; a closed Workspace, erased by hand once 30 days have passed; a suspended or held Customer Account, not erased until the suspension or hold ends (Section 9.2(c)); database copies, once they run, for the period then stated. AssemblyWright's own records: website requests 12 months; the operator-area ledger's admitted entries without limit and its refused entries to the newest 500; request and web-server logs without a fixed limit; billing records as tax and accounting law requires; the removal record until the person is re-added or AssemblyWright removes it on request. |
| Duration | For the term of the Agreement, and then until erasure as Section 9 describes. |
| Sub-processor transfers | As in Annex III, for the same subject matter, nature and duration as this DPA. |
C. Competent supervisory authority. Determined under Clause 13 of the SCCs by the Member State of the data exporter's establishment or of its EU representative; where the data exporter is not established in the EU and has no representative, the authority of the Member State where the data subjects are located.
Annex II — Technical and organizational security measures
These describe the measures in place on the date of this DPA. Nothing here is aspirational: where a measure is partial, switched off or missing, the stated limitations at the end say so. AssemblyWright may change these measures, but not in a way that materially reduces the overall protection of Customer Personal Data. The live posture of several of them is published by the Service itself at an open configuration address, so that a Customer can check rather than take AssemblyWright's word.
Tenant isolation. Every Workspace-owned table carries a Workspace identifier, and the filter is applied in one place, at the data layer, to every read and write the application makes: a read outside the Workspace's scope returns nothing rather than everything, a write outside it is refused rather than stored unattributed, relationship loads stay inside the Workspace, and bulk updates and deletes are scoped, which is what stops a restore or a bulk operation crossing a boundary. The application refuses to start with isolation switched on and authentication off. An isolation script runs the proof against a real database — another Workspace's row invisible by query, by count and by direct key — and passed every check when it was last run on 2 September 2026. Credentials and settings are stored under the Workspace's own namespace and never fall back to a shared value. Isolation is enforced in production, as the open configuration address reports. Hand-written database statements on start-up and administrative paths bypass the filter by design and touch no Customer Content; isolation is logical, within one database on one machine.
Access control. Identity is provided by Clerk: every application route verifies a signed session token (RS256) against Clerk's published keys, checking issuer and expiry, and the Service holds no Clerk secret key. The only paths that answer without a session are: the health, readiness and authentication-readiness checks and the public configuration address, which carry no Customer data; the browser crash-report beacon; the website's Request access form; the payment page, which loads only when a Paddle transaction id is present; and doors that are open because an outside system calls them and that verify a signature or a signed single-use token instead — the two billing webhooks (Paddle and the unused Stripe adapter), the webhook for a Workspace's own Paddle account, the email unsubscribe and bounce addresses, the social-network and Salesforce-hosted-MCP OAuth callbacks — plus the public blog, which serves only approved articles. Four Workspace roles (viewer, operator, admin, owner) are built: starting a Build needs the operator rung, changing Wrights, workflows, connections, settings, billing or an org-touching operation outside a Build (bulk update, test data, rollback, snapshot restore, deploy) needs admin or owner, and managing people needs the owner. Enforcement of those roles for Customer's own Users switches on when the identity provider's sign-up mode is restricted; as of the date of this DPA sign-up is open and that enforcement is switched off, so the Service refuses Customer's Users the actions that run work or reach a Connected Org — starting a Build, approving a gate, Wright chat, editing Wrights, workflows and the Knowledge Base, and connecting, importing from, disconnecting or writing to a Connected Org — and only accounts AssemblyWright itself lists may take them. A User recorded as a Workspace's owner or admin can still export, close (an owner only) and reopen the Workspace, restore items from its trash and delete them permanently, change its preferences (the execution mode among them) and its retention, custody and evidence settings, and start or manage a subscription; an owner can still invite, re-role and remove members; and a User recorded as an operator or higher can still ask the Guide. A membership added by email takes effect only when that person signs in with a verified address. The operator area — every route under the operator, entitlement, model, model-lab, cost and tenant prefixes, the crash-report administration route and the push-key route — is refused by middleware to anyone but the operator (a verified sign-in at the owner's addresses, a remembered owner account, or a listed identity), and every arrival at it is recorded. Evadaroo HQ reaches that area only with a per-request signed token bound to one method, address and body, valid for at most two minutes, single-use, and admitted only for an identity the operator rule already admits (Section 3.11). Multi-factor sign-in is a setting of Clerk; AssemblyWright does not enforce it and has not switched it on for the production sign-in.
Credential handling. Every credential Customer supplies — a Salesforce private key and client id, a Dynamics client secret, a HubSpot token, a Profusia access key, a Paddle API key, social-account tokens, Jira, Confluence, GitHub and Google Docs tokens, Salesforce-hosted-MCP tokens — is encrypted at rest (Fernet) under a key held in the production machine's environment, outside the database; the connections vault encrypts each saved connection as one whole snapshot rather than field by field; no screen or API returns a stored secret, only the names of the fields set; and a volatile session token is never captured into a saved connection. The Salesforce session the browser runner uses for a verification walk is handed to the runner for that walk and never written into plans, results or logs. Deployment-level secrets the operator sets in the product — the AI providers' API keys and the Apple push key — are stored in the database encrypted in the same way, platform-wide rather than per Workspace; the billing provider's keys and the email provider's key live in the machine's environment, never in the database; the identity provider's key is a publishable one; and the one key that signs checkout references is minted on first use and stored encrypted. There is no managed key service and no key-rotation procedure.
Writes to a Connected Org. One Workspace-wide execution mode (read-only, gated, autonomous) is asked on every write decision, so switching the live org mid-Build retargets the next decision; autonomous writes are permitted only in a Salesforce org the server has positively classified as a sandbox, scratch or Developer Edition org, and every Dynamics 365 and HubSpot write, every bulk update and its undo, and every email send pauses for a person in every mode but read-only. A metadata deploy retrieves the prior metadata first, validates with the org's own tests, and then deploys; the resulting undo point is applied only to the org it was captured in, identified by its normalized host, never guessed. Undoing a pure addition is a deletion that retrieves and stores the current definition first and requires the word "delete" to be typed. A bulk update cannot start writing until it has captured exactly the records and fields it will change, under the custody Customer chose (AssemblyWright's database, or a gzipped file in Customer's own org with only a receipt and a SHA-256 digest kept here); a capture that cannot be stored fails the job rather than downgrading it; ceilings of 10,000 records by default and 50,000 at most apply, and ownership or record-type changes over 1,000 records escalate the warning. Test-data seeding classifies the org live, opens only sandbox and Developer Edition orgs without a typed org name, uses unreachable email and phone patterns, keeps an exact ledger of every inserted record, and never prunes a batch whose records are still in the org. A production target for a release requires its name to be typed, and the release's deploy sheet warns on a production tag without refusing; a bulk update, and a metadata deploy a Wright proposes inside a Build, read no environment tag and carry no production warning. A reviewer's verdict is parsed fail-closed: an unreadable or contradictory verdict means revise.
Transport and browser protections. Every hostname is served over TLS with automatic certificate management, and every one that serves pages with HTTP Strict Transport Security for one year including subdomains, no-sniff, and a refusal to be framed; the two www hostnames only redirect to the site. The application's pages carry a Content Security Policy that forbids framing, plug-ins and base-tag injection; callback, unsubscribe, blog and payment pages carry strict policies of their own, the payment page admitting only Paddle's own script and frame sources. The Service's DNS is hosted at Cloudflare as plain records: Cloudflare's DNS service does not proxy or see the Service's traffic (Cloudflare's Workers AI, a separate service, receives only the AI requests routed to it — Annex III). The application sets no cookie of its own; Clerk's session cookies are the only ones on the app's origin, and Paddle's checkout frames may set theirs on the payment page.
Logging and audit. Privileged mutations — settings changes, model credentials, connecting and disconnecting an org or service, vault operations, snapshot and rollback restores, permanent deletes — are written to a per-Workspace audit trail recording who (the verified email address or account id), from which network address, what (with the ids, names and counts the act concerns), and the names of the fields a change touched — never a credential's value, though the new value of some non-secret settings, such as a retention period or a custody mode, is recorded; it keeps the newest 2,000 entries per Workspace, and once role enforcement is on a Workspace admin can read the newest of them in the product (Section 6.2 says how Customer obtains the trail as kept). An operator act is written the same way to AssemblyWright's own administrative trail ("via HQ" where applicable), stamped with the scope the operator was working in — its own, unless the act was taken inside a Customer's Workspace as one of its members (Section 3.11). Each Build's timeline records every event and gate, and what each tool was asked to do and whether it succeeded, not the data it returned, except a failed call's error message, of up to 200 characters, and the result of the check run on the org before a metadata deploy. Each model call is metered against the model that actually answered. A structured request log records method, path, status, latency and the signed-in account and Workspace by id, never a body or a token; the web server's access log also records each request's path with its query string. Browser crash reports are kept to the newest 500. Logs stay on the machine and are not shipped to a separate system; nothing alerts on an error.
Abuse and spend resistance. Requests are rate-limited per network address (600 a minute), trusting only the proxy-appended hop; the Request access form admits 5 requests an address an hour and stores at most 200 a day; each webhook door is rate-limited before any signature work; the Guide answers at most 200 questions a User a day. Every Build runs under a dollar ceiling (US $5 by default) that warns at 80 percent and pauses for approval rather than running on, and a 48-call budget that pauses and asks; every Workspace opened since 29 September 2026 is stamped with a monthly department budget (US $50 by default) that narrows and then stops new Builds while running ones finish, one is set on an older Workspace at Customer's request, and only AssemblyWright's operator changes it; a Workspace may start at most 25 Builds a day and run 3 at once (6 across the whole Service), and at most one browser verification at a time and 40 a day. A refused admission reads as busy, never as a silent drop. Every Customer Account carries an AI allowance — a limit on what all of its Workspaces' AI use costs together, Builds and the app's own AI features alike, counted at the rate of the model that answered over the Customer Account's whole life (US $25 by default; only AssemblyWright's operator sets, changes or removes it): at 80 percent a running Build is told so; once it is reached, the Service is designed to refuse a new Build or pause it before its first model call, to pause a running Build at a human checkpoint before its next model call, and to stop the app's AI features answering, unless it is raised; the count is durable, so a restart or a deploy does not reset it.
Change management. Every change to the Service is landed only after a gate has run, on that exact commit, the self-test every backend module carries, a live dependency audit against the public advisory database for every pinned dependency and both front-end trees, a contrast and accessibility sweep of every page, and a rebuild of the front end, and has written a record of that run; the production machine deploys only a commit such a record covers, holds anything else, smoke-tests the result, and automatically rolls back and quarantines a commit that fails. Database migrations are never applied automatically. There is no second human reviewer of code; the gate and the rollback are what stand in for one, by design.
Availability and recoverability. Since 5 October 2026 an external monitoring service checks the Service's public health every five minutes from eight monitors, two of them keyword checks that read whether sign-in is ready and whether isolation is enforcing, and alerts AssemblyWright's operator by email. There is no uptime commitment and no public status page. Scheduled off-server copies of the database are being set up and are not yet verified as running; Section 9.5 states what exists, what has been rehearsed and what Customer should assume meanwhile.
Deletion. Deleting a Deliverable or Knowledge Base entry moves it to the trash; permanent deletion requires typing a confirmation and removes every version. Closing a Workspace erases every stored credential at once and closes the Workspace to everyone for 30 days, after which its rows and files are erased by hand. Per-Workspace clocks for Deliverable retention, versions kept and trash purging exist and ship off; captured prior values expire on their own 30-day default clock in either custody, leaving a receipt.
Organizational measures. AssemblyWright is operated by one person, its principal, who is the only person with operator or administrative access; as of the date of this DPA it has no employees. Software is written with AI coding tools (Anthropic's Claude Code) working under the principal's direction, which are given no production credential and are not used to read Customer Personal Data (Section 3.4). The company's internal operations console, Evadaroo HQ, acts as Section 3.11 describes. Written policies exist for access review, incident response, change management, data classification and retention, and vendor management, two of which are being brought current (Section 10.1); the first access review has not yet been run and the incident-response plan has not yet been exercised. A vulnerability disclosure contact (security@assemblywright.ai) is published under RFC 9116.
Stated limitations. Isolation is logical, not physical, within one database on one machine. Role enforcement for Customer's Users is switched off while sign-up is open. Multi-factor sign-in is not enforced and not switched on. Customer Content is not encrypted beyond the host's disk encryption; credential encryption relies on a key in the machine's environment, with no managed key service and no rotation procedure, and no confirmed copy of that environment exists off the machine. The audit trail is bounded by row count rather than by time, so a Customer needing a longer archive should obtain copies of it as Section 6.2 describes; the web server's access log records query strings, which for an unsubscribe or an OAuth callback carry a signed token; request logs have no retention limit yet. Recoverability is as the Availability paragraph above states; verification evidence lives on the machine, outside the database and outside any database copy. Nothing alerts automatically on an error; the external monitor reads public health only, and alerts reach one person by email with no paging, so incident response depends on that person's availability. The operator's reads in the operator console and through Evadaroo HQ, a restore, and direct access to the database and the machine are not recorded. Gated writes to a production org are refused by nobody but the person at the gate; the approval card does not yet say which org is production. Rollback restores changed and added metadata, not deleted components and not record data, and nothing undoes the automation a write set off. Dynamics 365 and HubSpot writes, metadata restore, bulk update and its undo, snapshot restore, releases and test-data seeding have each been exercised against test doubles and not yet against a live org, and AssemblyWright makes no claim about how Builds perform on the models in the chain Section 8.1 states as of the effective date. The notices to a Workspace owner about operator acts (Section 3.11) and about a Personal Data Breach (Section 3.7) are written and sent by hand, not by the Service. These are recorded here rather than omitted.
Annex III — Sub-processors
Current list. These are all the outside services that receive personal data from AssemblyWright in providing the Service, together with the company's own systems and services that do and the development tool AssemblyWright builds the Service with, and whether each receives Customer Content today. The list is published at assemblywright.ai/privacy (and in the Privacy Policy), and changes follow Section 5.2. Each provider's published terms are linked from its name where available, and AssemblyWright will send a copy or link on request. Every provider that receives Customer Personal Data today is a US company; the location column states where each processes, and says so where that is not confirmed.
Infrastructure, identity, email and operations
| Who | Role | What for, and what it receives | Location | Customer Content today? |
|---|---|---|---|---|
| Google LLC — Google Cloud Platform | Sub-processor | Hosting: one Compute Engine machine running the application, its PostgreSQL database and the web server — all Customer Personal Data stored in the Service, and the network address of every request. Cloud Storage will hold the off-server database copies once they run (Section 9.5). Cloud Run runs the headless browser that walks a Connected Org's screens for verification and training captures and encodes Content Desk video: for each walk it receives the verification plan and a live Salesforce session token for Customer's integration user, and returns the screenshots and video it captured; the container is ephemeral. | United States: us-central1 for the machine and, by the documented deployment procedure, the browser runner; the storage bucket for the database copies is in the United States, its region not yet confirmed | Yes |
| Clerk, Inc. | Sub-processor | Sign-in, accounts and organizations: each User's email address, name, sign-in method and session; the organizations Customer creates and their members; and invitation email to the people Customer's owner invites, sent from Clerk's own infrastructure. AssemblyWright verifies Clerk's session tokens and holds no Clerk secret key. | United States company; processing location per Clerk's terms | Membership data only — no Deliverable, Knowledge Base or CRM content |
| Resend (Plus Five Five, Inc.) | Sub-processor | Email the Service sends: notifications to the Workspace's own notification address or its owner's address (a Build finished, a review gate waiting, input needed, a Content Desk digest — a title, up to 240 characters of detail naming the Build, and a link); and, only where Customer connects its own Paddle account, asks for an email response and a User approves each send, service email to Customer's own buyers (their address and name and the text Customer wrote). AssemblyWright's sending account at Resend is shared with its company's other product, Profusia AI; each product sends from its own domain and holds itself to its own daily cap, within the account's one shared allowance. Resend keeps, at account level, the addresses that bounced or complained. | United States | A small part: a Build's name in a notification; the text of a service email Customer approves |
| Apple Inc. — Apple Push Notification service | Sub-processor, once the iPhone app is released and a User installs it | The same notifications, to a phone that registered: the notification's title and detail, the Build's address in the app, and the device's push token — never Deliverable content, never CRM data. The server side is configured; the app itself is not yet released, so no device can register today. | Apple's network | No device today; when one registers, a Build's name in a notification |
| Google LLC — Google Workspace | Sub-processor | AssemblyWright's company mailboxes (legal@, security@, billing@ and hello@assemblywright.ai, and any other @assemblywright.ai address the Service or its pages name): whatever Customer or its Users send in correspondence, and AssemblyWright's replies. | United States | Only what someone chooses to email AssemblyWright |
AI model providers. Which of these providers answers a request is decided by a chain that AssemblyWright's operator configures — for the whole Service and, where it chooses, for one feature or one Wright — and can change at any time; only its entries from the providers below that may receive Customer Content and are connected (Section 8.1) are ever called. As of the effective date, every chain the Service uses by default starts with Anthropic — Claude Sonnet 5.5 for every feature and Wright the operator has not given a chain of its own, Claude Opus 5.5 for the architect Wrights, and Claude Haiku 5.5 for the documentation and writing Wrights and most of the Service's own AI features (Section 8.1) — with Google Cloud Vertex AI's Gemini 3.8 Flash, then Gemini 3.5 Flash-Lite, behind it; and Vertex AI also answers on the other occasions its row lists. Cloudflare Workers AI and OpenAI are connected and in none of those chains; each answers only on the occasions its row lists. An image prompt goes to the image model set for the Workspace (Section 8.1). The table says, for each provider, whether it receives Customer Content as of the effective date and on what occasions. A listed provider other than Google Cloud Vertex AI that is not connected on the effective date, and any provider not listed here, becomes eligible to receive Customer Content only after the notice in Section 5.2 (Section 8.1 says why Vertex AI is not among them); a provider whose terms permit training is refused in production by the Service itself (Section 8.3) and is never eligible.
| Provider | Tier and terms | May it train on what it is sent? | Customer Content today? | Location |
|---|---|---|---|---|
| Anthropic, PBC (Claude models, over Anthropic's own API) | Paid API | No, under its terms | Yes — first in every default chain as of the effective date (Section 8.1): every Build stage, review gate, Wright conversation, Guide answer, Maintenance Workflow, intake question, Content Desk draft and Paddle-event Build that uses those chains; a second-opinion or two-approaches stage for which a Claude model is picked; any feature or Wright AssemblyWright routes to it; and the features that call a model directly, where none of their own chain can be used (Section 8.1) | United States — every request held to US-only processing (Anthropic's inference_geo) |
| Google LLC — Vertex AI (Gemini models; Google's image model where configured) | Paid, under Google Cloud's enterprise terms | No, under its terms | Yes — behind Claude in every default chain as of the effective date, Gemini 3.8 Flash and then 3.5 Flash-Lite, answering whatever that chain sends when the Claude model before them does not; any feature or Wright AssemblyWright routes to it; a second-opinion or two-approaches stage for which a Gemini model is picked; and the image prompt, where Google's image model is the Workspace's image model | Google's us multi-region, in the United States, for the Gemini models the Service calls by default, Gemini 3.8 Flash and 3.5 Flash-Lite (the code's default, which AssemblyWright will not change to a region outside the United States without the notice in Section 5.2); for Google's image model and any other Vertex model, the Google Cloud region the deployment is configured for, which the Service's code does not set |
| Cloudflare, Inc. — Workers AI (Meta's Llama 3.1 8B model in the Service's catalogue as of the effective date) | Free allowance, then paid | No, under its terms | Only on these occasions, while it is connected (it is, as of the effective date, and in no default chain): any feature or Wright AssemblyWright routes to it; a second-opinion or two-approaches stage for which one of its models is picked; and the image prompt, where one of its image models is the Workspace's image model | Cloudflare's global network, which can be outside the United States; the Service sets no region for a request to it. Cloudflare, Inc. is a United States company |
| OpenAI, L.L.C. (GPT-4o and GPT-4o mini in the Service's catalogue as of the effective date) | Paid API | No, under its terms | Only on these occasions, while it is connected (it is, as of the effective date, and in no default chain): any feature or Wright AssemblyWright routes to it; a second-opinion or two-approaches stage for which one of its models is picked; and the image prompt, where one of its image models is the Workspace's image model | OpenAI's processing locations, per its terms, which can be outside the United States; the Service sets no region for a request to it |
| Google LLC — Gemini via Google AI Studio | Free tier | Yes | Never. Used in AssemblyWright's development and test environments with test data only; refused in production by the Service | United States |
| Groq, Inc., Cerebras Systems Inc., OpenRouter, Inc., Mistral AI SAS, GitHub Models and xAI | Free tiers (xAI paid), each marked in the Service's catalogue as a provider whose terms may permit training | Yes, or treated as yes | Never. Refused in production by the Service; not sub-processors of Customer Personal Data | United States, except Mistral (France); OpenRouter routes to upstream hosts that may be in other countries |
Anthropic's Claude models are catalogued as reachable over Anthropic's own API; no Claude model served through Vertex AI Model Garden exists in the Service's catalogue as of the effective date. Which providers are connected, and in what order a request may use them, is set by AssemblyWright's operator and can change; that does not change which providers may receive Customer Content, which this Annex states and Section 8.3 governs.
AssemblyWright's own company's systems and services, and a development tool not engaged to process Customer Personal Data
| Who | What it is | What it receives | Customer Content today? |
|---|---|---|---|
| Evadaroo HQ (hq.evadaroo.com) | The internal operations console of AssemblyWright's own company, Evadaroo & Company, LLC — a Cloudflare Worker behind Cloudflare Access, with a small database of its own | Whatever the operator console shows (Section 3.4) — Customer Account and Workspace names, member counts, packages, trials, grants and prices, usage by feature, model spend, entitlements and model routing — read through single-use signed requests and shown beside the records of the company's other products. The operator's Workspaces route answers it with each member's identifier and role, and Evadaroo HQ drops every member identifier that is not the operator's own at its own boundary, before anything is shown or stored. It keeps its own log of every act taken through it, and can take the operator acts in Section 3.11 — including adding or removing a member by the operator's route, which is recorded — within the operator area and nothing outside it | No — names and counts; a member's identifier is dropped before it is shown or stored |
| Profusia AI (profusia.ai) | Another service of Evadaroo & Company, LLC; a Connected Service Customer elects (Sections 2.4 and 5.5), reached with a Profusia access key Customer supplies for its own Profusia workspace | Only where Customer connects it: each Deliverable Customer publishes or lets the Service publish automatically (the connect screen offers automatic publishing switched on), as a document in Customer's Profusia workspace; a collection per Build carrying the Build request as its description; images a Build generates; and, where Customer switches it on, the Build's course as project turns. A manual push also mints an outward share link in Customer's Profusia workspace. Deleting a Deliverable here does not delete the Profusia copy. Held under the Profusia AI Terms and DPA Customer accepted there | Yes, where connected: the Deliverables Customer publishes |
| Uiia (uiia.app) | Another service of Evadaroo & Company, LLC: the Help assistant in the app, switched off as of the effective date (Section 8.3); AssemblyWright's own processing under Section 2.2(f), not a sub-processor of Workspace data | While on: the questions a person types into Help with the last few turns of that conversation, and their email address if they ask to be contacted; because its script loads with the app, it sees that visitor's network address and browser details; its answers may come from a model that uses inputs for training. It never receives Deliverables, Build content, Knowledge Base material or anything from a Connected Org | No |
| Anthropic, PBC — Claude Code | Development tool | The AI coding tool AssemblyWright builds the Service with, running on Anthropic's systems. It receives the Service's source code and documentation, is given no production credential and is not used to read Customer Personal Data (Section 3.4) | No |
| Anthropic, PBC — "Draft in Claude" | A hand-off Customer's User elects | When a User presses "Draft in Claude" in the Content Desk, their own browser opens their own Claude app or account with the desk's prompt (brand notes and post briefs); AssemblyWright sends nothing and holds no Claude credential; what the person's Claude account receives is held under that person's own terms with Anthropic | No — a Content Desk prompt, by the User's own act |
Not a sub-processor — Paddle. Paddle (Paddle.com Market Limited and its affiliates) is AssemblyWright's reseller and Merchant of Record for paid packages. It processes billing contact, payment and tax details as an independent controller under its own privacy notice (paddle.com/legal/privacy) and Buyer Terms, for the purchase itself. It receives no Customer Content. To identify a purchase, AssemblyWright tells Paddle a signed reference to Customer's Customer Account, which is part of AssemblyWright's own billing record (Section 2.2), and Paddle tells AssemblyWright the subscription's package, status and dates. Payment details go to Paddle, never to AssemblyWright. Whether AssemblyWright's Paddle configuration is running in Paddle's sandbox, in which no real payment can be taken, or live is stated at assemblywright.ai/privacy; the payment page loads Paddle's checkout script and frames only when a transaction is being paid, and Paddle's own frames may set cookies under Paddle's notice.
Not sub-processors — systems Customer directs. A Connected Org (Salesforce, Microsoft Dynamics 365, HubSpot) is Customer's own system and vendor relationship: the Service acts on it with credentials Customer supplies, and the records that stay in it are never in AssemblyWright's custody. The social networks Customer connects through the Content Desk (LinkedIn, Bluesky, Mastodon, Threads, Dev.to, X), Google Docs, Jira, Confluence, GitHub and Salesforce's hosted MCP servers are Customer's own accounts: a post or export reaches them only on Customer's User's approval, and the tokens for them are held encrypted and never returned. Customer's own Paddle account is Customer's own: the Service reads it with Customer's key and receives the events Customer's Paddle sends. The recipients of email Customer approves receive what Customer chose to send them.
Services that receive no personal data. UptimeRobot fetches the Service's public health addresses every five minutes and emails AssemblyWright's operator; it reads no Customer data. Cloudflare's DNS service hosts the Service's DNS as plain records and does not see its traffic; this line is about DNS only — Cloudflare's Workers AI receives Customer Content where a request is routed to it, and is listed under AI model providers above. Let's Encrypt issues the Service's TLS certificates and sees domain names only. GitHub holds the Service's source code and documentation, no Customer Personal Data and no production secret.
Evadaroo & Company, LLC · 502 W 7th St, Ste 100, Erie, PA 16502 · USA · legal@assemblywright.ai