Validation and Review Decisions
Each checkpoint answers a different question about a policy. A successful earlier checkpoint does not guarantee success at the next one.
Checkpoint Meanings
The following table explains what each checkpoint establishes and what to verify next:
| Checkpoint | What It Establishes | What Remains to Check |
|---|---|---|
| Save | Retain accepted authored input as a draft snapshot. | Resolve incomplete or invalid work before submission. |
| Preview | Inspect target-specific compilation output for the supplied input. | Save the intended content and validate its current context. |
| Saved validation | Check the latest saved draft for an authorized reviewer. | Correct blocking findings or review conflicts that permit acknowledgement. |
| Submit | Accept eligible current draft work into review. | Obtain the authorized review decision. |
| Approve | Commit the reviewed governed revision and queue delivery. | Verify publication and target-specific protection evidence. |
| Publication | Deliver generated configuration to the receiving product. | Follow the Data or Guardrails verification guide. |
Blocking and Reviewable Findings
Some findings require correction before the operation can continue. Other findings permit an explicitly recorded review acknowledgement. An acknowledgement records an authorized acceptance of a specifically reviewable finding. It does not suppress validation, widen permissions, or override a blocking finding. Use the returned conflict identifiers and the current operation contract. Do not acknowledge every finding merely to make a request succeed.
Review notes explain an approval. A request-changes reason explains what the author must correct. Neither text field replaces a missing capability or stale concurrency token.
Fresh Validation and Stale Work
Current dependencies can change after a preview or earlier save. That context includes discovered locations, identity metadata, and current native target inventory. Submission and approval therefore validate current inputs and governed context. A reviewer must load the submitted draft and its current validation results before approving.
If a command reports changed work, refresh the policy and review the new content. Do not blindly replace the token and replay a consequential decision. Refer to API error handling.
Diagnostics and Escalation
An error can provide a support reference without disclosing restricted diagnostics. An ordinary author may need an authorized operator to inspect that reference. Record the operation, policy identifier, time, and safe error details. Never include access tokens or sensitive payload values in a support request. The reference identifies retained evidence. It neither contains that evidence nor grants permission to read it.
Refer to diagnostics for evidence collection and access boundaries. Continue with lifecycle and governance.
Feedback
Was this page helpful?