🚧 Expanding soon — full Standing Orders governance documentation is in progress.
Standing orders as governance
Standing orders are covered in the Getting Started guide from a usage perspective. This page covers the governance layer: how orders are evaluated, how conflicts are resolved, and how the Guardian enforces them.
Order evaluation
On every directive execution, the Guardian evaluates:
- Is there an active standing order that covers this action?
- Does the action fall within the allowed scope?
- Does the action exceed any thresholds defined in active orders?
- If
requiresApproval: true, is there an existing approval for this specific action?
If any check fails, the move is queued for approval rather than executed.
Conflict resolution
When two standing orders conflict (one permits, one requires approval), the more restrictive order wins. The conflict is logged and surfaced in the morning brief.
{
"conflict": {
"orderId1": "ord_abc123",
"orderId2": "ord_def456",
"resolution": "most-restrictive",
"note": "Order ord_def456 requires approval for email sends; ord_abc123 permits them. Approval required."
}
}
Order priority
Orders have three priority levels that affect escalation urgency, not restriction level:
"high" — Violations trigger immediate escalation (Slack, email, or both)"medium" — Violations appear in the next morning brief"low" — Violations are logged but not escalated proactively
Order lifecycle
| State | Description |
|---|
active | Currently enforced by Guardian |
paused | Exists but not enforced (useful during setup) |
expired | Past expiresAt date — no longer enforced |
archived | Manually archived — preserved in history |
Audit trail
Every standing order evaluation is logged:
curl -sH "x-bossmode-token: $BOSSMODE_API_TOKEN" \
"https://bossmode.ing/api/pro/audit?type=standing-order-eval&limit=50" | jq
