Draft for attorney review — not yet in force.

AssemblyWright AI — Data Processing Addendum

Effective date: [DATE]

This Data Processing Addendum ("DPA") forms part of the AssemblyWright AI Terms of Service (the "Agreement") between Evadaroo & Company, LLC, a Pennsylvania limited liability company trading as AssemblyWright AI ("AssemblyWright", "Processor"), and the customer identified in the Agreement ("Customer", "Controller"). Where this DPA conflicts with the Agreement on data protection, this DPA governs.

1. Definitions

Terms not defined here have the meaning given in the GDPR. "Data Protection Laws" means the GDPR, the UK GDPR and Data Protection Act 2018, the Swiss FADP, the CCPA as amended by the CPRA, and other applicable US state privacy laws, each as applicable. "Customer Personal Data" means Personal Data contained in Customer Data and processed by AssemblyWright under the Agreement, including Personal Data read from or written to a Connected Org. "SCCs" means the Standard Contractual Clauses annexed to Commission Implementing Decision (EU) 2021/914. "UK Addendum" means the ICO's International Data Transfer Addendum, version B1.0.

2. Roles and scope

2.1 Customer is the Controller (or a processor acting for a third-party controller) and AssemblyWright is the Processor (or sub-processor). Under the CCPA, AssemblyWright is a Service Provider.

2.2 AssemblyWright is a Controller only for its own account, billing, security, and operational records, described in the Privacy Policy and outside this DPA.

2.3 A Connected Org is Customer's own system. AssemblyWright accesses it under credentials Customer supplies and only as Customer instructs. Customer's relationship with its CRM vendor is Customer's own; that vendor is not AssemblyWright's sub-processor.

2.4 Details of processing are in Annex I; security measures in Annex II; sub-processors in Annex III.

3. AssemblyWright's obligations

3.1 Process only on documented instructions — to provide, secure, and support the Service in accordance with the Agreement, this DPA, and Customer's use of the product, or as required by law, in which case AssemblyWright will tell Customer first unless the law forbids it.

3.2 Never sell or share it. No sale, no sharing for cross-context behavioral advertising, no retention, use, or disclosure for any purpose other than performing the Service, and no combining with data from other sources except as the CCPA permits. AssemblyWright certifies it understands and will comply with these restrictions.

3.3 Never train models on it. AssemblyWright will not use Customer Personal Data or Customer Data to train, fine-tune, or improve any machine-learning model. The production model provider's terms provide that customer inputs are not used to train its models (Annex III).

3.4 Write to a Connected Org only on instruction. Every write — metadata deploy, bulk data update, test-data seed, release deploy — requires an elevated role and an explicit instruction from one of Customer's authorized users. AssemblyWright does not initiate writes.

3.5 Bind its people to confidentiality and limit access to those who need it.

3.6 Implement the measures in Annex II, appropriate to the risk.

3.7 Assist Customer with data subject requests (Section 6), with security, breach notification, and — taking account of the nature of processing and the information available — with impact assessments and prior consultations.

3.8 Notify Customer of a Personal Data Breach without undue delay and in any event within 72 hours of becoming aware, describing the nature of the breach, the categories and approximate numbers affected so far as known, the likely consequences, the measures taken or proposed, and a contact point, with updates as facts emerge.

3.9 Delete or return Customer Personal Data on termination, per Section 9.

3.10 Make available the information needed to demonstrate compliance, and submit to audits, per Section 10.

3.11 Tell Customer if an instruction infringes Data Protection Laws, in AssemblyWright's opinion.

4. Customer's obligations

Customer will: (a) have a lawful basis for the Personal Data it processes through the Service, including Personal Data in a Connected Org that the Service reads, transforms, or writes; (b) provide notices and obtain consents required of it; (c) issue lawful instructions; (d) grant the narrowest CRM permissions that let the Service do the work, and assign product roles so that only intended people can approve a write; (e) exercise new workflows, deploys, and bulk operations in a sandbox or Developer Edition org before a production org; and (f) not process special-category data, protected health information subject to HIPAA, payment card data subject to PCI DSS, children's data, or government-classified data through the Service, which is not designed or certified for it.

5. Sub-processors

5.1 General authorization. Customer authorizes the sub-processors in Annex III and others engaged on the terms below.

5.2 Notice of change. At least 30 days' notice before a new or replacement sub-processor begins processing Customer Personal Data, by updating the Privacy Policy and notifying Workspace owners by email or in-product notice.

5.3 Objection. Customer may object on reasonable data protection grounds within those 30 days. If no reasonable alternative can be offered, Customer may terminate the affected part of the Service without penalty and receive a pro-rata refund of prepaid, unused fees.

5.4 Flow-down and liability. Sub-processors are bound to obligations no less protective than this DPA, and AssemblyWright remains liable for their performance.

