Ground rules per customer
A customer's ground rules determine what AI may do with that customer's data. They sit on one page and are kept in versions: a change creates a new version, and old versions remain visible. Enforcement always reads the newest version.
What the ground rules contain
| Topic | Example |
|---|---|
| Data access | Default setting metrics only; source X may be open |
| Pseudonymisation | Mandatory with real customer data |
| Models | Only Claude Sonnet and Mistral |
| Budget | Maximum credits per period |
| Disposable copies | What a copy may contain: synthetic, shaped to statistics, or real data |
| Local sessions | Off (default) or on |
| Exceptions per table or column | Always hide name columns |
| Guidelines | "Every change to production has a rollback script" |
Customer and source: the strictest wins
Data access is set in two places: in the customer's ground rules and on every source. The source is a ceiling, never a widening. The strictest of the two applies.
| Customer | Source | Effective |
|---|---|---|
| Encrypted values | Open | Encrypted values |
| Open | Metrics only | Metrics only |
| Metrics only | (follows the customer) | Metrics only |
The open setting moreover applies only to sources the ground rules name explicitly. A source that is not named never silently falls back to a wider setting. See data access.
Exceptions per table or column
Per table or column you can be stricter than the rest of the source. A column with names, for example, you set to hide. To get started the platform can make a proposal based on the source's columns. That proposal is a list for a person: nothing is applied until you tick the rules and adopt them.
Guidelines
Guidelines are rules you check afterwards. On creation a work item records which version applied, and afterwards the platform assesses the work item against it. Whatever cannot be checked automatically becomes needs a human. See audit.
If you lower the budget today, it applies today, also for work items already running. The assessment afterwards looks at the version from the start of the work item.
Ground rules per environment
A customer can have several environments, such as development, test, acceptance and production. Different rules can apply per environment: on test an agent may perhaps put real data in a disposable copy, on production not. See environments.
Who changes the ground rules
Changing ground rules requires the permission to manage the customer. Every change is in the audit. In onboarding a new customer, the ground rules are the last of five steps; after that they sit under Ground rules for the customer.
Example
A health insurer starts with these ground rules: all sources on metrics only, pseudonymisation mandatory, only Mistral and Azure OpenAI with EU residency, disposable copies synthetic only, local sessions off. After a month the data team wants to see product codes. The administrator sets the product catalogue source to open and names it in the ground rules. That becomes version 2. The source with policyholders stays on metrics only, and the name columns are set to hide as an exception.