AssemblyWright AI — Acceptable Use Policy

Effective date: October 29, 2026

The short version. This box is a plain-English summary for convenience. It is not part of this AUP, and where it differs from the numbered sections below, the sections govern.

AssemblyWright reads and writes real business systems on your instruction. Connect only a CRM org you own or are authorized in writing to change, with credentials issued to you for the purpose and the narrowest permissions the work needs, and do the work in a sandbox first. We cannot check your authorization, and we do not try to.

Do not use it to produce or deploy anything illegal, harmful or deceptive, and do not put health records, card numbers or other regulated data into it — including by reading them out of an org.

Do not attack it, overload it, or get around its limits, roles, spending caps or review gates. Security research that follows Section 4.3 is welcome. AI output can be wrong, and the gates exist so that a person decides; autonomous mode runs only in an org the product has confirmed is a sandbox.

Email, posts and links that leave the Service go out under our name. Email only your own customers, post only to accounts you own, under each network's rules, and treat a Profusia share link as a key.

If something breaks these rules, we usually take the narrowest step first — one Deliverable, one feature, one User, or asking you to drop one connection — tell you why, and look again if you ask. Child sexual abuse material is reported to NCMEC and the Customer Account — every Workspace in it — is suspended at once.

Report a problem to legal@assemblywright.ai — describe it and say where it is; never send the material. Security problems go to security@assemblywright.ai.

This Acceptable Use Policy (the "AUP") is part of the Agreement under the AssemblyWright AI Terms of Service (the "Terms") between the Customer and Evadaroo & Company, LLC, a Pennsylvania limited liability company trading as AssemblyWright AI ("AssemblyWright", "we", "us"). Capitalized words this AUP does not define — such as Agreement, Build, Connected Org, Connected Service, Customer, Customer Account, Customer Content, Deliverable, Service, User, Workspace and Wright — mean what the Terms say they mean.

Who it applies to. This AUP applies to you, to everyone in your Workspace, to every Wright acting in it, and to everything done through credentials your Workspace holds — a Connected Org or a Connected Service: a social account, a Profusia workspace, your own Paddle account. It also applies directly to anyone else who uses the Service — a person reading our public pages or the blog, sending a request through our website, or following a link in an email the Service sends — whether or not they have accepted the Terms. An owner or administrator accepts this AUP as part of the Terms, and every other User accepts it for themselves when they first sign in to a Workspace; each confirms that they are 18 or older (Section 2 of the Terms), and we keep a record of each acceptance and of the edition accepted. You are responsible for the conduct of the people you give access to, and for what is done with the credentials you supply, except to the extent that the access resulted from our breach of the Terms or from a Security Incident. In Sections 1 to 7, "you" means anyone this AUP applies to; in Sections 9 and 9A it means the person writing to us — the person reporting, the person shown in an image, or the person sending a copyright notice or counter-notice; everywhere else it means the Customer.

How it fits with the other documents. If this AUP and another part of the Agreement disagree, Section 16.2 of the Terms decides which one governs. Section 8 of this AUP is the enforcement procedure that Sections 8, 11.3 and 11.4 of the Terms refer to, and where it differs from those Sections, Section 8 of this AUP prevails (Section 16.2 of the Terms). Section 1 of this AUP is the rule that Section 7 of the Terms and Section 4 of the DPA rest on, and Section 3 is the one list of data that must not be put into the Service, which the Terms and the DPA refer to.

1. Connect only a system you are authorized to change

In short: the Service does what the credentials you give it allow. Connect only an org you own or are engaged and authorized in writing to change, with the narrowest permissions the work needs, and work in a sandbox first.

1.1 Authorization. You may connect a CRM org — a Salesforce org, a Microsoft Dynamics 365 environment, a HubSpot portal — or any other system to the Service only if all of the following are true: you own it, or you are engaged by its owner and authorized in writing to make the changes the work needs; connecting it, and what you will do through the Service, does not breach your agreement with the CRM vendor (its terms of service, API terms and license) or with the org's owner, including any change-management or approval process the owner has in place; the credentials you supply were issued to you, or to an integration user created for this purpose, by someone entitled to issue them; and your authority continues for as long as the org stays connected. Disconnect an org when the engagement ends, when the owner withdraws its authorization, or when the person whose credentials it uses leaves.

1.2 Least privilege. Connect with an integration user that holds the narrowest permissions the work needs, and widen them only for the work that needs it. The Service can see and change only what those credentials allow, so what you grant is what you put at risk: do not grant administrator rights, "modify all data" or their equivalents where the work does not need them, and remove permissions, or rotate the credential, when the work is done. The credentials you supply are held encrypted and used only on your Workspace's instruction (Sections 7.1 and 7.4 of the Terms); supplying them to the Service does not widen what you are allowed to do with the org.

1.3 Sandbox first. Do the work in a sandbox, scratch or Developer Edition org, or your CRM vendor's equivalent non-production environment, before any production org, and tag every saved connection honestly as sandbox, UAT or production. The product relies on both, in different ways: a release or promotion resolves its target from the tag and asks you to type a confirmation for a production target; UI verification runs only against a connection tagged sandbox or UAT, treats an untagged connection as production, and otherwise refuses unless a Workspace administrator has opted the Workspace into production (Section 1.7); and autonomous mode and test-data seeding classify a Salesforce org from the org's own data — for an unattended write, its address or what the org said about itself when it was connected; for seeding, what the org says about itself when asked — never from a tag a person typed, so that a production org, or one they cannot classify, pauses an unattended write for a person and is refused by seeding unless you type the org's name (Section 1.6). An org the product cannot classify is treated as production; for autonomous mode and UI verification a connection you tag production is production even at a sandbox address; a sandbox tag you type does not make an org a sandbox for autonomous mode or seeding, and it is the only thing UI verification checks. You may not mis-tag a connection, switch the active org while a Build is waiting so that its next write lands elsewhere, or present a production org as a sandbox to get a write past a stop.

