Tileward / DPA
Data processing addendum

The processor terms — and where they stop applying.

A DPA governs what a processor may do with personal data it holds. On the hosted API we hold it and these terms matter. In a VPC or air-gapped deployment we never receive it, so most of what follows has nothing to attach to.

Roles

Who is the controller, and of what.

DeploymentCustomer contentAccount, billing and licensing data
Hosted APITileward is the processor. You are the controller, or a processor for your own customer.Tileward is the controller.
Your VPCNo Tileward processing. The content, the context store and the audit records stay in your account. On committed-use billing, an aggregate usage count only — see below.Tileward is the controller.
On-prem, air-gappedNo Tileward processing, and no network path by which there could be.Tileward is the controller.

So for two of the three modes, the operative sections of this addendum are Annex I's description of account data and not much else. If you are self-hosting and being handed a full processor addendum to sign, most of it is describing something that does not happen.

On usage counting

Committed-use Enterprise billing reports an aggregate count, not a log: seats active, tokens sent, tokens received from the model, and the number of tiles actively used since the last report, rolled up for the billing period. It carries no prompt, completion or document content, no tile names or configuration, and no per-user or per-request detail — which is why it falls outside the personal-data processing this addendum governs. See the privacy policy for the same description.

// the entire body of a committed-use usage report — every field it contains
{
  "period_start": "2026-07-01",
  "period_end": "2026-07-31",
  "seats_active": 14,
  "tokens_sent": 4820193,
  "tokens_received": 1902744,
  "tiles_active": 6
}

That is the whole payload. No account identifier beyond whatever the billing connection already carries, no tile names, no user identifiers, no request or session ids — six numbers and a date range.

Annex I

What is processed, and why.

The description a processor addendum has to contain. This is for the hosted service; in the other two modes there is nothing to describe.

ItemDetail
Subject matterProviding governed inference: running a model, storing and retrieving conversation context, classifying requests against a topic policy, and recording the decision.
DurationFor the term of the customer's subscription, plus the retention windows in the privacy policy.
Nature and purposeStorage, retrieval, classification and generation, on the customer's instructions, for the customer's own purposes.
Categories of data subjectThe customer's staff who hold seats and keys; and any individual whose personal data the customer chooses to put into a prompt, a stored document or a conversation.
Categories of personal dataAccount identifiers for seat holders. Beyond that, whatever the customer sends — Tileward does not control it and cannot enumerate it in advance.
Special category dataNot something Tileward designs for or screens for. If a customer puts health, biometric, religious, political or similarly sensitive content into a prompt, a stored document or a conversation, Tileward processes it the same as any other content — same limitation as the row above, and no Art. 9-specific safeguard beyond what already applies to personal data generally.
Obligations

What a processor has to commit to.

Acting only on instructions

Tileward processes customer content only to provide the service and only as the customer instructs, unless the law requires otherwise. Using the service is the instruction; a documented change to it is a change to the instruction.

Confidentiality of personnel

Anyone at Tileward with access is bound to confidentiality.

Security measures

The technical and organisational measures are described on the security page, which stands as Annex II.

Sub-processors

Listed on the sub-processor page, which stands as Annex III.

No training, ever

Tileward does not use customer content (prompts, stored context, documents or audit records) to train, fine-tune or evaluate any model, in aggregate or de-identified form or otherwise. This is a description of the business, not a toggle: Tileward compresses and governs models trained elsewhere, and does not build or improve models on customer data. You can read the same commitment in same words as the privacy policy.

The hard cases

Two clauses that got a decision instead of a template.

Standard wording exists for both, and neither uses it: each is decided below in words specific to how Tileward actually operates, because these are the clauses a customer will actually test.

Data subject requests versus the audit trail

Tileward assists the customer in responding to access, correction, deletion and portability requests. The complication is Governance: an audit record exists to prove what was refused and when, and deleting one on request destroys the artifact the customer bought it for. Resolved by not treating them the same way: closing an account is immediate and irreversible for content — access ends, keys are revoked, and everything the customer's tiles and Tileward Context hold is deleted in the same transaction, no grace period. Audit records are not part of that deletion at all; they run out the same per-plan retention window as any live account and expire on that schedule, exactly as described under Return and deletion below.

Breach notification

If Tileward becomes aware of a breach affecting customer content, we notify the customer without undue delay, by email to the account or security contact on file, with what is known at the time — the nature of the incident, the customer data affected so far as we can tell, and what is being done about it — and we update that notice as the picture gets clearer. There is deliberately no fixed hour or day count attached to "without undue delay": the commitment is to tell you as soon as we reasonably can, not to hold the news until every fact is confirmed.

Transfers, deletion, precedence

The rest of it.

Return and deletion. Before terminating, the customer can export audit records as CSV or JSON, or through webhook or SIEM export where the plan includes it. On termination the account is marked deleted and locked out at once, and in that same transaction every tile created privately for the customer and everything Tileward Context holds for the account is erased in full — immediately, with no grace period. Audit records are unaffected by termination itself: they continue to age out under the per-plan retention window in the privacy policy, open account or closed.

Precedence. Where this addendum and the terms of service conflict on the processing of personal data, this addendum governs.

Signature. There is none, and that is intentional. When counsel has a version they are happy with, it becomes a document that gets signed alongside an order form — not a web page.