AssemblyWright AI — Terms of Service

Effective date: October 29, 2026

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

Your content is yours. Everything in your Workspace — your Build requests, your Knowledge Base, what is read from a CRM org you connect, and the Deliverables a Build produces — is yours. We use it only to run, secure and support the Service, to deal with abuse, and as the law requires. We do not sell it, and we do not train AI models on it.

Nothing is written to your CRM org except on your instruction. By default, every change a Build proposes to a connected org waits for a person in your Workspace to approve it. Writes that run without stopping happen only where one of your admins switched that mode on, and only in an org the Service has itself confirmed is a sandbox; Dynamics 365 and HubSpot changes always wait for a person. In that mode a Wright's pushes to the other services you connected, such as Jira or Profusia, also run without stopping. You supply the credentials, you decide what they may reach, and you confirm that you are authorized to change the org. Test in a sandbox first. An undo point is kept before every metadata deploy and every bulk update, and Section 7.6 says plainly what an undo cannot do.

AI output may be wrong. Deliverables, reviews and answers are produced by statistical models. The review gates and human checkpoints exist so that a competent person decides. Review every Deliverable before you rely on it, hand it to a client or deploy it.

A subscription belongs to a Customer Account and renews until you cancel. The packages, prices, included Builds and any overage rate that apply to you are the ones shown at checkout, in an Order or in the product — never a number in these Terms. If nothing names an overage rate, we do not charge one. Cancel at any time and keep what you paid for to the end of the term.

Money back. Ask within 30 days of your first payment and we refund it in full, once per Customer Account.

Spend brakes protect you; they are not a promise. A Build has a model-call budget and a spending ceiling, a Workspace can carry a monthly budget (on by default for new Workspaces) and has a daily Build cap, a Customer Account has an AI allowance that does not reset, and each pauses or stops rather than running on. None of them promises that a Build will finish within a particular cost.

Closing a Workspace is immediate; export first. When an owner closes a Workspace, every stored credential is erased at once and nobody can open the Workspace, though an owner can reopen it for 30 days. After that we erase it. Cancelling a subscription, or moving to a smaller package, deletes nothing.

What we do not claim. We hold no SOC 2 report, ISO 27001 certificate, HIPAA attestation or third-party penetration test. Off-server backups of our database are being set up and we do not yet claim them, so keep your own copies. AssemblyWright is operated by one person, who holds administrative access to the production systems.

Liability is limited on both sides to the fees paid in the 12 months before a claim, or US $100 if that is more, and neither side pays the other's indirect losses — including loss that follows from a change deployed to your CRM org. The main exceptions are on your side: you stay fully responsible for fees you owe, for claims about your content, your Users and your connected orgs, and for breaking the AUP (Section 14.3).

Disputes go to binding individual arbitration unless you opt out within 30 days. Either way, as far as the law allows, they are decided without a jury and not as a class action. Small-claims court stays open to both sides.

These Terms of Service (the "Terms") are a binding agreement between Evadaroo & Company, LLC, a Pennsylvania limited liability company trading as AssemblyWright AI ("AssemblyWright", "we", "us"), and the organization or individual that opens a Workspace, holds one as its owner, or buys a package for it ("you", "Customer").

You accept these Terms by ticking the box, or pressing the button, that says so when you open a Workspace, join one as its owner or admin, buy a package, or are asked to accept them when you sign in as an owner or admin of a Workspace (for example when they first apply to a Workspace you already own, or when you join one as its admin), or by signing an Order that refers to them. If you accept for a company or other organization, you represent that you have authority to bind it, and "you" means that organization; if you do not have that authority, you accept them yourself. Every other person who enters a Workspace accepts the AUP for themselves when they first sign in to it. If you do not agree, do not open a Workspace or buy a package.

Please read Section 15. It requires disputes to be resolved by binding individual arbitration, waives jury trials and class actions, and gives you 30 days to opt out of arbitration.

How it fits with the other documents. These Terms are the core of the Agreement. The AUP says what nobody may do with the Service and how we enforce that; the Refund Policy says when money comes back; the DPA applies where we process personal data on your behalf; the Privacy Policy describes what we store and who else handles it, and is a notice rather than a contract. Section 16.1 says what forms the Agreement and Section 16.2 says which document prevails when two differ.

1. Definitions

In short: the capitalized words in these Terms mean what this list says.