1.4 Production. Deploy to a production org only what a person has reviewed, and only after reading the pre-flight advisories the product shows. Section 7.6 of the Terms says what a rollback restores and what it cannot — the components a metadata deploy changed, not the components the deploy added, not record data, and never the downstream automation your own org ran on a change — so treat every production write as something you are prepared to answer for. Do not deploy anything you have been told not to deploy, and do not use the Service to get around a control, an approval or a change-management requirement your organization or your client has in place.

1.5 What you may not do. You may not:

connect an org belonging to a client, an employer, a former client or employer, or any other party without that party's authorization, or keep it connected after the authorization ends;
use credentials belonging to someone else, a credential you found rather than were issued, or a shared credential whose owner has not agreed to this use;
use the Service — its read tools, its org import, a data snapshot, a bulk update, an email audience, the Process Documentation workflow or anything else — to read, copy, export or otherwise take data or configuration out of an org whose owner has not authorized you to take it, or out of a client's org for a purpose outside the engagement. Reading what the work needs from an org you are authorized to change is ordinary use; harvesting an org is not;
connect an org, or run a Build against it, in order to learn about a competitor, to take its customers or staff, or for any other purpose the org's owner has not authorized;
aim a write at a production org through autonomous mode, or defeat the classification, the tag or the confirmation step that stands between a Wright and a production write (Section 5.4).

1.6 Test data. Put test data into a production org only through the product's own seeding flow — which refuses a production or unclassifiable org unless you type the org's name, keeps a ledger of every record it inserts, generates addresses and telephone numbers that cannot reach a real person, and removes what it inserted — and only where the org's owner has agreed. Never seed a production org by any other route, never seed records that look like real people, and remove what you seeded when the work is done. Know its limits, which the product states: the org's own automations fire on seeded records, the sweep cannot see records another user created in response, a seeded record somebody hand-edited is still removed, and the optional watermark field outlives the records.

1.7 Screens of a real org. UI verification and training-guide capture sign a headless browser we run on Google Cloud Run into the connected org, using the integration user's short-lived session, and record video and screenshots of the real screens it walks. Run them only on an org whose owner has agreed to its screens being captured, and only on screens the plan names; the product refuses a connection not tagged sandbox or UAT unless a Workspace administrator opts the Workspace into production — it reads the tag, not the org, so tag honestly (Section 1.3). What is captured is Customer Content you are responsible for, and Section 3 applies to it.

1.8 We cannot verify your authorization, and we do not try to. Nothing in the Service can tell an authorized connection from an unauthorized one. Connecting an org is your statement that this Section is met, and you repeat that statement each time the Service uses the credentials. If we ask, you will give us within five business days the written authorization the org's owner gave you — or, for an org you own, proof that you own it — for any org we name; where you cannot, we may treat the connection as unauthorized and act under Section 8.4. The Terms make you responsible for what is done in the org and for any claim its owner brings (Section 13.2 of the Terms), and an unauthorized connection — above all one that is causing damage — is a reason for us to act first under Section 8.4.

2. Do not break the law or harm people

You may not use the Service, a Build, a Deliverable, a Wright, or anything the Service sends or publishes for you, to do anything, or to produce, store, deploy or send content, that:

violates any applicable law or regulation, or helps someone else do so;
infringes a copyright, trademark, patent, trade secret, right of publicity or any other right;
sexually exploits or endangers a minor, or contains or links to child sexual abuse material. We report apparent child sexual abuse material to the National Center for Missing & Exploited Children (NCMEC), as US law requires; we preserve the material and the records connected with it for as long as the law requires, including by holding the Workspace so that a deletion already under way does not run (Section 8.10); we cooperate with law enforcement; and we suspend the Customer Account involved — which shuts out every User in every Workspace it holds — and may terminate the Terms, without notice or a cure period. We never provide an export, copy or restoration of that material;
is non-consensual intimate imagery, including imagery made or altered with AI (Section 9.3 says how the person shown can have it removed);
threatens, harasses, stalks or defames a person, or incites violence or hatred against a person or group;
publishes or compiles another person's private information — such as a home address, an identity document, or financial or health details — to harass, expose or endanger them;
promotes terrorism or violent extremism;
promotes or facilitates prostitution or sex trafficking;
facilitates any other human trafficking, illegal weapons or drug sales, or the exploitation of vulnerable people;
exfiltrates, sells or misappropriates data from a system you do not have the right to take it from (Section 1.5);
builds, documents, configures or deploys a system whose purpose is fraud, unlawful discrimination, unlawful surveillance of people, or harassment — for example a CRM automation designed to deny service on a prohibited ground, or to track individuals without a lawful basis;
violates US export-control or sanctions law, or knowingly gives access to anyone in an embargoed country or region or on a US restricted-party list.

Deception. You may not use the Service for phishing, credential harvesting, fraud, pyramid or Ponzi schemes, fake invoices, counterfeit goods, or impersonation of a person or organization you are not; and you may not use a Deliverable, an email, a post or an article the Service produces to make a reader believe it comes from someone else, or that it is something it is not (Section 5.5). You may also not use the Service as a general file store for material unrelated to your work in it.

What goes out goes out under our name. Email the Service sends for you comes from an assemblywright.ai address; an article the Content Desk publishes to the website channel is served from assemblywright.ai; and on the networks we connect through our own application (LinkedIn, X, Threads) a post goes out from an application the network can identify as ours. One abusive message or article can get our domain or our application flagged by email providers, networks and blocklists for every customer at once. Content designed to abuse that trust is a specific harm this Section exists to stop (Section 8.4(a)). Section 6 says what the product does about this; in short, nothing of yours is published by us to the open web except an approved article on our own blog, which carries no script, and every email to your customers and every post to a network is approved by a person first. Those safeguards do not catch every abuse, and they do not make abusive content acceptable.

We may block access to the Service from embargoed jurisdictions. We do not currently screen users or block access by location, so each Customer remains responsible for its own compliance (Section 16.7 of the Terms).

3. Do not put regulated or hazardous data in the Service

