States and Revisions

Distinguish draft work, governed revisions, compilation minors, and target-specific delivery evidence.

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:

ConcernQuestionRelevant Information
Draft workWhat proposal can the author edit or submit?Inspect draft identity, current snapshot, and draft status.
GovernanceWhich content has completed approval?Inspect the governed revision and its approval history.
Delivery and protectionWhat 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:

  1. Alex saves and submits a draft. The draft remains proposed work until an authorized approval succeeds.
  2. Morgan approves the current submission. Policy creates the first governed revision and queues publication.
  3. A later automatic cycle detects changed compilation output. Policy records a compilation minor and queues new delivery work.
  4. 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:

ResourceValidatorRequired Distinction
Current draftDraft-ETag, supplied as If-Match for draft commandsRe-read after save, submit, or review decisions.
Governed policyPolicy ETag for archiveDo not substitute the draft token.
Ownership registryRegistry ETag for reconciliation decisionsDo 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.

Last modified : November 03, 2026