Data processing

You decide. We carry out. That division is the whole of this agreement and everything else follows from it.

• Your firm decides what information goes into Spirit, what it is for, which systems Spirit may reach, and what the rules of each Job are. Under Canadian privacy law you remain the organisation accountable to the individuals the information is about.
• We handle it on your instruction, to provide Spirit, and for no purpose of our own. We are your service provider — a processor, in the language of GDPR, where that applies to your firm; a service provider rather than a seller, in the language of US state privacy laws.
• Your instructions are: this agreement, the terms of use, the configuration of your workspace, and the rules you write into your Jobs. We will not go beyond them, and if we think an instruction would put us in breach of a law, we will tell you rather than quietly carry it out.

• Process only on your instruction, and only to run Spirit for you.
• Never use your content to train models — not our own and not a provider's. This is the commitment, not just the current configuration.
• Never sell it, and never share it for advertising. There is no circumstance in which your content is a product of ours.
• Never pool it with another customer's. What Spirit learns from your corrections stays in your workspace.
• Keep it confidential, and bind everybody at Aslynx who could touch it to the same duty, including after they stop working here.
• Protect it with the measures in Annex C, and not weaken them during your agreement.
• Help you answer the people whose information it is — §9.
• Tell you about a breach within the time in §8.
• Delete it when you are done with us — §14.
• Keep records of what we process for you, as data protection law requires of a processor, and give you the part that concerns you on request.
• Only let a subprocessor near it if that subprocessor is in Annex B and is bound to terms no weaker than these.

Everything in §2 happens because you asked for it. There is one exception, and we would rather name it here than have you find it.

We generate aggregate operational data about how Spirit is being used: how many runs a workspace ran, whether its standing work is still running, how long things took, what failed and how often. We use it to keep the service up, to size capacity, to find what is broken, and to notice that a customer's work has quietly stopped — which is usually the first sign that something is wrong and nobody has told us yet.

The boundary is not a policy. It is what the database will let that process read:

• Counts, statuses and timestamps. That is the whole of it.
• Never a document, never a run's output, never a Job's rules, never the words in a Correction, never a trigger token, never a billing identifier. The process has no permission to read any of those columns, so it could not include them in an aggregate even if somebody asked it to.
• Nothing derived from it identifies an individual, and nothing derived from it is sold, shared or published.

Annex C lists how that permission boundary is enforced, and §12 is how you can ask us to show you.

Not boilerplate: each of these is something we have no way to do for you.

• Have the right to put it in. You confirm you may lawfully give us the information you give us, including that you have whatever consent or authority your own clients' situation requires.
• Have the right to connect what you connect. The credentials you supply must be yours to supply.
• Configure who sees what. Departments, roles and the write-approval gate are yours to set. If every member of your firm can see every Job, that is a choice your workspace made.
• Keep the roster right. Remove people who leave. Remove our `support` seat when we are finished — we will ask you to, but it is your roster.
• Do not send us more than the work needs. If a Job only needs an invoice, do not hand it the whole client file. If you can redact an identifier before it reaches us and still get the work done, redact it.
• Tell the people on the other end. If you publish a Spirit form or a link that starts work, or have Spirit watch a mailbox, then people who have no relationship with us — your clients, their counterparties, contractors in the field — have their information processed by us on your behalf. Telling them is yours to do: your privacy notice is the one they will have seen, not ours.
• Consider whether automated-decision rules apply to you. Spirit's work is automated by design, and Quebec law requires an organisation to inform an individual when a decision about them is made exclusively by automated processing, and to let them make submissions. Whether that bites depends on what your Jobs actually decide, which you know and we do not. The write-approval gate is the control that keeps a person in the loop where you need one.
• Do not put payment card numbers through Spirit. It is not built for cardholder data and is not PCI DSS assessed. Health information and government identifiers are supportable when the work genuinely requires them — tell us first so we can be straight with you about what Annex C does and does not cover.

Subject matter

Providing Spirit: reading the documents and messages your firm gives it, producing the work your Jobs describe, filing results where you tell it to, and writing into the systems you connect.

Duration

For as long as your agreement with us lasts, plus the deletion period in §14.

Nature and purpose

Automated reading, extraction, drafting, classification, filing, organising and transmission, carried out by large language models and by our software, under rules your firm writes.

Types of personal information

Whatever your firm's own work involves, because we do not choose it. In practice: names, addresses, phone numbers and email addresses; file, matter, account and invoice references; financial and transaction details; employment and payroll details; identifiers in the documents you process; the free text of correspondence; and, where your practice involves it, information about legal matters, health or other sensitive subjects. We do not inspect it to find out which.

Categories of individuals

