Published September 1, 2026.
An exception log prevents small publishing problems from becoming invisible habits. It should capture enough evidence to support a decision without becoming a second project-management system.
Record the failing expectation
Name the route or artifact, the expected condition, the observed result, and the time of observation. Attach a validator excerpt or response detail when it helps another operator reproduce the issue.
Assign a decision owner
The person who discovers a problem is not always authorized to resolve it. Assign the next action to the role that owns the affected boundary: editorial claims, technical release, accessibility, or deployment reconciliation.
| Field | Example purpose | | --- | --- | | Severity | Distinguish release stop from follow-up | | Evidence | Make the observation reproducible | | Owner | Identify who can decide | | Next check | Define a bounded retry condition | | Resolution | Preserve the final outcome |
Close with evidence
Do not close an exception because work was attempted. Repeat the failed acceptance check and save the new result. If the dependency remains external, name the unblock owner and action rather than reporting a vague delay.
Use the publishing failure recovery playbook for release incidents and the daily change log for successful changes.
Frequently asked questions
Should warnings stop a release?
Only warnings tied to explicit release requirements, accuracy, identity, access, or safety should automatically stop it. Record the policy used.
When should an exception be reopened?
Reopen it when the acceptance condition fails again or new evidence shows the resolution was incomplete.
