Interpret CSM commitments, policies and measurements
Read access to this guidance; editing requires the applicable module, operating view and record permissions.
Understand the model behind the workflows.
Download the original Connected Service Model whitepaper, version 1.0, dated 2 October 2026. Its 25 pages cover principles, conceptual and system models, six domains, relationship semantics, governance and adoption.
The PDF is the original proposed reference baseline. Online guidance includes later implementation clarifications; model recommendations do not establish automatic product enforcement.
CSM connects reusable commitments to operational evidence. A configured target, a predicted impact and a measured result answer different questions and should not be reported interchangeably.
Before you start
Identify the Offering, priority, schedule/timezone, target and measurement scope. Check which policy applies and what record supplies actual evidence. Avoid quoting a service percentage without explaining what it covers.
Steps
- Configure priority-based response/resolution targets and the relevant support schedule on the Offering.
- Validate a representative Incident during and outside support hours, checking actual routing and clock behaviour.
- Keep support hours, expected availability windows and maintenance windows distinct, even when their schedules look similar.
- For Changes, satisfy all applicable required maintenance windows and accumulated blackout restrictions, including documented exception conditions.
- For availability, select the intended CI/Instance/Offering target, committed schedule, Outage evidence and weighting policy.
- Review overlap, open records, missing evidence and propagation limitations before publishing figures.
SLA targets and historical measurements
An Offering target is reusable configuration. An Incident SLA measurement records the timing of one case; documented target/schedule context is fixed when measurement begins. Later configuration edits are not retroactive corrections to earlier measurements. Organisation SLA is separate and can pause when work leaves the organisation's teams.
Recurring schedules include timezone and weekly patterns. The documented business-time calculation does not include a holiday calendar; validate critical coverage expectations with the implementation team.
Availability and evidence
Conceptually, availability is 100 × (committed time minus counted downtime) divided by committed time. Do not invent a percentage when committed time is zero or evidence is incomplete. An Incident is work to restore service; an Outage records observed unavailability/degradation; graph traversal predicts potential consequences.
Documented propagation can include descendant CI Outages for particular CI/Instance targets. Fully aggregated Offering availability across all associated Instances is not established. Overlapping outage intervals may be counted independently, and redundant/quorum descendants are excluded from the documented availability propagation. State these limits when interpreting results.
Expected result
Owners can distinguish the support promise, the operational rule and the evidence-based result, and can explain the scope of a report.
Important behaviour
A planned maintenance window is not automatically an Outage. Potentially impacted Instances are not proof of downtime. A stored calculation-level field or conceptual policy relationship does not by itself establish that every runtime consumer evaluates it.