Privacy

What AssemblyWright AI stores, where it lives, how long it is kept, who else processes it, and how each data-protection right maps to something you can actually do. This notice describes the product as it runs today and claims only what is built. The security half of the picture is at Security & trust.

Who we are. AssemblyWright AI is a product of Evadaroo & Company, LLC, a Pennsylvania limited liability company. Privacy questions and rights requests: legal@assemblywright.ai.

The full legal documents, drafts for attorney review: Terms · Privacy Policy · DPA · Acceptable Use · Refund Policy

Last reviewed: 2026-10-26.

What we store, where, and for how long

Data	Where it lives	How long
Deliverables and Build records — the request you typed, the answers you gave before a Build started, the Build's timeline, the documents it wrote with each one's version history, chat with a Wright, and the drafts and critiques from "Two approaches" where you switch that on	Our PostgreSQL database on Google Cloud, `us-central1`	Until you delete them. Deleted items go to a trash and stay there until permanently deleted with a type-to-confirm step; nothing is purged automatically unless your Workspace sets a retention window or a version cap, which are off unless you set them. Build timelines and chat have no deletion path of their own; chat is rotated to the newest 200 turns per Wright.
Knowledge Base, Lore and imported org context — the objects, fields, automation and history read from a CRM org you connect	Same	Until you delete them, or disconnect and remove them
Bench memory — what the product's agents have learned across Builds in your Workspace, with where each note came from. The Bench is switched on in production.	Same	A learned note fades and is archived when the product's confidence in it drops low enough; a note you pin never fades; otherwise until deleted
Connection credentials — for a CRM org; for Jira, Confluence, GitHub, Google Docs, Salesforce's hosted MCP servers and Profusia if you connect them; and for a Workspace's own Paddle account if it connects one	Same database, encrypted at rest as a whole; never returned by any screen or API	Until you disconnect and delete the connection; closing the Workspace erases every one of them at once
Content Desk posting tokens — only if you switch the Content Desk on and connect a social account	Same database, encrypted at rest; never returned by any screen or API	Until you disconnect the account
Paddle signals — only if a Workspace connects its own Paddle account: one record per event Paddle sends it, including the buyer's name and email and a few purchase facts, never the raw message. That Workspace's owner controls this data; we process it for them.	Our database	180 days, then deleted
UI-verification evidence — only if a Workspace switches that feature on: a screen recording and a screenshot of each step as a browser walked your own org's screens after a change, and the plan it followed	Files on the same Google Cloud machine	30 days, and at most 512 MB per Workspace
Accounts — email, name, sign-in details, role	Clerk, our identity provider, plus the membership record in our database	The account itself lives with Clerk until it is deleted there. Our membership record goes when you are removed from the Workspace or the Workspace is erased. A record that you were removed on purpose — the Workspace, your user id or email, and when — is kept so you cannot be re-added by accident; the only thing that clears it is an owner adding you back.
Access requests — what you send with the Request access form on this website: your name, work email, company, CRM platform, team size, what you'd like first, whether you confirmed your org is a sandbox, what's frustrating you, how you heard of us, and which page of this site you came from; plus when you sent it, and our own status and notes on the request and when we last changed them. No IP address and no browser details are stored with it.	Our database	12 months, then deleted — sooner if you ask
iPhone app devices — only if you register the app, which is built and not yet released: your Clerk user id, your email address, the platform, a push token per device, the app version, the device's name, and when it last registered	Our database	Not deleted automatically. The row goes when the app signs out and tells us, or when a person removes the device in the product; a device Apple reports as unregistered is switched off but kept.
Admin audit trail — who changed a setting, connected an org or restored a snapshot: the actor's verified email address, the IP address the request came from, the action, and field names, never values	Our database	The newest 2,000 records per Workspace
Usage and cost records — per model call, when it happened, the Build, stage and agent or the app feature that made it, the model that answered, tokens and cost; never the prompt or the reply, and no person is named. Your Workspace sees every one of its own calls under Insights → Usage, beside its AI allowance	Our database	Kept — they are the billing history
Request logs — for each request to the app: method, path, status, timing, and the signed-in account and Workspace where there is one; never request bodies or passwords. The web server also writes its own access log, which records each request's full address including any query string: the signed token in a Paddle-signals address is removed before it is written, but a token in an email unsubscribe link or the single-use codes in a sign-in redirect are not.	The server's own log files, on the same Google Cloud machine	No fixed limit yet — kept until the log files are cleared
Crash reports — errors the app reports from your browser or phone: the kind of error, its message, and your browser's identifying string	Our database	The newest 500 records
Rollback payloads — the prior record values captured before a bulk update	Our database, or a file in your own CRM org — your choice per Workspace	30 days by default, configurable per Workspace
Backups	Being set up: copies of the database kept off the server, in Google Cloud Storage. The job that makes them was scheduled on the production machine on 2026-10-12, and on 2026-10-21 the storage bucket it writes to answered an anonymous probe with 401 — it exists — where on 2026-10-09 it answered that it did not. Not yet confirmed: that a copy has actually landed there on schedule, and a timed restore from one on the production machine. This row will say when they run.	Stated here once they run
Billing records	Paddle, our reseller, from the date we begin taking payment — today Paddle is connected in its sandbox, so a checkout opens a test transaction and no real payment is taken; with us, only the subscription's package, status, renewal date and Paddle's reference numbers	As long as tax and accounting law requires

