Workflow Policy Layering
Separate operating workflow from policy and authority.
Goal
Turn a messy assistant spec into clear layers:
- workflow;
- authority and boundaries;
- escalation;
- validation.
Workflow
- Extract the workflow
- write the actual operating sequence without policy noise;
- keep it in business or task language.
- Extract authority separately
- list what the assistant may do directly;
- list what requires confirmation;
- list what is forbidden.
- Extract escalation paths
- define what should be handed to a human, another role, or another system;
- make the next step concrete instead of vague refusal.
- Extract validation
- define what should be checked before a response, mutation, recommendation, or delivery is considered complete;
- keep this as a short checklist or gate list.
- Rewrite the spec
- keep workflow in the main skill body;
- keep detailed policy and validation in
references/or clearly named sections; - ensure the assistant does not confuse “can explain” with “can execute”.
- Run a conflict check
- look for steps that assume authority the policy layer does not grant;
- look for policy text that silently changes the workflow;
- fix contradictions before release.
Output Shape
Return:
- workflow layer;
- authority layer;
- escalation layer;
- validation layer;
- open contradictions, if any.
Design Rules
- Do not hide forbidden actions inside workflow prose.
- Do not let validation sprawl into generic QA philosophy.
- Keep escalation concrete and actionable.
- Treat drafts, summaries, and recommendations as different from real execution authority.