Your firm's clients and their representatives; the counterparties, courts, insurers, suppliers and agencies your work involves; your own staff and contractors; and anybody who fills in a form or uses a link your firm published, or who writes to a mailbox your firm has Spirit watch — people who may have no relationship with your firm at all, and certainly none with us.

Where it is kept

Application, database and queue in Canada. Files in Cloudflare R2, North America. Providers in Annex B process where Annex B says.

This section is the one we would most like you to check us on.

Nobody at Aslynx reads your workspace's content unless you invite us in. The invitation is a `support` seat that you grant from your own team page, and while we hold it:

• it is visible on your roster, named, so anybody in your firm can see we are there;
• you can remove it at any moment, without telling us and without our agreement;
• it is excluded from approving writes into your systems, so we cannot authorise Spirit to put something into your software on your behalf;
• we ask for it when there is a reason, we say what the reason is, and we give it up when the reason is finished.

This is not only a policy. The console our own people use is read-only over customer data apart from adding credits to a ledger, and it cannot read workspace content at all. The process that tells us whether your standing work has stopped running holds permissions granted column by column: counts, statuses and timestamps, and not a Job's rules, a run's output, the words in a correction, a trigger token or a billing identifier. The assistant that drafts a new customer's setup has no access to customer data whatsoever. Annex C lists how each of those is enforced.

The exceptions, stated rather than buried: content you send us yourself in a support message, and a lawful order we are compelled to obey (§11).

We remain responsible to you for every one of these, as if we had done the thing ourselves. Each is bound by terms no weaker than this agreement.

Changes. This page is the current list; we keep it accurate, and we email workspace owners when we add a subprocessor that will handle customer content.

Not subprocessors: the systems you connect. Your Microsoft 365, your SharePoint, your accounting or dispatch software are yours, reached on your instruction with your credentials, under your agreement with them. We do not control them and we are not responsible for what they do with what you tell Spirit to send.

A breach here means personal information in our care being lost, destroyed, altered, taken, or seen by somebody who had no business seeing it.

• We tell you without undue delay, and in any event within 72 hours of becoming aware of it. Not after the investigation finishes — a first notice with what we know, then updates.
• The notice says what happened, when, what information and whose, what we have done to contain it, what we are doing next, and who at Aslynx you can talk to.
• We help you meet your obligations — to the Privacy Commissioner, to your regulator, to your clients, to your insurer — including giving you what you need in writing.
• We will not notify your clients for you, unless you ask us to in writing. They are your clients, it should be your voice, and a vendor appearing in your client's inbox makes a bad day worse.
• We keep records of breaches for the 24 months Canadian law requires, and we will show you the ones that concern you.

Individuals have a right to ask for their information, to have it corrected, and sometimes to have it deleted. Those requests are yours to answer, because you are the one accountable to them.

• If a request reaches us that is really about your workspace, we forward it to you promptly and do not answer it ourselves.
• We help you answer it, with the tools in the product and with us if that is not enough.
• We will not correct or delete something inside your workspace on an individual's word. You decide; you may have a legal obligation to keep the very record they want gone.

Before personal information leaves Quebec, Quebec law requires your firm to assess the transfer. Our object storage is in North America, so for a Quebec firm that assessment is not hypothetical — it applies to using Spirit at all. Where GDPR applies to you, a data protection impact assessment may be required for the same work.

• It is your assessment and we will not pretend otherwise. We do not make it, sign it, or tell you what it should conclude.
• We will give you everything you need to make it: what we process and why, where each subprocessor is, what the security measures are, how long things are kept, and written answers to specific questions.
• Ask and we will fill in your form rather than sending you ours. A questionnaire you have to translate into our vocabulary is not help.
• If your conclusion is that something has to change before you can proceed, tell us what. Some of it we can do.

• We check the demand is valid and that it actually covers what it asks for.
• We tell you before producing anything, unless we are legally forbidden — and then as soon as we are allowed.
• Where we can, we direct the requester to you instead, because the arguments about privilege, relevance and scope are yours to make and not ours.
• We produce the narrowest thing that complies, and we keep a record of what we produced.

Worth knowing for a law firm: because of §6, for most demands the truthful answer is that we hold no readable access to the content being asked for. That is a better position for your client than any clause.

Once a year, on request, we will answer a written security questionnaire and give you our current description of the measures in Annex C. We would rather do this properly than pretend to hold a certification we do not: Spirit has not been SOC 2 or ISO 27001 audited. If somebody tells you otherwise, they are wrong, and we would like to know who said it.

If you have a specific, documented concern that the questionnaire cannot settle, we will agree a proportionate inspection with you, at your cost, on reasonable notice, and without exposing another customer's data. We will not agree to an open-ended audit right, because at our size that is a commitment we could not honour for everybody.

Annex B says where each provider is. Our own application, database, queue and backups are in Canada; a workspace's files are in a North American object store; the model providers, Stripe and our mail transport process in the United States.