This Section is the one list of data that must not be put into the Service; the Terms and the DPA refer to it. The Service is not designed, certified or sold for, and you may not put into it — by typing it, uploading it, writing it into a Knowledge Base entry or a Build request, or reading it out of a Connected Org:

protected health information subject to HIPAA — we will not sign a Business Associate Agreement;
payment card data subject to PCI DSS (card numbers, security codes, magnetic-stripe or chip data);
government-classified information, or technical data controlled under export-control law;
personal information collected from children under 13, or under the age of digital consent where you operate;
biometric identifiers, such as fingerprint, face or voice templates;
government identity numbers or financial account credentials in bulk — for example a list of Social Security or passport numbers, or of bank-account sign-ins;
special categories of personal data (health, racial or ethnic origin, religious or philosophical beliefs, political opinions, trade-union membership, sex life or sexual orientation, genetic or biometric data) and criminal-offence data, in bulk or as the main content of a Deliverable, a Knowledge Base entry, a snapshot or a Build — for example medical records, a staff health register, or a list of criminal convictions;
data whose handling requires a certification we do not hold. We hold none ourselves (see assemblywright.ai/trust).

How an org's records reach the Service. Importing an org's context reads its configuration — objects, fields, automation, profile and permission-set names — not its records. Records reach the Service when a Wright's read tool queries them during a Build (the results go into the prompt and can be quoted in a Deliverable and in the Build's log), when a bulk update captures the prior values of the records it will change, when you take a data snapshot, when an email audience is resolved, and when UI verification records a screen; and a Process Documentation Build reads 180 days of your org's setup history, including the names of the administrators who made each change, into its Deliverable. Scope each of those to what the work needs: where an org holds data in the list above, do not point a tool, a snapshot, a bulk update or a screen capture at those objects and fields, and prefer a sandbox with masked or synthetic data. Rollback payloads can be held in your own org instead of our database, and Deliverable text can be too; choosing that changes where a copy sits, not what this Section allows.

Incidental mentions. An incidental mention of special-category or criminal-offence data in ordinary business records — for example, a note in a user story that someone is on sick leave — is not a breach of the special-categories item above. It does not excuse any other item in this list. The Customer decides whether the security measures described in Annex II of the DPA are adequate for such content, and remains responsible for having a lawful basis for it (Section 4 of the DPA).

Where data is held. The Service stores everything in the United States — the application and its database on Google Cloud there. Not every AI request is held to the United States: a request is processed wherever the AI provider that answers it processes it. As of the effective date the models every default chain uses, Anthropic's Claude and then Google's Gemini on Vertex AI, process a request in the United States; a picture prompt to Imagen, or a request to any other Vertex model, runs in the Google Cloud region the Service's deployment is configured for; and Cloudflare Workers AI (on Cloudflare's global network) and OpenAI (in its own processing locations), which we can route a request to, can process one outside it. Which providers can answer, and where each runs, are in Sections 3 and 5 of the Privacy Policy, and we can change which of them answers. We offer no regional choice. Do not put in data that the law or a contract requires to stay in a particular country or region — including in the United States — or to stay out of the United States.

High-risk uses. You may not use the Service where its failure could lead to death, personal injury or severe environmental damage — including aircraft or vehicle control, life support, nuclear facilities or emergency dispatch — and you may not use a Deliverable, unreviewed, to configure such a system.

4. Do not attack, overload or get around the Service

4.1 The Service itself. You may not:

try to reach another Workspace's data, another Customer Account or its Connected Orgs, or any system, credential or address you were not given;
probe, scan or test the security of the Service, except good-faith security research that follows Section 4.3;
circumvent or interfere with authentication, Workspace roles, rate limits, the daily Build cap, the per-Build and per-Workspace spending ceilings, usage allowances, entitlements (the features a package includes), metering, or the audit trail;
introduce malware, ransomware, cryptominers or destructive code — including inside a Knowledge Base entry, a Build request, a skill, an uploaded file or a Deliverable, or in metadata you have the Service deploy to an org;
overload the Service with automated traffic, get around any rate limit or allowance (for example by spreading use across Workspaces or accounts), or use the Service as a denial-of-service origin — against us, or against your CRM vendor, whose API limits apply to the calls the Service makes with your credentials. The Service runs on capacity that every customer shares, and we may slow or refuse traffic that threatens it. Reaching a cap is not a breach: a Build that reaches its spending ceiling or its call budget pauses and asks, a Workspace that reaches its monthly budget or its daily Build cap is refused new Builds until the day or the month turns, a Customer Account that reaches its AI allowance has new Builds refused or paused before their first model call, and the app's AI answers stopped, unless we raise it, and the Service refuses rather than bills, as Section 4.4 of the Terms describes;
reverse engineer, decompile or try to derive source code from the Service, except where the law expressly allows it, and then only to that extent;
scrape or mirror the Service, or use it to build a competing product. This does not restrict exporting, copying or reading your own Customer Content through the Workspace export, the Word and Google Docs exports, the product's audit-trail page or any other interface we document, or automating your own normal use within the limits we publish;
publish, or give a third party, a benchmark, comparison or evaluation of the Service, of a Wright, or of the output of either, made without our prior written consent, or use the Service or its output to train, tune or evaluate a competing model or product. Describing your own experience of the Service in good faith is not a benchmark.

4.2 Accounts, trials, packages and Workspaces. You may not:

open more than one organization, Workspace or account to get another trial, to multiply a Workspace's budget, Build cap or other allowance, to use a feature your package does not include, or to get around a suspension (a further Customer Account you pay for is not a breach); or open an organization or account by automated means, with false details, or with someone else's details without their authority;
let more than one person use one User's sign-in, or share one Workspace across unrelated organizations to avoid paying for more than one;
resell or sublicense access to a Workspace, or provide the Service to third parties as a bureau service, without a written agreement with us. Doing work for your own clients in your Workspace, in orgs you are authorized to change, is ordinary use and not reselling.

