Service-Level Definition¶
Service contract — instantiates Functional Specification
Specifies the quality dimension of a service as a measured commitment — the performance or availability range it promises, the signal that measures it, and the threshold that counts as meeting or breaching the promise.
A Service-Level Definition specifies not what a service produces but how well — the quality attribute a functional description leaves out. It states the promised range on a performance or availability dimension (response time, uptime, throughput, accuracy, resolution time), names the signal that measures that dimension in live operation, and fixes the threshold that separates "met" from "breached." Its defining move is binding a promise to a continuously measured metric: the commitment is only as real as the observability behind it, and it is judged statistically over a window rather than pass/failed on a single event. That separates it from a Testable Requirement, which is a discrete check on one specified functional behavior, and from the functional spec of the service itself, which says what the service does at all rather than how well it does it.
Example¶
A B2B software vendor commits, in writing, to its enterprise customers: a priority-1 support ticket will get a first human response within one hour and a resolution within eight business hours, and this will hold for at least 95% of such tickets each month. The measuring signal is the ticketing system's own timestamps — response time and resolution time per ticket, recorded automatically. The threshold is the 95%-per-month objective, and a monthly attainment report shows whether it was met; a breach triggers service credits against the next invoice. Notice what makes this a service-level definition rather than a slogan: the promise is not "we are responsive," but a stated range, a specific instrument that measures it, and a threshold that decides met-or-breached over a defined window. A customer evaluating two vendors can compare them on exactly that number.
How it works¶
The definition picks the quality dimension that matters and states the promised range on it — this is the codomain of the quality attribute, not the functional output. It names the service-level indicator (SLI[1]) that measures that dimension in production, and sets the service-level objective: the threshold and the window over which attainment is judged, which is the acceptance criterion for the promise. Finally it states the consequence of a breach and the cadence at which attainment is reported, so the commitment is accountable rather than aspirational.
Tuning parameters¶
- Target level — how demanding the promised range is (three nines vs. four). Each additional nine of reliability costs disproportionately more to guarantee.
- Measurement window — the period over which attainment is judged. Short windows react fast but are noisy; long windows are stable but slow to flag decline.
- Percentile vs. average — whether the objective is stated on a p95/p99 tail or a mean. Percentiles govern the worst experiences; averages hide them.
- Signal choice — which instrument counts as the measurement, and how close it sits to real user outcomes.
- Breach consequence — how strong the penalty for missing the objective is, which sets how seriously the target is defended.
When it helps, and when it misleads¶
Its strength is that it converts a vague quality promise into a measured, comparable commitment — the basis for accountability between provider and consumer and for comparing vendors against the same expectation. Its central hazard is the proxy: it is far easier to measure a convenient signal (a health-check endpoint's uptime) than the thing customers care about (whether their real requests succeeded), and once the easy metric becomes the target it stops being a good measure — Goodhart's law in action. The commitment is then met on paper while users still suffer. The related misuse is setting a target the organization can clear trivially, or gaming the measurement window. The discipline is to measure user-facing outcomes rather than convenient proxies, and to set the objective where meeting it actually means the service is good.
How it implements the components¶
output_codomain— the promised range on the quality dimension (e.g., "≥99.9% available," "first response within one hour"), which bounds the acceptable output quality rather than its form.observability_signal— the SLI and its instrument that make the dimension continuously visible in production.acceptance_test— the objective's threshold and window, which decide whether the commitment was met or breached over each period.
It commits to a measured quality range but does not define the input_domain or the transformation_rule of the underlying function, nor package a discrete precondition_postcondition_pair check the way Testable Requirement does — its promise is a statistical threshold on a live signal, not a single pass/fail on one specified input.
Related¶
- Instantiates: Functional Specification — it makes a service's quality behavior explicit and measurable.
- Sibling mechanisms: Testable Requirement · API Specification · Model Specification · Input Validation · Policy Implementation Rule · Clinical Protocol Definition · Type Signature · Output Schema · Role Charter
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: Service-Level Definition operates as a standing rule, threshold, contractual commitment, or policy constraint governing future conduct because it specifies the quality dimension of a service as a measured commitment — the performance or availability range it promises, the signal that measures it, and the threshold that counts as meeting or breaching the promise.
Independent corroboration: The frozen evidence defines Service-Level Definition as 'Specifies the quality dimension of a service as a measured commitment — the performance or availability range it promises, the signal that measures it, and the threshold that counts as meeting or breaching the promise', so its operative form is Rule, Policy & Commitment.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: Turning service quality into an owned measurable target and breach threshold is service-management specification practice.
Related originating lineages:
- Engineering & Design — Performance requirements define measurable ranges and verification signals.
- Law & Governance — Contractual definitions determine what counts as compliance or breach.
- Statistics & Experimental Design — Measurement validity and sampling determine whether observed service truly meets the threshold.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: specifies the quality dimension of a service as a measured commitment — the performance or availability range it promises, the signal that measures it, and the threshold that counts….
Review resolution: The blind reviewers agree that organizational_management is the primary origin and differ only on alternate origin disagreement, origin mode disagreement, domain reach disagreement, encyclopedia synthesis disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain cross_disciplinary_synthesis because the combined record shows material contributions from several lineages. The broader reach of universal records portability separately from historical provenance, and encyclopedia_synthesis=true preserves the affirmative synthesis judgment where either reviewer identified one.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (eds.). Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media (2016). Defines an SLI as a quantitative service measure and an SLO as a target value evaluated over a measurement window. registry ↩