The application database is stored in the United States (Google Cloud, us-central1). Accounts sit with Clerk and billing records with Paddle, as below.

Who else processes it

Google Cloud (us-central1) — hosts the application and the database, and will hold the backups once they run. It also runs the browser runner (Cloud Run) used, only where a Workspace switches UI verification or training-guide capture on, to walk your own Salesforce org's screens: a short-lived container that receives the verification plan, a session token for that org, and the screenshots and recording it takes, returns them, and is discarded.
Anthropic (Claude) — our primary AI wherever our operator has configured an Anthropic key: Claude Sonnet drafts and reviews most Deliverables, Claude Opus the architecture work, and Claude Haiku documentation work and the app's own AI (the Guide, Team Chat, the questions asked before a Build, the advisors, the Knowledge Agent and memory tagging); a Workspace's second-opinion or two-approaches choice may reach it too. It is sent the prompt for a stage, which can include your Build request, org context, Knowledge Base material and earlier Deliverables, or, for the app's own AI, what you typed. Reached over Anthropic's own API — there is no Claude model served inside Google Cloud in the catalogue — under Anthropic's commercial terms, which do not permit training on inputs. Every call is held to processing in the United States (Anthropic's US-only inference setting, which the product adds to each request); a Claude model that cannot be held to the US is never called. Whether production holds an Anthropic key is our operator's setting and cannot be seen from outside the product; where it does not, Gemini on Vertex AI (next) answers instead.
Google Cloud Vertex AI (United States) — Google's Gemini models: the AI that answers wherever Claude is not configured, and the fallback whenever Claude cannot answer. It is sent the same prompt Claude would have been. Under Google Cloud's enterprise terms it does not train on customer inputs. The Gemini models are called in Google's us multi-region; where a Build asks for a picture, Google's Imagen on Vertex AI receives the picture prompt.
OpenAI and Cloudflare Workers AI are in the product's catalogue under terms that do not permit training: nothing reaches either unless our operator configures a key.
What the product refuses to send. In production, a provider whose terms allow it to train on what it receives — the free tiers of Google AI Studio, Groq, Cerebras, OpenRouter, Mistral and GitHub Models, and xAI — is never selected: not as the primary model, a failover, a per-feature or per-agent choice, or a saved setting, unless our operator sets a deliberate override; and if nothing else remains, the call fails rather than falling back. Google AI Studio's free tier is used in development only, with test data.
Clerk — sign-in and accounts, including invitation email, which Clerk sends from its own infrastructure. Its code runs in your browser on every page of the app.
Resend — notification email is switched on in production, and Resend delivers it: the product's own notifications — a Build finished, a review gate is waiting, your input is needed — to the address a Workspace chose or else to its owner, with the title, a short detail and a link; Content Desk digests; and, only where a Workspace connects its own Paddle account, switches on an email response and a person approves each send, that Workspace's service emails (a welcome, say) to its own customers — the recipient's address and name and the email the team wrote. We use one Resend account for both AssemblyWright and Profusia, so its dashboard shows the sending records of both products to the same operator.
Apple Push Notification service, only if you use the iPhone app with notifications on — the same notifications, on your phone. It is sent 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. Push delivery is configured on our side; the app itself is not yet released.
Uiia, the Help assistant in the app — another product of Evadaroo & Company, LLC, running on Cloudflare's network. It is switched off today (since 2026-09-29): while it is off, nothing is loaded from Uiia and nothing reaches it. If it is switched on, it receives the questions you type into Help, and your email address if you ask to be contacted; the product never sends it Deliverables, Build content or CRM data. It would answer with AI models on providers' free tiers, whose terms may allow them to use what they are sent to improve their models — so keep customer data out of Help.
Paddle, when you buy a paid plan — Paddle (Paddle.com Market Limited and its affiliates) is our reseller and Merchant of Record for paid plans. It processes billing contact, payment and tax details as an independent controller under its own privacy notice (paddle.com/legal/privacy). Payment details go to Paddle, never to us. Today Paddle is connected in its sandbox: a checkout opens a test transaction and no real payment can be taken. On the payment page (/pay), Paddle's own checkout code runs in your browser, under Paddle's notice.
Evadaroo HQ — our company's own operations console, a small service on Cloudflare's network. It reads what our operator console shows — customer and Workspace names, counts, usage figures, entitlements and model routing, never Workspace content — and can perform the operator's own acts through the product's own operator routes, one signed request at a time, each recorded. It holds no credential of the product's and no customer content.
Cloudflare — answers DNS queries for assemblywright.ai. Our records are not proxied through it, so it does not see the traffic to the app or the website.
Let's Encrypt — TLS certificates. It sees domain names only.
Profusia AI, only if you connect it — another product of Evadaroo & Company, LLC, which receives the Deliverables you choose to publish into your own Profusia workspace, and the Build request as the description of the collection they land in. When you connect it, the "publish every completed Build" option is pre-selected; untick it if you want to push Deliverables one at a time.

