AssemblyWright AI — Privacy Policy

Effective date: October 29, 2026

The short version — a summary only; the numbered sections give the full detail. What we keep: what you and your Workspace put into AssemblyWright (your Build requests, the Deliverables it writes, your Knowledge Base, what it reads from a CRM org you connect, and the credentials you give it), your account, and the records we need to run, secure and bill for the Service, each for as long as Section 1 says — and, for most of a Workspace's content, that is until you delete it, because little of it expires on its own. What we never do: sell personal information, use it for advertising, train AI models on your content, or have the product send a customer's content to an AI provider whose terms allow it to train on what it receives (Section 5). What the AI does with your org: it reads what the credential you give it allows, it writes to a connected org only under the rules in Section 6.1, and what it writes can quote your org's data back into a Deliverable. Who else handles it: the outside services in Section 3 — chiefly Google Cloud, which hosts everything; the AI model providers our operator's chain sends a request to, which as of the effective date are Anthropic's Claude first and Google's Gemini on Vertex AI behind it, both processing those requests in the United States, while two other providers we can route a request to, Cloudflare Workers AI and OpenAI, can process one outside it (Section 5.3); Clerk, which holds your sign-in; and Paddle, which handles payment. Who at AssemblyWright can see it: one person, with the access Section 4.2 describes. Your rights: some you can use directly in the product, and the rest are one email away (Section 10). What is still being put in place: off-server backups, the iPhone app, and a self-service way to delete one person's data; each is named where it belongs. Contact: legal@assemblywright.ai.

This policy explains how Evadaroo & Company, LLC, a Pennsylvania limited liability company trading as AssemblyWright AI ("AssemblyWright", "we", "us"), handles personal data when it provides the AssemblyWright service: the product at app.assemblywright.ai, the website at assemblywright.ai, the iPhone app once it is released, and the connections the product makes to systems you connect to it (together, the "Service"). It covers what we collect, where it lives, how long we keep it, who else handles it, and how each data-protection right maps to something you can do.

How it fits with the other documents. This policy is a notice. It explains our practices. It is not a contract and creates no contractual rights or obligations beyond those in our Terms of Service (the "Terms") and, where it applies, our Data Processing Addendum (the "DPA"), which governs on what it covers; Sections 9.1 and 16.1 of the Terms say which of them forms part of your agreement with us and which is a notice, and Section 16.2 of the Terms says how our agreements rank against each other. The Acceptable Use Policy (the "AUP") says what may not be done with the Service, and the Refund Policy says when money comes back. This policy is our privacy notice, and the page at assemblywright.ai/privacy summarizes it; if the two ever differ, this policy is the statement we stand behind, and we will correct the page. The page at assemblywright.ai/trust describes the security half of the picture and may only say what this policy and our own security records say.

Who we are. Evadaroo & Company, LLC, a Pennsylvania limited liability company trading as AssemblyWright AI, 502 W 7th St, Ste 100, Erie, PA 16502, United States. Privacy questions and requests: legal@assemblywright.ai. We have not appointed a data protection officer, and we have not appointed a representative in the EU or the UK. The same company also makes Profusia AI and Uiia; where the Service hands anything to either of them, this policy says so (Sections 3, 6.2 and 7.2).

