Draft for attorney review — not yet in force.
AssemblyWright AI — Design Partner Pilot Agreement
Effective date: [DATE]
The short version. This box is a plain-English summary for convenience. It is not part of the Pilot Agreement, and where it differs from Part A or the numbered sections of Part B, those govern.
A design-partner pilot is a trade. Partner gets a pre-release product on the terms in Part A — a pilot fee or none, a named allowance, model spend on us — and direct access to the person building it. We get honest feedback, and a case study only if Partner ticks the box.
This agreement sits on top of the Terms of Service. It is a signed Order under them. The Terms, the Acceptable Use Policy, the Refund Policy and the Data Processing Addendum apply in full; this agreement changes them only where it says so, and it uses their words.
Sandbox only, until two things exist. Partner connects sandbox, scratch, Developer Edition and UAT orgs — never a production org — until the DPA has been countersigned and Partner has given a written step-up naming the org, the writes and the people who may approve them. Some of the product's own stops refuse a production org; the rest of this rule is Partner's undertaking, and Section B.3 says which is which.
The product is early, and we say so once. Features may change; several have never been run against a live org; there is no SLA; we hold no SOC 2, ISO 27001, HIPAA attestation or penetration test; off-server backups are being set up; AI output may be wrong. A person reviews everything a Build proposes before it is relied on or deployed.
The allowance is a ceiling Partner keeps within, not a meter. No overage is ever charged during the pilot. The product's own spend brakes still pause a Build at its ceiling, or refuse a new one at a cap; a brake is not a charge.
Liability is the Terms' cap, no wider — the fees Partner paid or owes for the Service in the last 12 months or US $100, whichever is more, with the Terms' exceptions, and a data incident inside it. The pilot price reflects that allocation.
Either side can end it on 30 days' notice. Export before a Workspace is closed. Changes already deployed into Partner's org stay in Partner's org. At the end, Partner may convert to a package at the discount in Part A, or walk away; nothing is deleted by the pilot ending.
This Design Partner Pilot Agreement (the "Pilot Agreement") is between Evadaroo & Company, LLC, a Pennsylvania limited liability company doing business as AssemblyWright AI (registration pending) ("AssemblyWright", "we", "us"), and the party named in Part A ("Partner", "you"). It is made up of Part A (the Order Form, with the terms of this particular deal) and Part B (the pilot terms). It takes effect on the later of the effective date stated above and the date it has been signed by both parties (the "Effective Date"); the pilot itself starts as Section B.8.1 says.
How it fits with the other documents. By signing this Pilot Agreement, Partner accepts the Terms of Service (assemblywright.ai/legal/terms/) (the "Terms") and, with them, the Acceptable Use Policy (the "AUP"), the Refund Policy and the Data Processing Addendum (the "DPA"), each as the Terms incorporate it (Section 16.1 of the Terms). The Privacy Policy — and, until it is in force, the privacy notice at assemblywright.ai/privacy/ — is a notice rather than a contract. This Pilot Agreement is a signed Order under the Terms. Under Section 16.2 of the Terms it prevails over the Terms, the AUP and the Refund Policy only for the terms it expressly changes; the DPA prevails on the processing of personal data; Section 8 of the AUP prevails on how the AUP is enforced; and, as the Refund Policy's own introduction says, where this Pilot Agreement sets its own refund terms those apply in place of the Refund Policy. Everything this Pilot Agreement does not change — ownership of content, confidentiality, the CRM rules, the indemnities, the limitation of liability, disputes — is as the Terms and the DPA say, and nothing said in a sales conversation or a pilot proposal that this Pilot Agreement does not repeat is part of the deal (Section 16.1 of the Terms).
Part A — Order Form
| Field | Value |
|---|---|
| Partner (legal entity) | [PARTNER LEGAL NAME], a [PARTNER ENTITY TYPE AND JURISDICTION] |
| Partner address | [PARTNER ADDRESS] |
| Partner primary contact | [NAME, TITLE, EMAIL] |
| Partner technical contact | [NAME, TITLE, EMAIL] |
| Partner notice address | [PARTNER NOTICE EMAIL] (Section B.11.3) |
| Pilot start date | [PILOT START DATE], or the later day Section B.8.1 names |
| Initial pilot term | [NUMBER] months from the pilot start date, then month to month (Section B.8) |
| Pilot Workspace | [PILOT WORKSPACE NAME], or the Workspace we open for Partner (Section B.1.1) |
| Pilot fee | [PILOT FEE] per month in US dollars, exclusive of taxes — or "No fee" (Section B.4.1) |
| How the fee is billed | [INVOICING ROUTE] — one of: through Paddle, as a subscription to the package named below at the pilot fee; or by an invoice from AssemblyWright, payable within [NUMBER] days of its date (Section B.4.2) |
| Package and features during the pilot | [PACKAGE] — or every feature the product offers Partner's Workspace during the pilot (Section B.2.1) |
| Included Builds per month | [NUMBER] — a ceiling Partner agrees to keep within, not a meter the Service enforces. No overage is charged during the pilot (Section B.4.4) |
| Users | Up to [NUMBER] Users in the Pilot Workspace (Section B.4.5) |
| Connected Orgs authorized at signature | Non-Production Orgs only — sandbox, scratch, Developer Edition and UAT (Section B.3.1) |
| Production access | Not authorized. Requires a countersigned DPA and a Step-Up Authorization (Section B.3.2) |
| Feedback | [NUMBER] feedback sessions per month of up to 45 minutes, plus written notes on each completed Build (Section B.5) |
| Case study | ☐ Decline (the default) · ☐ Opt in, anonymized · ☐ Opt in, named — tick one (Section B.6) |
| Conversion discount | [NUMBER]% off the list price of the package Partner converts to, for [NUMBER] months from conversion (Section B.10) |
| Notice address — AssemblyWright | legal@assemblywright.ai; Evadaroo & Company, LLC, [REGISTERED OFFICE ADDRESS], Pennsylvania, USA |
Signatures
| Signed for AssemblyWright | Signed for Partner |
|---|---|
| By: ____________________ | By: ____________________ |
| Name: | Name: |
| Title: | Title: |
| Date: | Date: |
Part B — Pilot Terms
B.1 What this agreement is, and the words it uses
In short: the Terms' own definitions, plus a few for the pilot; the Terms apply in full; this document changes them only where it says so.
B.1.1 Definitions. Capitalized words this Pilot Agreement does not define — Agreement, AUP, Build, Connected Org, Connected Service, Customer Account, Customer Content, Deliverable, DPA, Order, Security Incident, Service, User, Workspace and Wright among them — mean what Section 1 of the Terms says they mean, and Partner is the Customer under the Terms, the AUP, the Refund Policy and the DPA. In addition: "Pilot Term" means the initial term in Part A and any month-to-month continuation under Section B.8; "Pilot Fee" means the fee in Part A, if Part A names one; "Pilot Workspace" means the Workspace named in Part A, or the Workspace we open for Partner for the pilot, and any other Workspace in Partner's Customer Account used for it; "Non-Production Org" means a Connected Org that is a sandbox, scratch, Developer Edition or UAT org of Partner's CRM vendor, or that vendor's equivalent non-production environment; "Production Org" means any Connected Org that is not a Non-Production Org, including one whose type the Service cannot confirm (Section 7.4 of the Terms); "Step-Up Authorization" means the written authorization described in Section B.3.2; "Confidential Information" means what Section 10.1 of the Terms says it means; and "Personal Data Breach" means what Section 1 of the DPA says it means.
B.1.2 The Terms apply in full. The Terms, the AUP, the Refund Policy and, where we process personal data on Partner's behalf, the DPA govern Partner's use of the Service throughout the Pilot Term and after it. This Pilot Agreement modifies them only where a Section of this Part B says so expressly, and only for the Pilot Term unless that Section says otherwise. A reference in this Pilot Agreement to a Section of the Terms, the DPA, the AUP or the Refund Policy is to that document as in force on the Effective Date, and to the same numbered Section of any later version that Section 16.3 of the Terms makes applicable to Partner.
B.1.3 What the Pilot Fee replaces. Where Part A names a Pilot Fee, it replaces the package price that would otherwise apply under Section 4 of the Terms for the Pilot Term. It changes nothing else in Section 4 of the Terms that this Part B does not expressly change.
B.1.4 Partner's Users, and acceptance. Each of Partner's Users accepts the AUP for themselves when they first sign in to the Pilot Workspace, and a User who is an owner or admin of it may also be asked in the product to accept the Terms; doing so accepts them for Partner and changes nothing in this Pilot Agreement, as the Terms provide. Partner is responsible for its Users, for the roles it assigns them and for the credentials it supplies, as Sections 2.3 and 2.4 of the Terms describe.
B.2 Pilot status, honestly stated
In short: pre-release; features may change; several paths have no live run yet; no SLA; no certifications; backups being set up; AI output may be wrong; one person operates it.
B.2.1 The Service is pre-release. AssemblyWright is in a private beta, onboarding design partners, and the whole Service is early. Features may be added, changed or withdrawn during the Pilot Term. Partner agrees that the features Section 3.3 of the Terms names, and any feature the product marks as new, beta or unproven, may change or be withdrawn without the notice Section 3.2 of the Terms gives for retiring a material feature; Section 3.2 of the Terms otherwise applies. Part A says which package or features the pilot includes; a feature not yet available in the product on the pilot start date is included when it ships, if it ships during the Pilot Term, and its absence is not a breach.
B.2.2 What has not yet been proven on a live system. Section 3.3 of the Terms lists the features that, as of the effective date of the Terms, have been exercised only against simulated orgs or have never posted, sent or run against a live account — among them Process Documentation, the Dynamics 365 and HubSpot connectors, metadata restore, bulk data updates and their undo, data-snapshot restore, test-data seeding, releases and promotion, UI verification, the Content Desk and the iPhone app. Those features are provided as-is, with no warranty or support commitment, as that Section says, and the same is true during the pilot. A design partner is, by its nature, among the first to run the Service against a real org; Section B.3 is built around that.
B.2.3 No uptime commitment. There is no service-level agreement, no status page and no uptime or response-time commitment, during the pilot or after it (Section 3.4 of the Terms). The Service's own limits — the daily and concurrent Build caps, the per-Build model-call budget and spending ceiling, the monthly Workspace budget and the others that Section names — apply to the Pilot Workspace at the defaults the product shows, and we may raise one for the pilot on request, at no charge.
B.2.4 AI output may be wrong. Every Deliverable, review, proposal and answer is produced by statistical models and may be inaccurate, incomplete or confidently mistaken (Section 6.2 of the Terms). Partner will have every Deliverable reviewed by a competent person before it is relied on, handed to a client or deployed, and every change a Build proposes to a Connected Org reviewed before it is approved. The review gates and human checkpoints exist for that purpose; using them, and setting their depth, is Partner's responsibility, not ours.
B.2.5 What we do not claim. We hold no SOC 2 report, no ISO 27001 certificate, no HIPAA attestation and no third-party penetration test, and none is in progress; isolation between Workspaces is logical, not physical; multi-factor sign-in is not enforced; and off-server backups of our database are being set up and are not yet confirmed as running (Sections 9.2, 9.3 and 14.1 of the Terms). AssemblyWright is operated by one person, who holds administrative access to the production systems and whose console shows names and counts, never Partner's content (Section 10.4 of the Terms). Partner accepts all of this in choosing to pilot, will keep its own copies of anything it cannot afford to lose, and will not put into the Service — or let a Wright read from a Connected Org into it — data whose handling requires a certification we do not hold, or any data Section 3 of the AUP excludes (Section 9.3 of the Terms).
B.2.6 Roles. Starting a Build, approving a review gate and connecting or writing to a Connected Org need the roles Section 2.3 of the Terms describes. Where role enforcement is not yet switched on for a Workspace, the Service refuses those actions rather than allowing them to everyone, as that Section says. The pilot therefore does not start until role enforcement is on for the Pilot Workspace, so that Partner's own Users can act in it by their roles (Section B.8.1); we tell Partner's primary contact when it is.
B.3 Environment restriction — the core safeguard
In short: Non-Production Orgs only, until the DPA is countersigned and a Step-Up Authorization exists; least privilege; masked data; which stops are technical and which are Partner's undertaking; undo's limits; Partner keeps its own CRM backups.
B.3.1 Non-Production Orgs only, until Section B.3.2 is met. Until both conditions in Section B.3.2 are met, Partner will connect only Non-Production Orgs to the Pilot Workspace, and will not connect a Production Org or run a Build, deploy, bulk update, seeding run or verification against one. Partner will tag every saved connection honestly as sandbox, UAT or production (Section 1.3 of the AUP). The Service enforces part of this rule and not the rest, and we say which is which: the autonomous execution mode refuses a Production Org on the server, classifying a Salesforce org from Salesforce's own address for it or from what the org reported about its type when it was connected (Section 7.4 of the Terms); test-data seeding classifies the org live from the org's own answer and refuses a Production Org, or one it cannot classify, unless the caller types the org's name (Section 7.8 of the Terms) — and Partner will not type it; UI verification reads the tag Partner typed rather than the org — it refuses a connection not tagged sandbox or UAT, an untagged one included, unless a Workspace administrator has opted the Workspace into production (Section 7.9 of the Terms); a release's target is resolved from the connection's tag, and a release aimed at a production-tagged connection warns and requires a typed confirmation (Section 7.5 of the Terms); and for a metadata deploy or a bulk update that a Wright proposes inside a Build, nothing reads the environment tag at all — the write pauses at a gate whose approval card does not name the target org (Section 7.4 of the Terms), so the person who approves it is the only stop, and the same acts run by hand outside a Build need the admin or owner role and an explicit instruction, a typed word for a bulk update, but no check of the org's type either (Section 7.4 of the Terms). Dynamics 365 and HubSpot have no sandbox concept the Service can read, so for them this Section rests entirely on Partner's undertaking. The restriction is Partner's obligation, not a technical lock, and a Production Org connected in breach of it is Partner's act under Sections 2.4 and 7.3 of the Terms.
B.3.2 Production access requires both of the following, and nothing less:
- a copy of the DPA countersigned by both parties — the DPA already applies from the Effective Date, as Section 12.2 of the DPA provides, and Partner asks for a countersigned copy at legal@assemblywright.ai; and
- a Step-Up Authorization: a written authorization from Partner, signed or sent by an officer of Partner or by the authorized CRM or IT lead of the org's owner, that names the specific Production Org (by its address or instance); confirms, where the org is a client's, that Partner holds the org owner's written authority to change it (Section 1.1 of the AUP and Section 4(d) of the DPA); states the scope of permitted writes (the objects, metadata types and operations); names the Users in the Pilot Workspace who may approve a write or a deploy to it; and confirms that the person giving it has read Sections 7.4 to 7.6 of the Terms.
An email from such a person stating these things is sufficient; a verbal go-ahead, a chat message or a tag set in the product is not. A Step-Up Authorization covers only the org and the scope it names; a second Production Org, or a wider scope, needs another. We may decline to act on a Step-Up Authorization, or withdraw our acceptance of one on written notice, where we reasonably believe the Service, the org or the scope is not ready for it; doing so is not a breach of this Pilot Agreement. Where we decline or withdraw, that Step-Up Authorization no longer satisfies this Section B.3.2: Partner will not approve any write or deploy to the org from our notice, and disconnects it in the product within five business days. Partner may withdraw one at any time by written notice, and then disconnects the org in the same way.
B.3.3 Execution mode where a Production Org is connected. In a Production Org the Service pauses every write for a person whatever the execution mode (Section 7.4 of the Terms). Partner will keep the Pilot Workspace in the gated mode, or in read-only, while any Production Org is connected to it, and will use the autonomous mode only in a Non-Production Org the Service has itself confirmed is one — which is the only place the Service allows it.
B.3.4 Least privilege. Partner will connect each org through an integration user holding the narrowest permissions that let the Service do the agreed work (Section 7.2 of the Terms and Section 1.2 of the AUP), will scope those credentials away from any object or field holding data Section 3 of the AUP excludes, and will review the permissions it has granted at the midpoint of the initial term and again before giving any Step-Up Authorization. We can do everything Partner's credentials permit if instructed to, and we do not reduce what a credential allows.
B.3.5 Data minimization in the pilot. Partner will prefer masked, synthetic or reduced datasets wherever the work does not require real records, will use the Service's own seeding tool rather than real records to populate a Non-Production Org for testing (Section 7.8 of the Terms), and will not import org context, records or files containing data Section 3 of the AUP excludes. Where personal data in a Connected Org is read, transformed or written on Partner's instruction, Partner has the lawful basis for it (Section 4 of the DPA).
B.3.6 Undo, custody and backups. Before every metadata deploy to a Salesforce org and every bulk update the Service keeps an undo point — no undo exists for a Dynamics 365 or HubSpot change (Section 7.4 of the Terms) — and Section 7.6 of the Terms states exactly what an undo restores and what it cannot — in particular, it does not remove components a deploy added, it does not cover record data, and it never reverses downstream automation a change set off in the org. Captured prior values are kept for 30 days by default, in our database or in Partner's own Salesforce org as Partner chooses (Section 7.7 of the Terms). Those are conveniences, not a substitute for Partner's own backup regime: Partner remains responsible for its own CRM backups, and nothing in a Connected Org is backed up by us at any time (Section 14.1 of the Terms).
B.3.7 Screens of a real org. Where Partner switches on UI verification or training-guide capture, the evidence is video and screenshots of Partner's real org screens, kept inside our application's own storage for 30 days by default (Section 7.9 of the Terms). Partner will run them only on screens that hold nothing it would not want captured, and only on an org whose owner has agreed to it (Section 1.7 of the AUP).
B.4 Fees, allowance and model spend
In short: the fee and the billing route are in Part A; Paddle or an invoice from us both work; model spend is ours; the allowance is a ceiling, never an overage; the money-back applies once.
B.4.1 The Pilot Fee. Partner pays the Pilot Fee set out in Part A, if any, for each month of the Pilot Term, in US dollars, in advance, exclusive of taxes. Where Part A says there is no fee, Sections B.4.2 and B.4.3 do not apply: the Service is provided to Partner during the Pilot Term without charge, under this Pilot Agreement rather than as a package trial under Section 4.5 of the Terms, and nothing is charged when the Pilot Term ends (Section B.10.4).
B.4.2 How it is billed is the route Part A names. (a) Through Paddle: Partner subscribes at checkout to the package Part A names, at the Pilot Fee, and Sections 4.7 and 4.8 of the Terms apply — Paddle is the Merchant of Record, collects any applicable sales tax or VAT at checkout and issues every refund. Part A governs over what checkout shows (Section 16.2 of the Terms); if checkout shows a different amount, Partner tells us before paying and we correct it, and any difference charged is refunded as a charge made in error (Section 10 of the Refund Policy). The subscription renews monthly while the Pilot Term continues, and we cancel it, or re-price it, with Paddle when the pilot ends or converts (Section B.10). (b) By invoice from AssemblyWright: we invoice the Pilot Fee monthly in advance to Partner's primary contact; each invoice is payable within the number of days Part A names, by bank transfer to the account the invoice names; and an amount still unpaid 10 days after we remind Partner in writing lets us suspend paid features as Section 4.8 of the Terms provides. On an invoice, Partner is responsible for any sales, use, value-added or similar tax that applies to the fee, other than a tax on our income; where we are required to collect such a tax, we add it to the invoice. A refund of an invoiced fee that this Pilot Agreement or the Refund Policy gives is paid by us directly, within 30 days of our confirming it, as Section 2 of the Refund Policy provides for a fee we invoice ourselves.
B.4.3 Money-back, and other refunds. The 30-day money-back in Section 4.6 of the Terms and Section 1 of the Refund Policy applies to Partner's first payment of a Pilot Fee: tell us at billing@assemblywright.ai within 30 days of that payment and we refund it in full — together with any charge added to the same subscription before Partner asks, for a larger package or a change of billing interval — once per Customer Account, and the pilot then ends unless we agree otherwise in writing. That refund is the once-per-Customer-Account refund, so a later conversion under Section B.10 does not start it again. Otherwise a Pilot Fee paid for a month that has begun is not refunded, except in the cases Section 5 of the Refund Policy lists — among them where we end the pilot for our convenience, materially breach this Pilot Agreement and do not cure it, or make a material change to the Terms that Partner rejects — and the unused part of a prepaid month is then refunded by days, as that Section describes.
B.4.4 The allowance is a ceiling, not a meter. Part A names the number of Builds included per month. That number is a contractual ceiling Partner agrees to keep within; the Service does not count Builds against it or refuse a Build for exceeding it, and no overage is charged during the Pilot Term, whatever the count (Section 4.2 of the Terms: no rate is named, so no charge is made). If Partner needs more Builds in a month, Partner asks, and we raise the allowance by written agreement — an email between the contacts named in Part A is enough — at no extra charge, or we agree a different fee for the following month. If Partner exceeds the allowance without asking, we may ask Partner to pause new Builds until the next month, treat a repeated excess as a breach to be cured under Section B.8.3, or let the work continue; none of those is a charge. An unused allowance does not carry over.
B.4.5 Users. Partner will keep the number of Users in the Pilot Workspace at or below the number in Part A. The Service does not count Users against that number. If our identity provider's own limit on the members of an organization is lower than the number in Part A, that lower limit applies until it is raised, and we tell Partner's primary contact what it is when the Pilot Workspace is opened.
B.4.6 Model spend is ours during the pilot. Partner is not billed for AI usage during the Pilot Term. The spend and volume brakes in Section 4.4 of the Terms — the per-Build model-call budget and spending ceiling, the Workspace's monthly budget, the daily and concurrent Build caps — still apply at the defaults the product shows, and each pauses, waits or refuses rather than charging; reaching one is not a fault in the Service, and we may raise one for the pilot on request, at no charge.
B.4.7 No other charges. During the Pilot Term we charge Partner nothing other than the Pilot Fee: no setup fee, nothing for a feedback session, nothing for raising an allowance or a brake, and nothing for the export Section 11.5(d) of the Terms describes. Partner's own costs — its CRM vendor's charges and API allowances, a network that bills per post, its own staff's time — are Partner's (Sections 7.10 and 7.12 of the Terms).
B.5 Feedback — what Partner owes us
In short: sessions each month, notes on each Build, prompt defect reports; feedback is ours to use freely; Partner's content is never feedback; missing a session is not grounds for termination, but two silent months end pilot pricing.
B.5.1 What Partner provides, in good faith, during the Pilot Term:
- the number of feedback sessions per month stated in Part A, each of up to 45 minutes, by video call, with at least one person who actually uses the Service;
- written notes on each completed Build — what was usable, what was wrong, what was missing — sent to hello@assemblywright.ai within ten business days of the Build completing;
- prompt notice of defects, with enough detail to reproduce them, to hello@assemblywright.ai (a security problem goes to security@assemblywright.ai under Section 4.3 of the AUP);
- a reasonable answer to our questions about how the Service is being used, in Partner's own words.
B.5.2 We learn from Partner, not from Partner's content. Our operator console shows us names and counts — never a Build's request, a Deliverable, a Knowledge Base entry or an org's data — and we open Customer Content ourselves only as Section 10.4 of the Terms allows. What we learn about the pilot comes from Partner, in the sessions and the notes, which is why Section B.5.1 matters to the trade; Partner's primary contact will make sure it is given.
B.5.3 The license. Section 16.16 of the Terms applies, and in addition Partner grants AssemblyWright a perpetual, irrevocable, worldwide, royalty-free, sublicensable license to use, copy, modify and incorporate the feedback, suggestions, defect reports and ideas Partner or its Users give about the Service, to improve, operate and commercialize the Service and other products, without attribution, without payment and without any obligation to implement any of it. Feedback is not Partner's Confidential Information (Section 10.5 of the Terms).
B.5.4 Feedback never includes Partner's data. The license in Section B.5.3 does not reach Customer Content: Partner's Build requests, Knowledge Base, org configuration, records, Deliverables, and anything identifying Partner, its staff or its clients remain Partner's Confidential Information under Section 10 of the Terms. If Partner sends us a screenshot, a Deliverable or a file to illustrate a defect, we use it to find and fix the defect and for nothing else, we hold it only in the mailbox or on the device it reached, and we delete it at Partner's request. Partner will remove or mask personal data and client data from such material before sending it, where it can.
B.5.5 Missing a session is not a breach we will terminate over. If Partner provides no feedback session and no written notes for two consecutive months, we may, on 30 days' written notice, end the Pilot Fee and the conversion discount in Part A and charge, from the next month, the list price of the package Part A names (or, where Part A names features rather than a package, of the smallest package that includes them) — on the Paddle route by re-pricing the subscription on that notice (Section 4.10 of the Terms); on the invoice route by invoicing at that price; and where there is no fee and no subscription, by Partner subscribing at checkout within the notice period, failing which the pilot ends under Section B.8.2 — or end the pilot under Section B.8.2. We will raise it with Partner's primary contact first.
B.6 Case study — opt-in, approved and revocable
In short: the default is no case study; nothing is published without Partner's written approval of the text; consent can be withdrawn and we take it down within 30 days; copies already held by others cannot be recalled.
B.6.1 The default is no case study. Section 16.9 of the Terms applies: we do not use Partner's name or logo as a customer reference without its prior written consent. Nothing is published about Partner, named or unnamed, unless Partner has ticked an opt-in box in Part A, and the box ticked is the whole extent of the consent.
B.6.2 Anonymized opt-in permits us to describe the engagement without naming Partner or anyone who works for it — by sector, size and region at most, and in a way that does not reasonably identify Partner — and to publish only anonymized, non-identifying figures that Partner has confirmed as accurate in writing.
B.6.3 Named opt-in additionally permits us to use Partner's name and logo in the case study, in a customer list on our website and in sales material, in the form Partner supplies.
B.6.4 Partner approves the text before publication. We send the draft to Partner's primary contact and do not publish until that contact confirms the text in writing. Approval of one piece is not approval of another, and a material change to an approved piece needs approval again. We will not publish a quotation Partner has not approved, or describe Partner's outcomes in a way Partner has not confirmed.
B.6.5 No figure without its basis. We publish no number about Partner's engagement — time saved, Builds run, cost — unless Partner has confirmed, in the same written approval, both the figure and how it was arrived at. The Service's own counts of Builds and model spend are available to Partner in the product for that purpose.
B.6.6 Revocable. Partner may withdraw its consent at any time by written notice to legal@assemblywright.ai. Within 30 days of receiving it we remove the case study, the name and the logo from our own website, materials and customer list, and stop distributing them. Copies already printed, downloaded or held by third parties, and material a third party has already published, cannot be recalled, and we say so rather than promise otherwise; where we supplied a third party directly, we will ask it to remove the material where we reasonably can.
B.6.7 Partner's own obligations come first. Partner is responsible for having the rights to whatever it confirms, including any client's consent to being described, and Partner's confidentiality obligations to its own clients take precedence over anything in this Section.
B.7 Confidentiality of the pre-release Service
In short: Section 10 of the Terms applies both ways; in addition, unreleased features, the roadmap, unpublished pricing and this agreement's commercial terms are ours to keep confidential; Partner may say it is evaluating AssemblyWright.
B.7.1 Section 10 of the Terms applies to each party's Confidential Information, during the Pilot Term and for the three years after this Pilot Agreement ends, and to Customer Content for as long as we hold it (Section 10.5 of the Terms).
B.7.2 Our pre-release information. During the Pilot Term and after it, Partner will treat as our Confidential Information: features, workflows and designs not yet generally released or announced; the product roadmap and anything we tell Partner about what we plan to build; pricing, packaging and allowances discussed with Partner or shown to it but not published; the fee, discount and other commercial terms of this Pilot Agreement; and our security questionnaire and internal policies where we supply them under Section 10 of the DPA. Partner will not publish screenshots, recordings, benchmarks or comparative evaluations of the Service during the Pilot Term without our prior written consent, which we will not unreasonably withhold for a feature once it is generally released.
B.7.3 What Partner may say. Partner may say publicly that it is evaluating or piloting AssemblyWright; may discuss its own experience of the Service with its own staff, advisors and clients, under confidentiality obligations at least as protective as this Section where our pre-release information is involved; and may show the Service to a client in the course of the engagement the pilot supports. This Section restricts the disclosure of our non-public materials, not Partner's opinion of the product, and it does not restrict a report to a regulator or a disclosure the law requires (Section 10.3 of the Terms).
B.7.4 Our side. Partner's identity as a design partner is Partner's Confidential Information unless Partner has opted in under Section B.6 or tells us otherwise in writing; we will not name Partner as a customer, a reference or a design partner without that.
B.8 Term and termination
In short: the initial term, then month to month; 30 days' notice either way; 15 days to cure a material breach; what happens to the Workspace, the content and the org when it ends.
B.8.1 Term. The Pilot Term begins on the pilot start date in Part A, or on the day we tell Partner's primary contact that the Pilot Workspace is ready for Partner's Users to act in it by their own roles (Section B.2.6), whichever is later, and runs for the initial term in Part A. It then continues month to month until it is ended under this Section, or until Partner converts under Section B.10, when it ends on the day the conversion takes effect.
B.8.2 Ending for convenience. Either party may end this Pilot Agreement at any time, including during the initial term, on 30 days' written notice to the other party's notice address in Part A. A Pilot Fee already paid for a month that has begun is not refunded, except under Section B.4.3; where we end the pilot for our convenience, we refund the unused part of any prepaid month by days (Section 5 of the Refund Policy).
B.8.3 Termination for breach. Either party may terminate this Pilot Agreement on written notice if the other materially breaches it, or the Terms, and does not cure the breach within 15 days of a written notice describing it (Section 11.3 of the Terms). A breach of the AUP is dealt with as Section 8 of the AUP provides, including suspension or termination without a cure period where Section 8.4 of the AUP allows it — a write forced past one of the Service's stops is such a case (Section 8.4(a) of the AUP). In addition, as a term of this Pilot Agreement: where a Production Org is connected to the Pilot Workspace in breach of Section B.3, we may require Partner to disconnect it at once and may suspend the Pilot Workspace until it is disconnected, without the notice Section 8.3 of the AUP gives; if it is not disconnected within five business days of our notice, that is a material breach of this Pilot Agreement, which we may terminate without a further cure period. Any other breach of Section B.3 that is not cured on notice is a material breach of this Pilot Agreement.
B.8.4 What ending the pilot does, and does not do.
(a) The pilot terms end; the Terms continue. When the Pilot Term ends without a conversion, the Pilot Fee, the allowance, the no-overage rule, our payment of model spend, the feedback obligations and the conversion discount end. Partner's Customer Account and the Pilot Workspace are not closed by the pilot ending: they continue under the Terms, on no package unless Partner buys one, and Section 4.1 of the Terms then says what a Workspace on no package is entitled to. Nothing in the Pilot Workspace is deleted because the pilot ended.
(b) If Partner wants to leave, Partner exports first and then closes the Pilot Workspace (Section 11.5(b) of the Terms): closing erases every stored credential at once, and during the 30 days in which an owner can reopen it nobody can open it to take an export. Export before you close. The product's own export — every current Deliverable as Markdown, the Knowledge Base, the list of Builds and the Workspace's configuration — is available on every package and at no charge (Sections 4.12 and 11.5(d) of the Terms), and each Deliverable can be exported singly as a Word file.
(c) If the Terms are terminated by either party under Section 11.3 of the Terms or Section 8 of the AUP, Section 11.5(c) of the Terms says what an owner may ask for, and when, in the 30 days that follow.
(d) Partner's org is Partner's. Changes already deployed into a Connected Org stay there; neither ending the pilot nor closing the Workspace writes anything to an org or reverses anything in it. When the pilot ends, Partner will disconnect each Connected Org in the product and, in its own CRM, revoke or delete the connected app, integration user or private-app token it created for the Service and remove any permissions granted for the pilot.
(e) Anything published or posted stays where it went. A Deliverable published to a Profusia workspace, a post made to a network and an email sent to a customer are outside our reach once made (Sections 7.11 and 7.12 of the Terms); Partner manages them there.
B.8.5 Survival. Sections B.1, B.2.4, B.2.5, B.3.6, B.4.3 (for a refund owed), B.5.3, B.5.4, B.6, B.7, B.8.4, B.9, B.10 and B.11 survive the end of this Pilot Agreement, together with every provision of the Terms that Section 11.6 of the Terms says survives, and the DPA for as long as Section 12.1 of the DPA provides.
B.9 Liability during the pilot
In short: the Terms' cap and exclusions apply, no wider; for the pilot, "fees paid" means the Pilot Fees actually paid; the pilot price reflects this allocation.
B.9.1 Section 14 of the Terms applies unchanged. Neither party is liable to the other for the indirect and consequential losses Section 14.1 of the Terms excludes — including loss that follows from a change deployed to a Connected Org and from downstream automation it set off — and each party's total aggregate liability arising out of or relating to this Pilot Agreement, the Terms, the DPA and the Agreement as a whole is limited as Section 14.2 of the Terms provides, to the greater of the fees Partner paid or owes for the Service in the 12 months before the event giving rise to the claim, or US $100, subject only to the exceptions in Section 14.3 of the Terms. For the Pilot Term, the fees Partner paid or owes means the Pilot Fees Partner actually paid or owes under Part A, and nothing else: not the model spend we absorbed under Section B.4.6, and not the list price of any package. Where no Pilot Fee is payable, the cap is US $100.
B.9.2 No wider. This Pilot Agreement is not a signed Order that raises the cap under Section 14.2 of the Terms or grants an indemnity under Section 13.1 of the Terms; it does neither. A Security Incident, a Personal Data Breach and a breach of the DPA stay inside the cap and the exclusions, as Section 14.3 of the Terms and Section 11 of the DPA provide, and nothing in this Section widens or narrows the exceptions in Section 14.3 of the Terms.
B.9.3 The pilot price reflects the risk. Partner acknowledges that the Service is pre-release, that the Pilot Fee is set — or waived — because of that, and that this allocation of risk is part of the trade this Pilot Agreement records. Partner's indemnities in Section 13.2 of the Terms and Section 4 of the DPA apply during the pilot, including for a Production Org connected in breach of Section B.3.
B.9.4 Notice of a breach of personal data. Where the DPA applies, we notify Partner of a Personal Data Breach without undue delay, and where feasible within 72 hours of becoming aware of it, as Section 3.7 of the DPA provides; otherwise Section 9.4 of the Terms applies. Nothing in this Section limits that obligation, or Partner's right under Section 14.5 of the Terms and Section 11.4 of the DPA to leave with a pro-rata refund after a Personal Data Breach caused by our breach of the DPA.
B.10 What converts at the end
In short: during the pilot, or within 30 days after it ends, Partner may buy a package at the discount in Part A; the Workspace carries over as it is; the pilot's special terms do not.
B.10.1 Converting. At any time during the Pilot Term, or within 30 days after it ends, Partner may convert to a paid package: where the Pilot Fee is billed through Paddle, by asking us at billing@assemblywright.ai to change that subscription to the package Partner chooses (Section 4.8 of the Terms and Section 4 of the Refund Policy — checkout refuses a second subscription while one is live); where Partner has no subscription, by subscribing at checkout (Sections 4.7 and 4.8 of the Terms); or, where we agree, by a further signed Order. The price is the then-current list price of the package Partner chooses, as shown at checkout or in that Order, less the conversion discount in Part A for the number of months Part A states, counted from the day the conversion takes effect. It is a discount on list price for that period, not a price lock beyond it; after the period the package renews at its then-current price under Section 4.8 of the Terms, with the notice Section 4.10 of the Terms gives for any change. Where checkout cannot apply the discount, the discounted price in this Pilot Agreement governs over what checkout shows, as a signed Order does (Section 16.2 of the Terms), and any difference charged is refunded as a charge made in error (Section 10 of the Refund Policy).
B.10.2 What carries over. Partner's Customer Account, the Pilot Workspace and everything in it — Builds, Deliverables and their versions, the Knowledge Base, Bench memory, connections, settings and the audit trail — carry over as they are. Nothing is migrated, re-created or deleted by a conversion. A Step-Up Authorization given under Section B.3.2 continues for the org and the scope it names, and the sandbox-first obligations in Section 7.5 of the Terms and Section 1 of the AUP apply to the converted Workspace as to any other.
B.10.3 What does not carry over. From the day the conversion takes effect, the Pilot Fee, the allowance in Part A, the no-overage rule in Section B.4.4, our payment of model spend under Section B.4.6, the feedback obligations in Section B.5 and the notice right in Section B.8.2 end, and the package's own terms under Section 4 of the Terms apply instead. The consent, or the absence of consent, in Section B.6 continues as given until Partner changes it, and Section B.7 continues as Section B.7.1 says.
B.10.4 Not converting. If Partner does not convert within 30 days after the Pilot Term ends, the conversion discount lapses and Section B.8.4 applies; Partner may still buy a package at list price at any time. We will not re-price the Pilot Workspace, start a subscription or charge Partner anything without Partner's own act at checkout or a further signed Order.
B.11 General
In short: this is a signed Order under the Terms; the Terms' dispute, notice, assignment and other general rules apply; changes to this agreement are made in writing.
B.11.1 The Agreement, and precedence. This Pilot Agreement, together with the Terms, the AUP, the Refund Policy and the DPA, is the entire agreement between the parties about the pilot and the Service, and replaces any earlier discussion, proposal or offer (Section 16.1 of the Terms). The pre-printed terms of a purchase order have no effect. Where the documents differ, Section 16.2 of the Terms decides, with this Pilot Agreement as the signed Order it names: it prevails only for the terms it expressly changes, and the DPA, Section 8 of the AUP and the Refund Policy prevail in the matters that Section gives them.
B.11.2 Disputes and governing law. Section 15 of the Terms applies to any dispute arising out of or relating to this Pilot Agreement as it applies to a Dispute under the Terms: the 30-day talk-first period in Section 15.1, binding individual arbitration under Section 15.2 with the small-claims and injunction exceptions in Section 15.4, the class waiver in Section 15.3, the one-year limit in Section 15.7 and the governing law of the Commonwealth of Pennsylvania in Section 15.9. The 30-day opt-out in Section 15.5 of the Terms runs from the day Partner first accepted the Terms — the Effective Date, where signing this Pilot Agreement is that acceptance — and is not restarted by this Pilot Agreement.
B.11.3 Notices. A notice under this Pilot Agreement is in writing and goes by email to the other party's notice address in Part A — for us, legal@assemblywright.ai, with a copy by post to Evadaroo & Company, LLC, [REGISTERED OFFICE ADDRESS], Pennsylvania, USA, for a notice of breach or termination — and is given when sent, unless the sender learns that it was not delivered (Section 16.5 of the Terms). Operational messages — a raised allowance, a Step-Up Authorization, a case-study approval, feedback — may pass between the contacts named in Part A by email. Each party keeps its contacts in Part A current by notice to the other.
B.11.4 Changes to this Pilot Agreement. A change to Part A or Part B is effective only in a writing signed, or sent by email, by an authorized person of each party, except that a raised allowance (Section B.4.4), a Step-Up Authorization (Section B.3.2) and a case-study approval or withdrawal (Section B.6) are made in the way those Sections describe. Changes to the Terms, the AUP, the Refund Policy and the DPA during the Pilot Term follow Section 16.3 of the Terms, Section 10 of the AUP, Section 12 of the Refund Policy and Section 12.3 of the DPA; where Partner rejects a material change under those Sections, Partner may end this Pilot Agreement before the change takes effect, and we refund the unused part of any prepaid month (Section 5 of the Refund Policy).
B.11.5 Assignment, force majeure, relationship, waiver, severability. Sections 16.4 (assignment), 16.6 (force majeure), 16.7 (export and sanctions), 16.10 (independent contractors, no third-party beneficiaries), 16.11 (severability and waiver), 16.14 (equitable relief) and 16.15 (interpretation) of the Terms apply to this Pilot Agreement as they apply to the Terms, reading "this Pilot Agreement" for "these Terms" where the context requires.
B.11.6 Signature. This Pilot Agreement may be signed in counterparts and electronically, and a signature delivered as a PDF or through an electronic-signature service is as effective as an original (Section 16.12 of the Terms). Each signatory represents that they are authorized to bind the party they sign for.
Evadaroo & Company, LLC, doing business as AssemblyWright AI (registration pending) · [REGISTERED OFFICE ADDRESS] · Pennsylvania, USA · legal@assemblywright.ai