EM-TEC-06 · Subject model · W1
Reliability, SLO and observability
SLI specification, SLO target, evaluation window, error budget and reaction rules. Metric definitions and observations are reused from the analytics foundation.
Queued for research
Claude: not-started; Grok: not-started.
Research note, in Russian: Entire research brief pending
Subject boundary and candidate types
- SLISpecification
- SLO
- SLOEvaluation
- ErrorBudgetPolicy
- ObservabilityBinding
Deep research questions
- How to define a useful outcome for the user?
- Where does the SLO live: service, journey, system or instance?
- How to treat telemetry gaps and a window change?
Verifiable invariants
- An SLO specifies an SLI, a target and a window
- No data does not equal met
- SLA and SLO have different grounds
End-to-end acceptance scenario
One user journey across three services, incomplete telemetry and a window change yield a verifiable evaluation and unknown instead of false success.
Negative case
99.9% on a product card with no window and no measurement method is declared proven reliability.
Approaches to compare
- AISMM/WM-SFT and ArchiMate: product, system and architecture
- CSDM: business application, service and runtime instance
- SPDX/OpenTelemetry/Google SRE: delivery, observation and reliability; choose by boundary
Candidates in the live catalogue
- WM-SFT-016 · Service Level / SLO · unversioned · not installed automatically
Semantic fit requires boundary research; a published model does not by itself complete this card.
Result requirements
Every card is executed together with the full research contract: definitions, fields and cardinalities, lifecycle, sources, data mastership, rights, the five object facets, at least eight invariants, positive and negative examples, dependencies, migration and applicability limits.