Data processing agreement — a template for the hosted edition

PROVISIONAL wording by the operator (2026-10-04) in §5 aws-s3 / github and §7 Export — lawyer review pending. One mark stays open for the bug reports: the final words of §9's «What stays» bullet on a delivered bug report, whose mark still names the lawyer; the operator fills them at signing. Every other «<fill in>» mark stays open for the parties to fill at signing, §5's model-provider and Stripe data terms among them.

TEMPLATE. This is not legal advice: a starting text for the controller's and the processor's lawyers, to be completed at every «<fill in>» and reviewed before anyone signs it. It describes the hosted edition of Significans Architect as the repository builds it (the processor's data map); where the text and the map differ, the map is the service's record.

1. The parties

• The controller: «<fill in: the customer organisation, its address and its representative>».
• The processor: «<fill in: the operator of the hosted edition, its address and its representative>».

2. Subject and duration

The processor runs the hosted edition of Significans Architect (the chat with the model, the product's tools, the files and the organisation's administration) for the controller's users. The agreement lasts as long as the service agreement «<fill in: its reference and dates>» and ends with it; section 9 says what happens to the data then.

3. Nature and purpose of the processing

Storage, transmission and deletion of the users' accounts, chats and files; the model calls and the product's tool calls a user's message starts; the metering of those calls; the operators' audit of their changes and of their openings of a customer's account, organisation and balance records, of an organisation administrator's console sign-ins, sign-outs and changes to the organisation's agents and to its members' recipe rights and of a recipe studio account's sign-ins, sign-outs and changes to recipe packs and submissions. Purpose: providing the service to the controller's users as the service agreement describes it. Nothing of a member's turns is kept to improve the service: «Help us improve Architect» keeps a personal account's telemetry — the features used, timings, token counts and error codes, never a chat's content — 30 days to find mistakes and improve Architect, is always off for a member of an organisation, and what an account collected before it joins is deleted at the join (PROVISIONAL).

4. The data and the data subjects

The data subjects: the controller's users (the members of its organisation) and the addresses its admins invite. The data categories are the processor's data map's rows: the account (the address, the password's Argon2id hash, the times, the plan, the flags, the sealed product key, the Stripe link of a bought plan, and the user's display name and standing instructions to the assistant — content the user types, treated as a chat's: the instructions go to the model's provider with each model request), the sessions and mail links (hashes only), the organisation's membership and invitations, the stored chats and their messages and events, the files and their bytes, the «Help us improve Architect» telemetry (never of a member's turns), the metering record, the operators' audit, the AE-Agent link's tokens (their hashes only), the install key a token is pinned to and the computer name a code sign-in reported, the sign-in codes for their ten minutes, its live link and its update rows (the versions, the outcome and its code), the logs, and what the external holders below receive. No special category of data is asked for; what a user types or uploads is the controller's responsibility «<fill in: the controller's rule for special categories>».

5. Subprocessors

• hosting — AWS Lightsail, «<fill in: the region>»: the host, its disk and its backups.
• mail-relay — «<fill in: the mail relay>»: the account mails (the address and the mail's text).
• model-provider — for the calls that run on the processor's own key (every call on a personal plan; on an enterprise plan, every call paid from the organisation's prepaid balance), the model provider under the processor's own key: Anthropic, or Amazon Web Services (Amazon Bedrock, in the region «<fill in: bedrock_url's region>») for a model the processor's catalogue offers there («<fill in: the provider and its data terms>»); for the calls that run on the organisation's own model key, none of the processor's: those calls go to the organisation's own endpoint under the controller's own contract.
• aewc-mcp — the product server (Significans Automation's), which keeps the product key's record and the product's own session data of the chats: each chat's working copies, the workflow draft and the files handed to it, for 7 days after the last use, unencrypted in its own database and backed up nightly with the host; the processor's own database keeps the chat text encrypted at rest but not the contents of files (§6).
• aws-s3 — Amazon Web Services (Amazon S3: a Lightsail bucket attached to the host, or a plain S3 bucket, in the host's region «<fill in: the region>»): a delivered bug report's bundle — the user's description, the transcript the user sent and the files the user named, the account by a tag, never its id —, one private, server-side-encrypted object a report, deleted at 180 days or at the user's erase, under the AWS GDPR Data Processing Addendum that forms part of the AWS Service Terms.
• github — GitHub (one private repository of the processor's, read by its maintainers alone): a delivered bug report's issue — its title line and description, the contact address and reach note, the account's tag, the facts of the client and the service —, rewritten to its forgotten form at 180 days or at the user's erase, under the GitHub Data Protection Agreement that forms part of GitHub's customer terms.
• gateway — the processor's own TLS gateway in front of the service, with its access log.
• stripe — Stripe, the payment provider of the personal plans and of the prepaid balance's top-ups — an account's and, bought by its admin, an organisation's, under the organisation's own Stripe customer (its name and the buying admin's e-mail address) — («<fill in: Stripe's data processing terms>»): the Stripe customer (the e-mail address, the account's id and, for a buyer who gives them, the business name, the billing address and the tax ID, as Stripe Checkout saves them: https://docs.stripe.com/tax/checkout/tax-ids, https://docs.stripe.com/payments/checkout/name-collection?payment-ui=stripe-hosted), its subscriptions, checkout sessions, charges, invoices and receipts.

The processor informs the controller «<fill in: the notice period>» before adding or replacing a subprocessor.

6. Security measures

• Passwords: Argon2id; every login costs one verification.
• Sessions, the organisation console's and the recipe studio's sessions, mail links and AE-Agent tokens: only a token's sha256 is stored. An AE-Agent update carries the product's own update file, checked against the product's sha256 before it is sent and never opened; the AE-Agent checks it again before installing it.
• The customer's product key and an organisation's model key: sealed with AES-256-GCM.
• Chat content at rest — chat titles, messages, tool calls and their results, the live stream and file names: AES-256-GCM under a data key per chat (and per file), each wrapped by the data key, a secret file on the host outside the database; the service decrypts a chat to answer in it and to show it. Not yet encrypted at rest: file contents and their checksums, the copies a bug report keeps, the product's working drafts and the account's display name and standing instructions.
• Secret files: read only at modes 0400 or 0600.
• Transport: TLS at the gateway.
• What is kept, where, for how long and who sees it: the processor's data map, pinned by tests.
• The operators' own accounts, apart from the customers', and the audit log of their changes and of their openings of a customer's account, organisation and balance records, of an organisation administrator's console sign-ins, sign-outs and changes to the organisation's agents and to its members' recipe rights and of a recipe studio account's sign-ins, sign-outs and changes to recipe packs and submissions (365 days, PROVISIONAL).
• «<fill in: the host's backups, access control and the processor's staff rules>».

7. Export

A user takes out what the service holds about them with GET /hosted/api/account/export: one JSON document of the account, the organisation's membership, the pending invitations to the address, the usage windows, the balance history of the account's own prepaid balance (each grant with its invoice reference, each top-up, each refund and payment dispute with what it took or gave back, and each day's charges per model), the files (with their download routes), the «Help us improve Architect» telemetry, the AE-Agent update rows the account started, its AE-Agent records (each one's name and dates, whether it is still linked and the computer name its sign-in reported), its MCP client grants (each client's name and the grant's state and dates), its AE-Agent direct client grants (each client's name and the grant's state and dates), its bug reports' facts and the stored chats; a document without its closing "complete": true was cut short and is refused by the client.

Your export holds your data as the service shows it to you — your messages and files, the assistant's replies and, for each tool call the assistant made, what its card shows (the tool's name and status and the details the card draws: a summary line, a download, a workflow graph, a question or a refusal) — and leaves out the requests and answers behind the cards unless an operator has switched Debug mode on for your account or your organisation.

8. Breach notice

The processor notifies the controller of a personal data breach within «<fill in: hours>» hours of becoming aware of it, with what is known of its nature, the data and subjects concerned, its likely consequences and the measures taken.

9. Deletion and return of data

A user erases their account with POST /hosted/api/account/erase {password}: the sessions end at once and no turn starts; the account, its sessions and mail links, its throttle counters keyed by its id, its membership (a lone member's organisation stays empty for the operator), the pending invitations to its address, its stored chats with their messages, events, collected records and file records, the files' bytes no other record names, the AE-Agent link's tokens and update rows (its live link closed; those it started on an organisation's AE-Agents stay the organisation's until 365 days from their start, their actor rewritten erased), the account's MCP client connections (grants), the Stripe customer (deleted before the account is marked: Stripe cancels its subscriptions; while Stripe cannot be reached the erase is refused and the user tries again), the account's address on every organisation's Stripe customer it is the contact of (cleared before the account is marked, the same way) and the product key (revoked, then its record's owner texts forgotten by the product server — the account's id and, for keys issued before 30 September 2026, its address) go; a step that fails is finished by the service's reconciler within minutes, and the user is mailed once when the account's document is gone. An account with no plan in force that nobody uses is erased the same way at the end of the inactivity term the Terms of Service state, after emails to its address before that day — never a member of an organisation with a plan. What stays:

• the metering record: the collections ledger, windows and customer_daily, ids and amounts, no content;
• the plan payments record: the collection plan_payments, an accounting record of each paid plan invoice — its id, the account's id, the subscription's id, the amount, the currency and the moment —, never an address;
• the prepaid balance's record: the balances document, its _id holding the account's id, its sums, its credits (a grant with the operator's id and the invoice number) and its debits (a refund or a dispute, with Stripe's id for it and the payment's) — the credits' ids, amounts, sources and stamps, a grant's copy in the operators' audit staying 365 days; the debits' kinds, amounts and moments; a zero record for an account that never held a balance —, the remainder extinguished without a refund (the Terms' words are the lawyer's); an organisation's balance is untouched by a member's erase and keeps the top-ups the person bought for it under the account's id, without the address;
• the operators' audit records, for their 365 days: their ids (target.id, detail.account — the account's id —, and actor.customer_id, an organisation admin's own id on its AE-Agent changes and its sign-ins to and sign-outs from the organisation console and a recipe studio account's own id on its sign-ins, sign-outs and changes to recipe packs and submissions) and detail.reason, the reason the operator typed for the account's erase or export or for its removal from an organisation (up to 200 characters), kept as typed — an address written in it stays —, with the address blanked;
• the product's key record, revoked: its id, hash and stamps, its owner_name, owner_company and client_label read «(forgotten)» from the erase's call on;
• the product server's working copies of the account's chats — the workflow drafts and the files handed to it, unencrypted in its own database —, until 7 days after their last use (a revoked key's workspace within 7 days and 5 minutes), and their copies in the host's nightly sets until retention prunes them;
• beside a bug report the service delivered (its bundle in aws-s3, its issue in github, rewritten to its forgotten form): earlier versions of the record and copies our engineers have already received are not recalled — the issue's edit history keeps its original body, the renamed event its previous title, the repository watchers' notification e-mails the original and a maintainer's comment quoting the report its quote, each until removed by hand; an object in a bucket or prefix the processor has since moved from, until emptied by hand; the host's nightly sets (7 dailies + 4 Sundays) keep a forgotten report's bundle and ledger row until retention prunes them, the processor's recovery copies, never read by the service «<fill in: the final words — the lawyer>»;
• a sign-in code the account confirmed for an AE-Agent, until its ten minutes end — the code, the installation's public key, its computer name and kit version, the account's id —; no AE-Agent links by it once the erase began;
• the logs, the host's own, under its rotation «<fill in: the rotation period>»;
• Stripe's records of the payments: the charges, invoices and receipts, with the e-mail address and the business details they carry (a finalized invoice keeps those it was finalized with: https://docs.stripe.com/api/invoices/object), under Stripe's own terms.

At the end of the agreement the processor deletes the controller's users' data as above, account by account, or returns it as their exports first «<fill in: which, and within how many days>».

10. Audits

«<fill in: how the controller may audit the processor, how often and at whose cost>».

Back to the front page