• Agreement — these Terms, together with the AUP, the Refund Policy, the DPA where it applies, and any Order.
• AUP — the Acceptable Use Policy at assemblywright.ai/legal/acceptable-use/. It is part of the Agreement and applies to you and to every User.
• Build — one run of a workflow through its stages, producing Deliverables, directed by a User and carried out by Wrights. A Build is the unit of work and, where a package counts Builds, of metering.
• Connected Org — a CRM instance — Salesforce, Microsoft Dynamics 365 or HubSpot — that you connect to the Service with credentials you supply, whatever its environment (sandbox, UAT, Developer Edition, scratch or production).
• Connected Service — any other system you connect to the Service or hand content to through it: a Profusia AI workspace, a social-media account, your own Paddle account, Google Docs, Jira, Confluence, GitHub, Salesforce's hosted MCP servers, or your own Claude account.
• Customer Account — the record under which we group one or more Workspaces for billing and entitlements. A subscription attaches to a Customer Account and covers every Workspace in it. Workspaces opened by the same owner, or under the same identity-provider organization, belong to one Customer Account unless we agree otherwise.
• Customer Content — everything you, your Users or a Wright acting for you put into or produce in the Service: Build requests and intake answers; Knowledge Base entries (including Lore — the promoted notes about your organization, with their provenance and dates, that a Wright is given as authoritative); the objects, fields, automation, configuration and history read from a Connected Org; the records a Wright reads during a Build; Deliverables and every version of them, with the drafts, critiques and review verdicts behind them; Bench memory; Wright chat and notes; delivery-board content; Maintenance Workflow briefs; the prior values and metadata captured before a change to a Connected Org; verification screenshots and video; Content Desk items; and the events your own Paddle account sends to the Service. It does not include Service data (Section 5.3A) or what anyone types into the Help assistant (Section 6.5).
• Deliverable — a document a Build produces: a solution design, user stories, a test plan, process documentation, training material, a release note, and the rest of the catalog in the product.
• Documentation — the help pages inside the app (the Guide's catalog), our trust page at assemblywright.ai/trust/, our security questionnaire where we have provided one, and our pricing page once it is published, as updated from time to time. The Documentation describes the Service; except as Section 4.1 says, it is not a contract or a warranty (Section 16.2).
• DPA — the Data Processing Addendum at assemblywright.ai/legal/dpa/, which applies where we process personal data on your behalf (Customer Personal Data, as the DPA defines it).
• Maintenance Workflow — a standing instruction on one skill of one Wright that runs on a schedule, reads what changed, and produces a brief. It holds no tools and activates nothing.
• Order — the package, billing interval and price you select at checkout or in Admin › Plan & billing, or an order form signed by both parties (a "signed Order").
• Security Incident — as defined in Section 9.4.
• Service — the AssemblyWright AI hosted software at app.assemblywright.ai (and the .com host that redirects to it), including the Build pipeline, the Wrights and their skills, the Knowledge Base, the Delivery module, the connectors, the Guide, the Admin area, the iPhone app once we release it, and the Documentation. Our own operator console is not part of the Service.
• User — a person you allow into a Workspace, in any role (viewer, operator, admin or owner). Users are not parties to these Terms. They must follow the AUP, and you are responsible for them.
• Workspace — the separate tenant in which your content, connections and settings live (called a "factory" in some places in the product). Access is scoped to a Workspace; billing is scoped to its Customer Account.
• Wright — one of the Service's AI roles (business analyst, solution architect, developer, QA, project manager and the rest), each with configurable skills, that drafts and reviews work in a Build and, where you allow it, uses tools to read from and write to a Connected Org.

2. Eligibility, accounts and responsibility

In short: adults only, for business use; you are responsible for your Users, your credentials, the roles you assign and what a Wright does with the access you give it.

2.1 You must be 18 or older. The Service is not offered to or directed at anyone under 18, and we do not knowingly collect personal information from anyone under 18. You will make sure that every User is 18 or older.

2.2 Business use. The Service is a business product. It is sold to organizations and to individuals acting for business or professional purposes, not for personal, family or household purposes, and you confirm that you are using it for business or professional purposes. If consumer-protection law where you live applies to you anyway, nothing in these Terms takes away a right that law gives you and does not allow to be waived, such as a consumer's statutory right to cancel a purchase within a cooling-off period, which Paddle's Buyer Terms also describe for the countries where it applies. Our 30-day money-back (Section 4.6) is available alongside such a right, but a payment is refunded only once.

2.3 Accounts, credentials and roles. Sign-in is handled by our identity provider, Clerk: your password, sign-in sessions and any organization you create there are held by Clerk under its terms, and we never see your sign-in password. The credentials you give the Service for a Connected Org or Connected Service are stored encrypted at rest as a whole, under a key kept outside the database, and no screen or interface returns them — only the names of the fields they fill. Every outward address the Service mints for you is a bearer credential: whoever holds it can use it. That includes the signed address your own Paddle account posts events to, an unsubscribe link in an email you send, and a share link that a manual push to Profusia mints; treat each one as a secret. You are responsible for who holds your credentials, for the Users you invite, and for keeping the permissions you grant the Service in each Connected Org no wider than the work needs (Section 7.2). The Service has four roles — viewer (sees everything, changes nothing), operator (runs Builds and answers review gates), admin (also edits Wrights, workflows, connections and settings) and owner (everything, including who can reach the Workspace). Once roles are on, starting a Build needs the operator role or higher; connecting, changing or writing to a Connected Org outside a Build, and changing the execution mode in Section 7.4, needs admin or owner. When a person joins through your identity-provider organization, their role is read once from their role there (the person who opened the organization is the owner; its admins are admins; other members are viewers); changing a person's role afterwards is done in the Service, at Admin › People, and removing them from the organization removes them from the Workspace. Assigning roles correctly is your responsibility, and the role is your primary control over who can change a Connected Org. As of the effective date role enforcement is switched off for every Workspace, because open self-serve sign-up is still on. Until we close it, the product refuses every customer User the acts that run work or reach a Connected Org — starting a Build, approving a gate, chatting with a Wright, editing Wrights, workflows or the Knowledge Base, and connecting, importing from, disconnecting or writing to a Connected Org — rather than allowing them to everyone, and says so. A User recorded as a Workspace's owner or admin can still take the acts that keep the Workspace itself: exporting it, closing it (an owner only) and reopening it, restoring items from its trash and deleting them permanently, changing its preferences (the execution mode in Section 7.4 among them) and its retention, custody and evidence settings, and starting or managing a subscription; an owner can still invite, re-role and remove members; and a User recorded as an operator or higher can still ask the Guide a question. Closing open sign-up switches roles on for every Workspace at once; a customer Workspace cannot run a Build until that has happened. Wherever these Terms say that you or a User can do something in the product, you can do it there where the product makes it available to you, and otherwise by writing to us at the address in Section 17 where another Section of these Terms, or Section 10 of the Privacy Policy, says we take that act on request.

2.4 Your Users, and what a Wright does for you. You are responsible for your Users, and for every Wright, Maintenance Workflow and automated response that acts in your Workspace under the settings you and your Users chose. A Wright acts inside your Workspace only, with the tools the execution mode in Section 7.4 allows it and the credentials you gave it. Everything it does — including an act prompted by instructions it read in a Knowledge Base entry, a document, a CRM record or a Connected Org's configuration — is the Customer's act under these Terms, as is every approval a User gives at a review gate or human checkpoint. Wrights make mistakes and can be steered by what they read, so review what they propose, give them only the access they need, keep the execution mode no more permissive than the org in question warrants, and switch a feature off if it misbehaves. Our safeguards — the human checkpoints, the sandbox-only rule for unattended writes, the undo points and the spend brakes — reduce this risk but do not remove it. We are not responsible for loss caused by what a Wright did with the access you gave it, except loss caused by our failure to hold it to the execution mode, the role rules and the sandbox rule that Sections 2.3 and 7.4 describe.

3. The Service

In short: what AssemblyWright does, how it may change, which parts are new or unproven, and what it does not promise.

3.1 What it does. AssemblyWright runs a governed, multi-agent delivery pipeline for CRM work. You describe a request; the Service runs it as a Build through a workflow of stages, each owned by one Wright and producing one Deliverable, past review gates whose depth you set per stage — Advisory (recorded, never blocking), Standard (blocking, up to two revision cycles) or Rigorous (iterates to approval, capped at three cycles and then escalated to a final determination) — and past human checkpoints (Review & Approve, Ask a Question, Talk it through) at which a User decides. A reviewer who requires upstream changes revokes every later approval, and the affected stages run again. Deliverables fall into seven catalog categories (Requirements, Design, Development, Quality, Release, Enablement, Management), each with an intent the writing and reviewing Wrights are given. Around the pipeline sit the Knowledge Base (your notes, and the objects, fields and automation imported from a Connected Org), the Bench (what each Wright has learned from review gates across the Builds in your Workspace, which decays unless pinned and which you can delete), Team Chat with a Wright outside a Build, the Delivery module (board, calendar, timeline, releases, portfolio), Maintenance Workflows, the Guide (search, a tour, and AI answers grounded on our help content and a capped snapshot of your Workspace's facts), and connectors to Salesforce, Dynamics 365 and HubSpot that can read from and — only as Section 7 describes — write to a Connected Org. Nothing in the Service writes to a Connected Org by itself. A write happens only on a User's approval, or, in an org the Service has confirmed is a sandbox, under the autonomous mode an admin of yours switched on (Section 7.4). Maintenance Workflows hold no tools and only propose.

3.2 We may change the Service. We add, improve and occasionally retire features. Where we retire a material feature, we will give at least 30 days' notice, except where the law, security or a third-party provider forces a faster change, and, where content is involved, a way to take it with you. If a retirement materially reduces the package you paid for, you may end your subscription — by telling us before, or within 30 days after, the retirement takes effect — and receive a pro-rata refund of the fees prepaid for the unused term (Refund Policy, Section 5). This Section, not Section 4.10, governs retiring a feature. We will not delete Customer Content to effect a product change.

3.3 Beta, limited and unproven features. A feature we label beta, preview or experimental, or that the Documentation described as untested, limited or not yet run against a live system on the date you ordered or last renewed, is provided as-is, may change or be withdrawn, and is excluded from any warranty or support commitment in these Terms. As of the effective date that includes: Process Documentation, which has not yet been run against a live org; the Dynamics 365 and HubSpot connectors, which have not been exercised against a live account; metadata restore, bulk data updates and their undo, data-snapshot restore, test-data seeding, releases and promotion, each of which is built and tested against simulated orgs and had no recorded run against a real one; keeping Deliverable text or captured values in your own org (Section 7.7), tested against simulated orgs only; UI verification and training-guide capture, whose browser runner is live but which have no recorded walk of a real org; the Content Desk, Campaign Studio and the Email Campaign workflow, which are not yet offered to customer Workspaces and none of which has posted to a real account or sent a real email (no email sender is switched on, so a campaign records who would have received it and sends nothing); Paddle signals (Section 7.13); image generation inside a Build, which works only where a current image model is set for the Workspace — the Imagen model the Service names by default was retired by Google on 30 June 2026, and until the Documentation says a replacement is in place treat the feature as unavailable; and the iPhone app, which is written but not yet built or published, so no phone can install it or receive a notification from it today. We make no claim about how Builds perform on the models in the chain Section 6.4 states as of the effective date, and we may change that chain at any time. Where the product says a feature is new or unproven, treat its output accordingly. We will keep this list current in the Documentation.

3.4 No uptime or response-time commitment. We do not currently offer a service-level agreement or a status page. We aim for continuous availability — an external monitoring service has checked the Service every few minutes since 2026-10-05 and alerts us — and we will make reasonable efforts to tell affected Workspace owners about material incidents we become aware of, but these Terms promise no percentage of uptime and no response time. We are a very small company, and we answer support requests as soon as we reasonably can. The Service applies its own limits, shown in the product or the Documentation: a daily number of Builds and a number of concurrent Builds per Workspace, a model-call budget and a spending ceiling per Build, a monthly budget per Workspace, an AI allowance per Customer Account (Section 4.4), a daily number of Guide answers per person, a number of requests per minute, and a daily number of notification emails for the whole Service. When one is reached, that kind of request pauses, waits or is refused until the limit resets — or, for the AI allowance, which does not reset, unless we raise it; a Build that reaches its own budget pauses and asks rather than stopping, as Section 4.4 describes. Notification email — a Build finished, a gate is waiting, your input is needed — goes to the address a Workspace sets or to its owner's address, is limited per day across the whole Service, and may be skipped; the notification in the product is the record, so do not rely on email as the only way you learn of something. We may also slow or refuse use that threatens the Service or is far beyond ordinary use of its package (AUP Section 4.1), and, where it is practical, we will tell the Workspace owner when we do.

4. Packages, fees and allowances

In short: checkout, an Order or the product sets the price and what it includes; subscriptions renew until you cancel; no overage unless something names a rate; the brakes protect, they do not promise; ending a subscription deletes nothing.

4.1 Packages and prices. The Service is sold as a subscription to a package, monthly or annually, per Customer Account; one subscription covers every Workspace in the Customer Account. The packages, prices, included Builds or credits, overage rates, trial lengths, features and limits in force are those shown at checkout, in Admin › Plan & billing, in a signed Order, or on our pricing page once it is published, and what checkout shows when you order governs your order. These Terms state none of those numbers, and a number in the Documentation is part of your Order only to the extent checkout or an Order repeats it. Our prices are not yet final: a price we show is a proposed price until checkout charges it, and the price shown at checkout governs. For a subscription you already hold, we do not raise its price or reduce what it includes except as Sections 3.2 and 4.10 allow. A package we mark as not available, or that checkout has no price for, cannot be ordered. A Workspace on no package is not entitled to any paid feature, whatever the product allows it meanwhile, and we may restrict such a Workspace to the features of the package it last held or to a free tier (a set of features we may offer without charge; we offer none as of the effective date) at any time, telling the Workspace owners first (Section 4.11).

4.2 Included Builds, overage and metering. A package may include a number of Builds or credits for a period. Usage is metered per Workspace and per feature — Builds started, Maintenance Workflow fires, Guide answers, verifications, bulk updates, seed batches, release deploys — and your usage and its model cost are visible to you in the product; a usage figure we cannot attribute is shown as such rather than as zero. Overage is charged only where your Order or checkout names a rate for it. Where a rate is named, use beyond the allowance is charged at that rate, in the way and at the time checkout or the Order states, through Paddle. Where no rate is named, no overage is charged: the allowance is a ceiling, and once you reach it we may refuse further Builds of that kind until the next period, ask you to move to a larger package, or allow the work to continue at no extra charge — we decide which, and none of those is a charge. We will not invent a charge for a rate nothing names. An allowance that is not used does not carry over.

4.3 Pay-as-you-go and prepaid credits. As of the effective date we do not sell pay-as-you-go usage or prepaid credits. If we offer either, it will be on terms shown at checkout, and pay-as-you-go usage will run only under a monthly cap that an owner of the Customer Account sets and can lower at any time; nothing will be charged above that cap. The Refund Policy (Section 11) says how prepaid credits would be treated.

4.4 Spend and volume brakes. Every Build carries a spending ceiling, with a default shown in the product and adjustable there — approaching it warns, and reaching it pauses the Build at a human checkpoint and asks before granting more (a stricter setting stops the Build instead) — and a fixed model-call budget of 48 calls, which pauses the Build and asks before it runs out; a person may extend it, at most twice. Every Workspace opened since 29 September 2026 carries a monthly budget, on by default (US $50 unless another figure is set); we set or change one for any Workspace at an owner's or admin's request, and the product offers a Workspace no control to change it itself. The budget warns as it fills, narrows the pipeline before it would ever touch a review gate, and then refuses new Builds while letting running ones finish. Every Customer Account 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 (the Guide, Team Chat, the questions asked before a Build and the rest) — counted at the rate of the model that answered, over the life of the Customer Account rather than per month, so it does not reset (US $25 unless we set another figure; we set, change or remove it, except that a figure checkout or a signed Order states is part of your order under Section 4.1; the product shows how much of it is used). It warns as it fills; once it is reached, the Service is designed to refuse a new Build or pause it before its first model call, to pause a running Build at a human checkpoint before its next model call and let it go on only once we raise the allowance, and to stop the app's AI features answering. Reaching it deletes nothing already produced. Every Workspace also has a daily number of Builds and a number of Builds that may run at once. Each spending figure is priced against the model that actually answered. These brakes protect both of us. They are not a promise that a Build will complete within a particular cost or number of model calls, and reaching one is not a fault in the Service. Where a brake stops a Build part-way, the Deliverables already produced stay in your Workspace.

4.5 Trials. A package trial exists only where checkout shows one. A trial started at checkout with a payment method is the start of a subscription: unless you cancel before the trial ends, Paddle will charge the first payment for the package and billing interval shown at checkout when the trial ends, and the subscription then renews automatically under Section 4.8. You can cancel during the trial at Admin › Plan & billing › Manage billing, or by writing to billing@assemblywright.ai from an owner's or admin's address, and you will not be charged. We may also switch a feature on for a Customer Account for a period, in the product; such a feature trial runs to the date we set and then ends on its own, and nothing is charged when it does unless an Order says so. We offer one package trial per Customer Account and may decline a trial, or end one early, where one has already been had or where we reasonably suspect abuse.

4.6 Money-back. If you are not satisfied, tell us at billing@assemblywright.ai within 30 days of your first payment for a package, and we will refund that payment in full — together with any charge added to the same subscription before you ask, for a larger package or a change of billing interval — once per Customer Account, monthly and annual alike, as the Refund Policy (assemblywright.ai/legal/refund/) sets out; a renewal charged after your request reached us is refunded as a charge made in error (Refund Policy, Section 10). The Refund Policy is part of the Agreement. When we refund a payment under this Section, we also cancel the subscription with immediate effect, and the Customer Account's Workspaces keep their content intact; we may then restrict them to the features of a free tier (Section 4.11). Paddle, as Merchant of Record, may also give a refund under its own Buyer Terms, including, at its discretion, within 14 days of a renewal; a refund Paddle gives counts as this once-per-Customer-Account refund, and if Paddle refunds a payment in full, we cancel the subscription in the same way once we learn of the refund. Before we apply this rule we check Paddle's own record of refunds and chargebacks, and we note the refund against the Customer Account ourselves. Where this Section and the Refund Policy differ on a refund, the Refund Policy prevails (Section 16.2).

4.7 Our reseller, Paddle. Our order process is conducted by our online reseller Paddle.com. Paddle.com is the Merchant of Record for all our orders. Paddle provides all customer service inquiries and handles returns. For orders, payments, invoices, tax and refunds, Paddle is your point of contact and issues every refund. We decide refund requests under the Refund Policy, and you may send them to Paddle or to billing@assemblywright.ai. Questions about the Service itself come to us at hello@assemblywright.ai. Paddle calculates and collects any applicable sales tax or VAT at checkout, and Paddle's Buyer Terms (paddle.com/legal/checkout-buyer-terms) govern the purchase transaction between you and Paddle. These Terms govern your use of the Service. Checkout opens on a page of ours that loads Paddle's own checkout; your card and billing details go to Paddle and never to us.

4.8 Automatic renewal, payment and cancellation. Paid packages renew automatically at the end of each monthly or annual term, for a term of the same length, at the then-current price for your package (Section 4.10), until you cancel. Paddle charges each term in advance, in the currency shown at checkout, to the payment method you gave it, and you authorize those recurring charges and any overage charge Section 4.2 names. Prices we show exclude tax unless checkout says otherwise; Paddle's checkout shows any tax and the total before you pay, and you are responsible for any tax Paddle does not collect, unless you provide a valid exemption certificate. A subscription is started by an owner or admin of a Workspace in the Customer Account, at Admin › Plan & billing where the product offers it, and we may rely on that person as acting for the Customer. A Customer Account holds one subscription at a time; checkout refuses a second while one is live. To change package or billing interval — including moving from a pilot or other signed Order billed through Paddle to a package, which is a change to that subscription, not a second one — write to billing@assemblywright.ai from an owner's or admin's address; Paddle's own portal does not change a package, and if you cancel and buy a new package yourself instead, the old subscription runs to the end of the period it was paid for without a refund or a credit. An owner or admin can cancel at any time at Admin › Plan & billing › Manage billing (Paddle's portal, which is also where a card is changed and an invoice is read), or by writing to billing@assemblywright.ai. Cancelling stops the next renewal and takes effect at the end of the term you have paid for; you keep your package until then. A cancellation by email takes effect when we confirm it, and if a renewal is charged after you wrote to us to cancel, we refund it. We do not send our own reminder before a renewal — Paddle may send one under its own terms — and Plan & billing shows the date your subscription next renews or ends; an owner or admin can cancel there at any time before it. If a payment fails, Paddle retries it and your package stays in place meanwhile; if the subscription is cancelled because payment could not be collected, Section 4.11 applies. We may also suspend paid features if an amount remains unpaid 10 days after we tell you, or while a charge is disputed or reversed; an unfounded chargeback does not cancel fees owed.

4.9 Annual terms. An annual term is billed once, in advance, for twelve months, at the annual price shown at checkout. Annual fees are non-refundable except as the Refund Policy provides.

4.10 Changes to prices and packages. We may change the price of a package, or what it includes (included Builds or credits, overage rates, limits, features, trial length), for future terms by telling the Workspace owners in the Customer Account by email at least 30 days before the change applies to you. A price increase, or a reduction in what your package includes, applies only from a renewal at least 30 days after that notice. Except as Section 3.2 allows (with the remedy it gives), the price and what a term includes do not change during a term you have already paid for, and you may cancel before a change applies. A change that only adds to what a package includes may apply at once.

4.11 What ending or changing a subscription does. Ending a subscription, or moving to a smaller package, limits what you are entitled to next; it does not delete Deliverables, Builds, Knowledge Base content, settings or anything else in your Workspaces, and your content stays exportable. When a subscription ends, we may restrict the Customer Account's Workspaces to a free tier, switch off paid features, or leave them running for a time, and we tell the Workspace owners by email before we switch a paid feature off under this Section; nothing we do under this Section deletes content, and a change in what you are entitled to does not revoke anything already deployed into a Connected Org or published to a Connected Service. We do not erase a Workspace for being unpaid or unused without first telling its owners by email at least 30 days before, and such a Workspace is then closed as if an owner had closed it (Section 11.5(b)), with the same 30 days to reopen it. This never applies to a Workspace with a live subscription or on a signed Order.

4.12 Never gated. Regardless of package, we do not put the following behind a paywall: exporting your Workspace (Section 11.5(d)) and exporting a Deliverable as a Word file; the trash and restoring from it; closing a Workspace; your own view of your usage and model spend; the audit trail; Process Documentation (it needs no feature beyond Builds themselves); publishing to Profusia; and the security measures Section 9.2 describes, which apply to every package alike.

5. Your content

In short: you own your content and the Deliverables; we use your content only to run the Service; we never train on it or sell it; what a Wright reads from your CRM org is yours and stays in your Workspace.

5.1 You own it. Customer Content is yours. Nothing in these Terms transfers ownership of it to us.

5.2 The license you give us. You grant us, and the service providers we use to run the Service (listed in the Privacy Policy and in Annex III of the DPA), a worldwide, non-exclusive, royalty-free license to host, store, copy, transmit, index, process, render, convert and display Customer Content, to make technical derivatives of it (for example the Knowledge Base entries built from an imported org, search indexes, Bench memory, briefs, digests and exports), to send the parts a Build needs to the AI providers Section 6 describes, and to make it available to the Users you choose and to the Connected Orgs and Connected Services you direct it to, solely to: provide, maintain, secure and support the Service for you; prevent and investigate fraud, abuse and security incidents; enforce the Agreement and the AUP; and comply with law. You grant this license on behalf of your Users as well. It ends when the content is permanently erased, except that copies may remain in our database backups until they age out (once our off-server backups run, for the period the Privacy Policy then states), in a copy we take by hand for a restore or a test (deleted within 30 days), in a copy kept under Section 16.13, and in records the law requires us to keep. Those copies stay protected by these Terms and are used only to restore the Service or as the law requires.

5.3 No training, no sale. We do not use Customer Content to train AI models, we do not sell it, and we do not use it for any purpose other than those in Section 5.2. Bench memory is derived from the Builds in your own Workspace and is used only there. Third-party AI providers receive Customer Content only as Section 6 describes.

5.3A Service data. We collect and use data about how the Service is used — such as counts of Builds and gates, timings, token counts and model cost, error reports, feature usage and audit events — to operate, secure, bill for and improve the Service. Service data does not include the content of your Deliverables, Knowledge Base or Connected Orgs; where Service data contains Customer Content, such as a Build's name in a usage record, that part is treated as Customer Content and used only as Section 5.2 allows. We may publish or share statistics derived from Service data only in aggregated, de-identified form that does not identify you, your Users, your clients or your Connected Orgs. We do not disclose Service data in a form that identifies you except to you, to our service providers, to a prospective acquirer, investor or lender under Section 10.1(b), or where the law requires.

5.4 Deliverables and AI output. As between you and us, you own the Deliverables and every other output a Wright produces for your Workspace, to the extent any rights exist in them, and, to the extent we hold any rights in the text of a Deliverable produced for your Workspace, we license them to you perpetually, irrevocably and royalty-free for any purpose — except that our templates, prompts, seeded Wrights, workflows and help content, and any part of them that appears in a Deliverable, stay ours and are licensed to you only as part of that Deliverable (Section 16.17). We make no claim that AI output is original. AI output may not be protected by copyright in every jurisdiction, may be similar to output produced for others, and may unintentionally reproduce third-party material; you are responsible for checking that your use of it is lawful and for reviewing it before use (Section 6.2). Our templates, seeded workflows, Wrights, skills, prompts and help content stay ours (Section 16.17); the changes you make to them for your Workspace, and what a Build makes from them, are your Customer Content.

5.5 Your responsibility for your content and your orgs. You represent that you have the rights to Customer Content; that you are authorized to connect each Connected Org and Connected Service you connect and to let the Service read from and, where you allow it, write to it; that doing so does not breach your agreement with your CRM vendor, your obligations to your own clients, or applicable law; and that, where the data a Wright reads from a Connected Org is personal data, you have a lawful basis for the Service to process it on your behalf (DPA, Section 4). You will not put into the Service the data Section 9.3 and AUP Section 3 exclude.

5.6 Where we keep it, and your custody choices. Customer Content is held in our database and storage on Google Cloud in the United States (Section 9.1) and, where you choose, in your own Connected Org: a Workspace can keep the bodies of its Deliverables as files in its own Salesforce org, with only metadata and a receipt kept by us, and can keep the prior values captured before a bulk update there too (Section 7.7). Deliverables keep every version; deleting one moves it to a trash from which it can be restored until a User permanently deletes it with a type-to-confirm step. No Build, Build timeline or Knowledge Base entry is ever purged automatically; a Deliverable is purged automatically only where a Workspace switches on the retention clocks the product offers (a maximum age, a number of versions to keep, a trash purge interval), each of which ships off. Captured values (Section 7.7), verification evidence (Section 7.9), your Paddle account's event records (Section 7.13) and a Wright's chat beyond its newest 200 turns have clocks of their own. Content we hold is not encrypted from us beyond the encryption of the disk it sits on; credentials are (Section 2.3). Section 10.4 says when we ourselves open it.

6. AI features and AI disclosure

In short: the whole Service is AI-powered; outputs may be wrong and a person reviews them; your content goes only to the providers we list, whose terms do not allow training on it, and the models our chains use by default process a request in the United States, though two other listed providers can process one outside it; the Wrights hold tools, so the gates are the control.

6.1 The Service is AI-powered throughout. Deliverables, reviews, revisions, proposals, intake questions, workflow drafts, Wright chat, Maintenance Workflow briefs, Content Desk drafts, images generated inside a Build (where an image model is configured) and the Guide's answers are produced by third-party AI models that we select and route. Two optional stage settings, Second opinion (the stage's own Wright reviews its draft on a second model) and Two approaches (two models draft and critique each other once), are off by default, gated by your package and your Workspace's preferences, and switched on by us for your Customer Account. The Guide's AI lane is on by default, answers from our help content plus a capped snapshot of your Workspace's facts (workflow names, the Wright roster, connection status, the last three Builds and the size of the Knowledge Base) and the page you are on, and we can switch it off for the whole Service; a Workspace cannot switch it off for itself today. The Help assistant is a separate product (Section 6.5). You are never required to use a particular AI feature, but a Build cannot run without a model.

6.2 Outputs are generated by statistical models and may be wrong. They can be inaccurate, incomplete, internally inconsistent, or confidently mistaken about your org, your data model or your business. A reviewing Wright can approve a flawed draft, and a verdict the Service cannot read is treated as a request for revision rather than an approval. Every Deliverable must be reviewed by a competent person before it is relied on, handed to a client, or deployed to any system, and every change a Build proposes to a Connected Org must be reviewed before it is approved — particularly for anything that touches security settings, sharing, data, money, or anything legal, regulatory or safety-related. The review gates and human checkpoints exist for this; using them, and setting their depth, is your responsibility, not ours. A change a Build proposes to a Connected Org takes effect only when a User approves it, or under the autonomous mode an admin of yours chose for a confirmed sandbox (Section 7.4), and once it takes effect it is your act under these Terms. We disclaim all warranties as to AI output under Section 12.

6.2A AI output, and the providers' own policies. Section 5.4 says who owns AI output and what copyright it may or may not carry. AI features must also be used in line with the usage policies of the model providers named in the Privacy Policy, as AUP Section 5 describes, and the review gates may not be defeated or bypassed to push unreviewed output into a Connected Org or to a client (AUP Section 5).

6.3 What is sent, and what is kept. When a stage runs, the content it needs is sent to the model provider that answers: the Build request and intake answers, the Knowledge Base and imported org context (sent without a size cap today), the Deliverables of earlier stages, the Bench slice and briefs for the Wright, the results of any tool the Wright used (which can include records read from a Connected Org), and the stage's own instructions and skills, including any you edited. If a provider is unavailable, the request may go to the next provider we have configured, within the rule in Section 6.5. We do not keep the full prompt. We keep what comes back — Deliverables, drafts and critiques, review verdicts, chat replies and briefs — in your Workspace as Customer Content, with the events of each Build (including what each tool was asked to do and whether it succeeded — not the data it returned, except a failed call's error message, of up to 200 characters, and the result of the check run on the org before a metadata deploy — and the text of each human gate) in the Build's timeline, and the token counts, model and cost of each call in your usage records. Wright chat is kept to the newest 200 turns per Wright; the Guide's conversation stays in your browser and is not stored.

6.4 AI providers. The providers we may route to, and what each receives, are listed in the Privacy Policy (Sections 3 and 5) and in Annex III and Section 8 of the DPA. Which of them answers a request is decided by a chain — an ordered list of models — that we configure for the whole Service and, where we choose, for one feature or one Wright, and may change at any time; only its entries from the listed providers whose terms do not permit training, and that are connected, are ever called, and the Service skips any other entry (Section 6.5). A provider is connected when we hold a key for it or, for Google Cloud Vertex AI, which takes no key, when the Service is configured with a Google Cloud project for it. 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 Gemini 3.8 Flash and then Gemini 3.5 Flash-Lite on Google Cloud Vertex AI; the Solution Architect and Data Architect Wrights use Claude Opus 5.5, then Claude Sonnet 5.5, then the same two Gemini models; and the Wrights whose work is documentation and other writing, and the Service's own AI features other than the workflow builder (which follows the default chain), use Claude Haiku 5.5, then the same two Gemini models (Privacy Policy, Section 5.3, names each). Where the model that would answer cannot, the request goes to the next model in the chain — except in 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 of those uses the first usable model of its own chain or, where none of it can be used, the first of the default chain (Claude Sonnet 5.5 as of the effective date), and if that call fails, the request is sent to no other model. Claude is reached over Anthropic's own API, and every request to it is held to processing in the United States: a Claude model that cannot be held there is never called. Where a newer Claude Opus, Sonnet or Haiku costs no more than the one a chain names and can be held to processing in the United States, the Service may call it in that one's place. Those two Gemini models are called in Google's United States multi-region. Cloudflare Workers AI and OpenAI are connected too, but are in none of those chains as of the effective date: each answers only where we route a feature or a Wright to it, a second-opinion or two-approaches stage picks one of its models, or the Workspace's image model is one of its models, and either can process a request outside the United States (Section 9.1). A second-opinion or two-approaches stage may pick a model from any connected listed provider that we allow for it. The picture prompt goes to the image model set for the Workspace — Google's Imagen on Vertex AI unless another is named; we, or a Workspace admin once role enforcement is on, may name a model of another listed provider whose terms do not permit training, and the prompt reaches it only where that provider is connected. We rely on those providers' terms, as we use them, for the rule in Section 6.5 that they do not train on what we send. Each provider processes a request under its own published API terms, which may allow it to keep the request for a limited period, for example to detect abuse; we have not negotiated separate terms with any provider. We may change providers and models, and we will keep the Privacy Policy current; Annex III states the position as of the effective date, and a new provider that receives Customer Personal Data is a new sub-processor under Section 5 of the DPA.

6.5 Your content is not sent to providers that may train on it. Some providers' free tiers may use what they are sent to train their models. We do not send Customer Content to an AI provider on terms that allow it to train on what it is sent. The Service enforces this in production: a provider our own catalog marks as one that may train on its inputs is never selected — as the first model, as a failover, for a feature or for a Wright — and if no other provider can answer, the request fails rather than being sent. Our development and test environments use other model tiers with test data only, never Customer Content. The one exception is the Help assistant — the "Help" control in the app, answered by Uiia, a separate product of ours. It is switched off as of the effective date. While it is on, it reads only our approved help articles, the questions typed into it and, if you ask to be contacted, your email address; the Service never sends it Deliverables, Build content or anything from a Connected Org; and it may answer on a provider tier that keeps and trains on what it is sent. What you type into it is not Customer Content, so do not type anything confidential into it. DPA Section 8.3 says the same for personal data.

6.6 Wrights hold tools; what they read can steer them. Unlike a chatbot, a Wright can use tools: to read your Knowledge Base, to query a Connected Org, and — where the execution mode allows — to write to one. Text a Wright reads, in a document you upload, a Knowledge Base entry, a CRM record or an org's own configuration, can contain instructions designed to make it act. The controls against this are the ones Section 7.4 describes: the gated mode, which puts every write in front of a person, the sandbox-only rule for unattended writes, and the pre-flight advisories the Service shows before risky changes. Where you choose the autonomous mode, you accept that a write a Wright was steered into can reach a sandbox without a person seeing it first. Putting such instructions into content in order to make a Wright, or anyone else's, act is prohibited (AUP Section 5).

6.7 No professional advice. The Service, including its AI features, the Guide and the Help assistant, does not provide legal, tax, accounting, security, medical or other professional advice, and a Deliverable is not a substitute for a qualified practitioner's judgment.

7. Your CRM systems and other connected services

In short: you supply the credentials and decide the scope; every write happens on your instruction; sandbox first; here is exactly what an undo can and cannot do; the systems and services you connect are your relationships, not ours.

7.1 You supply the credentials, and you decide the scope. You connect a Connected Org with credentials you supply — for Salesforce, a connected app and a key the Service can generate for you (you install the certificate in your org), for an org of a kind your Customer Account's org policy admits (Section 7.5); for Dynamics 365, an application registration and its secret; for HubSpot, a private-app token. The Service stores each connection encrypted at rest as a whole (Section 2.3), never returns it, and never captures a passing session token into a saved connection. You may disconnect a Connected Org at any time (an admin or owner, at the connection, where the product offers it, or by writing to us). Disconnecting erases the live credential the Service uses; a saved copy of that connection stays in the Workspace's connections list, encrypted, until an admin deletes it there or the Workspace is closed — closing a Workspace erases every stored credential, live and saved, at once (Section 11.5(b)). Disconnecting does not remove anything already deployed into the org, and does not by itself remove what the Service imported from it into your Knowledge Base, which you can delete separately.

7.2 Least privilege is your control. Grant the Service the narrowest permissions in each Connected Org that let it do the work you want: an integration user with the objects, fields and metadata it needs and no more. We can only do what your credentials permit, and we can do everything they permit if you instruct it. The Service does not reduce what a credential allows.

7.3 You confirm you are authorized. By connecting a Connected Org or Connected Service you represent that you own it or are authorized by its owner to connect it, to let the Service read from it and, if you allow writes, to change it, and that you will obey any restriction your CRM vendor, your employer or your client places on that access. Connecting a system you are not authorized to change is the first rule of the AUP (AUP Section 1), and you indemnify us for any claim that follows from it (Section 13.2).

7.4 Every write happens on your instruction. A Workspace has one execution mode, set by an admin or owner: read-only (no writes; the write tools are hidden), gated (the default: every write a Wright proposes pauses at a human checkpoint until a User approves it), or autonomous (writes run without stopping, within the rule below). A Wright, a Maintenance Workflow or an automated response can never write outside that mode. The Service does not write to a Connected Org except on an instruction given by one of your Users through the product — and the standing choice of the autonomous mode is such an instruction — and we will not instruct it otherwise. The autonomous mode is sandbox-only, and the Service enforces that on the server: a Salesforce write runs unattended only when the org is positively known to be a sandbox, scratch or Developer Edition org — from Salesforce's own address for the org, or from what the org itself reported about its type when it was connected — and never from a label a person typed; an org whose type is unknown is treated as production, and a production label a person set wins even over a sandbox address. In a production org, or any org not confirmed as a sandbox, every write still pauses for a person whatever the mode. Dynamics 365 and HubSpot writes always pause for a person in every mode but read-only; the Service has no sandbox concept and no undo for either. The sandbox rule is about CRM orgs. In the autonomous mode a Wright's writes to the other Connected Services you have connected — Jira, Confluence, GitHub, Google Docs and Profusia — and image generation run without stopping, whatever org is connected; in the gated mode they pause for a person like every other write. Bulk data updates, their undo and email campaigns pause for a person even in the autonomous mode; a metadata deploy or a data-snapshot restore that a Wright proposes is an ordinary write, which runs unattended only where the autonomous mode applies. Outside a Build, every act that touches a Connected Org — a metadata deploy or its restore, a bulk update, seeding or removing test data, a release — needs the admin or owner role and an explicit instruction, and the riskier ones a typed confirmation. The Service shows deterministic pre-flight advisories before risky writes; in the autonomous mode they are logged rather than blocking. As of the effective date the approval card for a proposed write does not name the target org, reads no environment tag and does not show the exact change that will be made, so check the active connection before you approve, and know that switching the active connection while a Build is waiting retargets its next write.

7.5 Sandbox first, and which orgs you may connect. Exercise every new workflow, deploy, bulk operation and seeding run in a non-production org — a sandbox, scratch, Developer Edition or UAT org (for a Salesforce org, one of a kind your org policy admits) — before a production org. Which Salesforce orgs a Customer Account may connect at all is an org policy we set for it: by default Developer Edition and scratch orgs only — not a sandbox, and not production; a pilot under a signed Order may add sandboxes; and production is added only by agreement with you. The Service is designed to refuse an org the policy does not admit: when a Salesforce org is connected, it reads the org's kind from the org's own record and address — never from a label a person typed, and the more restricted reading wins where the two disagree — before any credential is stored; when a saved connection is switched back on, it reads the kind from that connection's stored address, and a production tag on the connection is honored as production. Dynamics 365 and HubSpot connections are not checked against it. Saved connections carry an environment tag (sandbox, UAT or production). Here is exactly what reads it. A release's target is resolved from the tag rather than guessed: the deploy sheet refuses a release whose tagged target it cannot find and warns when the target is tagged production — that warning is advisory and does not stop you — and a release aimed at a production-tagged connection requires you to type a confirmation, as does arming a scheduled release, which is an unattended production deploy at the time you set (a slot missed by more than 30 minutes is disarmed, never fired late). UI verification reads the tag rather than the org — a connection not tagged sandbox or UAT, an untagged one included, is production to it, and it refuses that unless a Workspace admin has opted the Workspace into production (Section 7.9). Nothing else reads the tag to stop a write: a metadata deploy or a bulk update that a Wright proposes inside a Build pauses at a gate whose approval card does not name the target org (Section 7.4), so the person who approves it is the only stop, and a bulk update started outside a Build reads no tag either. The autonomous mode refuses a production org outright and test-data seeding refuses one unless you type the org's name (Section 7.8), each classifying the org from its own data — a production tag you set is honored by the autonomous mode as a further stop, but a sandbox tag never opens it (Section 7.4). The org policy and these checks are aids: whether or not one of them stops a write, the sandbox-first rule is your obligation everywhere, not a lock in the product.

7.6 Undo is real, and it is not a guarantee. Before every metadata deploy to a Salesforce org the Service retrieves the affected metadata as it stood and keeps it as an undo point; before every bulk data update it captures the exact rows and fields it is about to overwrite, and cannot start writing until it has. Those are real protections, and these are their limits, stated once here. A metadata undo point restores components the deploy changed by re-deploying the earlier package, through the same validate-then-deploy path as a forward deploy; it needs an admin and the same execution mode, and it is applied only to the org it was captured in — an undo point that does not record its org is refused rather than guessed. It does not remove components the deploy added, and it does not re-create a component the deploy itself removed: an undo point holds the state of what the deploy changed, and a component the deploy deleted is not brought back by re-deploying it. Undoing an addition is a separate act, a type-to-confirm delete of pure additions, which the Service runs only after retrieving and storing the current definitions; a deleted field goes to the org's own recycle bin for the period Salesforce keeps it, and any data in it is Salesforce's to keep or drop. Record data is never covered by a metadata undo point. A bulk update's undo restores the captured values record by record; records the update deleted are not covered (the tool does not delete), fields the org makes read-only cannot be restored, and a partial success is possible in both directions. The Service keeps the newest 50 metadata undo points and the newest 200 bulk-update jobs per Workspace; beyond that the undo is gone, and the product says so. As of the effective date a deploy that fails only because the connection dropped is marked failed and the product offers no undo for it; write to us and we can look for its undo point. What no undo can do: reverse downstream automation your change set off in the Connected Org (triggers, flows, validation rules, roll-up summaries, assignment rules, integrations, emails sent, webhooks fired); undo changes made by anyone else between the capture and the undo; recover anything your platform's own retention has already aged out; or reach any other system. You remain responsible for your own CRM backups.

7.7 Custody and retention of what we capture. The prior values captured before a bulk update, and the records of a data snapshot (a copy of chosen records that a Wright or an admin takes from a Connected Org before a risky data change, which can later be restored), are held either in our database (the default) or as a compressed file in your own Salesforce org, with only a receipt — counts, size and a digest — kept by us; a Workspace chooses. The digest lets us detect that such a file was changed; it cannot prevent it, because the file is yours. Captured values are kept for 30 days by default, configurable per Workspace from never expiring to ten years; the receipt is kept after the payload is destroyed, as the record that a backup existed and when it was removed. A capture that cannot be stored under the custody you chose fails the job rather than running without a backup. A Workspace can also keep the bodies of its Deliverables as files in its own Salesforce org (Section 5.6). Two things have clocks of their own: Deliverable text, which can quote record values a Wright queried, is kept until you delete it; and UI-verification evidence follows Section 7.9. Keeping a file in your org has been tested against simulated orgs only (Section 3.3).

7.8 Test data. The seeding tool fills an org with generated records whose email addresses and phone numbers cannot reach a real person, keeps an exact ledger of every record it inserted, and can later remove them. It classifies the org from the org's own answer: a sandbox or Developer Edition opens; a production org, or one it cannot classify, refuses unless the caller types the org's name. Creating and removing each require a typed confirmation, the read-only mode blocks both, and the ceilings are shown in the product. Removal is an ordinary delete to the org's recycle bin. Automations in your org fire on seeded records exactly as on real ones; records your org created in response are found by a sweep and are never deleted unless a person ticks them; a seeded record somebody hand-edited is still removed; and the optional watermark field outlives the records.

7.9 UI verification and training captures. Where you switch it on, the Service drives a browser on Google Cloud (in the United States) through your org's screens to verify a change or capture screenshots for a training guide. The runner signs in with the integration user's current session token, which is handed to it for that walk and never stored in plans, results or logs; the steps are read-only (navigate, read, assert, screenshot). It refuses an org unless its connection is tagged sandbox or UAT, or the Workspace has opted into production; an untagged connection counts as production. The evidence — a video and screenshots of your real org's screens, which may show real records — is kept for 30 days and up to a size limit per Workspace, on our application server, outside our database; training-guide screenshots become Deliverables and follow their rules. The design rule for such captures is to walk only the screens the plan names and to seed fictional records rather than photograph real ones; checking that the screens you verify hold nothing you would not want captured is yours.

7.10 Your CRM vendor relationship is yours. Salesforce, Microsoft and HubSpot are your vendors. Their terms, limits and API governor rules apply to you, the Service consumes your API allowances when it reads or writes, and a charge they levy on your account, a limit they impose, a change they make to their platform, or an outage on their side is between you and them. We are not responsible for a Connected Org's availability, behavior or data, and Section 3.3 names the connectors that have not yet been exercised against a live account.

7.11 Publishing to Profusia. If you connect it, the Service publishes into a Profusia AI workspace — another product of Evadaroo & Company, LLC, operated separately under its own Terms (profusia.ai/legal/terms), Privacy Policy and DPA — using a Profusia access key you supply, which we store encrypted and never return. Each Build becomes a collection there, named for the request and carrying the request text as its description; each Deliverable becomes a document, a rework a new version of it; generated images are hosted there; and Wrights get tools to search and read that workspace and one tool that publishes a document to it, which runs under your execution mode like every other write (Section 7.4). Nothing is published there unless you connect it — and when you connect it through the product, the option to publish every completed Build's Deliverables automatically is pre-selected; untick it if you want to push by hand. A manual push also mints an outward share link, which is a bearer credential (Section 2.3). A failure to publish never fails a Build. Deleting a Deliverable here does not delete it in Profusia; manage it there. Profusia is not a separate company: it is another service of Evadaroo & Company, LLC, the same legal person as AssemblyWright, run on separate systems. Your Profusia workspace is a Connected Service of your own (DPA, Sections 2.4 and 5.5): what we publish there is held under the Profusia Terms, Privacy Policy and DPA you accepted for that workspace, and nothing of yours moves between the two products except what you publish, the key you gave us and the links to what was published.

7.12 Social accounts, through the Content Desk. Where the Content Desk is offered to your Workspace (Section 3.3) and you switch it on and connect a social account (LinkedIn, Bluesky, Mastodon, Threads, Dev.to or X), the account is yours, the posting token or password is stored encrypted and never returned, and nothing is posted until a User approves the item; there is no path from an unapproved item to a network. You are the publisher of every post. Some networks' tokens expire and must be reconnected; one network bills you per post under your own terms with it, and connecting it requires you to acknowledge that in the product; a network you have not connected is offered as a hand-off that opens its own composer, pre-filled, and records the post only when you mark it posted. Once posted, an item cannot be deleted from the Desk and we cannot recall it from the network; remove it there. The Desk's own spend and volume caps are shown in the product.

7.13 Your own Paddle account (Paddle signals). Where a Workspace connects its own Paddle account — separate from our billing, with a key of its own that the connector refuses if it is ours — Paddle posts that account's events to a signed address of the Service. The Service keeps one record per event, including the buyer's name and email address and a few purchase facts but never the raw message, for 180 days, and can answer an event with a response you create: a service email to your customer, or a Build. A response is created off; a named User switches it on; an email response can be switched on only by a person who operates the Service, because the email goes out from our domain; every email is approved one by one before it is sent, waits at most 48 hours for that approval, goes once per customer, carries an unsubscribe link, and is delivered through our email provider. A Build started this way runs under your execution mode and asks first even in the autonomous mode. For the people whose data those events carry, you are the controller and we are your processor (DPA): a lawful basis for emailing your own customers, the content of the email and the truth of what it says are yours. Caps per response, per Workspace and for the whole Service are shown in the product, and no real Paddle account has yet been connected (Section 3.3).

7.14 Other destinations you connect. Where you connect Google Docs, Jira, Confluence or GitHub, the Service pushes Deliverables into them with the token you supplied, stored encrypted and never returned, and what arrives there is governed by your agreement with that provider. In the autonomous mode a Wright can push a Deliverable there without a person seeing it first (Section 7.4). Where a User connects Salesforce's hosted MCP servers, the Service holds the tokens that User's own sign-in produced, encrypted, as the Workspace's one live MCP connection: every Wright in the Workspace then reads and writes through them under that User's Salesforce identity and permissions, until they are disconnected or another User connects. "Draft in Claude" opens a Content Desk prompt in your own Claude app or account and takes back what you paste; no Claude credential is held and no model is called by us, and what you send there is between you and Anthropic. Exporting a Deliverable to Word, or to Google Docs with a token you supplied, fetches any linked images from where they are hosted.

7.15 Third-party services generally. Your CRM vendors, the model providers, Paddle, Clerk, Google Cloud, Apple, the social networks and every Connected Service are outside our control. We are not responsible for their availability, terms, acts or omissions, or for content they return, and nothing in these Terms makes us a party to your relationship with them.

8. Acceptable use

In short: follow the AUP; you are the publisher of what you deploy, post and send, and we may act on what breaks the AUP or the law.

Your use of the Service, and your Users' use, is subject to the Acceptable Use Policy, which is part of the Agreement. Where something violates it, we may take the steps AUP Section 8 describes — for example switching off a specific feature for your Customer Account, asking the Workspace owner to disconnect a Connected Org, remove a User or delete content, or suspending the Customer Account, which closes every Workspace in it — and we will usually take the narrowest step that deals with the problem. We have no control in our console that disconnects one of your Connected Orgs; that is done from inside your Workspace, by you. Before suspending a paid Customer Account for a violation, we will give the notice and cure period in AUP Section 8.3, except where AUP Section 8.4 allows us to act first. Switching off a single feature is not a suspension and does not wait for that period (AUP Section 8.2).

You are the publisher of what you deploy to a Connected Org, post to a network, send to a customer and share through Profusia. We do not review Customer Content before a Build runs or a Deliverable is used, and we have no duty to monitor it; we act on reports and on what we otherwise learn. We may remove, disable or refuse content we reasonably believe breaks the AUP or the law, whether or not it is lawful elsewhere.

8A. Copyright

In short: send copyright notices to legal@assemblywright.ai; repeat infringers lose access.

If you believe that material held or served through the Service infringes your copyright, write to us at legal@assemblywright.ai, or to Evadaroo & Company, LLC, 502 W 7th St, Ste 100, Erie, PA 16502, USA. Your notice must contain the information 17 U.S.C. §512(c)(3) requires, which AUP Section 9A lists. When we receive a notice that substantially complies, we remove or disable access to the material and tell the Workspace owner. A User whose material was removed may send a counter-notice under 17 U.S.C. §512(g), as AUP Section 9A describes, and we then restore the material as that Section provides. We keep a record of valid notices, and in appropriate circumstances we terminate the Users and Workspaces of repeat infringers. Other abuse and takedown reports also go to legal@assemblywright.ai.

9. Privacy, security and data protection

In short: how we protect your content, what we do not claim, what not to put in, and how we tell you about an incident.

9.1 Privacy and the DPA. The Privacy Policy (assemblywright.ai/legal/privacy/) describes what we store, the providers that hold it, how long it is kept, and who processes it, and the privacy notice at assemblywright.ai/privacy/ summarizes it. We do not offer a choice of region: the Service runs on one Google Cloud machine in the United States (us-central1), which hosts the application and its database, with the browser runner on Google Cloud in the United States. Model inference happens wherever the provider that answers a request processes it (Section 6.4; Privacy Policy, Sections 3 and 5.3): in the United States for a request Anthropic's API answers, which is held to US-only processing, and for a request Gemini 3.8 Flash or 3.5 Flash-Lite answers on Google Vertex AI, in Google's United States multi-region; a picture prompt to Google's image model, or a request to any other Vertex model, is processed in the Google Cloud region the Service's deployment is configured for; and a request routed to Cloudflare Workers AI or OpenAI is processed where that provider processes it, which can be outside the United States, because nothing in the Service holds such a request to a region. Accounts sit with Clerk and billing records with Paddle under their own terms. Where we process personal data on your behalf (Customer Personal Data, as the DPA defines it), the DPA applies and is part of the Agreement.

9.2 How we protect Customer Content. We maintain administrative, technical and physical safeguards designed to protect Customer Content; Annex II of the DPA and assemblywright.ai/trust/ describe them in more detail. The safeguards include these: Workspace isolation is applied once, at the data layer, to every read and write the application makes — a read outside the Workspace's scope returns nothing and a write outside it is refused — and a verification script has confirmed it against the running code (last run September 2026); credential-shaped settings and whole connection snapshots are encrypted at rest under a key kept outside the database; every hostname is served over TLS, every one that serves pages with HSTS (the two www hostnames only redirect to the site), and the app refuses to be framed; privileged actions — settings changes, connecting and disconnecting, vault operations, restores, permanent deletes — are written to an audit trail recording who, from where, what (with the ids, names and counts the act concerns) and the names of the fields a change touched — never a credential's value, though the new value of some non-secret settings, such as a retention period or a custody mode, is recorded — whose newest entries a Workspace admin can read in the product once role enforcement is on (Section 11.5(d)); requests are rate-limited. Our practices also include these, which describe how we work and do not add to the warranty in Section 12.1: every change to the Service is deployed only after an automated gate has run its full test suite on that exact change, with a smoke test and automatic rollback on failure; dependencies are pinned and checked against the public advisory database on every change; and an external service has monitored the Service's public health since 2026-10-05. We may change these measures, but not in a way that materially reduces the overall protection of Customer Content. No security measure is perfect, and we do not promise that Customer Content will never be accessed, lost or disclosed without authorization. In particular: isolation is logical, not physical, and a small number of boot-time and administrative queries run outside it; the audit trail keeps the newest 2,000 records per Workspace and is not shipped off the server; the encryption key lives on the server and has no managed key service or rotation procedure; multi-factor sign-in is not switched on for the production sign-in and is not enforced as of the effective date; and off-server backups of our database are being set up; until we have confirmed that they run and that a restore from them works on our production machine, we do not claim them, and you should treat our database as not backed up off the server — a written recovery runbook exists, and a restore has been rehearsed on a separate machine, not yet on the production one (Section 14.1).

9.3 What we do not claim, and data you must not put in. We hold no SOC 2 report, no ISO 27001 certificate, no HIPAA attestation, and no third-party penetration test, and none are in progress. Isolation is logical, not physical. We have no dedicated security officer (Section 10.4 says who operates the Service). We say so plainly here and at assemblywright.ai/trust/ rather than implying otherwise. You will not put into the Service, or let a Wright read from a Connected Org into it, the data described in Section 3 of the Acceptable Use Policy — protected health information, payment card data, government-issued identifiers at scale, and the rest of that list — or any data whose handling requires a certification we do not hold. Where a Connected Org holds such data, scope the Service's credentials away from it (Section 7.2).

9.4 Security incidents. If we confirm a breach of our security that leads to the accidental or unlawful destruction, loss, alteration or unauthorized disclosure of, or access to, Customer Content (a "Security Incident"), we will notify the Workspace owner without undue delay after confirming it, with what we know at the time and updates as we learn more. Where the DPA applies, its Section 3.7 governs instead, including notice where feasible within 72 hours. A Security Incident does not include unsuccessful attempts or activities that do not compromise the security of Customer Content (such as pings, port scans, blocked sign-ins or denial-of-service attacks); access through a credential, link or account that you or your Users handed out or failed to protect; anything done in a Connected Org through credentials you supplied, on an instruction given under Section 7.4; or a breach of a Connected Org, Connected Service or CRM vendor that is not a breach of our systems. Notifying you is not an admission of fault.

10. Confidentiality

In short: each side keeps the other's non-public information confidential; we open your content only for support you ask for, to investigate a security incident or abuse, to keep the Service running or restore it, or where the law or a legal claim requires it.

10.1 What each party does. Each party may receive the other's non-public information ("Confidential Information"). The receiving party will use it only to perform its obligations and exercise its rights under the Agreement, will protect it with at least reasonable care, and will disclose it only (a) to its and its affiliates' personnel, contractors, professional advisers and service providers (including those listed in the Privacy Policy and the DPA) who need it for the Agreement and are bound by confidentiality obligations or professional duties at least as protective as this Section, or by the service provider's own published terms where the DPA permits; and (b) other than Customer Content, to a prospective acquirer, investor or lender under a written confidentiality agreement.

10.2 What it does not cover. This Section does not cover information that is or becomes public through no fault of the receiving party, that the receiving party already had or developed independently, or that it lawfully received from a third party without a duty of confidence.

10.3 Compelled disclosure. A party compelled by law to disclose Confidential Information may do so, after giving the other party notice where the law allows, and only to the extent required. Section 16.13 says how we handle legal process for Customer Content.

10.4 Customer Content, and our own access to it. Customer Content — including your org's schema, configuration and the records a Wright read — is your Confidential Information. AssemblyWright is operated by one person, who holds administrative access to the production machine, its database and its storage and so can technically read Customer Content; it is not encrypted from us. We access Customer Content ourselves only (a) at your 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; (d) to keep the Service running or restore it from a backup, where that cannot be done without it; or (e) as Section 16.13 allows. There is no consented support-access mode: support means asking you, and the Service has no mode that lets us open your Workspace as its members see it (the "View as customer" switch in our own account only hides our operator controls from ourselves). We never show Customer Content to an investor, a lender or a prospective acquirer, and a successor under Section 16.4 receives it only to keep providing the Service under these Terms. Our operator console shows us names, counts, dates, status and usage — the Customer Account and its Workspaces, each Workspace's members with their sign-in identity and role, the package, trials and grants, usage by feature, model spend, and the requests sent through our website — and no Deliverable, Knowledge Base entry, CRM record, credential or Build request; the operator acts we can take are assigning or changing a package, a trial, a grant or a switch-off (with a reason), setting a price we agreed with you, setting, changing or removing a Customer Account's AI allowance (Section 4.4), setting which Salesforce orgs a Customer Account may connect (Section 7.5), suspending or reinstating a Customer Account (which closes or reopens every Workspace in it), deleting a Customer Account that holds no Workspace, adding models and prices, keeping private notes about a Customer Account, and adding a member to or removing one from a Workspace (for example to restore control to an owner whose identity we have verified (Section 16.18), or to remove a User as Section 11.4 or the AUP provides). It has no control that disconnects one of your Connected Orgs (Section 8). Each of these acts is written to our own administrative audit trail — the same kind of trail every Workspace has (Section 9.2), holding the newest 2,000 entries — naming the person who did it and, for an act made through Evadaroo HQ, that it came through that console. That record is ours: an operator act is written to the trail of our own Workspace, not yours, unless we are acting inside your Workspace as one of its members at your request — then it is written to your Workspace's trail like any member's change, naming us. Your Workspace's trail otherwise records only what your Users and the Service do inside it. Reading or changing the database or the machine directly, with our host's own tools, is not recorded by the product. Our internal operations console (Evadaroo HQ, a system of ours) can take the same acts, within the same wall, through a short-lived token that names the person acting, and keeps its own log of each act it makes; such an act is recorded here as that person's, marked as made through that console. The AI coding tools we build the Service with see its source code and documentation, are given no credential for the production machine, its database or its storage, and are not used to read Customer Content; what they write reaches production only through the automated gate described in Section 9.2. The Privacy Policy (Section 4.2) describes who at AssemblyWright can see what.

10.5 How long, and feedback. These obligations last while the Agreement is in force and for three years after it ends; for Customer Content, for as long as we hold it; and for trade secrets, for as long as they remain trade secrets. Feedback (Section 16.16) is not your Confidential Information.

10.6 Security and the limits. Our obligations for the security of Customer Content are those in Section 9 and the DPA, and the limits in Section 14 apply to them.

11. Term, suspension and termination

In short: cancelling a package does not end your Workspace; closing a Workspace ends access at once, and an owner can reopen it for 30 days; if the Agreement is terminated, an owner can still ask for an export for 30 days; export before you close.

11.1 Term. These Terms apply from when you accept them until they end under this Section.

11.2 Ending for convenience. Cancelling a subscription does not end these Terms: the package runs to the end of the paid term and Section 4.11 then applies. You may end these Terms for a Workspace at any time by closing it (Section 11.5(b)) after cancelling any subscription that covers only that Workspace; they end for that Workspace when it is erased, and reopening it within the 30 days continues them. If your Customer Account holds other Workspaces, these Terms continue for them. If you cannot close a Workspace yourself, write to legal@assemblywright.ai from an owner's address and we will help. We may end the Service for our convenience on 30 days' notice, and will then refund the fees prepaid for the unused term (Refund Policy, Section 5). Otherwise a term ended early is not refunded, except as the Refund Policy provides.

11.3 Termination for breach. Either party may terminate these Terms on written notice if the other materially breaches them and fails to cure the breach within 15 days of notice, or, for a breach of the AUP, as AUP Section 8 provides. If you end the Agreement because we materially breached it and did not cure, we refund the fees prepaid for the unused term (Refund Policy, Section 5).

11.4 Suspension. We may suspend the Service for a Customer Account or a Workspace, or restrict part of it — for example by switching off a feature, removing a User, or asking the owner to disconnect a Connected Org — if we reasonably believe that: (a) it is needed to prevent or stop a security threat, an attack, or harm to the Service, to other customers, to a Connected Org's users or to the public; (b) you or your Users are violating the AUP, subject to AUP Section 8; (c) it is required by law, a court order, or a lawful request from a government authority; (d) an amount remains unpaid after the notice in Section 4.8, or a payment is reversed, disputed or appears fraudulent; or (e) a Workspace opened through self-serve sign-up is being used to evade a limit or an earlier suspension. Switching off a single feature under AUP Section 8.2 is not a suspension under this Section; AUP Section 8 governs it. We will tell the Workspace owner why by email: for a violation of the AUP, as AUP Section 8 describes, including before suspending where AUP Section 8.3 requires it; for any other reason, before suspending where that is practical, and otherwise as soon as we can. In either case we need not do so where the law forbids it, or where telling you would put a person at risk, compromise an investigation or defeat the purpose of the suspension. We will limit a suspension to what is reasonably needed and lift it once the cause is resolved. Suspension deletes nothing: a suspended Workspace is closed to its members and its Builds do not run, and it is held rather than erased (Section 16.13), except one being erased after these Terms were terminated and the export window in Section 11.5(c) has passed. Suspension does not by itself stop billing; if we suspend for a reason that is not your breach, the Refund Policy (Section 6) applies. While a Workspace is suspended, an owner may ask for an export of its content, and we will provide one unless that would be unlawful or would defeat the purpose of the suspension.

11.5 What happens to your content.

(a) Cancelling a subscription does not end your Workspace. At the end of the paid term Section 4.11 applies, and your content stays.

(b) If an owner closes a Workspace (an owner's act, confirmed by typing the Workspace's name in the product, or asked for by writing to legal@assemblywright.ai from an owner's address where the product does not offer it), it closes at once: every stored credential for every Connected Org and Connected Service is erased immediately, and nobody — owner included — can open the Workspace. An owner can reopen it for 30 days, which puts everything but the erased credentials back. Export before you close: the product offers the export first, and during the 30 days the Workspace cannot be opened to take one, so reopen it first if you need to. After the 30 days we erase the Workspace's rows and files; that erasure is run by a person, so it may happen some days after the window closes, and we do not promise a date, but we do not reopen a Workspace once the window has passed. You may ask for earlier erasure at legal@assemblywright.ai from an owner's address; we will do it where reasonably practicable and confirm it in writing. Cancel any subscription that covers only that Workspace before closing it; if one is still running when the Workspace is erased, it runs to the end of its term without a refund. Closing a Workspace removes nothing from a Connected Org — changes deployed there are in your system and are yours to keep or reverse — and removes nothing already published to Profusia or posted to a network.

(c) If either party terminates these Terms, the Workspace is closed as in paragraph (b), and your credentials are erased in the same way. For 30 days after termination, a Workspace owner may ask us for an export at legal@assemblywright.ai. We will either reopen the Workspace long enough for an owner to use the product's own export (after disabling anything that was the reason for the termination) or provide the export ourselves by a secure method we choose, unless doing so would be unlawful or would create a security risk. We will not provide material that is unlawful to hold or return, material taken down on a valid legal notice, or anything an authority directs us to withhold. After that window we erase the Workspace as paragraph (b) describes.

(d) What the export contains. The product's own export is one archive holding the current version of every Deliverable you can see, as Markdown; the Knowledge Base; a list of Builds with the first 2,000 characters of each request; and the names of the Workspace's workflows, Wrights and connections. It does not include credentials, items in the trash, earlier versions, Build timelines, chat, evidence files, or the rest of the Workspace's configuration (workflow stages, Wright skills and prompts, document types and settings). Each Deliverable can also be exported on its own as a Word file, and once role enforcement is on a Workspace admin can read the newest entries of the audit trail in the product. We provide the audit trail as kept within 30 days, and earlier versions, Build timelines, chat and the rest of the Workspace's configuration within a reasonable time, on a Workspace owner's or admin's written request, in a form we choose, not more than once a quarter for each Workspace (and once after termination), unless the law requires more; for personal data, Section 6 of the DPA applies, and it holds the audit trail to the same 30 days and the same once a quarter.

(e) What stays after erasure. Copies may remain in our database backups until they age out, once our off-server backups run, for the period the Privacy Policy then states; a copy we take by hand, for a restore or a test, is deleted within 30 days of being taken; one kept under Section 16.13 is kept only as long as that purpose requires. We keep a minimal record after erasure, as the Privacy Policy describes: billing records and events, the package, trials, grants and prices the Customer Account held, our own administrative audit trail and the notes we kept about the Customer Account (which may describe the matter they concern), the ledger of identities that reached our operator console, the record that a person was removed from a Workspace (which we remove on request once the Workspace is erased), our email provider's own account-level list of addresses that bounced or complained, the requests sent through our website on their own clock, and our request logs until the log files are cleared. Clerk keeps the account itself until its holder deletes it there, and Paddle keeps its own billing records.

(f) You are responsible for exporting anything you want to keep before these windows close. After erasure we cannot recover it.

11.6 Survival. Sections 1, 2.3, 2.4, 4 (for fees accrued before termination), 5, 6.2, 6.2A, 6.7, 7.3, 7.6, 7.10, 7.15, 9.3, 10, 11.5, 12, 13, 14, 15 and 16, and any other provision that by its nature should survive, survive termination. The DPA continues for as long as its Section 12.1 provides.

12. Warranties and disclaimer

In short: on paid packages we promise reasonable skill and care and the safeguards in Section 9.2; otherwise the Service is provided as is, and no deploy, undo or Deliverable is warranted.

12.1 Our limited warranty. For paid packages, we warrant that during your paid term we will provide the Service with reasonable skill and care and will maintain the safeguards Section 9.2 names as safeguards (not the practices it describes after them) in all material respects. If we breach this warranty and you tell us within 30 days of discovering the breach, we will use reasonable efforts to correct it. If we cannot correct it within 30 days of your notice, you may end the affected subscription and receive a refund of the fees prepaid for the unused part of the term. This is your sole and exclusive remedy for breach of this warranty. A free tier, a trial and any feature Section 3.3 names are provided with no warranty.

12.2 Otherwise, the Service is provided "AS IS" and "AS AVAILABLE". To the maximum extent permitted by law, we disclaim all other warranties, express or implied, including merchantability, fitness for a particular purpose, title, non-infringement, and any warranty arising from course of dealing or usage of trade. We do not warrant that the Service will be uninterrupted or error-free, that it will meet your requirements, that any Deliverable or other AI output will be accurate, complete or suitable for your purpose, that a deployment or other change to a Connected Org will succeed or behave as intended, that a review gate will catch an error, or that an undo will restore any state or downstream effect beyond what Section 7.6 describes.

12.3 Dissatisfaction. Your remedy for dissatisfaction within 30 days of your first payment is the refund in Section 4.6.

13. Intellectual-property claims and indemnification

In short: if the Service is said to infringe, we fix it or refund; you cover claims that come from your content, your Users, your connected orgs, what you deploy, post or send, or your breach.

13.1 If the Service is claimed to infringe. If a third party claims that the Service, as we provide it, infringes their intellectual property rights, or we reasonably believe such a claim is likely, we may, at our option and expense: (a) obtain the right for you to keep using the Service; (b) modify or replace the affected part so that it no longer infringes, without materially reducing what it does; or (c) end the affected part of the Service and refund the fees prepaid for the unused part of the term (Refund Policy, Section 5). This Section states our entire obligation, and your exclusive remedy, for any claim that the Service infringes a third party's rights. It does not apply to a claim arising from Customer Content, from the content of a Deliverable, from a Connected Org or Connected Service, from your combination of the Service with anything we did not supply, or from use in breach of the Agreement. We do not defend or indemnify you against such claims unless a signed Order says we will, and then only up to the amount that Order states, which will be no more than the fees paid in the 12 months before the claim.

13.2 By you. You will defend us, our affiliates, and our and their members, managers, officers and contractors against any claim, demand, investigation or proceeding by a third party (including one of your Users, your clients, your employer, your CRM vendor, a user of a Connected Org, a recipient of an email or post you sent through the Service, or a government authority) arising out of or relating to: (a) Customer Content, including data read from a Connected Org and a Deliverable or its use; (b) your or your Users' use of the Service in breach of the Agreement or applicable law, including putting into the Service, or letting a Wright read into it, data that AUP Section 3 excludes; (c) any change made to a Connected Org on your instruction, including under the autonomous mode you chose and anything a User approved or deployed, and anything that change set off there; (d) your connection of an org or service you were not authorized to connect or to change, or in breach of your agreement with its vendor or your obligations to a client; (e) any email, post or publication made to your customers, your networks or anyone else through the Service, including its lawful basis and its content; (f) anything a Wright, Maintenance Workflow or automated response did with the access and settings you gave it; or (g) a dispute between you and your Users, clients or vendors. You will pay the damages, fines, penalties, settlement amounts and reasonable legal fees and costs that result, except to the extent the claim results from our breach of these Terms.

13.3 Procedure. The party seeking a defense must tell the other promptly of the claim (a delay relieves the other party only to the extent it is prejudiced by it), let the defending party control the defense and settlement, and cooperate reasonably at the defending party's expense. The protected party may take part with its own counsel at its own cost. No settlement that admits fault on the protected party's part, or imposes an obligation on it other than a payment the defending party makes, may be made without its written consent, which will not be unreasonably withheld.

14. Limitation of liability

In short: neither side pays the other's indirect losses — including what follows from a change to your CRM org — and, apart from the exceptions in Section 14.3, each side's total liability for everything is capped at the fees paid in the last 12 months or US $100, whichever is more.

14.1 Excluded damages. To the extent the law allows, neither party is liable to the other for indirect, incidental, special, consequential, exemplary or punitive damages, or for lost profits, revenue, business or goodwill, however caused and on any theory of liability, even if it was advised of the possibility and even if a limited remedy fails of its essential purpose. This expressly includes loss arising from a change deployed to a Connected Org, from downstream automation that change set off, from a change made by someone else between a capture and an undo, from a Deliverable relied on or handed to a client, and from an email or post sent through the Service.

Loss or corruption of Customer Content. If Customer Content is lost or corrupted because we breached the Agreement, we will use reasonable efforts to restore it from the most recent backup we hold that contains it. Your reasonable, direct cost of recreating or re-entering what could not be restored is not excluded by this Section and is subject to the cap in Section 14.2; any other loss that follows from it, such as lost profits, revenue, business or goodwill, stays excluded. Our database backups are as Section 9.2 describes; until off-server copies are confirmed, Customer Content lost on our server may be unrecoverable, and nothing in your own Connected Org is backed up by us at any time. Keep your own copies of anything you cannot afford to lose: the export (Section 11.5(d)), the Word export of each Deliverable, and the custody options that keep Deliverable text and captured values in your own org (Section 7.7) help you do that.

14.2 One cap. To the extent the law allows, each party's total aggregate liability arising out of or relating to the Agreement — these Terms, the DPA (including, as far as they allow, the Standard Contractual Clauses and UK Addendum it incorporates) and any Order, taken together — is limited to the greater of (a) the fees you paid or owe for the Service in the 12 months before the event giving rise to the claim, or (b) US $100. The DPA creates no separate or additional cap; claims under it count toward this one (DPA, Section 11). A higher cap applies only where a signed Order says so.

14.3 Exceptions. Sections 14.1 and 14.2 do not limit: (a) your obligations under Section 13.2; (b) your obligation to pay fees; (c) your liability for breaching Section 7.3, Section 8 or the AUP (other than a breach only of AUP Section 4.2, on accounts, trials, packages and Workspaces, or of AUP Section 5.3, on model providers' own policies, which Sections 14.1 and 14.2 do limit), or for infringing or misappropriating our intellectual property; (d) either party's liability for its own fraud or willful misconduct; or (e) any liability that the law does not allow to be limited or excluded. A breach of Section 9, of Section 10 as it relates to Customer Content, or of the DPA — including any Security Incident or Personal Data Breach (as the DPA defines it) — is subject to Sections 14.1 and 14.2 and is not an exception to them (DPA, Section 11). In this Section and in the DPA, "willful misconduct" means a deliberate act or omission done with the intent to cause the harm in question, or with knowledge that the harm was substantially certain to follow. It does not include negligence of any degree, a mistake, or a decision about how to design, secure or run the Service, including any limitation these Terms or the Documentation disclose (such as the state of our backups, or that multi-factor sign-in is not switched on).

14.4 Basis of the bargain. These allocations are an essential basis of the Agreement and of our prices, and they apply even if a limited remedy fails of its essential purpose. They reflect what the Service does: it writes to systems of record at your instruction, and the fees do not price the risk of what those systems hold.

14.5 Leaving after a breach of personal data. If a Personal Data Breach caused by our breach of the DPA affects your Workspace, you may terminate the Agreement by written notice within 60 days of our notice of it, and receive a pro-rata refund of the fees prepaid for the unused term (DPA, Section 11.4).

14.6 Our people, and yours. To the extent the law allows, neither party's members, managers, officers, employees or contractors are personally liable to the other party, or to its Users, under or in connection with the Agreement or the Service; a claim may be brought only against the party itself. Those persons may rely on Sections 14 and 15 as if they were parties.

15. Disputes, governing law and venue

In short: talk to us first; then binding individual arbitration, not a class action or a jury; small-claims court stays open; you may opt out of arbitration within 30 days; claims must be brought within a year.

PLEASE READ THIS SECTION CAREFULLY. IT REQUIRES MOST DISPUTES TO BE RESOLVED BY BINDING INDIVIDUAL ARBITRATION, AND IT WAIVES THE RIGHT TO A JURY TRIAL AND TO TAKE PART IN A CLASS ACTION. YOU MAY OPT OUT OF ARBITRATION UNDER SECTION 15.5.

15.1 Talk first — 30 days. Before starting an arbitration or a court case, the party with the complaint will send the other a written description of it and of what it wants (to legal@assemblywright.ai for us; to the Workspace owner's email address for you), and both will try in good faith to resolve it. Neither party may start proceedings until 30 days after that notice, except to seek an injunction under Section 15.4(b). This period also extends any applicable time limit by its own length.

15.2 Binding individual arbitration. Except as Section 15.4 provides, any dispute, claim or controversy between you and us — including a claim you bring against any of our members, managers, officers, employees, contractors or affiliates — arising out of or relating to the Agreement or the Service, including its formation, scope or validity (a "Dispute"), will be resolved by final and binding arbitration administered by the American Arbitration Association ("AAA") under its Commercial Arbitration Rules. If you are an individual and the AAA decides that its Consumer Arbitration Rules apply, those rules apply instead. The AAA's Mass Arbitration Supplementary Rules apply where their own terms say they do. The arbitration will be held in English before a single arbitrator, seated in Erie County, Pennsylvania; if the amount claimed is less than US $25,000, the claimant chooses whether it is held by video conference or decided on written submissions, unless the arbitrator decides an in-person hearing is needed. The arbitrator may award any individual relief a court could, applying the governing law, but only to the party seeking it and only as far as that party's individual claim requires. Judgment on the award may be entered in any court with jurisdiction. Fees are allocated under the applicable AAA rules, and, for an individual claim of less than US $10,000 that you bring in good faith, we will pay the AAA filing, administration and arbitrator fees to the extent they exceed what filing the same claim in court would have cost you, unless the arbitrator finds the claim frivolous or brought for an improper purpose (judged by the standards of Federal Rule of Civil Procedure 11(b)), in which case the applicable AAA rules allocate those fees. Where the AAA's Mass Arbitration Supplementary Rules apply, their fee schedule governs the cases they cover. The arbitrator decides questions about the scope and enforceability of this Section 15, except that a court decides any question about Section 15.3 and about whether a Dispute falls within Section 15.4. The Federal Arbitration Act governs this Section 15.

15.3 No class or representative actions. EACH PARTY MAY BRING A DISPUTE ONLY IN ITS INDIVIDUAL CAPACITY, AND NOT AS A PLAINTIFF OR CLASS MEMBER IN ANY CLASS, COLLECTIVE, CONSOLIDATED OR REPRESENTATIVE PROCEEDING. The arbitrator may not consolidate more than one party's claims, except that the AAA may administer related cases together under its Mass Arbitration Supplementary Rules, and may not preside over any class or representative proceeding. If this Section 15.3 is found unenforceable as to a particular claim or request for relief, that claim or request — and only that one — is severed and decided by a court under Section 15.6, after the arbitration of every other claim has finished.

15.4 Exceptions. Either party may (a) bring an individual claim in a small-claims court that has jurisdiction, for as long as it stays there on an individual basis; and (b) seek an injunction or other equitable relief in any court with jurisdiction to stop actual or threatened infringement or misappropriation of intellectual property, a breach of Section 10, or a breach of the AUP.

15.5 Opting out. You may opt out of Section 15.2 by emailing legal@assemblywright.ai from a Workspace owner's address, naming the Workspace and saying that you opt out of arbitration, within 30 days after you first accept these Terms. Opting out does not affect anything else in these Terms: Disputes are then decided in court under Section 15.6, and Section 15.3 applies there to the extent the law allows.

15.6 Courts, and no jury. Any Dispute that is not arbitrated, other than a small-claims action under Section 15.4(a) or a request under Section 15.4(b), will be brought only in the state courts located in Erie County, Pennsylvania, or in the United States District Court for the Western District of Pennsylvania, and each party consents to their personal jurisdiction and venue. TO THE EXTENT THE LAW ALLOWS, EACH PARTY WAIVES ANY RIGHT TO A JURY TRIAL IN ANY SUCH PROCEEDING.

15.7 Time limit. To the extent the law allows, a Dispute must be started within one year after the party bringing it knew, or reasonably should have known, of the facts giving rise to it, or it is permanently barred. The 30-day period in Section 15.1 extends this limit by its own length. The limit applies equally to both parties; it does not apply to a claim for fees, or for a refund or credit, owed under the Agreement, or to a claim the law does not allow to be shortened.

15.8 Changes to this Section. A change we make to this Section 15 after you accepted it does not apply to a Dispute of which either party had given notice before the change took effect. If we make a material change to this Section 15, you may reject it by emailing legal@assemblywright.ai from an owner's address within 30 days after it takes effect; the version you last accepted then continues to apply to you.

15.9 Governing law. These Terms, and any Dispute, are governed by the laws of the Commonwealth of Pennsylvania, without regard to its conflict-of-laws rules, and, as Section 15.2 says, by the Federal Arbitration Act. The UN Convention on Contracts for the International Sale of Goods does not apply. The Standard Contractual Clauses and UK Addendum incorporated by the DPA keep the law and courts they name.

16. General

In short: how the documents fit together, how they change, and the other rules that hold the Agreement together.

16.1 Entire agreement. The Agreement — these Terms, the AUP, the Refund Policy, the DPA where it applies, and any Order (Section 1) — is the entire agreement between us about the Service and replaces any earlier discussions, including anything said in a sales conversation or a pilot proposal that a signed Order does not repeat. The Privacy Policy explains how we handle personal data; it is a notice, not part of the Agreement. The pre-printed terms of a purchase order have no effect.

16.2 Order of precedence. If documents conflict, this order applies: (1) a signed Order, but only for the terms it expressly changes; (2) the DPA, including the Standard Contractual Clauses and UK Addendum it incorporates, on the processing of personal data (within the DPA, those clauses prevail — DPA, Section 7.5); (3) AUP Section 8, on how we enforce the AUP, where it differs from Section 8, 11.3 or 11.4 of these Terms; (4) the Refund Policy, on refunds only; (5) these Terms; (6) the AUP otherwise; and (7) the text of an Order that is not a signed Order, such as what checkout or Admin › Plan & billing shows, to the extent Section 4.1 does not already make it part of your Order. Paddle's Buyer Terms govern the purchase transaction between you and Paddle. Our trust page and security questionnaire, our in-force privacy notice (assemblywright.ai/privacy/) and the rest of the Documentation — other than the pricing page and Plan & billing, to the extent Section 4.1 makes them part of your Order — describe our practice on the date they show; they are not contracts or warranties.

16.3 Changes to these Terms. We may update these Terms. We will post each version with its effective date and keep every earlier version, which we will send on request. For a material change we will email the Workspace owners in your Customer Account at least 30 days before it takes effect, and we will say so in the product. 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. Continuing to use the Service after a change takes effect accepts it. If you reject a material change, you may cancel before it takes effect, and we will refund the fees prepaid for the unused term (Refund Policy, Section 5). Changes to prices and packages follow Section 4.10; each payment is refunded under the Refund Policy in force when it was made; and a change to Section 15 applies only as Section 15 itself provides.

16.4 Assignment. We may assign or transfer these Terms, in whole or in part, without your consent, to an affiliate or to a successor in a merger, acquisition, reorganization, or sale of all or substantially all of the assets or business to which these Terms relate, and we will tell you when we do. You may assign them only with our prior written consent, which we will not unreasonably withhold, except that you may assign them on notice to a successor to all or substantially all of your business if all fees due are paid. Any other attempted assignment is void.

16.5 Notices. Notices to us go to legal@assemblywright.ai, with a copy to Evadaroo & Company, LLC, 502 W 7th St, Ste 100, Erie, PA 16502, USA. Notices to you go to the email address on file for the Workspace owner or owners — the address the Service holds for them or, where it holds only an account id, the address in the owner's sign-in account with Clerk — which you will keep current. An email notice is given when it is sent, unless the sender learns that it was not delivered. Before acting on an emailed instruction to change a package or billing, to cancel, or to close or erase a Workspace, we may ask an owner to confirm it in the product or from the owner's address on file, and we may rely on an instruction that reasonably appears to come from an owner.

16.6 Force majeure. Neither party is liable for a delay or failure to perform caused by events beyond its reasonable control. These include natural disasters, epidemics, war, terrorism, civil unrest, labor disputes and government action; failures or outages of the internet, of utilities, or of third-party services we rely on (including Google Cloud, Clerk, Paddle, our email provider, Apple's push service, the CRM platforms you connect and the AI model providers); and denial-of-service or other cyberattacks that happen despite reasonable safeguards. This does not excuse an obligation to pay fees.

16.7 Export and sanctions. You will not use or export the Service in violation of US export-control or sanctions law, and you represent that you are not located in, organized in or ordinarily resident in an embargoed country or region, and are not on a US restricted-party list. We do not screen users or block access by location; you are responsible for your own compliance and for not giving access to anyone the law forbids.

16.8 US government end users. The Service is "commercial computer software" under FAR 12.212 and DFARS 227.7202; government rights are those in these Terms.

16.9 Publicity. We will not use your name or logo as a customer reference without your prior written consent.

16.10 Independent contractors. No partnership, agency, employment or joint venture is created. There are no third-party beneficiaries, other than the persons Sections 13.2 and 14.6 protect.

16.11 Severability and waiver. If a provision is unenforceable, it is limited to the minimum extent necessary and the rest stands. A failure to enforce is not a waiver.

16.12 Electronic communications. We and Paddle may give you agreements, notices, invoices, receipts and other communications electronically, and they satisfy any legal requirement that they be in writing. Ticking a box or pressing a button to accept these Terms is your electronic signature.

16.13 Legal process, preservation and holds. Apart from what Sections 5.2 and 10.1 allow (our service providers, and the Users, Connected Orgs and Connected Services you choose), we disclose Customer Content to a government authority or other third party only: (a) when we are legally compelled to, including a report the law requires; (b) when we believe in good faith that disclosure without delay is needed to prevent death or serious physical injury to a person, as the law permits; (c) as reasonably needed to establish, exercise or defend our legal rights, including in a Dispute with you; (d) to pass a copyright notice or counter-notice to the other side, as AUP Section 9A describes; or (e) with the Workspace owner's consent — in each case only as much as that purpose needs. Where the law allows, we tell the Workspace owner before we disclose in response to legal process under (a), so you can seek a protective order, and where reasonably practicable we seek to narrow a request that appears overbroad. Where the law requires, or for an investigation, legal process or a legal claim, we may preserve Customer Content and records beyond the normal retention and erasure periods, including after a closure or a deletion request, and may disclose them as (a) to (e) allow, telling the Workspace owner where that is lawful and safe. A Workspace we have suspended, or one we must preserve for an investigation or legal process, is held: we do not run its erasure — not after a closure an owner asked for, before or after the suspension or hold began — until the suspension or hold ends, except a Workspace being erased after these Terms were terminated and the export window in Section 11.5(c) has passed, which only a legal hold delays. When a suspension or hold ends, the 30 days in Section 11.5(b) run again from that day before we erase it. A hold changes nothing else in the Workspace — what its Users delete themselves is still deleted — and we record it in our own administrative audit trail, not in the Workspace's. Records that expire by age under the Privacy Policy go on expiring while a Workspace is held, unless we keep them, or a copy of them, for that purpose. Where the DPA applies, its terms on disclosure apply as well.

16.14 Equitable relief. A breach of Section 7.3, Section 8, Section 10 or the AUP, or an infringement of a party's intellectual property, may cause harm that money cannot adequately remedy. The harmed party may seek an injunction or other equitable relief in addition to any other remedy, without posting a bond where the law allows.

16.15 Interpretation. "Including" means including without limitation. Headings, "The short version" box and the "In short" lines are for convenience only; where one differs from a section, the section governs. These Terms are written in English, and the English version governs any translation.

16.16 Feedback. If you or your Users send us suggestions or other feedback, we may use them freely, without obligation or payment to you. Feedback gives us no right in your Customer Content.

16.17 Our rights, and your right to use the Service. We and our licensors own the Service, its software, its seeded Wrights, skills, workflows, deliverable catalog, templates, prompts and help content, and the AssemblyWright names and marks, and no rights are granted except those these Terms state. Subject to the Agreement, we give you a non-exclusive, non-transferable right, during your subscription or while you use a free tier or trial, to use the Service for your business and to let your Users do so. The restrictions in AUP Section 4 are part of that right. What you make from our Wrights, workflows and templates, and the changes you make to them for your Workspace, are your Customer Content; the Wrights, workflows and templates themselves stay ours.

16.18 Workspace control. We may rely on instructions from a Workspace owner as instructions from you. If there is a dispute about who controls a Workspace or a Customer Account, we may require reasonable proof, hold changes to its ownership, or follow a court order, and we may restore control to an owner whose identity we have verified by the means the Service gives us, including adding or removing a Workspace's members (Section 10.4). Sign-in itself, including password reset, is handled by our identity provider, Clerk; multi-factor sign-in is not switched on as of the effective date (Section 9.2). We may refuse a Workspace name, or require it to change, if it infringes someone's rights or misleads.

16.19 If we stop offering the Service. If we decide to stop offering the Service, we will give at least 30 days' notice where we reasonably can, keep export available during that time, and refund the fees prepaid for the unused term.

17. Contact

In short: where to write.

• General and legal notices, privacy and rights requests, abuse, takedown and copyright reports: legal@assemblywright.ai
• Billing, refunds, and package changes: billing@assemblywright.ai
• Support and everything else: hello@assemblywright.ai
• Security vulnerability reports: security@assemblywright.ai (see /.well-known/security.txt)

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