5.5 Profusia AI is an affiliate sub-processor engaged only at Customer's election. It is another service of Evadaroo & Company, LLC. Deliverables are published to it only where Customer connects it with a Profusia access key Customer supplies. Its own Privacy Policy and DPA describe its processing; the affiliation does not reduce the notice, objection, or liability terms above.

6. Data subject rights

6.1 AssemblyWright will assist Customer, by appropriate technical and organizational measures and taking account of the nature of processing, in responding to data subject requests.

6.2 Honest statement of the mechanism. Deliverables and Knowledge Base entries can be exported and deleted in the product, and permanently deleted from trash with a type-to-confirm step. There is no self-service "delete everything for this individual" flow today. On Customer's request AssemblyWright performs the deletion manually — Knowledge Base entries, Deliverables, Builds, and saved connections, then permanent deletion from trash — and confirms completion in writing. AssemblyWright will complete such a request within 30 days of a sufficiently specific instruction.

6.3 If a data subject contacts AssemblyWright directly about Customer Personal Data, AssemblyWright will not respond substantively; it will refer them to Customer and tell Customer promptly.

7. International transfers

7.1 AssemblyWright is established in the United States and the Service runs in us-central1. Where Customer Personal Data protected by the GDPR is transferred, the SCCs are incorporated by reference:

• Module Two (Controller to Processor) where Customer is a controller; Module Three (Processor to Processor) where Customer is a processor.
• 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 17: governed by the law of Ireland. Clause 18(b): courts of Ireland.
• Annex I.A/I.B are populated by Annex I of this DPA; Annex II by Annex II; Annex III by Annex III.

7.2 United Kingdom. The UK Addendum is incorporated: Table 1 from the parties' details in the Agreement; Tables 2 and 3 from Section 7.1 and the Annexes; Table 4: neither party.

7.3 Switzerland. The SCCs apply with the Swiss FDPIC as supervisory authority and "Switzerland" read for the EU where necessary.

7.4 Conflict. The SCCs and the UK Addendum govern over this DPA where they conflict.

7.5 Government access. To the extent legally permitted, AssemblyWright will notify Customer of a binding public-authority request for Customer Personal Data, challenge requests it believes unlawful or overbroad, and disclose only the minimum required. As of the effective date, AssemblyWright has received no national-security order requiring access to Customer Personal Data.

8. AI processing

8.1 Prompts for a Build stage — which may include the Build request, org context imported from the Connected Org, Knowledge Base material, and prior Deliverables — are transmitted to the model provider that answers, for that request.

8.2 Production inference runs on Google Cloud Vertex AI in us-central1, under Google Cloud's enterprise terms, which provide that customer inputs are not used to train Google's models.

8.3 Free consumer AI tiers are development-only by policy and are never pointed at production. Real customer data is never sent to them.

8.4 The models hold no autonomous authority over a Connected Org. Every write is a separate, role-gated action on an instruction from one of Customer's authorized users.

8.5 Outputs may be inaccurate, and Customer is responsible for review before reliance. AssemblyWright does not use AI to make decisions producing legal or similarly significant effects on data subjects.

9. Deletion and return

9.1 Deliverables, Knowledge Base entries, and Build records are exportable at any time during the term.

9.2 They remain available for export for 30 days after termination. Within that window Customer may request erasure, which AssemblyWright performs and confirms.

9.3 After the window, Workspace data is deleted on AssemblyWright's normal cycle. Backups expire on their own schedule — daily disk snapshots at 7 days, database dumps on their storage schedule — and remain protected under this DPA until they do.

9.4 Changes already deployed into a Connected Org are in Customer's own system and are not deleted by anything here.

9.5 Retention beyond the above occurs only where law requires, with protection continuing for as long as it does.

10. Audit

10.1 AssemblyWright will make available the information reasonably necessary to demonstrate compliance, including Annexes II and III, its written internal policies (access review, incident response, change management, data classification and retention, vendor management), and the dated output of its dependency vulnerability scans.

10.2 Where that is insufficient for a Customer subject to Data Protection Laws, Customer may, once in any 12-month period, on 30 days' written notice, conduct an audit — remote and document-based by default — at Customer's expense, during business hours, without unreasonable disruption, and subject to confidentiality. A regulator's audit right is not limited by this Section.

10.3 AssemblyWright holds no SOC 2 report, ISO 27001 certificate, HIPAA attestation, or third-party penetration test, and none is in progress. A Customer whose procurement requires one should raise it before contracting.

11. Liability

Liability under this DPA is subject to the limitations and exclusions in the Agreement, except where Data Protection Laws do not permit that limitation. Nothing here limits a data subject's rights under the SCCs.

12. Term

This DPA takes effect on the date above and continues until AssemblyWright has ceased all processing of Customer Personal Data.

