markusdowne/detectability-contract
Creates boundary-point validation contracts, defines invariant-based success criteria, and sets up automated verification probes so reliability workflows trigger on objective evidence rather than intuition. Use when designing robust handoff, memory-persistence, or tool-call reliability workflows; when you need to verify handoffs work, check memory persistence, validate tool calls succeeded, or convert vague reliability goals into concrete, testable checks at each boundary point with explicit failure-class mapping (operational vs. critical); or when you want to test your workflow end-to-end, make sure it works, or verify your automation runs correctly using read-back probes and escalation triggers rather than agent confidence. Includes explicit untrusted-content/prompt-injection guardrails for third-party inputs.
96
Quality
90%
Does it follow best practices?
Impact
98%
1.25xAverage score across 9 eval scenarios
task.mdevals/scenario-6/
Workflow Orchestrator Escalation Policy
Problem/Feature Description
An internal workflow orchestration platform runs long-running automation jobs that touch three kinds of external systems: a file storage backend, an in-memory state store, and several REST APIs. When something goes wrong, the platform currently tries the job three times and then marks it as failed — no distinction is made between transient glitches and fundamental data integrity failures that could corrupt downstream state.
The platform team wants to introduce differentiated escalation policies. Some failures should trigger a retry; others should cause the orchestrator to halt the entire run and page on-call; others should force a re-computation of cached state before retrying. They need a documented policy that covers what to do at each type of boundary in their jobs, with enough specificity that the orchestrator developers can implement it as code.
Output Specification
Produce the following files:
contract.md— A detectability contract document with a boundary table covering at least three boundary types: file storage handoff, in-memory state resume, and REST API tool call. For each boundary, the escalation trigger column must specify a precise action policy, not just "escalate" or "alert". The contract should include the invariants and failure classes that feed into each escalation decision.