Summary
Two binding instructions tell the agent to record full-run pre-authorization as a decision_log entry with category: "approval_policy". That value is not in the decision_log schema's category enum, so the checkpoint write is rejected. The instruction cannot be followed as written.
The contradiction
AGENT_GUIDE.md:592 — stated as binding:
Approval is per-gate. An early "go ahead" never covers later gates; explicit full-run pre-authorization must be recorded as a decision_log entry (category: "approval_policy") to count.
skills/meta/checkpoint-protocol.md:148 says the same thing.
schemas/artifacts/decision_log.schema.json enum:
pipeline_selection, provider_selection, renderer_family_selection,
render_runtime_selection, composition_mode, playbook_selection,
fallback_decision, budget_tradeoff, downgrade_approval, music_source,
motion_commitment, concept_selection, voice_selection,
capability_extension, playbook_override, visual_accuracy_check
No approval_policy. write_checkpoint validates the artifact and raises.
Why it matters
The guide makes this the only way pre-authorization counts — "absent that entry, stop at every gate." So an agent whose user says "go ahead, build the whole thing" has three options, all bad:
- Follow the guide, hit a validation error, and lose the checkpoint write.
- Mislabel the decision under an unrelated category that happens to validate.
- Ignore the pre-authorization and stop at every gate, contradicting the user.
Hit during a character-animation run after the user approved the sample and said "build the full 20s." I recorded the authorization in proposal_packet.metadata instead and noted the mismatch, but that is a workaround — the decision does not appear on the board's Decisions rail, which is exactly where an audit would look for it.
Suggested fix
Add approval_policy to the enum in schemas/artifacts/decision_log.schema.json. It is the smaller change and matches what both documents already promise.
If the category is deliberately excluded, then AGENT_GUIDE.md:592 and checkpoint-protocol.md:148 should name the field that is actually meant to carry it, since as written they instruct an operation the schema forbids.
Reproduce
write_checkpoint(..., artifacts={"decision_log": {
"version": "1.0", "project_id": "x",
"decisions": [{"decision_id": "d-001", "stage": "proposal",
"category": "approval_policy", "subject": "Gate policy",
"options_considered": [{"option_id": "a", "label": "a", "score": 1, "reason": "r"}],
"selected": "a", "reason": "user pre-authorized the run"}]}})
→ validation error on decisions[0].category.
Summary
Two binding instructions tell the agent to record full-run pre-authorization as a
decision_logentry withcategory: "approval_policy". That value is not in thedecision_logschema's category enum, so the checkpoint write is rejected. The instruction cannot be followed as written.The contradiction
AGENT_GUIDE.md:592— stated as binding:skills/meta/checkpoint-protocol.md:148says the same thing.schemas/artifacts/decision_log.schema.jsonenum:No
approval_policy.write_checkpointvalidates the artifact and raises.Why it matters
The guide makes this the only way pre-authorization counts — "absent that entry, stop at every gate." So an agent whose user says "go ahead, build the whole thing" has three options, all bad:
Hit during a
character-animationrun after the user approved the sample and said "build the full 20s." I recorded the authorization inproposal_packet.metadatainstead and noted the mismatch, but that is a workaround — the decision does not appear on the board's Decisions rail, which is exactly where an audit would look for it.Suggested fix
Add
approval_policyto the enum inschemas/artifacts/decision_log.schema.json. It is the smaller change and matches what both documents already promise.If the category is deliberately excluded, then
AGENT_GUIDE.md:592andcheckpoint-protocol.md:148should name the field that is actually meant to carry it, since as written they instruct an operation the schema forbids.Reproduce
→ validation error on
decisions[0].category.