4.3 Security research. We welcome good-faith security research that follows all of these rules: test only against a Workspace you own or have written permission to test, and never against a customer's Connected Org through us; do not access, copy, change, delete, keep or share data that is not yours, and stop and tell us at once if you come across any; do not degrade the Service for anyone — no denial-of-service, load or spam testing, no social engineering of our customers or of us, and no physical testing; report what you find promptly to security@assemblywright.ai and give us a reasonable time to fix it (we suggest 90 days) before disclosing it; and do not ask for payment as a condition of telling us — we run no paid bounty program. Research that follows these rules is authorized by us, and we will not bring a legal claim against you for it. That authorization is ours alone: it cannot bind a third party — such as a customer whose data you reach — or a law-enforcement authority, and it does not authorize testing of the services we depend on (such as Google Cloud, Clerk, Paddle, Resend, Apple, the AI providers, or any customer's CRM vendor), whose own policies apply. These rules are our vulnerability disclosure policy, and our contact is published at /.well-known/security.txt; if you are unsure whether something falls within them, ask security@assemblywright.ai first.

4.4 Skills, prompts and knowledge you write. A skill prompt you edit, a Knowledge Base entry you write, a workflow you design and an instruction you give a Wright direct what the Service does with your credentials, and you are responsible for every one of them. In a Workspace's connected systems they act with the integration user's permissions, so write and import only what you trust.

5. Use the AI features responsibly, and do not defeat the review gates

This Section applies to every AI feature of the Service — the Wrights in a Build, review gates and second-opinion models, Wright chat, Maintenance Workflows, the Content Desk's drafting, the Guide's answers, image generation and the Help assistant. The AI features are described, and their providers named, in Section 6 of the Terms and Section 5 of the Privacy Policy.

5.1 Prohibited uses. You may not:

use the AI features to generate content prohibited by any other section of this AUP;
use them to generate content designed to deceive a reader about whether it was machine-generated, where doing so would be unlawful or misleading in context;
circumvent, extract or interfere with a model provider's safety systems, or try to extract model weights, system prompts, a Wright's underlying instructions, or another customer's content;
automate bulk Builds or requests with the purpose of exhausting an allowance, degrading service for others, or reselling model access;
produce legal, medical, financial or safety-critical advice with the AI features and then present it to others as reviewed when it was not. AI output may be wrong; you are responsible for reviewing it before relying on it, and before deploying it to any system;
use the AI features, or anything they produce, as the sole or principal basis for a decision that has a legal or similarly significant effect on a person — about employment, credit, housing, insurance, education, healthcare, legal services or access to public services — without meaningful human review, or for any practice the EU AI Act prohibits.

5.2 Prompt injection. You may not put content into a Build request, a Knowledge Base entry, a skill, a Deliverable, a chat, an org the Service reads, or anything else an AI system will read, that is designed to make that system — a Wright, a reviewer, the Guide, another customer's, or a reader's own assistant — act against the interests of the person using it ("prompt injection"), for example hidden instructions to write to an org, send data elsewhere, approve its own work, or skip a gate. Instructions a Wright meets in data are not instructions from you, but a write a Wright makes because of them is still your act under the Terms; and you may not plant such instructions in anyone's data, your own included.

5.3 Model providers' own policies. The AI features are answered by third-party model providers, named in the Privacy Policy, and their own usage policies also apply to what you ask. You may not use the AI features for anything the published usage policy of any of those providers prohibits. If a provider tells us that requests from your Workspace breach its policy, we may switch an AI feature off for your Customer Account while we look into it, and we will tell you.

5.4 The review gates and human checkpoints. The Service is a governed pipeline: a Wright drafts, reviewers at the depth the stage sets check the draft, a person approves at the checkpoints the workflow sets, and every write to a Connected Org pauses for a person unless autonomous mode applies. You may not:

approve a gate, a checkpoint or a write you have not read, or arrange for gates to be approved automatically or by someone who has not read the work;
configure a workflow, a review depth or an execution mode to remove human review from work that affects a production system, and then rely on us for the outcome. Turning review down is your choice and your risk;
point autonomous mode at anything but a sandbox. The product enforces that: a Wright writes unattended only to a Salesforce org the product has positively identified as a sandbox, scratch or Developer Edition org; a production org, an org it cannot classify, and every Dynamics 365 and HubSpot environment pause for a person; and bulk data updates, their undo and email campaigns always pause for a person — even in autonomous mode; in read-only they are refused outright. Removing metadata from an org and releasing a deploy to another org are never a Wright's acts — each is an administrator's own instruction outside a Build, with a typed confirmation for the riskier ones (Section 7.4 of the Terms); a metadata deploy or a data-snapshot restore that a Wright proposes is an ordinary write, which runs unattended only where autonomous mode applies. You may not mis-tag, re-point or misclassify an org to get past any of those stops (Section 1.3);
mass-generate Deliverables you have no intention of reviewing, in order to satisfy an audit, a contract or a regulator by volume;
grant a paused Build more budget, more calls or another approval as a reflex. Each grant is a decision, and the Service records who made it.

5.5 Deliverables are not for deceiving anyone. A Deliverable is a draft until a person has reviewed it, whatever gates it passed. You may not present an unreviewed Deliverable to a client, an auditor or a regulator as reviewed; present a Deliverable as independently audited, tested or certified when it was not; present a Deliverable as the work of a named person who did not review it, where that matters to the reader; or strip or alter the provenance markings a Deliverable carries — the labels that say what was read from the org, what was inferred and still needs confirming, and what the team must supply — in order to make it read as more certain than it is. A diagram, a screenshot or a generated image in a Deliverable must not be presented as a record of something it does not show.

5.6 The Guide, Wright chat and the Bench. The Guide answers from the product's own help and a small snapshot of your own Workspace — its workflow names, roster, connections, last few Builds and Knowledge Base size — and Wright chat and the Bench work only on your Workspace. You may not use any of them to reach, or to try to reach, another customer's Workspace, a Wright's underlying instructions or anything you were not given, and the limits on them — a daily cap on Guide answers, a chat kept only to its newest turns — are not to be worked around.

