2. field_llm_judge / create_doc
{
"type": "field_llm_judge",
"tool": "create_doc",
"action_id": "create_release_checklist",
"path": "args",
"criterion": "The body is a concise, actionable operating checklist for lifecycle routine-send release, rather than merely a narrative summary.\n\nThe checklist clearly states that Ines may independently approve and release routine, non-state-changing lifecycle sends without Riley's case-by-case approval.\n\nThe checklist imposes an exact ceiling of no more than three routine lifecycle sends per week.\n\nThe checklist requires every routine, non-state-changing lifecycle send released under Ines's delegated authority to be audited within 24 hours. It need not apply this delegated-lane audit condition to state-changing sends, which are outside Ines's routine release authority.\n\nThe checklist says missing or conflicting required state fails closed, meaning the send must not be released while that condition exists.\n\nFor state-changing sends, the checklist requires both an active-suppression check and a recipient-level merge-alias check during preflight.\n\nThe checklist draws a clear escalation boundary: routine non-state-changing work stays in Ines's lane, while preflight exceptions go to Riley; customer corrections and incident stops remain with Riley, and state-changing, ambiguous, or exception-heavy sends are outside routine release authority and must be escalated rather than released under it.",
"check_id": "riley_060_01"
}Complete grading specification
{
"type": "tool_trace",
"config": {
"check_version": 2,
"today": "2028-01-01",
"semantic_judge_version": 2,
"assertions": [
{
"type": "field_equals",
"tool": "create_doc",
"action_id": "create_release_checklist",
"path": "result.ok",
"value": true,
"check_id": "riley_060_00"
},
{
"type": "field_llm_judge",
"tool": "create_doc",
"action_id": "create_release_checklist",
"path": "args",
"criterion": "The body is a concise, actionable operating checklist for lifecycle routine-send release, rather than merely a narrative summary.\n\nThe checklist clearly states that Ines may independently approve and release routine, non-state-changing lifecycle sends without Riley's case-by-case approval.\n\nThe checklist imposes an exact ceiling of no more than three routine lifecycle sends per week.\n\nThe checklist requires every routine, non-state-changing lifecycle send released under Ines's delegated authority to be audited within 24 hours. It need not apply this delegated-lane audit condition to state-changing sends, which are outside Ines's routine release authority.\n\nThe checklist says missing or conflicting required state fails closed, meaning the send must not be released while that condition exists.\n\nFor state-changing sends, the checklist requires both an active-suppression check and a recipient-level merge-alias check during preflight.\n\nThe checklist draws a clear escalation boundary: routine non-state-changing work stays in Ines's lane, while preflight exceptions go to Riley; customer corrections and incident stops remain with Riley, and state-changing, ambiguous, or exception-heavy sends are outside routine release authority and must be escalated rather than released under it.",
"check_id": "riley_060_01"
}
]
}
}