Annex I — Details of processing

A. List of parties

• Data exporter / Controller: the Customer named in the Agreement. Contact: the Workspace owner's email on file. Role: controller (or processor for a third-party controller).
• Data importer / Processor: Evadaroo & Company, LLC, d/b/a AssemblyWright AI, [REGISTERED OFFICE ADDRESS], Pennsylvania, USA. Contact: legal@evadaroo.com. Role: processor. Activities: providing the AssemblyWright AI governed multi-agent delivery platform described in the Agreement.

B. Description of transfer

C. Competent supervisory authority. Determined under SCC Clause 13.

Annex II — Technical and organizational security measures

These describe measures actually implemented.

Workspace isolation. Every tenant-owned table carries a workspace identifier, and the filter is applied in one place at the data layer rather than in each feature: reads are rewritten to add the scope, writes are stamped with it, and an attempt to write without a scope raises rather than writing an unattributed row. A read without a scope returns nothing rather than everything. Proven against a real database: another tenant's row is invisible by query, by count, and by direct primary-key lookup; relationship loads stay inside the tenant; and bulk updates and deletes are scoped, which is what stops a snapshot restore or a bulk operation crossing a boundary. The live posture is reported by an open configuration endpoint, so it is checkable rather than asserted.

Authentication and authorization. Identity is provided by Clerk (RS256 JWT, JWKS verification, issuer and expiry checked) and gates every API route; the only open paths are the health check, the public configuration, the authentication-readiness probe, and the client-error beacon. Per-Workspace roles (viewer, operator, admin, owner) are enforced in one middleware. Every destructive, cost-bearing, or org-touching route requires an elevated role — approximately 52 routes.

Credential protection. Credential-shaped settings are encrypted at rest with Fernet under a deployment key. The multi-org connections vault encrypts the entire credential snapshot as one blob rather than only secret-suffixed fields, and the API returns field names only, never values. Volatile token caches are cleared on every connection switch, so a token minted against one org is never replayed against another. Stated limitation: the encryption key derives from an environment secret on the host; there is no managed key service and no automated rotation procedure.

Transport. TLS on all hostnames with automatic certificate management, HSTS, and a standard security-header set.

Auditability. An admin audit table records actor (email or id), trusted client IP, action, and detail for privileged mutations: settings changes, model credentials, CRM connect/disconnect, vault operations, snapshot restores, and permanent deletes. Details log field names, never values. Structured request logging per request; client crash reports persisted and capped.

Abuse and spend resistance. Per-IP rate limiting that trusts only the proxy-appended hop; a daily Build cap; a per-Build dollar ceiling that warns at 80% and pauses for approval rather than running on; a durable per-Workspace budget brake computed from recorded usage; a bounded model-call budget per Build.

Change management and recoverability. Every backend module carries a self-test that must pass before merge; the full suite runs in CI on every push. Deploys rebuild, smoke-test, and automatically roll back and quarantine a bad commit. Database migrations are never auto-applied. Daily PostgreSQL dumps to cloud storage plus daily disk snapshots, with a written disaster-recovery rehearsal runbook and measured restore steps.

Data handling in the CRM. Metadata deploys capture a pre-deploy rollback snapshot with one-click undo; bulk data updates capture prior record values before writing; test-data seeding carries a removal tracer. Rollback payload custody is Customer's choice — our database or a file in Customer's own org, with only a receipt and checksum kept here — and a capture that cannot be stored under the chosen custody fails the job rather than proceeding without a backup.

Supply chain. Production dependencies are pinned in a lockfile generated from a clean environment, the production image installs from that lockfile, and the pins are scanned against the public advisory database with the dated output kept as evidence. Unused dependencies are removed rather than carried.

Written policies. Access review, incident response, change management, data classification and retention, and vendor management, each stating its own gaps rather than describing a process that is not real.

Stated limitations. Isolation is logical, not physical. No SOC 2, ISO 27001, HIPAA attestation, or third-party penetration test. No dedicated security officer. No managed key service or key rotation procedure. The admin audit trail is bounded by row count rather than by time, so a Customer needing a longer archive should export it. Deletion of an individual's data is a manual process (Section 6.2).

Annex III — Sub-processors

Not sub-processors:

• Customer's CRM vendor (Salesforce, Microsoft, HubSpot) — Customer's own system and own vendor relationship. AssemblyWright acts on it with credentials Customer supplies.
• Google AI Studio — development only, by written policy; production never points at it and real customer data is never sent to it.
• GitHub — holds application source code. It holds no Customer Personal Data and no production secrets.

Current list. Maintained in the Privacy Policy. Changes follow Section 5.2.

Evadaroo & Company, LLC · [REGISTERED OFFICE ADDRESS] · Pennsylvania, USA · legal@evadaroo.com