5.7 The Help assistant. The Help assistant in the app is Uiia, another product of ours, and it is switched off as of the effective date. When it is on, it answers from AssemblyWright's own published help and reads no Workspace content, and it is answered by third-party AI services on free tiers whose terms may allow them to use what they are sent to improve their models. What you type into it is not Customer Content, so the rule that keeps Customer Content away from such services (Section 6.5 of the Terms) does not cover it: do not type personal, confidential or customer information, or anything from a Connected Org, into it.

6. Do not misuse email, social posting or sharing

6.1 Email the Service sends is for running the Service, never for promotion. The Service sends: notifications to the address a Workspace sets, or otherwise to its owner — a Build finished, a review gate waiting, input needed, a Content Desk digest; and, through our identity provider, an invitation to a person you invite into your organization. The Privacy Policy describes what each one contains. You may not use any of them to send unsolicited, bulk or commercial messages, to reach people who have not asked to hear from you and have no business reason to, or to deceive the person who receives them. Invite only people you have a business reason to invite. Text you choose that appears in our email — your Workspace's name, a Build's title, a display name — must not advertise, solicit or impersonate anyone, and must not carry a link or instruction designed to mislead. Notification email is capped per day across the Service. We may refuse, limit or stop sending any message, and where a Workspace misuses email we may suspend the Customer Account under Section 8.4.

6.2 Email to your own customers. Where your Workspace connects its own Paddle account and an email response is switched on for it — which only a person who operates the Service can do, because the email leaves from our domain (Section 7.13 of the Terms) — the Service can send a service email, a welcome for example, to a person who has just completed a purchase from you, from an assemblywright.ai address with your reply-to address, after an administrator or owner in your Workspace approves each send. Where an email campaign is run, the Service resolves the audience from your Connected Org under the lawful basis you record for it, honors a suppression list, and carries an unsubscribe link in every message. Both are transactional or consented email to your own customers, sent on your behalf from our domain, and you are responsible for it as the person on whose behalf it is sent. You may not use either to send unsolicited or bulk commercial email, to email anyone who has unsubscribed or whom you have no lawful basis to email, to email anyone but your own customers and the people who have asked to hear from you, or to send anything Section 2 prohibits; you must comply with the CAN-SPAM Act and, where they apply, the GDPR, the ePrivacy rules and your recipients' own laws; and you must honor every unsubscribe and complaint at once, including by keeping the person out of every later audience. Sending is capped — a service email per response, per Workspace and across the Service; a campaign per day — and every send goes out under our domain's reputation, so a complaint rate that threatens it falls under Section 8.4(a). As of the effective date, the email-campaign path records who would have received a message and sends nothing, because no campaign sender is switched on; what this Section says applies wherever it is switched on.

6.3 Social posting and the website channel. The Content Desk posts to a social account only after a person in your Workspace has approved the post, and that approval is your act. You may post only to accounts you own or are authorized to manage, under each network's own terms, developer policies and advertising and disclosure rules, which also apply to what you post through us; you may not connect an account that is not yours, use the Content Desk to post spam, coordinated inauthentic content or anything Section 2 prohibits, or use it to get around a network's suspension of you. Where a network bills per post, the Service asks you to acknowledge that cost before it will connect the account, and the cost is yours. An article approved for the website channel is served from our own domain, under our name, so Section 2's rule on what goes out under our name applies to it with particular force, and we may take an article down at once under Section 8.2. Where the product hands a post to you to publish yourself in a network's own composer, the same rules apply to what you post, and Mark as posted must be true.

6.4 Sharing and publishing Deliverables. Do not publish, export, push or share a Deliverable, a screenshot or an org's data that you do not have the right to distribute. Where your Workspace is connected to Profusia, each completed Build's Deliverables are published into your own Profusia workspace as documents — automatically, if you left auto-publish ticked when you connected — and a manual push also mints a share link. A Profusia share link is a bearer link: whoever holds it can open the document, a link forwarded is a link that works, and it does not expire unless an expiry is set on it, or it is revoked, in Profusia; a Deliverable you delete here stays in Profusia until you delete it there; and Profusia's own Acceptable Use Policy governs what you do with it. The same care applies to a Deliverable you push to Google Docs, Jira, Confluence or GitHub, or export as a Word file: once it has left the Service, our controls no longer reach it.

7. Connected systems and services

The Service acts as the credential you give it. Everything the Service does in a Connected Org or a Connected Service — a Profusia workspace, a social account, your own Paddle account, Google Docs, Jira, Confluence, GitHub, Salesforce's hosted MCP servers — it does as the user whose credential your Workspace holds — including a write a Wright makes under autonomous mode, a post an approver releases, and an act prompted by instructions a Wright read in data. Every one of those is the Customer's act under the Terms. What the Service sends to a connected system leaves AssemblyWright and is held by that system's vendor under your own terms with it; Section 6 of the Privacy Policy says which systems receive what. Connect only systems you control or are authorized to use, with the narrowest grant that does the work (Section 1), and do not try to widen a connection's scope or use it to move content you have no right to move.
Profusia AI is another product of ours, and connecting it is your choice: you supply the access key for your own Profusia workspace, and the Service publishes what Section 6.4 describes. Untick auto-publish when you connect if you want to choose Build by Build. Disconnecting stops publishing; it does not remove what was already published, which is yours to manage in Profusia.
Your own Paddle account. The Paddle connection reads your own Paddle account with a key you supply and receives the events Paddle sends to a signed address of your Workspace's. It is separate from Paddle as our reseller, and it has no write action. Connect only a Paddle account that is yours, and use what it tells the Service only for your own customers, as Section 6.2 says.
Disconnecting. Disconnect a system as soon as you no longer trust the connection or no longer have the authority behind it; a Workspace administrator does that from the Workspace's connections; disconnecting erases the live credential, and a saved connection you keep in the vault is deleted separately. Closing a Workspace erases every one of them at once (Section 11.5(b) of the Terms). We cannot disconnect one connection for you from our side; if a connection is doing harm and its owner does not act, we may suspend the Customer Account or close the Workspace (Section 8.1).
Vendor terms. Your CRM vendor's terms, your social networks' terms and Paddle's terms govern your accounts with them, and nothing in the Service changes what they allow. If a vendor suspends or restricts your account because of what you did through the Service, that is between you and the vendor.