Your CRM vendor (Salesforce, Microsoft, HubSpot), Salesforce's hosted MCP servers, Google Docs, Jira, Confluence and GitHub where you connect them, any social account you connect through the Content Desk, and a Paddle account a Workspace connects for its own sales are your own systems, reached with credentials you supply. We run no advertising and no third-party analytics, and we do not sell personal information or share it for advertising.

At AssemblyWright, one person operates the service. The operator console shows counts, names and dates, never Workspace content, and no screen in the product reads a Workspace's Deliverables or org context; the operator does hold administrative access to the production machine and its database, which no screen uses.

Your rights, as things you can do

Access and portability — an admin or owner can export the whole Workspace in one archive: the current version of every Deliverable as Markdown, the Knowledge Base, a list of every Build, and the Workspace's configuration (not credentials, not trashed items, not earlier versions). A single Deliverable exports from the Documents area, including as a Word file; an admin can export the audit trail. Anything a screen does not cover, ask for.
Correction — Deliverables, Knowledge Base entries and configuration are editable in the product; the product has no screen for your name or sign-in email today — write to legal@assemblywright.ai and we correct them at the identity provider for you.
Deletion — delete items in the product, then permanently delete them from the trash. An owner can close the whole Workspace by typing its name: every credential it holds is erased at once and access ends at once; the Workspace stays dormant and reopenable for 30 days, during which nobody can reach it unless an owner reopens it — so export first; after the 30 days we erase its rows and memberships, and today a person runs that erasure rather than a scheduled job, so it may happen some days after the thirtieth. Deleting one individual's data — a name on audit entries, say — is a manual process: ask at legal@assemblywright.ai and we do it by hand and confirm in writing.
Anything else — a restriction, an objection, a question: email legal@assemblywright.ai. We check the request comes from you, usually by confirming control of the account's email address.

If your details sit inside a customer's Workspace — a name in a CRM record, say — that customer controls them, so ask them. If you ask us, we pass the request on and tell you we have.

Cookies and tracking

This website (assemblywright.ai) sets no cookies, runs no analytics, and loads nothing from any third party — its fonts are served from our own domain. Its one form, Request access, sends what you type to our own app (app.assemblywright.ai), nowhere else. The blog at assemblywright.ai/blog is served by our app with no script and shows only articles a person approved; today it shows nothing.
The app (app.assemblywright.ai) itself sets first-party cookies only, to sign you in and keep your session, and remembers your light or dark theme on your device. Clerk's sign-in code runs on every page of the app, because it is how you sign in. On the payment page (/pay), and only when a Paddle transaction is in the address, Paddle's checkout code loads from Paddle and runs under Paddle's own privacy notice, and Paddle's checkout may set cookies of its own. The Help assistant (Uiia) is switched off today; while it is on, the app loads it from Uiia. There is no advertising cookie, no third-party analytics and no cross-site tracker, which is why there is no cookie banner: there is nothing a banner would be consenting to.

California and other US states

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" link — there is nothing to opt out of.

Children

AssemblyWright is a business product for people aged 18 and over. It is not directed to children, and we do not knowingly collect information from anyone under 18.

Changes and contact

This notice changes when the product does, in the same change. Privacy questions and requests: legal@assemblywright.ai. Vulnerability reports: security@assemblywright.ai.