TRUST

Privacy

What we hold, where it goes, how long it stays, and what happens when somebody asks for it to be removed.

The data map is derived, not written

Every process declares its fields, each with a data classification and — for anything classified restricted — a reason it is collected at all. The map of what a workspace holds is computed from the published version of each process rather than maintained by hand, so it cannot drift from what the system actually does.

It also traces where each value goes: which emails quote it, which documents contain it, which webhook payloads carry it off the platform. On the reference onboarding process one field reaches eleven destinations, one of which leaves the platform entirely.

A workspace member with reporting permission can run it against their own workspace. Somebody without is refused.

The compiler refuses some things outright

  • A restricted field in an email body, a webhook payload, or a document that leaves the platform is a compile error, not a warning. The process does not publish.
  • A restricted field with no stated reason for collecting it is a compile error.
  • Every process declares the highest data class it may hold. A field above that ceiling is a compile error — so a health-adjacent field cannot arrive by accident inside a routine form.

Retention comes from the published process

  • The period is read from the published blueprint, so nobody deletes faster than the process promised.
  • It runs from completion. A record still in progress is never touched.
  • The account of what was removed is written before the deletion, in the same transaction — so the record of what happened outlives the data.
  • A dry run executes the whole thing and rolls it back, which is the only honest way to answer “what would this delete?”
  • A process that declares no retention period is kept indefinitely, and the data map says so in plain words rather than leaving a blank.

Erasure distinguishes a subject from a mention

Somebody can be the subject of a record — it is about them — or merely mentioned in one, as the manager who approved it. Erasing a subject removes the record and its history. Erasing a mention redacts the value in place, so the audit trail still shows that a manager was asked and answered, without naming them.

A record still running is left alone, and the request says so. Erasure requires administrative permission; an operator is refused.

Erasure is per workspace. A person in two workspaces needs two requests — correctly, since the controllers are different — and there is no way for them to discover that.

What reaches a model, exactly

Designing a process sends the description somebody typed. That is business text, not anybody’s personal data.

The operational copilot sends the schema — state names, field names and labels, task and approval names. It does not send a single answer. The model produces a typed query plan; a deterministic compiler resolves that plan and runs the query. The model never sees the rows that come back.

That is the reason the plan language exists rather than a convenience: the records being queried contain free text that respondents typed, so anything that fed them to a model would be feeding it attacker-controlled input on every question.

Nothing is sent to any model provider unless a key is configured. With none set, both features are unavailable and say so.

The full list of who processes what is on the subprocessors page.

What is not met

Named rather than implied.

  • Privacy terms are not written.
  • No data protection impact assessment. Compliance depends on controls, practice, contracts, evidence, training and audits — not on a feature list.
  • AI interaction logs have no retention period. They are kept indefinitely.
  • No subject access export. A member can export a record they can see; a data subject asking what is held about them has no self-serve route.
  • No consent capture or withdrawal. Where a controller relies on consent, a process has nowhere to record that it was given.

Back to the overview