Policies
A policy is a rule the platform holds on your behalf: what an identifier must look like, how long data is kept, who may access it and on what terms, what requirements it must meet.
One kind is enforced today. A naming policy is checked on every write, and a create that breaks it is either refused or flagged for review. Naming policies →
The other three are declarative records for now: they document the rule where the data lives, and enforcement is the roadmap part of one of the two building blocks still being built.
Lifecycle, access and requirement policies are recorded, not enforced. Nothing in the platform currently expires data, gates access or checks requirements because a policy says so: retention is a coming feature planned together with policy enforcement, and access comes entirely from groups in your identity provider. Treat what you write as documented intent, and write it as though it will be enforced, because it will be.
Naming policies are the exception, and they are what the rest of policy enforcement is being built out from: naming is checked at the moment of writing, which is far simpler to enforce than a retention sweep or an access decision, so it shipped first.
Why record rules before they are enforced
It sounds backwards, and it is the right order, for the same reason the model comes before the analytics, and for the same reason governance works best attached to the data it governs.
Most organisations keep data rules in procedure documents: a retention schedule in a PDF, an access principle in a policy manual, a regulatory requirement in somebody's head. The rule and the data it governs live in different places, so the rule is invisible exactly where decisions get made.
A recorded policy fixes the visibility problem on its own:
- The rule is findable from the data. Whoever opens the data set sees what governs it, rather than needing to know which document to check.
- Intent survives people. "We keep this for ten years because of obligation X" stops being tribal knowledge, the same argument as for the model itself.
- Enforcement becomes a switch, not a project. When it ships, the rules are already written, reviewed and attached. Organisations that waited will be starting their retention workshops while yours activates.
The four kinds
| Kind | What it records | Enforced |
|---|---|---|
| Naming | What an external id must look like: a preset, or a pattern of your own | Yes, today, on every write |
| Lifecycle | How long data is kept, and what happens when the clock runs out | Once shipped: measurement history actually expires on schedule |
| Access | Who may read or write, and on what terms | Once shipped: gating, aligned with the organization groups that grant access today |
| Requirement | What the data set must satisfy, completeness, standards, review cadence | Once shipped: checks that flag when the requirement is not met |
The naming policy, in short
The one kind that acts rather than documents. It fixes the shape of new external ids, either by preset (verbatim tags, snake_case) or by a pattern you supply, and it runs in one of two modes: reject, where the write fails and nothing is created, or warn, where the write succeeds and a finding goes into a data steward's queue.
Three properties are worth carrying in your head:
- It is set for the tenant, and can be overridden on one data set. The most specific policy wins and replaces the one above it rather than adding to it.
- A near-duplicate guard runs regardless of the preset, refusing
pump-a-01next to an existingpump_a_01anywhere in the tenant. - It does not govern events. An event external id is the source system's key for the subject the event is about, not a name anyone chose, and events are meant to share one.
The full rules, presets and findings queue →
Writing a policy worth having
The test for a good policy is the same as for a good description: a colleague in a year should understand not just the rule but the reason.
"Retain 10 years, NORSOK requirement for well data" beats "retain 10 years". The reason is what lets a successor revisit the rule safely when the obligation changes.
Lifecycle, access and requirement policies live on data sets, so the data set boundary decides what a rule can govern. If one rule must cover two data sets, or half of one, that is a sign the boundaries need a look first. A naming policy is the exception: it is set for the whole tenant, because a rule living on a data set could not govern the naming of the data set itself, and overridden on an individual data set only where a source system's identifiers leave you no choice.
A reported figure can only ever be traced to inputs that still exist, so retention rules on anything feeding a regulated report should outlive the report's auditability. Retention versus traceability →
A quarterly pass over the policies alongside the permission review, so recorded intent tracks reality.
Where they appear
Each data set has a Policies tab in the console, which is where its rules are recorded and read. Data sets →
Warnings raised by a naming policy collect in a findings queue, grouped by policy and by the shape of the mistake rather than listed row by row, and a resource shows its own open findings. The findings queue →
Policies are one of four pieces that carry governance here, alongside the graph, data sets and functions. How the pieces fit →
- Naming and standards: the naming policy in full, presets, modes and findings
- Data governance: the umbrella policies are one piece of
- The roadmap building blocks: policies and functions in the vocabulary
- Data sets: the boundary a policy governs
- Data set permissions: where access actually comes from today
- Data lifecycle: retention, and the expiry feature policies will drive
- Functions: the other roadmap block, computations where policies are rules