Scenarios

Five deployment failures.
One missing layer.

Every scenario starts with a change that passed every check. The failure only emerged when it hit production. Legible breaks this pattern at step zero.

01 Transaction infrastructure Payments

Two services both pass canary.
They break each other in production.

The hardest failure class to catch — two independent changes that look clean individually, but interact destructively when they co-deploy.

Without Legible

A payments team raises the retry ceiling on charge-authorization-service from 3 to 5. Simultaneously, dispute-handling-service ships an update assuming authorization emits no more than 3 retry events before escalating. Both pass CI. Both canaries look clean at 1% traffic. At 20% rollout, dispute state machines silently misclassify transactions.

With Legible

Legible generates a behavioral evidence record including retry.ceiling: 5. The dependency registry shows dispute-handling qualified against ≤3. A re-qualification requirement is surfaced before promotion — the deploy is blocked until the downstream team reviews.

How Legible prevents this

Cross-service capability assertion enforcement. Downstream services register the capability assertions they qualified against. When an upstream signed capability changes, Legible identifies affected dependents and requires re-qualification before promotion.

RE-QUALIFICATION REQUIRED Prevented: cascading misclassification of thousands of transactions
02 Multi-team platform Ledger & reconciliation

One transaction chain. Three teams.
No one owns the behavioral contract.

A single end-to-end flow spans multiple services with independent release cadences. The dependency is real — but no single team sees the full chain before deploying.

Without Legible

Team A changes field ordering in an event schema — backward-compatible by their definition. Team B's parser was built against a specific field ordering assumption. Team C depends on Team B's output for ledger entries. Team A ships. Team B emits malformed ledger inputs. Team C reconciles silently with bad data. Discovery: a finance audit two billing cycles later.

With Legible

Legible builds the behavioral dependency graph from telemetry, not docs. When Team A prepares to deploy, Legible surfaces Team B and Team C as downstream dependents with qualification state attached. Team B must re-qualify before Team A's change is promoted. The gate is automated and cannot be missed.

How Legible prevents this

Behavioral lineage with cross-team dependency enforcement. Legible tracks not only who calls whom, but which behavioral version each downstream service qualified against, and enforces that chain at deployment time.

PROMOTION BLOCKED Prevented: 2 billing cycles of corrupted ledger data
03 Monorepo · High-velocity teams Shared infrastructure

A single PR touches 40 services.
No one knows which contracts just changed.

Deployment automation can fan out a monorepo change across dozens of services — but it doesn't tell you which behavioral contracts changed or which dependents need review.

Without Legible

An infrastructure team refactors a shared authentication library used across 40 services. Rollout is mechanically clean: latency and error rates stay healthy. But 6 of the 40 touched services have downstream dependents that qualified against prior auth error codes. Three of those use those codes to decide whether to retry, escalate, or silently fail. Weeks later, a subtle authorization bypass is discovered in a security review.

With Legible

Before deployment starts, Legible computes the behavioral signature delta across every touched service in one pass. It identifies the 6 of 40 services whose downstream consumers qualified against the old behavior, surfaces the exact capability assertions that changed, and scopes re-qualification to only the 3 affected teams. The 34 unaffected services deploy without interruption.

How Legible prevents this

Fan-out behavioral delta computation. Legible computes behavioral change scope across the full set of changed services in one pass, so governance scales with the dependency graph instead of with how much context humans can hold in a large PR.

RE-QUALIFICATION SCOPE: 3 TEAMS Prevented: authorization bypass discovered in security audit weeks post-deploy
04 API governance Platform engineering

The API review approved the change.
No one told the 12 services that qualified against it.

API review captures intent. It does not enforce behavioral continuity across the dependency graph after the review is done.

Without Legible

A platform team changes how payment_method.detach() behaves under a race condition, replacing PM_LOCKED with PM_ACTIVE_SUBSCRIPTION. The change passes rigorous review, is documented in the changelog, and announced in Slack. Eleven of 12 downstream services update their handling. One subscriptions-billing service misses it. Its error mapping now interprets the new code as 'cancel subscription' instead of 'retry later.' The issue surfaces in customer billing complaints.

With Legible

When the review is approved, Legible attaches a signed behavioral evidence record to the API version. The registry automatically identifies all 12 downstream services that qualified against the old behavior. The change cannot be promoted through the twelfth service's dependency graph until re-qualification is complete. The gate does not care whether a Slack message was read.

How Legible prevents this

Evidence-qualified API governance. Human review captures intent. Legible records what the API was proven to do under tested conditions and enforces downstream re-qualification regardless of who read the changelog.

BLOCKED: 1 OF 12 NOT RE-QUALIFIED Prevented: incorrect billing behavior reaching customers
05 Platform & SRE Reliability governance

You have SLO commitments per service.
You don't have proof a deployment will meet them.

SLOs measure outcomes after deployment. Nothing currently enforces that a deployment preserves the assumptions behind them before it ships.

Without Legible

A platform team has strong reliability culture: quarterly reviews, per-service SLOs, centralized incident tooling. An infrastructure team refactors an account identity service — a unified endpoint moves from the critical path of 3 downstream services to 7. No system flags the blast-radius expansion before deployment. The next serious incident degrades 7 services instead of 2.

With Legible

Legible computes the behavioral dependency surface delta for each release — showing exactly how many downstream services are newly on the critical path — and checks whether the deployment preserves the behavioral properties the SLO depends on. Teams make an explicit decision before rollout instead of discovering the expanded impact in the post-mortem.

How Legible prevents this

Deployment-time blast radius computation plus SLO behavioral proof. Legible turns reliability governance from a measurement framework into an enforcement framework by checking structural dependency changes and SLO-supporting execution properties before release.

BLAST RADIUS DELTA: +4 SERVICES Prevented: blast-radius expansion invisible until next major incident

Every one of these happened while the dashboards were green.

Legible is the governance layer that sees what they couldn't.

Start a conversation →