Our role. We are the controller for your account, sign-in and billing relationship with us, and for the records we keep to run and secure the Service: the audit trail of privileged actions, request logs and crash reports, rate-limit counters, our own operator records and the ledger of who reached our operator console, our record of who accepted our terms, requests sent through the website's Request access form, and the email we send about the Service. For what a customer puts into its Workspace (its "Workspace content", which the Terms call "Customer Content") — Build requests, Deliverables, the Knowledge Base, what is read from a CRM org it connects, the people its documents and its org's records describe, the chat its members have with the product's agents, the credentials it supplies, and the buyers whose purchases a Workspace's own Paddle account reports to it — and for the records kept for that Workspace (its members' roles, its usage record, its notifications, its undo points and its verification evidence), the customer is the controller (under US state laws, the "business") and we act on its instructions as its processor (or "service provider"). A CRM org you connect is your own system under your own agreement with its vendor: we read from it and write to it only as the credential you give us allows and as Section 6.1 describes, and we are not that vendor's processor or yours for what stays inside your org. Once our DPA forms part of a customer's agreement with us, it governs on what it covers.

1. What we keep, and for how long

Where it lives. The Service's application data lives in one PostgreSQL database on one Google Cloud virtual machine in us-central1, in the United States, alongside the application itself, its configuration and its log files. Screen recordings and screenshots made by the UI-verification feature are files on that same machine. Your sign-in account lives with Clerk, our identity provider. Payment and tax records live with Paddle. Email you send us is held in our Google Workspace mailbox. The providers in Section 3 hold what is sent to them, and your browser keeps the storage described in Section 9. Off-server copies of the database are to be kept in Google Cloud Storage, in the United States, once they run (Section 1.8).

How to read the tables. Most of what a Workspace holds has no time limit: it is kept until someone deletes it, or until the Workspace is erased (Section 1.9). Where a row gives a period, that period is one the Service is built to apply by itself — a scheduled job, a count cap, or a check made on the next write — and the row says when it works differently. Where a row says a record is kept "indefinitely", the product has no path that deletes it short of erasing the Workspace, and we say so rather than imply one. Keeping a record is not a promise that it cannot be lost: Section 1.8 says what is backed up today, which is less than we would like. Anything erased also leaves our backups as Section 1.8 describes.

1.1 Your account, your membership and the records about you

Your profile picture, if you add one, is held by Clerk, not by us, and is deleted under Clerk's rules. One preference of yours is kept on our servers: the view you pick on the Build page, stored in the Workspace's settings under a name that includes your Clerk user id; clearing it empties the choice but leaves that setting, with your user id in its name, until the Workspace is erased. Everything else the product remembers about how you like the screen stays in your browser (Section 9).

1.2 What a Workspace holds

1.3 Changes to your CRM org, undo points, test data and verification evidence

The parts of your org's data that reach a Deliverable are in the Deliverables themselves. Two cases are worth naming once. A Wright with read tools can query records during a Build and quote what it finds, so a Deliverable can carry record values; the Build's timeline records what each tool was asked to do and whether it succeeded, not the data it returned, with the two exceptions its row in Section 1.2 names. And a Process Documentation Build appends your org's setup audit trail for the last 180 days to its Automation Inventory, including the name of the Salesforce user who made each change, so the names of your org's administrators land in that Deliverable. We keep neither of these anywhere else. An import of your org's configuration reads profile and permission-set names, never your user list.

1.4 The credentials you give us

Every credential is stored encrypted at rest (Fernet symmetric encryption) under a key that lives in the production machine's environment, not in the database, and a saved connection is encrypted as one whole snapshot rather than field by field. No screen, API response, export or error message ever returns a stored value: the product shows field names, or a yes or no. Credentials are kept separately per Workspace and never fall back to a shared value, so one Workspace cannot inherit another's org. A short-lived session token is never captured into a saved connection. Stated plainly: the encryption key is kept in a configuration file on the host rather than in a managed key service, and there is no rotation procedure for it yet (Section 14). Our own credentials — the keys for the AI providers we configure, the Apple push key, the deployment's billing credentials and the key that signs our checkout references — are held the same way or only in that environment file, and are never a customer's to see.

1.5 Usage, security, abuse prevention and email

1.6 Billing, website requests and a Workspace's own Paddle signals

1.7 Our own records and correspondence

1.8 Backups

Off-server backups of the database are being set up, and we do not yet claim them. What exists: a script that copies the whole database to a Google Cloud Storage bucket, checks each copy is complete before it leaves the machine and records every table's row count beside it; a written recovery runbook; and a restore from such a copy rehearsed on 2026-08-18 on a separate machine. A scheduled job to run that script was installed on the production machine on 2026-10-12, and on 2026-10-21 the storage bucket answered an anonymous probe the way an existing private bucket does. What we have not yet confirmed: that the copies are landing on schedule, how many are kept and for how long, and how long a restore onto the production machine takes. Until each of those is confirmed and timed, the honest statement is that a failure of the production machine's disk could lose data, and the page at assemblywright.ai/trust says the same. Google Cloud's own disk snapshots, if any run, are likewise unconfirmed and not claimed. We will update this section, and the trust page, in the same change that confirms them.

What follows will be true of the backups once they run, and is true of any copy we take by hand today (for example before a restore or a test): a copy contains everything in the database at that moment, including anything you later delete, until the copy itself is deleted; a copy is kept only in an account or on a device under our control; a copy we take by hand is deleted once that recovery or test is complete, and in any case within 30 days of being taken, unless we must keep it for a legal reason (Section 1.7); and we use it only to restore the Service after a failure, or as Section 4 allows. Files the UI-verification feature keeps on the machine, and Deliverable text or undo payloads you chose to hold in your own org, are not in a database copy. If we ever restore from a backup, we will re-apply every deletion made since that copy that our remaining records show; where a failure leaves us unable to tell what was deleted since then, we will tell the owners of every affected Workspace so that they can check and delete again.

1.9 When a Workspace ends

Deleting one person's data is a manual process today. Removing a member deletes their membership row and leaves the removal record. Their identifiers can remain in the Workspace: as the actor on audit entries, on a registered phone, on a social connection or a role profile they created, on a Paddle-signal decision they made, and in the Builds, chat and notes they wrote. There is no routine yet that erases a person across a Workspace; on request we do it by hand, within the time Section 10 states, remove what can be removed without destroying the Workspace's own records, tell you what we could not remove and why, and confirm in writing.

2. What we do not do

• We do not sell personal information, and we do not share it for cross-context behavioral advertising.
• We do not train AI models on your content, and the product does not send a customer's content to an AI provider whose terms allow it to train on what it receives. Section 5.4 says how that rule is enforced in code, names the providers it refuses, and says what we would disclose before ever overriding it; the one exception is the in-app Help assistant, which is never given your Workspace content (Section 7.2 says whether it is on).
• No advertising and no trackers. We place no advertising pixel, cross-site tracker or analytics script on any page we serve — not on the website, not in the app, not on the blog. In three places code from another service runs, each for the thing you are doing there: the app loads Clerk's sign-in code on every page, because Clerk is how you sign in; the payment page (/pay) loads Paddle's checkout when you go to pay; and the Help panel loads the Uiia assistant's script while that assistant is switched on (Section 3).
• We do not profile you or make automated decisions producing legal or similarly significant effects. The product's AI writes documents and proposes changes; a person decides what happens to your org (Section 6.1).
• We do not read your CRM beyond what you authorize. What the product can see and do in a connected org is bounded by the credential and permissions you give it, and by the execution mode your Workspace sets (Section 6.1).
• We do not send marketing email. If we ever start, we will update this policy first, every message will carry a one-click unsubscribe, and we will get the consent EU and UK law requires. The only email we send is listed under Resend and Clerk in Section 3. Email that a Workspace itself drafts for its own audience — a campaign, or a welcome to a buyer its own Paddle account reported — is that Workspace's own outreach, sent only after one of its people approves each one (Sections 6.4 and 6.6).

3. Who else handles personal data

These are all the outside services that receive personal data from AssemblyWright. A sub-processor handles data for us, on our instructions. An independent controller decides for itself how it uses what it receives, under its own notice. Each acts under its own published terms, linked from its name where it has them.

AI model providers (Section 5). Which provider answers a request is decided by a chain our operator configures and can change at any time; only its entries from the providers below whose terms do not permit training, and that are connected — we hold a key for it or, for Vertex AI, which takes no key, the Service is configured with a Google Cloud project for it — are ever called (Section 5.3). As of the effective date, every chain the Service uses by default starts with Anthropic's Claude — Sonnet for every feature and Wright we have not given a chain of its own, Opus for the architect Wrights, Haiku for the documentation and writing Wrights and most of the app's own AI features — with Google's Gemini on Vertex AI behind it; and Vertex AI also answers on the other occasions its row in the list above describes. Cloudflare Workers AI and OpenAI are connected and in none of those chains; each answers only on the occasions its row in the list above describes. Each provider below that may receive Workspace content is under terms that do not permit training; the rest of the catalog is refused in production by the guard in Section 5.4.

Not on these lists, because you direct them: your CRM vendor (Salesforce, Microsoft, HubSpot) and Salesforce's hosted MCP servers, reached with credentials you supply (Section 6.1); the social networks you connect through the Content Desk (Section 6.3); your own Paddle account (Section 6.4); Jira, Confluence, GitHub and Google Docs where you send a Deliverable to them (Section 6.5); and the Claude app, where you choose "Draft in Claude" (Section 7.3). Each is your own account under your own agreement with that vendor. The product signs in to another platform on your behalf only with a credential you give it, and never to read anything you did not connect it to.

Changes to these lists. The current list is this section; the privacy notice at assemblywright.ai/privacy summarizes it and names every sub-processor in it. Where the DPA applies, we email Workspace owners at least 30 days before a new sub-processor, or a listed AI provider other than Google's Vertex AI (which runs within Google Cloud, which already hosts the Service) that was not connected on the effective date, begins processing personal data we hold for your Workspace (Customer Personal Data, as the DPA defines it), and Section 5.3 of the DPA says what you may do if you object — except where an urgent replacement is needed to keep the Service secure or running, when we tell you as soon as we can. Which of the connected listed AI providers answers a request, and in what order, is our operator's setting and can change without that notice (Section 5.3); this section says which of them receive Workspace content as of the effective date.

4. When we share or disclose personal data

4.1 Who we share it with

We share personal data only:

• With the services in Section 3, to run the Service — including, if you dispute a charge, the facts Paddle needs to answer it, as its row in Section 3 says.
• At your direction. When your Workspace connects a CRM org, the product reads from it and writes to it as Section 6.1 describes; when it connects Profusia, a social account, its own Paddle account or another destination, or exports a Deliverable to Word, Google Docs, Jira, Confluence or GitHub, the systems you chose receive what you chose to send them; when a person approves a post, a campaign or a service email, the recipients receive it.
• Within your Workspace. A Workspace is one shared space: every member, in any role, can see everything in it — Builds and their requests, timelines and checkpoint answers, Deliverables and their versions, the Knowledge Base and what was imported from your org, chat with a Wright, the Bench, the Delivery board, notifications, and who connected or created what. Owners manage the member list (each person's sign-in identity — an email address or user id — and role). Admins and owners can read the audit trail, which names each actor by email address and records the IP address they acted from (while role enforcement is off, the product refuses that read; we send 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 — Section 10). What a Build quotes from your org is visible to everyone in the Workspace, whatever their access in the org itself; choose the org and the credential with that in mind.
• To comply with law. We disclose data in response to a subpoena, court order or other legally binding request, or to establish, exercise or defend legal claims, and we report and preserve material as US law requires. For a legally binding request for Workspace content, we tell the affected customer before we disclose where the law allows it and doing so would not put anyone at risk or compromise an investigation, and otherwise as soon as that becomes lawful and safe; we disclose only what the request requires. Sections 10.3 and 16.13 of the Terms say how we handle compelled disclosure.
• To protect people and the Service. Where we believe in good faith that it is needed to prevent serious harm to someone, to investigate or stop fraud, abuse or a security incident, or to enforce the Terms and the AUP (whose Section 8 sets out how we enforce it), we may disclose the data needed for that, including to law enforcement, and we tell the affected customer where that is lawful and safe.
• To our professional advisers. Lawyers, accountants and insurers may receive data under a duty of confidentiality, as needed to run the business.
• In a business transfer. If Evadaroo & Company, LLC or the AssemblyWright AI business is merged, acquired, reorganized, passed to a successor (including under the company's own succession arrangements) or sold, personal data may transfer with it. It remains protected by this policy unless you are told otherwise and given the chance to delete your data first.

We do not sell personal information or share it for cross-context behavioral advertising.

4.2 Who at AssemblyWright can see your data

AssemblyWright is run by one person, who holds administrative access to the production machine and its database, and can read them. Workspace content is not encrypted from us; the credentials you give us are encrypted, but with a key the operator holds.

• What the operator console shows: each customer and each Workspace by name; member counts, Build counts, usage and cost figures, and what each is entitled to; packages, prices, trials and switch-offs; which model serves each feature; the ledger of identities that reached the console (Section 1.1); the requests sent through the website's form, with the names and addresses in them; and the status of billing. By design it shows numbers, never content: it does not show a Build's request, a Deliverable, your Knowledge Base, anything read from your org, or a credential. It does show people in three places: a request from the website; the console's own access ledger; and the operator's Workspaces page, which lists every Workspace with each member's identity (the email address a membership is keyed by, or else the Clerk user id) and role.
• How the operator can reach content anyway, and what is and is not recorded. The operator's own account passes every Workspace's role checks, so the product does not wall the operator out of a customer's Workspace; there is 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. A change the operator makes inside a Workspace through the product is recorded in that Workspace's audit trail like any member's change, naming the operator; reading is not recorded. The operator can also read or change the database directly on the production machine with the host's own tools, which is not recorded by us. We do any of this only (a) at the customer's or a user's request for support; (b) to investigate a security incident or a reported breach of the AUP; (c) where the law requires, to respond to legal process, or to establish, exercise or defend a legal claim; or (d) to keep the Service running or restore it, where that cannot be done without it — and in each case we open only what that purpose needs. There is no consented "support access" mode: support means asking you.
• What the operator can do, and how it is recorded: put a customer on a package, start or end a feature trial, grant or switch off a feature with a reason, set a price agreed with a customer, set, change or remove a customer's AI allowance (Section 5.8), set which Salesforce orgs a customer may connect (Section 6.1), suspend and reinstate a customer (which suspends every Workspace it holds), delete a customer that holds no Workspace, add a model to the catalog and configure the credentials and routing for the AI providers, set the Apple push key, and answer a request from the website; and, on the Workspaces page, create a Workspace, move a Workspace between customers, and add a person to a Workspace or remove one — the route we use when a customer asks us to do that for it. Each of these is written to our own administrative audit trail — the same kind of trail every Workspace has, kept to its newest 2,000 entries — naming the operator (or "via hq") and stamped with the operator's own scope, not the Workspace's: it does not appear in a Workspace's own trail, and an act on a Workspace's membership names the Workspace and the person. Setting or clearing the Apple push key is recorded there too, as "set" or "cleared", never the key itself. The operator cannot disconnect a customer's CRM org or delete one Deliverable from the console.
• Our internal operations console (Evadaroo HQ) can do the same — the member listing and the member changes included, as its catalog of operations in Section 3 says — through the product's own operator routes, one signed request at a time, and never anything outside them: it cannot export, close or connect a Workspace, start a Build, or touch the Content Desk. It is run by the same person. What it does is recorded in the same audit trail, marked as done through HQ, and in HQ's own log.
• The AI coding tool we build AssemblyWright with (Anthropic's Claude Code) works on the source code and documentation and holds no credential for the production machine or database. A change it makes reaches production only through the deploy gate, which runs the full test suite on the exact commit and lets the machine deploy only a commit the gate has recorded.

Beyond what this section describes, no screen, listing or export shows your Workspace content to anyone at AssemblyWright, and we do not read it. To keep the Service running we do look at operational records: counts, sizes, timestamps, error records, request logs and configuration.

5. AI features, and what reaches AI providers

Section 6 of the Terms is the AI disclosure that forms part of your agreement with us: that outputs can be wrong and that a person reviews them before relying on them. This section says what leaves the Service and where it goes. Section 8 of the DPA covers the same ground as a contractual term where the DPA applies.

5.1 Which features use a model

The Service is AI-powered throughout. A model is called by: each stage of a Build and each review gate; "Second opinion" and "Two approaches", where a Workspace switches them on (Section 5.5); chat with a Wright; the Guide's question lane (Section 7.1); Maintenance Workflows, where switched on; the questions the product asks before a Build starts, and the workflow builder; drafting in the Content Desk; a Build started by a Paddle signal (Section 6.4); and picture generation (Section 5.7). Searching, the product tour, exports, deploys to your org, seeding test data and the UI-verification walk call no model.

5.2 What is sent, and what is kept

When a feature runs, the text it needs is sent to one model provider, in the request that produces the answer. For a Build stage that can include: the Build request and your answers to the pre-run questions; the org context and Knowledge Base material imported from a connected org; prior Deliverables of the same Build; a slice of the Bench; a brief of recent Builds; your earlier answers from the ledger; and what the Wright's tools returned, which can include values read from your org's records. For chat, the conversation so far. The models are given no tools against your org except the read and write tools your Workspace's execution mode allows (Section 6.1), and a write never runs without the gate that mode requires.

Full prompts are not kept. What is kept is the output: the Deliverable, the chat reply, the drafts and critiques of "Two approaches", the Build's timeline (which records what each tool was asked to do and whether it succeeded, not the data it returned, with the two exceptions Section 1.2 names), and the usage record of which model answered, how many tokens it used and what it cost (Section 1.5). A conversation with the Guide lives only in the page you had open and is not stored.

5.3 Where it runs

Which provider answers a request is decided by a chain — an ordered list of models — that our operator configures for the whole Service and, where we choose, for one feature or one Wright; only its entries from the providers in Section 3 whose terms do not permit training, and that are connected (Section 3), are ever called. Our operator can change it at any time; if the first model cannot answer, the request is retried with the next model in the chain, subject to Section 5.4 — except in the features that call a model directly, below. As of the effective date, the chain every feature and Wright uses unless we have given it its own is Anthropic's Claude Sonnet 5.5 first, then Google's Gemini 3.8 Flash and then Gemini 3.5 Flash-Lite on Vertex AI. Two groups of Wrights, and the app's own AI features, have chains of their own:

• The Solution Architect and Data Architect 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 app's own AI features — the questions asked before a Build and the workflow fit check, the Guide, chat with a Wright outside a Build, Maintenance Workflows (other than one an architect Wright runs), the Content Desk, the advisors, the Knowledge Agent, Bench routing and question triage (the check run 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 asked 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); if that call fails, the request is sent to no other model. Where a newer Claude Opus, Sonnet or Haiku costs no more than the one a chain names and can be held to US-only processing, the Service may call it in that one's place; it is still Anthropic's model, under the terms in Section 3. Where a request is processed depends on the provider that answers it:

• Anthropic's Claude answers first in every chain above, and a second-opinion or two-approaches stage for which a Claude model is picked. Every request to it is held to processing in the United States (Anthropic's US-only inference setting, which the Service adds to each request; a Claude model that cannot honour it 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).
• Google Vertex AI answers behind Claude in every chain above, whenever the Claude model before it cannot; where the chain routes a request to it, including a feature or a Wright we route to it; where a Workspace picks a Gemini model for a second-opinion or two-approaches stage; and for the picture prompt, where Imagen is the image model set for the Workspace (Section 5.7). Gemini 3.8 Flash and 3.5 Flash-Lite are called in Google's us multi-region, which is fixed in the product's code and overrides the deployment's general region setting; any other Vertex model, including Imagen, runs in the region the deployment is configured for, which is a setting of the deployment rather than of the product's code. A deployment setting exists that could move the Gemini calls to Google's eu or global location; we would update this policy and the page at assemblywright.ai/privacy before using it, because global means Google may process a request anywhere.
• Cloudflare Workers AI and OpenAI are connected, and in none of the chains above as of the effective date: each answers only where we route a feature or a Wright to it, a Workspace picks one of its models for a second-opinion or two-approaches stage, or a Workspace's image model is one of its models. Cloudflare runs a request on its global network, and OpenAI in its own processing locations under its terms. Either can be outside the United States: nothing in the Service holds a request to them to a region.

5.4 Training tiers, and the guard that enforces the rule

Some providers' free tiers may use what they are sent to improve their models, and may let their staff read it. A customer's Workspace content is never sent to such a tier. The rule is enforced in code: in production, a provider our catalog marks as one that may train on inputs is never selected — not as the first choice, not as a fallback, not for one feature, not for one Wright, and not from a saved setting — and if no other provider can answer, the call fails with a sentence rather than falling back. The providers so marked today are Google AI Studio, Groq, Cerebras, OpenRouter (which passes a request to a host we do not choose, so we treat it as one that may train), Mistral, GitHub Models and xAI. The guard has one deliberate override, a deployment setting that we will not set for a deployment serving customers (DPA Section 8.3). Three things are true of the providers it does not refuse. Anthropic's API, Google's Vertex AI, Cloudflare Workers AI and OpenAI all run under terms that do not permit training, and each serves only where it is connected and our chain, a Workspace's second-opinion or two-approaches pick (Section 5.5), or another occasion Section 5.3 lists sends it a request; Section 5.3 says which does what as of the effective date. Which of them is connected, and the order of the chain, are set by our operator and can change, so read a second-opinion or two-approaches choice, or a Workspace's image model, as one that may reach any of them. And our development and test environments run on Google AI Studio's free tier with test data only, by written policy, and the product refuses that tier wherever Vertex AI is configured.

5.5 Second opinion and Two approaches

A Workspace admin can set a stage's effort above standard: a second model reviews the first model's draft ("Second opinion"), or two models each draft the stage, critique each other once, and the owner writes the final from both ("Two approaches"). Both are off by default, both need the feature to be included in the customer's package and allowed by us, and the designer picks the second model from the cataloged models of the connected providers (Section 3), within any list of models we allow for it. A Claude model so chosen is served by Anthropic over its own API, under the terms in Section 3; the product treats Claude reached through any route as the same family, and the route a request takes is bounded by Section 5.4. The drafts and critiques are kept with the Build (Section 1.2).

5.6 What the models do and do not decide

A model writes a document, a review verdict or a proposal; it does not decide anything about your org. Every change to a connected org runs through the rules in Section 6.1, and a reviewer's verdict that cannot be read is treated as "not approved". Outputs can be inaccurate, incomplete or confidently wrong about your org, and the review gates and human checkpoints exist so that a person decides; Section 6 of the Terms says what that means for your responsibility.

5.7 Pictures

Where a Build asks for a picture, the picture prompt is sent to the image model set for your Workspace — Google's Imagen on Vertex AI unless another is named — and the picture comes back as a Deliverable asset. We, or a Workspace admin once role enforcement is on, can name a model of another provider in Section 3 whose terms do not permit training; the prompt reaches it only where that provider is connected, and the guard in Section 5.4 refuses one whose terms permit training. The Imagen model the Service names by default was retired by Google on 30 June 2026, so picture generation works only where a current image model is set. Screenshots for training guides are taken from your own org by the browser runner (Section 3), not generated.

5.8 What providers keep, and your controls

Each provider handles what it receives under its own API terms, and most keep API inputs for a limited period to monitor abuse. We have not negotiated zero-data-retention terms with any provider. Your controls: a Workspace admin can set the execution mode to read-only, so that no Wright holds a write tool; leave "Second opinion" and "Two approaches" off; and choose what to connect. Every Workspace opened since 29 September 2026 carries a monthly spending ceiling that stops new Builds when it is reached (US $50 a month unless we set another figure at your request), an older Workspace carries one where we have set it, and only we can change it. Every customer also carries an AI allowance: a limit on what all of its Workspaces' AI use costs together — Builds and the app's own AI features — counted at the rate of the model that answered, over the customer's whole life rather than per month (US $25 unless we set another figure). Only we set, change or remove it, the product shows how much of it is used, and 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 before its next model call and to stop the app's AI features answering, unless we raise it. Apart from the second model a designer picks for "Second opinion" or "Two approaches" (Section 5.5) and the Workspace's image model (Section 5.7), there is no setting that lets a Workspace pick which provider answers; we configure the chains, and Section 5.4 bounds them.

6. The connections you make

6.1 Your CRM orgs (Salesforce, Dynamics 365, HubSpot)

Section 1 of the AUP leads with the rule that you connect only an org you are authorized to change, and Section 7 of the Terms carries your responsibilities for a connected org; this section says what the product does with it.

• What the product reads. An import reads your org's configuration: the org's own name, id and environment type; the list of your objects (names only — a Wright fetches an object's fields, picklists and relationships on demand during a Build, and what it fetches goes into the prompt); your active flows, triggers and validation rules; and the security model as the names of profiles and permission sets — never your user list. It stores that as Knowledge Base entries, and the survey and dependency map it builds alongside (Section 1.2) record per-object field inventories (never picklist values), record types, which automations touch each object, and which configuration depends on which. It does not copy your records into the Knowledge Base. During a Build, a Wright's read tools can query records, and what they return goes into the prompt (Section 5.2) and can be quoted in a Deliverable; the Build's timeline records what each tool was asked to do and whether it succeeded, not the data it returned, with the two exceptions Section 1.2 names. A Process Documentation Build reads your flows, triggers, rules and 180 days of your setup audit trail, with the names of the administrators who made each change, and writes them into a Deliverable (Section 1.3). Bulk updates and data snapshots read the records you target (Section 1.3). An email campaign resolves its audience from a CRM query at send time and never stores the resulting list (Section 6.6).
• What the product writes, and who decides. A Workspace has one execution mode, set by an admin. Read-only: no write tools exist. Gated (the default): every write pauses at a human checkpoint until one of your users approves it. Autonomous: writes run without a per-write approval — but only in a Salesforce org the product has itself confirmed is a sandbox, scratch or Developer Edition org, from Salesforce's own address pattern or the org's own flags captured at connect, never from a role a person typed; a production org, or one the product cannot classify, still waits for a person every time, and that is enforced on the server. Dynamics 365 and HubSpot writes always wait for a person, in every mode. Bulk data updates, their undo and email campaigns always wait for a person, even in autonomous mode. Pre-flight advisories are shown before risky writes.
• What is taken before a write, and what undo cannot do. A metadata deploy snapshots the affected configuration first and keeps it as an undo point, which restores the components it changed by redeploying them: it does not resurrect components a deploy deleted, it does not cover record data, and it never undoes what your own org's automation did in response. Undoing an addition is a deletion with a type-to-confirm step; a deleted field goes to your org's recycle bin, and any data in it is Salesforce's to keep or drop. A bulk update captures the prior values of exactly the rows and fields it will overwrite before it writes anything, and if that capture cannot be stored under the custody you chose, the update does not run. Where the captures live, and for how long, is Section 1.3.
• Which orgs a customer may connect. We set, per customer, which kinds of Salesforce org it may connect — by default Developer Edition and scratch orgs only; sandboxes too for a signed pilot; production only by agreement — and the product is designed to refuse one outside the policy: when the org is connected it reads the org's kind from Salesforce's own record and address, before the credential is stored, and when a saved connection is switched back on it reads the kind from that connection's stored address, treating a production tag as production. Dynamics 365 and HubSpot connections are not checked against it. The policy is an aid; testing in a non-production org first remains the customer's obligation everywhere (Section 7.5 of the Terms).
• Credentials and sessions. Your org's credential is stored as Section 1.4 describes. For a UI-verification walk, a short-lived session token for the integration user is handed to the browser runner (Section 3) so it can sign in through Salesforce's own front door, and is never persisted. Salesforce's hosted MCP servers, if a user connects them, are reached with that user's own OAuth tokens.
• Test data the product seeds into a sandbox uses addresses and numbers that cannot reach a real person, and every inserted record is ledgered so it can be removed (Section 1.3). Seeding refuses a production org unless the caller types the org's name.
• Disconnecting deletes the credential at once; closing the Workspace deletes every credential it holds (Section 1.9). What the product already wrote into your org, and what it stored there under your custody choice, stays in your org, under your control.

6.2 Profusia (publishing Deliverables)

Only if a Workspace connects it. Profusia AI is another product of our company; AssemblyWright connects to it as an ordinary client, with a Profusia access key the Workspace supplies for its own Profusia workspace, stored encrypted and never shown back. When connected, each completed Build becomes a collection in that Profusia workspace, named for the request and carrying the request text as its description, and each Deliverable becomes a document there, a rework a new version of the same document; generated pictures are hosted there. The connection form pre-ticks automatic publishing, so connecting without unticking it publishes every completed Build's Deliverables from then on; with it unticked, nothing crosses until a person presses Push, and a manual push also creates an outward share link in Profusia. Deleting a Deliverable here does not delete it in Profusia; what is there is governed by your agreement with Profusia and its own privacy policy. Disconnecting deletes the key and stops the flow; it removes nothing already published.

6.3 Social accounts and the Content Desk

Only if a Workspace switches the Content Desk on and connects an account (LinkedIn, Bluesky, Mastodon, Threads, Dev.to or X). Today the desk is operated only by our own people for our own brands; a customer Workspace cannot switch it on until we open it, and we will say so here when we do. The desk drafts posts with a model; every draft lands as a draft, and a post reaches a network only after a person approves it; there is no path from an unapproved item to a network. The tokens for each account are stored as Section 1.4 describes, used only to publish an approved post, and deleted when you disconnect the account. The connection record keeps the account's label, the token's expiry and who connected it. Posted items are kept with the Workspace and cannot be deleted in the product, because they are the record of what was published; take a post down on the network itself. Where a network is not connected, the desk opens that network's own composer pre-filled and records only that you marked it as posted. Posting on X is billed by X to the account you connect, and connecting it requires you to tick an acknowledgment. As of the effective date no Workspace's desk has posted to any network, and the desk is held off for public posting on our own brand.

6.4 Your own Paddle account, and the signals it sends

Separate from Paddle as our reseller (Section 3). Only if a Workspace connects its own Paddle account, with its own API key and notification secret (which the product refuses to confuse with our own): the product reads that account on your behalf with read-only tools, and Paddle posts the account's events to a signed address of ours. For each event we keep the record in Section 1.6, for 180 days. A response a Workspace configures can send a service email to the buyer (a welcome, say) or start a Build; a response is created off; a response that starts a Build is switched on by one of your admins, and a response that sends email can be switched on only by us, at your request, because the email leaves from our domain; and in this version every email is approved one at a time by a person before it is sent through Resend from our domain, with a reply-to and an unsubscribe link, and at most once per buyer. Your buyers are your customers: your Workspace is the controller of their data and we process it for you, and the DPA covers it where it applies.

6.5 Other destinations you send a Deliverable to

A Deliverable can be exported as a Word file, built in memory and sent to your browser, or sent to Google Docs, Jira, Confluence or GitHub with a credential you connect (Section 1.4). What arrives there is governed by your agreement with that vendor. The product records nothing about an export beyond an audit line where one applies.

6.6 Email campaigns

A Workspace can draft an email campaign to an audience defined by a CRM query, with a stated lawful basis, a suppression list, signed unsubscribe links and a daily volume cap built in. No email sender is connected for campaigns in this deployment, so nothing has ever been sent: the product records who would have received a campaign and sends nothing. If we ever connect one, we will update this policy and the DPA first, because the Service would then be emailing your customers for you.

7. The Guide, the Help assistant, and the assistants you take work to

7.1 The Guide

The Guide is the in-app assistant (the ✦ in the top bar). Its search and its tour read nothing beyond the page. Its question lane sends your question, with the page you are on and a capped snapshot of your Workspace — workflow names, the Wright roster, which systems are connected, the last three Builds and the size of your Knowledge Base — to the model our chain sends it to (Section 5.3), grounded on the product's own help catalog. It never receives a Deliverable's text or your org's data. The conversation lives only in the page you had open and is not stored; the usage record notes that a question was asked, which model answered and what it cost (Section 1.5). It is limited to 200 questions a day per person, and we can switch it off for the deployment.

7.2 The Help assistant (Uiia)

Help is answered by Uiia, another product of our company. It is switched off in the app today, and while it is off nothing is loaded from Uiia and nothing reaches it. While on, its script runs in your browser and Uiia receives the questions you type into Help and, if you ask to be contacted, your email address; it answers from help articles we approved, using AI providers on free tiers whose terms may allow them to use what they are sent to improve their models. The product never gives it your Deliverables, Builds, Knowledge Base or CRM data, so Help is for questions about using AssemblyWright: do not type customer data into it. Section 8.3 of the DPA records this exception. This policy does not set out what Uiia keeps of a conversation; you can ask us at legal@assemblywright.ai. We will say here, and at assemblywright.ai/privacy, when it is switched on.

7.3 "Draft in Claude" and other hand-offs

The Content Desk can hand its drafting prompt to your own Claude app (the desktop app, claude.ai or Claude Code), where you draft under your own Anthropic plan and paste the result back. This is a hand-off, not an integration: the product holds no Claude credential and calls no model; what you paste into Claude is governed by Anthropic's terms with you. The same is true of anything you copy out of the product into another assistant.

The model providers themselves are in Sections 3 and 5.

8. The website, the Request access form, the blog and the payment page

• The website (assemblywright.ai) is static. It sets no cookies, runs no analytics, and loads nothing from any third party; its fonts are served from our own domain. It links out to other sites — for example Profusia, LinkedIn, Paddle and our providers' terms — but loads nothing from them. Its web server may keep ordinary request records, as Section 1.5 describes for the app.
• The Request access form posts what you type to our own app and nowhere else. The fields, their retention of 365 days, and the fact that no IP address or browser detail is stored with your request are in Section 1.6. Behind the form: a submission that fills a hidden field is discarded as a bot's; five submissions an hour per address and two hundred a day in all are accepted; and a request to review a sandbox org is refused unless the box confirming it is a sandbox is ticked, because we never review a production org. A person reads each request and replies from hello@assemblywright.ai; we state no turnaround time.
• The blog (assemblywright.ai/blog) is served by the app with no script and a strict content-security policy, and shows only articles that a person approved in the Content Desk; as of the effective date it shows nothing.
• The payment page (app.assemblywright.ai/pay) is where a Paddle checkout opens. It reads no database and holds no credential of yours. When a Paddle transaction is in its address it loads Paddle's checkout code from Paddle's own domain, and Paddle's frames may set cookies under Paddle's notice (Section 9); without a transaction it loads nothing. The page carries a sentence saying that by continuing you agree to the Terms and the Refund Policy and that Paddle is our reseller and Merchant of Record.

People described in a customer's Workspace. If a customer's Workspace holds information about you — a record a Wright quoted, a name in a setup audit trail, a buyer a Paddle signal reported, a person in a Deliverable — that customer is the controller and we act only on its instructions. Contact the customer; if you write to us instead, we will pass your request on and tell you we have.

9. Cookies and browser storage

The app sets no cookies of its own. The cookies in your browser on app.assemblywright.ai are set by Clerk's sign-in code, to keep you signed in, under Clerk's own notice; we hold no cookie of our own to describe.

Browser storage. The app keeps a few things in your browser's storage, on your device. In local storage: aw_theme (light or dark; an older key, aw_hero_skin, is read once to set it), aw_nav_collapsed (whether the side navigation is folded), aw_help_seen (which pages' guided tours you have seen), aw_bt_left and aw_bt_right (how you arranged two panels on the Build screen), aw.factory (which of your Workspaces you last opened) and, in the iPhone app once it is released, aw.mobile.device (that phone's registration id and push token), with aw.lastRoute (the last screen you were on, so the app's offline page can take you back) kept in the app's own storage on the phone. For the length of a browser session only: aw-legal-notnow:<edition> (that you chose to decide later about a new edition of our terms) and aw_customer_view (a switch used only in our operator's own account). Two of these reach us: the app sends aw.factory's value with each request, so that we know which of your Workspaces you are working in, and the iPhone app uses its registration to switch notifications off or to sign out, which updates the device record in Section 1.1. None of it is used to track you; clearing your browser data removes it, and in the iPhone app deleting the app removes what is on the phone (the device record in Section 1.1 stays until it is removed).

Why there is no banner. We use no cookie of our own, Clerk's cookies exist only to sign you in, and none of the storage above is used to track you across other sites or for advertising, so we do not show a consent banner.

Other services' code. Clerk's script runs in your browser on every page of the app, because it is how you sign in. On /pay, Paddle's checkout runs when you choose to pay. While the Help assistant is on (Section 7.2), Uiia's script runs in the Help panel; we have not yet confirmed what, if anything, it stores in your browser. The website loads no outside code at all.

What we count. Nothing: there is no page-view counter, no analytics and no fingerprinting on the website, in the app or on the blog. What the servers do keep is in Section 1.5: request logs, crash reports your browser sends, the audit trail's IP address on a privileged action, and in-memory rate-limit counters.

10. Your rights

How to ask. Email legal@assemblywright.ai. We confirm receipt within 10 business days and answer within 30 days, extendable once by a further 60 days where a request is complex, in which case we tell you. We verify a request before we act on it, usually by emailing the address on the account. Where that is not enough to be sure, or there is no account, we may ask for other information that shows the request is yours, and we will not act on a request we cannot verify. We use what you give us for verification only for that. You may ask through an authorized agent (Section 12). We do not charge for a rights request unless it is manifestly unfounded or excessive.

Until self-serve sign-up moves to invitation-only (Section 14), the product refuses every customer the acts that run work or reach a connected org — among them starting a Build, chatting with a Wright, editing Wrights, workflows and the Knowledge Base, connecting or disconnecting a system, moving an item to the trash, and reading the audit trail — and says so when you try. Where a right in this Section needs an act the product refuses or reserves — an export, moving an item to the trash or deleting it from there, removing a member, or reading the audit trail — we take it for you on a written instruction from a Workspace owner, or an admin for an act open to admins, to legal@assemblywright.ai, within the same 30 days, and confirm in writing. Reading and exporting a single Deliverable as a Word file work for every member today. A member recorded as the Workspace's owner or admin can also export, close (an owner only) and reopen the Workspace, restore items from the trash and delete them permanently, change the Workspace's preferences (the execution mode among them) and its retention, custody and evidence settings, and start or manage a subscription; an owner can invite, re-role and remove members; and a member recorded as an operator or above can ask the Guide.

If you are a user in a customer's Workspace, or anyone whose information is in one: for the Workspace's content (Builds, Deliverables, the Knowledge Base, what was read from its org, chat) and its records about you, contact that customer, which controls them; Section 6 of the DPA says how we help a customer answer such a request. If you write to us instead, we will pass your request to the customer and tell you we have. For your sign-in account itself (your email address, password, name and sessions at Clerk) and for a request you sent through the website, we are the controller and handle your request ourselves.

11. Legal bases (GDPR and UK GDPR)

Where the GDPR or the UK GDPR applies to our own processing, we rely on:

• Contract. Where you are our customer, or act for it: creating and running your account and Workspace, the connections you make and the features you switch on, billing through Paddle, support, and the notifications the Service sends about your Builds. For people a customer invites, who are not party to our contract, we rely instead on our and the customer's legitimate interest in providing the Workspace the customer asked for: your account and membership, and the notifications your Workspace has configured.
• Legitimate interests. Keeping the Service secure and available, and preventing abuse: rate limits that briefly use your IP address, the audit trail with its IP addresses, request logs, crash reports, the ledger of who reached our operator console, and the record of who was removed from a Workspace on purpose. Also keeping our own operations and commercial records; answering a request you send through the website; investigating reports of misuse, which can mean opening the reported content; and establishing, exercising or defending legal claims. We have weighed these against your interests: each uses the least data that works; an IP address held to limit abuse lives in memory for the length of its window — a minute for the app, an hour for the website's form — and the audit trail that keeps one for a privileged action is bounded to 2,000 entries per Workspace; a website request is deleted after a year; every period is stated in Section 1; and none of it is used for advertising. You can object at legal@assemblywright.ai.
• Legal obligation. Tax and accounting, responding to lawful requests, and reporting and preserving material where the law requires it.
• Consent. Only where we ask for it; you can withdraw it at any time, without affecting what happened before.

An email address is required to have an account; without it we cannot create one. Everything else in your profile is optional. For Workspace content processed on a customer's instructions — including what is read from its CRM org and the buyers its own Paddle account reports — the customer's own legal basis governs; ours is our contract with the customer.

12. California and other US state privacy laws

We do not sell personal information and do not share it for cross-context behavioral advertising, so there is no "Do Not Sell or Share" mechanism because there is nothing to opt out of. We do not use or disclose sensitive personal information for purposes beyond those permitted without an opt-out.

Your rights, whether or not a law requires them. Several state privacy laws apply only to businesses above size thresholds we may not meet. Whether or not a state privacy law applies to us, we honor requests to know, access, correct and delete, as Section 10 describes and subject to the exceptions those laws allow, and we let you appeal a decision. We do not discriminate against anyone for exercising these rights. Use legal@assemblywright.ai for all of it, including an appeal; we will respond to an appeal within 45 days with our reasons.

Do Not Track and Global Privacy Control. We do not track you across other websites. Apart from Clerk's sign-in code, Paddle's checkout on the payment page, which runs under Paddle's own notice, and the Uiia assistant while it is switched on (Section 9), we do not let third parties run code through the Service, and none of them is there to track you, so a browser's Do Not Track or Global Privacy Control signal has nothing further for us to switch off. We treat a Global Privacy Control signal as a valid request to opt out of sale and sharing, which we do not do in any case.

Authorized agents. You may make a request through an authorized agent. We may ask the agent for your signed permission, and ask you to confirm your identity with us directly.

What we collect, by category:

How long each is kept is in Section 1. We do not sell or share any of it.

Where we act for a customer. Where we process personal data on a customer's behalf, we act as a service provider / processor under these laws, on the terms in the DPA, and we do not retain, use, or disclose it for any purpose other than performing the Service, keeping it secure, complying with the law, and the other disclosures in Section 4.1 that these laws allow a service provider to make.

13. Where processing happens, and international transfers

We are a US company, and the Service is run from the United States. The application, its database and its files sit on one machine in Google Cloud's us-central1 region, the browser runner runs on Google Cloud in the United States, placed in the same region by our deployment procedure; off-server backups will be kept in Google Cloud Storage in the United States once they run. We offer no regional choice: all customer data is stored in the United States. The AI models every chain uses by default process a request in the United States; not every AI request is held there. A request is processed wherever the provider that answers it processes it (Section 5.3): in the United States for Anthropic's API, which is held to US-only processing, and for Gemini 3.8 Flash and 3.5 Flash-Lite on Google's Vertex AI, in Google's us multi-region; Imagen and any other Vertex model run in the region the deployment is configured for; and Cloudflare Workers AI runs a request on Cloudflare's global network, and OpenAI in its own processing locations, either of which can be outside the United States — neither is in a default chain as of the effective date. The outside companies in Section 3 that receive personal data are in the United States and process it there, with these exceptions: Paddle (United Kingdom and United States); Google's Vertex AI, for Imagen and the other Vertex models, in the region the deployment is configured for; Cloudflare Workers AI and OpenAI, as just described; Uiia, Profusia and Evadaroo HQ, our own company's products, which run on Cloudflare's global network; and Apple's push network, which delivers a notification wherever the phone is. The model providers the product refuses in production (Section 5.4) include Mistral, in France, and OpenRouter, which may pass a request to a host elsewhere; neither receives anything. Where the Service hands something to a provider that passes it on, Section 3 says so.

• Workspace content from the EEA, the UK or Switzerland is transferred under the Standard Contractual Clauses in our DPA, with the UK Addendum and the Swiss amendments, where the DPA applies; Section 7 of the DPA governs, and its Section 7.5 says the clauses prevail over anything in this policy or the Terms that conflicts with them.
• Your own account data you provide directly to us in the United States when you sign up or sign in from abroad. We protect it as this policy describes.
• We are not certified under the EU-US Data Privacy Framework, and we have not appointed a representative in the EU or the UK.

14. Security

The security half of this picture is at assemblywright.ai/trust. In short:

• every table that belongs to a Workspace carries its identifier, and the filter is applied once, at the data layer: a read outside a Workspace returns nothing and a write outside one is refused, which a test proves against a real database and the product reports live on an open address;
• sign-in is Clerk's, verified on every request against Clerk's published keys; per-Workspace roles (viewer, operator, admin, owner) are built into the product and come into force for customers when self-serve sign-up moves to invitation-only, which the product's public configuration reports, and until then a customer cannot take most of the acts the product gates on a role (Section 10 says which stay open to a recorded owner or admin, and which we take for it on written instruction where a privacy right needs it);
• the credentials you give us are encrypted at rest as whole snapshots and never shown back; Google Cloud encrypts the disks; Workspace content is not otherwise encrypted from us (Section 4.2);
• traffic is encrypted in transit on every hostname, and every hostname that serves pages carries HSTS and a standard set of security headers;
• privileged actions are written to an audit trail the product never edits (Section 1.5);
• spend cannot run away: a per-Build dollar ceiling that pauses for approval, a per-Build model-call budget, a per-Workspace monthly budget, a per-customer AI allowance, a daily Build cap and per-address rate limits;
• a change reaches production only through a gate that runs every module's self-test and a dependency audit on the exact commit, after which the machine smoke-tests the deploy and rolls back and quarantines a bad one by itself;
• an outside service has watched the product every five minutes since 2026-10-05, reading not only that it answers but that sign-in can work and that Workspace isolation is on, and emails our operator when a check fails.

No way of storing or sending data is completely secure. These measures reduce risk; they do not guarantee that the Service is free of vulnerabilities or that an incident cannot happen.

What we do not have yet: multi-factor sign-in is neither required by the product nor enabled on the production sign-in; off-server backups are being set up (Section 1.8); the key that encrypts stored credentials lives in a configuration file on the host, with no managed key service and no rotation procedure; the audit trail is bounded by count and not shipped off the machine; there is no intrusion detection, no error alerting beyond the uptime checks, and nothing that warns before a certificate expires; rate limits are kept per process; one person answers, with no on-call rotation; the written security policies have not yet been exercised in a drill; our written access review has not yet been run; and the configuration file that holds the credential-encryption key has no confirmed copy off the machine, so losing the machine could make stored credentials unrecoverable.

What we do not claim: no SOC 2 report, no ISO 27001, no HIPAA attestation, no third-party penetration test — none in progress. Isolation is logical, not physical. We say so here and at assemblywright.ai/trust rather than implying otherwise.

Reporting a vulnerability. If you believe you have found a vulnerability, please tell us at security@assemblywright.ai (see also the contact published at /.well-known/security.txt per RFC 9116). We do not run a paid bounty program. Our vulnerability disclosure policy is Section 4.3 of the AUP: research that follows its rules is authorized by us, and we will not bring a legal claim over it. That authorization binds only us and cannot authorize testing of anyone else's systems, including a CRM org you do not own.

15. Security incidents

If we confirm a security incident affecting personal data we hold, we will tell affected customers as Section 9.4 of the Terms and, where it applies, Section 3.7 of the DPA set out, and tell affected individuals and regulators where the law requires and within the time it requires. Notice goes to the Workspace owner's address on file, by email, from one person; there is no status page. Attempts that do not compromise personal data (blocked sign-ins, pings, port scans, denial-of-service attempts) are not incidents, and nor is anything done in your own CRM org with a credential, an approval or an execution mode your Workspace chose. Telling you about an incident is not an admission of fault.

16. Children

Accounts are for people aged 18 and over. The Service is a business product, is not directed to children, and we do not knowingly collect personal information from anyone under 18. A customer is responsible for what its own CRM org and Deliverables contain. If you believe a child has given us personal information, write to legal@assemblywright.ai: we will delete account data ourselves, and tell the Workspace owner about anything inside their Workspace so they can remove it.

17. Changes to this policy

We will post any change here with a new effective date. We keep every earlier version and will send any of them on request. For a material change, we will email each Workspace owner at least 30 days before it takes effect; a change that only adds a connection you must switch on yourself, or that says a feature named here as switched off is now on, is announced here and at assemblywright.ai/privacy — except switching on the Help assistant (Section 7.2), which we announce 30 days ahead in the same way as a material change. Where a change is required by law, or is needed to address a security risk or an active harm, it may take effect sooner, with notice as soon as practicable. Other changes take effect when posted. We will not use personal data we already hold in a materially different way from what this policy said when we collected it without your consent, where the law requires consent.

18. Contact

• legal@assemblywright.ai — privacy questions, rights requests, appeals, and reports of misuse.
• security@assemblywright.ai — vulnerability reports.
• billing@assemblywright.ai — billing and refunds.
• hello@assemblywright.ai — anything else, including a reply to a request you sent through the website.

Evadaroo & Company, LLC · 502 W 7th St, Ste 100, Erie, PA 16502 · USA