Contract and SLA Review¶

Review procedure — instantiates Dependency Exposure

Reads the contracts and service-level agreements behind external providers to expose what is actually guaranteed, what happens on breach, and how little recourse the fine print really leaves.

The Contract and SLA Review exposes external dependencies through a specific and often-ignored evidence source: the legal and service terms that govern them. Every outsourced service rests on a document that already states — in writing — what the provider must deliver, what it owes you when it fails, how much notice it must give before it walks, and what it is quietly not on the hook for. This review's distinguishing move is to treat that paperwork as a dependency map hiding in plain sight, and to convert its clauses into two concrete things: the dates you must watch, and the recourse you actually have when the service degrades. It answers "how badly are we exposed to this vendor?" not from architecture but from the contract's own terms.

Example¶

A lending startup routes every transaction through a third-party payment processor and assumes an enterprise "99.9% uptime" SLA means they're covered. The Contract and SLA Review reads the actual document. Three nines, it notes, permits roughly 43 minutes of outage a month with no breach at all — and the remedy for exceeding it is a service credit capped at that month's fees, not compensation for the loans they couldn't fund. Buried further down: a termination-for-convenience clause letting the processor exit on 90 days' notice, an auto-renew date the startup would have to cancel 60 days ahead of, and a force-majeure carve-out that excuses the very regional outages most likely to hit.

The review's output is not a renegotiation but exposure: a single dependency, now annotated with what it truly guarantees (little), what happens when it fails (a token credit, then you're on your own), and two calendar dates that must be watched. That is enough to justify standing up a fallback processor before the contract, not an incident, forces the issue.

How it works¶

The review works by mining the contract as documentary evidence rather than interviewing engineers. It reads the service-level clauses for the real guarantee (and its measurement window and exclusions), the remedies section for what recourse a failure actually triggers, the term and termination clauses for exit and lock-in, and the notice and renewal dates for the deadlines that must be monitored. Its distinctive contribution is separating the marketing level of assurance from the contractual one — and turning the difference into an explicit picture of what breaks, what you're owed, and when the clock runs out.

Tuning parameters¶

Read depth — headline SLA numbers only, versus the exclusions, measurement windows, and remedy caps that decide what the number is worth. Depth is where the real exposure hides.
Provider coverage — every vendor, or only those on a critical path. Reviewing all is thorough but costly; triaging risks missing a small vendor with an outsized blast radius.
Date-extraction rigor — whether renewal, notice, and price-review dates are pulled into a watched calendar or left in the PDF. Un-surfaced, a lock-in deadline becomes an ambush.
Recourse realism — how skeptically remedies are read. Counting a service credit as "coverage" flatters the exposure; pricing it against your actual loss on an outage tells the truth.

When it helps, and when it misleads¶

Its strength is that contracts are high-confidence written evidence — unlike tacit or inferred dependencies, the terms are stated, dated, and enforceable, so the exposure they reveal is unusually solid. It is the natural mechanism when third-party services define the risk and when exit or lock-in matters as much as uptime.

Its blind spot is that a contract describes the legal relationship, not the operational one: a provider can meet every SLA and still leave you unable to function, and the review sees only what the paper covers, missing the informal reliance, the undocumented integration, the sub-processor the contract never names. Read naïvely, a reassuring SLA number breeds exactly the false confidence the archetype exists to puncture — a service credit is a penalty on the vendor, not insurance for you^[1]. The discipline is to read for exclusions and remedy caps, not headline percentages, and to pair the contractual view with an operational one before calling the dependency understood.

How it implements the components¶

evidence_and_confidence_basis — it grounds each external dependency in written, enforceable contract terms, the highest-confidence evidence class and the one that says exactly what is and isn't guaranteed.
monitoring_signal — it extracts the contractual dates and thresholds (renewal, notice, price review, SLA breach) that become the cues someone must watch going forward.
failure_path_model — it derives the response constraints a failure triggers: what remedy applies, how much notice you get, what recourse remains, and how long you're stuck.

It does not rate and rank providers against each other or design the backup (Vendor Risk Map), trace the physical upstream supply chain (Supply Chain Mapping), or hold owners and status over time (Dependency Registry).

Instantiates: Dependency Exposure — the review operationalizes the archetype where external providers and their terms define the risk.
Sibling mechanisms: Vendor Risk Map · Supply Chain Mapping · Assumption Log · Architecture Dependency Review · Critical Dependency Dashboard · Dependency Graph · Dependency Registry · Dependency Review Workshop · FMEA Dependency Table · Impact Analysis · Software Bill of Materials

Notes¶

The review feeds two siblings directly: the dates it extracts become entries on a Critical Dependency Dashboard, and its provider-by-provider findings populate a Vendor Risk Map. On its own it exposes the terms; it takes those siblings to turn the terms into ongoing governance.

References¶

[1] A service-level agreement sets a promised level of service and a service credit — a partial refund — as the remedy for missing it. The credit is a contractual penalty sized to fees paid, not to the customer's downstream losses, which is why an SLA is a poor proxy for real resilience. ↩