States and Revisions
A policy can have governed content and an open replacement draft simultaneously. Saving that replacement does not make it the approved policy. Publication and observed protection remain separate from both authoring and approval.
Three Independent Questions
The following table distinguishes the questions answered by draft, governance, and delivery evidence:
| Concern | Question | Relevant Information |
|---|---|---|
| Draft work | What proposal can the author edit or submit? | Inspect draft identity, current snapshot, and draft status. |
| Governance | Which content has completed approval? | Inspect the governed revision and its approval history. |
| Delivery and protection | What happened at the intended targets? | Check the latest operation and the Data observations or Guardrails consumer receipt. |
Before first approval, no governed revision or protection evidence may exist. An empty protection value does not mean protection succeeded or failed. Do not derive these independent concerns from one displayed status.
Drafts and Saved Snapshots
The policy identifier remains stable across its lifecycle. A draft identifies proposed work for that policy. Each successful save creates a retained snapshot of that work. Repeated saves do not create repeated governed revisions. The draft head is its current saved snapshot, not the governed revision. A snapshot records saved content. The draft’s head changes when later work supersedes it.
Submission puts the current proposal into review. A request for changes returns editable work with the reviewer’s reason. The author can correct that proposal and submit it again. Reviewing a draft does not publish its contents.
Governed Revisions and Compilation Minors
Approval creates a governed revision from the exact reviewed draft. It also starts asynchronous delivery work. A later authored replacement must pass through the review workflow again.
Automatic recompilation serves a different purpose. It recompiles approved intent against fresh context without requiring author edits. Changed output creates a compilation minor under the governed revision. Approved intent means the reviewed classifications, principals, methods, and permission selections. A compilation minor changes generated target configuration, not those authored selections. It preserves the original approval identity and leaves open drafts unchanged. Unchanged output creates no compilation minor or publication work.
For example:
- Alex saves and submits a draft. The draft remains proposed work until an authorized approval succeeds.
- Morgan approves the current submission. Policy creates the first governed revision and queues publication.
- A later automatic cycle detects changed compilation output. Policy records a compilation minor and queues new delivery work.
- Alex edits the authored policy. The new draft remains separate from the governed revision and its compilation minors.
Refer to automatic recompilation for scheduling, failures, and observation.
Delivery Generations and Evidence
A deployment generation identifies a particular publication or withdrawal operation. A retry continues retained work for that generation. It does not approve new authored content or substitute a corrected draft. The deployment identifier selects the retained operation. Its generation distinguishes successive publication or withdrawal operations for the policy. Inspect operation history rather than deriving either value from the governed revision number.
For Data protection, verify the expected location scope and positive protection observations. For Federated Guardrails, a consumer receipt records retrieval of the currently generated configuration. A receipt does not prove execution against real traffic or activation by every replica. A policy using both targets needs complete Data observations and the matching Guardrails receipt.
Publication failure does not undo the approval that created the governed revision. Withdrawal can also remain incomplete after an archive request succeeds. Do not treat archive acceptance as completed deprotection.
Concurrency Tokens Identify Different Resources
Application programming interface (API) clients must retain server-issued validators.
An entity tag (ETag) is an opaque validator for one resource version.
Send the exact value, including quotes, in the operation’s required If-Match header.
It is not an authentication token, policy identifier, or interchangeable revision number.
The table identifies each resource’s validator and the distinction API clients must preserve:
| Resource | Validator | Required Distinction |
|---|---|---|
| Current draft | Draft-ETag, supplied as If-Match for draft commands | Re-read after save, submit, or review decisions. |
| Governed policy | Policy ETag for archive | Do not substitute the draft token. |
| Ownership registry | Registry ETag for reconciliation decisions | Do not substitute a policy or draft token. |
The API reference defines each operation’s exact token and error contract. Continue with lifecycle and governance for the author and reviewer tasks.
- ←Previous: Role-Based Access Control and Artificial Intelligence Policies
- Next: Roles and Permissions→
Feedback
Was this page helpful?