Where information is outside Canada it is subject to the laws of where it is, including lawful access by the authorities there, and no contract removes that. Where GDPR applies to your firm, we will enter into the Standard Contractual Clauses with you on request.

At any time, without asking us: you can export your content and delete any part of it from inside the product. Deleting a workspace purges its files from storage and drops its records.

When your agreement ends: you have 30 days to get everything out. After that we delete your content within a further 30 days.

Four things outlive that, and you should know all four:

• Backups, for up to 14 days from deletion. Backups are nightly and expire on their own schedule; we do not surgically edit them, because a backup somebody has reached into is not a backup.
• Your credit ledger and invoices, archived for six years, because tax law requires us to be able to produce them. They are financial records: amounts, dates and identifiers, with no workspace content in them.
• Operational logs, for 30 days. They record which workspace, Job and run did what and whether it failed, with credentials stripped by a central rule — they do not contain your documents or your results.
• A one-way hash of each account's email address, kept indefinitely so free credits cannot be claimed twice. It cannot be reversed, mailed or matched against anything else, and the product itself has no permission to read the table it is in.

We will confirm deletion in writing if you ask.

For firms whose files are privileged or subject to professional secrecy, which is most of the firms we work with:

• Nothing about using Spirit is a waiver. We are your service provider, handling your files on your instruction, in the way a cloud document system or an outsourced bookkeeper is.
• We do not review your content. There is no quality process, no sampling, and no human reading of your files at Aslynx. §6 is how that is enforced rather than promised.
• Our own staff cannot see privileged material without your invitation, which appears on your roster and can be withdrawn at any moment.
• We will tell you before producing anything under compulsion, so privilege can be asserted by the person entitled to assert it (§11).
• If your law society, your regulator or your insurer needs something specific in writing before you can use Spirit on client files, ask. We would rather write a letter than have you work around us.

Each of these is implemented today. When one changes, this annex changes with it.

Keeping customers apart

• Every table holding workspace data has row-level security forced on in Postgres — including for the table's own owner, so there is no role that quietly bypasses it.
• The workspace a request may touch is bound inside the database transaction from the signed-in session, never from anything the browser sent.
• A test in our build proves that the protection is on for every such table, rather than relying on somebody remembering to add it.

Encryption

• In transit: TLS everywhere, with HSTS so a browser will not downgrade.
• Credentials for your connected systems: AES-256-GCM, with the key held outside the database.
• Files: encrypted at rest by the storage provider, reached only by short-lived signed links scoped to one workspace's own prefix.
• Tokens for invitations, email changes and sign-in: stored hashed, so reading the database does not let somebody finish an action they were never sent.

Separation of our own access

• Five database roles, each with its own password and its own grants: the product, our console, the retention engine, the setup assistant, and migrations.
• Our console is read-only over customer data with one exception — adding a row to a credit ledger — and cannot read workspace content.
• The retention engine's read permissions are granted column by column: counts, statuses and timestamps only.
• The setup assistant's role has no permissions at all on customer data.
• Our console requires a password and a time-based one-time code, and runs on its own hostname so it shares no origin or cookie with anything public.

Controls on what Spirit can do

• A connection is read-only until you change it.
• A Job can reach only the connections you grant it — a Job with nothing granted gets nothing, rather than everything.
• Writes into your systems can be gated on a person's approval, with the exact payload shown as a form built from the action's own schema rather than as raw JSON.
• Documents are treated as data and never as instructions: inputs are wrapped in per-run markers and the model is told that only your Job's rules are authoritative, so a document that contains “ignore your instructions and…” does not get to drive a run.
• Outbound requests pass an SSRF guard that refuses internal and private addresses.
• The model never handles file bytes. It names a label or a path, and the server performs the copy or move. A 200MB scan it could never read is filed by the same code path as a 40KB receipt.
• Every file placed, split, moved or written is recorded as a row and shown on the run, so a claim about what happened can be checked against what happened.

Operations

• Nightly database backups, kept 14 days.
• Rate limits on the paths that cost money, and per-workspace caps on spend.
• Credentials and keys held in the environment, outside the database and outside source control.
• A pre-production adversarial security review has been carried out and its findings tracked; the open items are recorded as decisions rather than left as surprises.

The liability limits in “Limits on what we owe” in the terms of use apply here too, including to a breach of this agreement. We are not going to dress that up: the obligations in this document are real, and the money a court could order us to pay for breaking them is capped at what you paid us in the preceding 12 months. If your firm needs a higher limit, ask us before you start and we will put it in a signed agreement.

Where this agreement and the terms of use disagree about handling personal information, this one wins. On commercial matters, the terms of use win. A signed agreement with your firm beats both.

If we change this agreement in a way that materially reduces your protection, we email workspace owners at least 30 days before it takes effect.