Name: markusdowne/detectability-contract
Rating: 96.4 (1 reviews)
Author: markusdowne

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.

1.25x

Quality

90%

Does it follow best practices?

Impact

98%

1.25x

Average score across 9 eval scenarios

Securityby

Passed

No known issues

Evaluation results

100%

Build a Reliability Detectability Contract

boundary contract generation

Criteria

Without context

With context

Contract table exists

100%

Invariant specificity

100%

Failure mapping

100%

Unknown state handling

100%

90%

36%

Data Pipeline Reliability Contract

File handoff contract

Criteria

Without context

With context

Boundary identification

100%

Artifact exists invariant

100%

Schema valid invariant

100%

Table format

100%

Failure class mapping

100%

Escalation trigger defined

100%

Verification probe defined

100%

Path exists assert

100%

Schema parse check

100%

Missing file as critical

100%

Retry-then-halt escalation

100%

28%

Conversation Context Persistence Contract

Memory resume verification

Criteria

Without context

With context

Memory resume boundary

100%

Key exists invariant

100%

Timestamp freshness invariant

100%

Value deserialises invariant

100%

Table columns present

100%

Stale entry as operational

100%

Missing key as critical

100%

Re-computation escalation

100%

Timestamp check in script

100%

Objective checks only

100%

Non-null probe

100%

32%

Payment API Integration Reliability Contract

Tool call reliability contract

Criteria

Without context

With context

Tool call boundary named

100%

HTTP status invariant

100%

Required fields invariant

100%

Re-fetch probe

100%

Required keys validation probe

100%

Non-2xx as operational

44%

100%

Missing fields as critical

44%

100%

Two-failure escalation

100%

Table format correct

50%

100%

Script field validation

100%

Unknown state as operational

87%

100%

Non-zero exit on failure

100%

26%

Automated Deployment Pipeline Contract

Multi-boundary workflow contract

Criteria

Without context

With context

Multiple boundary types

100%

Five-column table

100%

Invariants for each boundary

100%

Probes for each boundary

100%

Failure class for each boundary

100%

Escalation trigger for each boundary

100%

Artifact exists invariant used

100%

Timestamp freshness invariant used

100%

Checksum or hash invariant used

100%

Critical vs operational distinction

100%

Final report boundary included

100%

Resume/readiness boundary included

100%

93%

36%

Workflow Orchestrator Escalation Policy

Escalation trigger design

Criteria

Without context

With context

File handoff escalation

75%

83%

Memory resume escalation

100%

API call escalation

33%

58%

Five-column table

100%

Critical vs operational

20%

100%

Critical triggers halt

80%

100%

Operational triggers retry

80%

100%

Missing evidence = operational

90%

100%

Invariants in table

57%

100%

Probes in table

28%

100%

Automated Stage-Gate Verification Script

Invariant check implementation

Criteria

Without context

With context

Path exists check

100%

Non-empty check

100%

JSON parse check

100%

Timestamp freshness check

100%

SHA-256 checksum

100%

Exit code on failure

100%

Per-check output

100%

Conditional timestamp check

100%

Contract table present

100%

Failure message specificity

100%

Assert pattern or equivalent

100%

Monitoring Alert Modernisation

Objective vs confidence triggers

Criteria

Without context

With context

Objective triggers only

100%

No confidence-based trigger

100%

Unverifiable state classified

100%

File write boundary trigger

100%

API integration boundary trigger

100%

Cache freshness boundary trigger

100%

Failure classification present

100%

Design principle documented

100%

Unknown state principle documented

100%

Five-column table

100%

14%

State Machine Failure Classification Scheme

Failure classification mapping

Criteria

Without context

With context

Missing artifact as critical

100%

Bad schema as operational

100%

Stale timestamp as operational

100%

Non-2xx as operational

100%

Missing fields as critical

100%

Unknown state as operational minimum

100%

Five-column table

50%

100%

Four boundary types

100%

Critical halt escalation

100%

Operational retry escalation

100%

Taxonomy completeness

100%

Evaluated: 27 days ago
Agent: Claude Code
Model: Claude Sonnet 4.6

Table of Contents

Build a Reliability Detectability Contract Data Pipeline Reliability Contract Conversation Context Persistence Contract Payment API Integration Reliability Contract Automated Deployment Pipeline Contract Workflow Orchestrator Escalation Policy Automated Stage-Gate Verification Script Monitoring Alert Modernisation State Machine Failure Classification Scheme