Write policies
Reference mutation modes, identity rules, duplicates, conflicts, deletion, schema evolution and the approved policy revisions required for writes.
A write policy defines mutation semantics. Authorization and approval are checked separately. Manage policy proposals and approved revisions in Settings → Write Policies, then bind the appropriate revision to its scope.
For proposal, approval, binding and ongoing management, see Write policies in Workspace management. This page documents the serialized contract.
Fields
| Field | Values or meaning |
|---|---|
contractVersion | 1 |
sourceState | snapshot, delta, append |
mutation | append, replace, upsert, update, delete |
identity | Key list; nullKeys is reject |
duplicates | reject, preserve, last_write_wins |
conflicts | reject, overwrite |
omission | preserve, delete |
emptySnapshot | reject |
relationships | preserve, reject, cascade |
schemaEvolution | reject, create_only, additive, recreate |
partitionEvolution | reject, allow |
retention | Minimum days and explicit physical-delete permission |
compaction | disabled, manual, automatic |
concurrency | reject, destination_managed |
atomicity | row, object, file, run |
invalidRows | reject, quarantine |
Complete policy examples
Append with explicit duplicate rejection:
Open Settings → Write Policies and use the manual policy form. Fill the controls below, then review and validate the proposal before saving. Policy approval and binding remain separate operations.
| UI control | Setting (contract value) |
|---|---|
| Incoming data | New records only |
| Allowed operation | Add records |
| Identity columns | forecast_id, run_id |
| Duplicate input | Reject duplicate input |
| Conflicting values | Reject conflicting records |
| Records missing from a snapshot | Keep records missing from the input |
| Schema changes | Reject schema changes |
| Minimum retention | 30 days |
| Physical deletion | Disabled |
| Concurrent writes | Reject concurrent writes |
| Commit boundary | The entire run |
| Invalid records | Reject invalid records |
Use Edit policy contract as JSON for settings not exposed in the form. The Code tab supplies the complete example contract; supported choices still depend on the destination.
In Settings → Write Policies, ask the assistant:
Prepare a write-policy proposal. Contract version: 1; Source state: append; Mutation: append; Identity / Keys: ["forecast_id", "run_id"]; Identity / Null keys: reject; Duplicates: reject; Conflicts: reject; Omission: preserve; Schema evolution: reject; Retention / Minimum days: 30; Retention / Physical delete: Disabled; Concurrency: reject; Atomicity: run; Invalid rows: reject. Use the actual accessible resources and required enclosing definition. Show the proposed settings and validate them before saving or executing.This request describes the example’s intent; review the generated contract and any required permissions. It does not create missing resources or make an unsupported operation available.
This is a serialized configuration/contract fragment, not a complete UI workflow. Use it only in the enclosing operation or advanced editor described on this page.
{
"contractVersion": 1,
"sourceState": "append",
"mutation": "append",
"identity": { "keys": ["forecast_id", "run_id"], "nullKeys": "reject" },
"duplicates": "reject",
"conflicts": "reject",
"omission": "preserve",
"schemaEvolution": "reject",
"retention": { "minimumDays": 30, "physicalDelete": false },
"concurrency": "reject",
"atomicity": "run",
"invalidRows": "reject"
}Keyed upsert from a delta source:
Open Settings → Write Policies and use the manual policy form. Fill the controls below, then review and validate the proposal before saving. Policy approval and binding remain separate operations.
| UI control | Setting (contract value) |
|---|---|
| Incoming data | Changes since the last read |
| Allowed operation | Add or update by identity |
| Identity columns | account_id |
| Duplicate input | Keep the last duplicate |
| Conflicting values | Allow overwriting matches |
| Records missing from a snapshot | Keep records missing from the input |
| Schema changes | Add new fields |
| Minimum retention | 30 days |
| Physical deletion | Disabled |
| Concurrent writes | Reject concurrent writes |
| Commit boundary | The entire run |
| Invalid records | Quarantine invalid records |
Use Edit policy contract as JSON for settings not exposed in the form. The Code tab supplies the complete example contract; supported choices still depend on the destination.
In Settings → Write Policies, ask the assistant:
Prepare a write-policy proposal. Contract version: 1; Source state: delta; Mutation: upsert; Identity / Keys: ["account_id"]; Duplicates: last_write_wins; Conflicts: overwrite; Omission: preserve; Schema evolution: additive; Retention / Minimum days: 30; Retention / Physical delete: Disabled; Concurrency: reject; Atomicity: run; Invalid rows: quarantine. Use the actual accessible resources and required enclosing definition. Show the proposed settings and validate them before saving or executing.This request describes the example’s intent; review the generated contract and any required permissions. It does not create missing resources or make an unsupported operation available.
This is a serialized configuration/contract fragment, not a complete UI workflow. Use it only in the enclosing operation or advanced editor described on this page.
{
"contractVersion": 1,
"sourceState": "delta",
"mutation": "upsert",
"identity": { "keys": ["account_id"] },
"duplicates": "last_write_wins",
"conflicts": "overwrite",
"omission": "preserve",
"schemaEvolution": "additive",
"retention": { "minimumDays": 30, "physicalDelete": false },
"concurrency": "reject",
"atomicity": "run",
"invalidRows": "quarantine"
}The examples validate as policy contracts; each destination must also support the selected semantics. Approval does not add unsupported backend behavior.
Constraints and approval
- Upsert, update, and delete require identity keys. Duplicate handling other than preserve also requires keys. Keys must be unique.
- Updates, upserts, and replacements explicitly allow overwrite.
- Replace requires snapshot source state and omission-delete; deletion also requires physical-delete permission. A full read is not deletion permission.
- Destructive policy combinations require explicit destructive approval.
- Actor grants include
data:write, plusdata:deleteordata:maintainwhen applicable. Append still requires authorization and a usable policy. - Inherited policies cannot silently change meaning or weaken protected rules.
Policy approval is distinct from approving an individual governed-action request. See Governed actions.