8. Enforcement

8.1 What we may do. If we reasonably believe that content or conduct breaks this AUP, we may: remove or disable access to a specific Deliverable, Knowledge Base entry, post or article; ask the Workspace owner to remove content, disconnect a system, stop a process or remove a User; remove a User from a Workspace ourselves; switch off a specific feature for your Customer Account where the product gives us a way to (the features a package lists — Builds, Maintenance Workflows, the Content Desk, Paddle signals, Team Chat, the Guide's AI answers, UI verification, bulk updates, test data, release deploys, Model effort and the modules); suspend your Customer Account, which suspends every Workspace it holds; close a Workspace and terminate the Terms for it; or take any other step reasonably needed to stop the harm or to comply with the law. The product has no takedown control of its own, so removing one item — and closing a Workspace we have terminated the Terms for, since the product's own close control is the owner's — is a step a person at AssemblyWright takes by hand on the database, outside the product's screens. The product gives us no way to disconnect one of your connected systems, so for that we ask the owner and act on the Workspace if the owner does not; it does let us remove a User from a Workspace, which we do ourselves where asking the owner would not stop the harm in time. Whether something breaks this AUP is decided by us, in our reasonable judgment, and we may restrict access to material we consider in good faith to be harmful or otherwise objectionable, whether or not it is lawful. We generally prefer the narrowest step that stops the harm — one Deliverable, one feature or one User before a Workspace, and one Workspace before a Customer Account — but we decide which step fits. If an owner we ask to act does not, we may take one of the other steps.

8.2 Content first, without waiting. Removing one item, or switching off one feature, is not a suspension and does not wait for a cure period. We may do it as soon as we receive a notice that appears valid (such as a copyright notice or a court order), or reasonably believe the content is unlawful, deceptive or harmful, and we tell the Workspace owner when we do, as Section 8.5 describes.

8.3 Notice and cure before suspension or termination. For a paying Customer, unless Section 8.4 allows us to act first, we will tell the owner by email what is wrong and give at least 5 business days to fix it before we suspend the Customer Account or terminate the Terms. If it is fixed in that time, we will not suspend or terminate for it.

8.4 When we act first. We may suspend or terminate without prior notice or a cure period where we reasonably believe that: (a) there is a risk of harm to any person, to the Service, to other customers, to us, or to an org whose owner has not authorized the connection — including child sexual abuse material, malware, phishing, an attack on the Service, an unauthorized connection that is causing damage, a production write being forced past the product's stops, or a threat to the standing of our domain or our application with email providers, networks or blocklists; (b) the law, a court or a regulator requires it; (c) the Customer Account is on a trial or is not being paid for, or the Workspace was opened through self-serve sign-up and has never been paid for; (d) the same or a similar violation has happened before, after we gave notice of it; or (e) the Customer Account, the organization or the Workspace was opened with false information or to evade an earlier suspension. We will tell you why as soon as we can, unless the law forbids it or telling you would put a person at risk or compromise an investigation.

8.5 Telling you why, and looking again. When we remove content, switch off a feature, or suspend or terminate, we will tell the Workspace owner by email what we did, which content or conduct it concerns, which part of this AUP or which law it rests on, whether a report prompted it, and how to ask us to look again — subject only to the exceptions at the end of Section 8.4. Reply to that message, or write to legal@assemblywright.ai, within six months. A person will review the request and tell you the outcome. If you ask about a termination within the 30 days in Section 8.10, we do not erase the Workspace while your request is open; and if we got it wrong, we will put back what we still hold as soon as we can. This review is in addition to any remedy the law gives you. We keep our own record of every removal, switch-off, suspension and reinstatement, with the reason we recorded (which, where the exceptions at the end of Section 8.4 apply, may say no more than which part of this AUP it rests on); an act we take through our operator console — a feature switched off, a suspension, a User removed — is also written to our own administrative audit trail, not to your Workspace's (Section 10.4 of the Terms); and we will tell you what our record says on request.

8.6 Removing one item. Where a single Deliverable, Knowledge Base entry, post or article breaks this AUP, we can remove it, or disable access to it, on its own, without suspending its Workspace. An article we take down stops being served from our website at once. A Deliverable we remove is removed from the Workspace, with its version history, and from any export the product makes afterwards; where it has already been published to Profusia or pushed to another system, we tell the owner, who must remove it there (Section 6.4), and for a Profusia document we may report it to Profusia, which acts under its own Acceptable Use Policy. A post that has already gone out to a network is beyond our reach: we can stop its Workspace posting, and we ask the owner to remove it on the network. Removing an item is a deletion — we do not keep a copy for you, except where Section 8.9 requires us to preserve one, and except that an item we remove on a copyright notice is kept by us, outside the Workspace and served to nobody, until the counter-notice period in Section 9A has run, so that it can be put back if that Section requires. So we take that step on a valid notice, on a clear violation, or where the item is unlawful to hold; where it is not clear we ask the owner first (Section 8.1). For material that is unlawful to hold or pass on, we may suspend the Customer Account instead. To report content, see Section 9.

8.7 What a suspension does. A suspension is applied to your Customer Account, and so to every Workspace it holds, unless we confine it to the one Workspace concerned, as Section 11.4 of the Terms allows: each suspended Workspace refuses to serve anyone, its own members included, until we lift it. A member who signs in, or who was already signed in, is refused rather than served and reaches no Workspace; the signed address your Workspace's own Paddle account sends events to stops accepting them; and no Build, chat, export or connection is usable. A suspension does not by itself disconnect a Workspace's connected systems or erase their credentials, and it does not by itself stop every scheduled process the Workspace had set in motion; where a Maintenance Workflow, an automatic publish to Profusia, a scheduled post or a Paddle-signal response is the harm, we switch the feature off or ask the owner to stop it, before or alongside the suspension, and we may close the Workspace. Suspending deletes nothing, and a suspended Workspace is held rather than erased (Section 8.10), except that once the Terms are terminated it is closed and erased as Section 8.10 describes, whether or not it is still suspended (only a hold under Section 8.9 delays that). Only we can lift a suspension, and lifting it puts everything back as it was. We tell the owner by email, as Section 8.5 describes.

8.8 No monitoring obligation, and how we investigate. We do not review Customer Content as a matter of course — the operator's console shows names and counts, never a Build's request, a Deliverable, a Knowledge Base entry or an org's data — and nothing in this AUP obliges us to monitor it or to act on any report. We do not automatically scan content for malware or illegal material; we act on reports — from anyone, including a CRM vendor, a network, an email provider or a blocklist — and on what we otherwise learn. When we investigate a report, we may open the reported content and look at the records connected with it — who created it and when, which Build and which Connected Org it concerns, where it was published or sent, and the Workspace's audit trail — as far as the investigation needs. Acting on one report does not oblige us to act on any other, and not acting is not approval.

8.9 Preservation and disclosure. Where the law requires, or for an investigation, legal process or a legal claim, we may preserve content and the records connected with it — including beyond the retention and erasure periods in the Terms and the Privacy Policy, and after a deletion request — by holding the Workspace as Section 8.10 describes, or by keeping a copy of the records. We disclose them only as Section 16.13 of the Terms allows — for example a report the law requires to NCMEC, or what a court order compels — and we tell the Workspace owner as that Section describes.

8.10 Your content after a suspension or termination. A suspended Workspace is held, not erased, except after termination, as the end of this paragraph says. Suspending it deletes nothing, and while it is suspended — or while we must preserve it for an investigation or legal process under Section 8.9 — none of our erasures runs on it: not the erasure that follows an owner closing it (Section 11.5(b) of the Terms), whether the closing began before or after the suspension or hold, and not the erasure of any individual's data on request. A hold for an investigation or legal process does not stop what the Workspace's own Users delete themselves while it stays open to them; where that matters, we may keep a copy (Section 8.9). When the suspension or hold ends, normal retention resumes, with the closing window counted again from that day. The one exception is termination: once the Terms are terminated, the Workspace is closed and erased as the next paragraph describes, whether or not it is still suspended, and only a hold under Section 8.9 delays that; once such a hold ends, the erasure waits 30 days more. Records that expire by age under the Privacy Policy go on expiring meanwhile; where we need to preserve any of them under Section 8.9, we keep them, or a copy of them, before they expire.

While a Workspace is suspended, an owner may ask us at legal@assemblywright.ai for one export of the kind Section 11.5(d) of the Terms describes — every current Deliverable, the Knowledge Base, the list of Builds and the Workspace's configuration, without credentials, trash or version history — and we will provide it unless that would be unlawful or would defeat the purpose of the suspension. If the Terms are terminated for a violation, an owner may ask us at legal@assemblywright.ai, within 30 days after termination, for such an export. We provide it by a secure method we choose, or by lifting the suspension for a short time so that an owner can use the product's own export (the Workspace works again for that time); because the product's own export includes every current Deliverable, we restore a Workspace for this only where it holds none of the material described in the next sentence. We will not provide material that is unlawful to hold or return (such as child sexual abuse material), material we have removed on a valid legal notice, or anything a court or authority directs us to withhold. After that window, we will erase the Workspace as Section 11.5(b) of the Terms describes, whether or not it is still suspended, unless we preserve it under Section 8.9 or a request to look again under Section 8.5 is still open; until it is erased, it stays closed to everyone, as Section 8.7 describes. The credentials a Workspace holds for its connected systems are erased when it is closed, not at the end of the window.

8.11 Refunds. We do not refund fees for a period in which a Customer Account was suspended, or for a term cut short by termination, because of a violation of this AUP, including under the 30-day money-back in the Refund Policy. This does not affect a refund that Paddle, as Merchant of Record, gives under its own buyer terms, or any right the law gives you that cannot be waived. It also does not apply where you show, and we are reasonably satisfied, that the violation was caused by someone who used your sign-in or credentials without your authority, or by a single User whose access you removed promptly once you knew, and you have taken the steps we reasonably ask to secure the Workspace. In those two cases a suspension is treated as one that is not because of you (Refund Policy, Section 6), the 30-day money-back stays available within its 30 days, and if we terminate, we refund the fees prepaid for the unused term (Refund Policy, Section 7).

8.12 No charge for a suspended period. If a Customer Account we suspended under this AUP is still suspended on a renewal date, we will pause or cancel that renewal with Paddle so that you are not charged for a period you cannot use, unless an amount is also unpaid. That is a step a person at AssemblyWright takes by hand in Paddle's dashboard, so a renewal can be charged before we take it; if a renewal is charged while the Customer Account is still suspended under this AUP, we refund it, unless an amount was also unpaid (Refund Policy, Section 10). If we lift a suspension because it was a mistake, we will extend your paid period by the time you lost, or credit its value against your next bill or bills, or refund it where the Refund Policy says so.

8.13 Good-faith enforcement. Apart from what Sections 8.5, 8.10, 8.11 and 8.12 say we will do, we are not liable to you or to anyone else for action we take, or decline to take, in good faith under this AUP.

8.14 Disputes about enforcement. A dispute between the Customer and us about how we enforced this AUP is resolved under Section 15 of the Terms.

9. Reporting a violation

9.1 How to report. Write to legal@assemblywright.ai. There is no report button in the product or on our pages, so email is the way to reach us. So that we can act quickly, include: where you saw the problem — the address of the article, post, Profusia link or email, or, if you are a member of the Workspace concerned, the Workspace and the Build or Deliverable; what is wrong — and, if you say it is illegal, which law and why; your name and email address (you may report child sexual abuse material without giving them); and a statement that you believe in good faith that your report is accurate and complete. Where you have given us a way to reach you, we will confirm that we received your report and tell you what we decided, unless the law forbids it or telling you would put a person at risk or compromise an investigation.

9.2 Never send us the material itself. Describe it and say where it is — above all for anything you believe shows a child. You can also report child sexual abuse material directly to NCMEC, at report.cybertip.org or 1-800-843-5678.

9.3 Intimate images shared without consent. If you are the person shown in an intimate image or video that was made, stored or published through the Service without your consent — including one made or altered with AI — or you are authorized to act for that person, write to legal@assemblywright.ai with the subject "Removal request". Include: your physical or electronic signature; where it appears — the address of the article, post or Profusia link, or the Workspace and Deliverable if you know them; a short statement that you believe in good faith it was made or published without consent, with any information that helps us confirm it; and how to contact you. Within 48 hours of receiving a valid request, we will remove it from everything we serve or hold — the article, the Deliverable, the uploaded file, the generated image — and tell you when that is done. Where it has gone out to a social network or into a Profusia workspace, we will within the same time tell the Workspace's owner to remove it there, and we may suspend the Customer Account if that is not done promptly, or instead of asking; a post that has reached a network is also reportable to that network under its own process, and a Profusia document to Profusia under its policy. Where the law requires it, we will also make reasonable efforts, within the same time, to find and remove identical copies that we know of. We have no tool that searches the Service for copies of a file, so this means the copies you point us to and any we find among the records connected with the one you reported (Section 8.8): tell us every place where you have seen it.

9.4 Security and copyright. Security vulnerabilities go to security@assemblywright.ai (also named in /.well-known/security.txt), under the rules in Section 4.3. Copyright complaints follow Section 9A.

9.5 What happens to what you send. Reports reach our company mailbox, which is hosted by Google Workspace. We use a report to investigate and act on it. When we act, we tell the affected Workspace's owner that a report prompted it (Section 8.5), but we do not give them your name or contact details unless you agree, the law requires it, or your report is a copyright notice or counter-notice (Section 9A).

9A. Copyright complaints (DMCA)

We respond to notices of claimed copyright infringement under the US Digital Millennium Copyright Act, 17 U.S.C. § 512. Our copyright agent is:

Copyright Agent, Evadaroo & Company, LLC
Address: 502 W 7th St, Ste 100, Erie, PA 16502, USA
Telephone: provided when our agent is registered with the US Copyright Office
Email: legal@assemblywright.ai, with the subject line "DMCA notice"

We have not yet registered this agent with the US Copyright Office, and until we do we do not claim the safe harbor in 17 U.S.C. § 512(c). We act on notices sent to this address as this Section describes regardless.

What a notice must include: (1) a physical or electronic signature of the copyright owner or of a person authorized to act for them; (2) identification of the copyrighted work claimed to be infringed, or a representative list if several works are involved; (3) identification of the material claimed to be infringing and where it is — the address of the article, post or Profusia link, or the Workspace and Deliverable if you know them — with enough detail for us to find it; (4) your name, postal address, telephone number and email address; (5) a statement that you have a good-faith belief that the use is not authorized by the copyright owner, its agent, or the law; and (6) a statement that the information in the notice is accurate and, under penalty of perjury, that you are authorized to act on behalf of the owner.

What we do with it. When a notice substantially meets these requirements, we act expeditiously to remove or disable access to the material, usually by removing the Deliverable, file or article under Section 8.6 (keeping a copy, served to nobody, for the counter-notice period below). Where the material has already gone out to a Profusia workspace, a connected system or a network, we tell the Workspace owner to remove it there, and we may take a further step under Section 8, up to suspending the Customer Account. We send the Workspace owner a copy of the notice. That copy may include the sender's name and contact details; we may remove them where we think that is appropriate.

Counter-notice. If material of yours was removed and you believe that was because of a mistake or misidentification, you may send our agent a counter-notice that includes: (1) your physical or electronic signature; (2) identification of the material and where it was before it was removed; (3) a statement under penalty of perjury that you have a good-faith belief the material was removed or disabled as a result of mistake or misidentification; and (4) your name, address and telephone number, and a statement that you consent to the jurisdiction of the federal district court for the judicial district in which your address is located (or, if your address is outside the United States, any judicial district in which we may be found), and that you will accept service of process from the person who sent the notice or their agent. We will send a copy of the counter-notice — including your name and contact details, as the law requires — to the person who sent the notice, and we will put the material back — from the copy we kept, into its Workspace, where that Workspace still exists — no less than 10 and no more than 14 business days after we receive the counter-notice, unless our agent first receives notice that the sender has filed an action seeking a court order to restrain the activity, or the material breaks this AUP or the law for another reason.

Misrepresentation. Under 17 U.S.C. § 512(f), anyone who knowingly and materially misrepresents that material is infringing, or that it was removed by mistake, may be liable for damages. If you are not sure whether something infringes, take advice before sending a notice.

Repeat infringers. We keep a record of each valid notice, and of the Workspace and, where we can tell, the User it concerned. In appropriate circumstances we end the access of repeat infringers — by suspending their Customer Account or terminating the Terms for the Workspace, or by removing the User or requiring the Workspace owner to — and we may do so after a single notice where the infringement is clear and deliberate.

Other rights. We may also act under Section 8 on a complaint that does not meet these requirements, or that concerns a trademark or another right.

10. Changes

We may update this AUP. We post each version here with its effective date and keep every earlier version, which we will send on request. For a material change we will email each Workspace owner at least 30 days before it takes effect. A change required by law, or needed to address a security risk, a new kind of abuse or another active harm, may take effect sooner, with notice as soon as practicable. A change that is not material takes effect when posted. Section 16.3 of the Terms applies, including the right to cancel before a material change takes effect and receive a refund of the fees prepaid for the unused term.

Evadaroo & Company, LLC, a Pennsylvania limited liability company trading as AssemblyWright AI · 502 W 7th St, Ste 100, Erie, PA 16502 · USA · legal@assemblywright.ai