AI Glossary / AI and machine learning / Advanced
Dependability state model
Definition
A dependability state model represents a system through states such as operational, degraded and failed, together with possible transitions between them. It is used to analyze measures such as availability and reliability, often using a Markov-chain formulation.
What it means
A service can remain available after one component fails if another component takes over. A simple count of component failures therefore does not fully describe the service's behavior. A state model records which combinations of conditions still deliver the required function.
Transitions represent events such as failure, repair or recovery. Their probabilities or rates allow analysts to estimate how the system behaves over time under stated assumptions.
The concept comes from dependability and reliability engineering, not specifically from AI. It can nevertheless be applied to the infrastructure around an AI service. A working server state should not be confused with a guarantee that the model's answers are correct.
How it works
The analyst defines states, marks which meet the service requirement and specifies possible transitions. A continuous-time Markov model commonly uses transition rates and memoryless holding-time assumptions.
Solving the model gives state probabilities over time or, when appropriate, a long-run distribution. Availability can be obtained by summing probabilities of operational states. Reliability concerns uninterrupted successful operation over an interval and requires a corresponding treatment of failure paths.
The state space can grow quickly as components and modes are added. Simplification is often necessary, but omitted common-cause failures or recovery dependencies can make results unrealistically optimistic.
Three practical examples
- An infrastructure team models a primary and backup service with explicit failure and repair states.
- A platform team compares how recovery time affects expected service availability.
- An AI application team distinguishes infrastructure outage, degraded response capacity and normal operation when planning support arrangements.
Think of it this way
Think of a building with several lifts. One broken lift may mean reduced service, while all lifts being unavailable means a different state entirely.
The analogy has limits because numerical predictions require assumptions about failures, repairs and shared causes. Drawing boxes and arrows alone does not supply credible transition rates.
Worked example
A simple repairable two-state calculation
Suppose a fictional service has an operational state and a failed state. Under a constant-rate continuous-time Markov model, let the failure rate be 0.001 per hour and the repair rate be 0.1 per hour.
For this simple model, steady-state availability is the repair rate divided by the sum of failure and repair rates: 0.1 divided by 0.101, approximately 0.9901, or 99.01%.
This is not the probability of having no failure during an arbitrary mission. Under the same constant failure-rate assumption, survival from an initially operational state without failure over 100 hours is exp(-0.001 times 100), approximately 90.48%.
The different answers reflect different questions. A repairable service can be available most of the time while still experiencing interruptions. The figures are invented and rely on a very simplified model, so they are not a forecast for an actual platform.
Illustrative case study
A fictional document-processing company models two redundant servers and predicts strong availability. During review, engineers note that both servers depend on one storage service.
The original state model treated server failures independently and omitted the shared dependency. The team adds the storage failure mode and revises recovery assumptions using operational evidence.
The resulting estimate is less optimistic but more useful for planning. The company also tracks output quality separately, because an operational processing pipeline can still misclassify documents. The case illustrates the importance of the service boundary and the distinction between availability and correctness.
Common misconceptions and mistakes
- Equating availability with uninterrupted reliability: repair can restore availability after a failure.
- Summing the wrong states: operational states must match the declared service requirement.
- Ignoring shared dependencies: redundancy does not remove common-cause failures.
- Treating assumed rates as measured facts: parameter uncertainty should be visible in the analysis.
Business use
Dependability state models support infrastructure design, maintenance planning and service-level analysis. They help teams reason about degraded operation and recovery rather than viewing systems as only perfectly working or permanently broken.
Define the service requirement before drawing the model. Ask where transition rates came from and how sensitive results are to them. Include common dependencies and realistic repair resources. For AI services, pair infrastructure analysis with separate evaluation of model behavior, because these address different dimensions of dependable operation.
People also ask
Is every state model a Markov model?
No. Other state-based formulations can represent different timing assumptions.
Can repairs be included?
Yes. Repair transitions are central to availability models.
Does high availability imply accurate AI output?
No. A service may respond continuously while producing poor answers.
Check your understanding
A system is operational 99% of the time but has several short outages each month. Is that incompatible with high availability?
Answer: No. Availability concerns being operational at the relevant times; uninterrupted reliability is a different measure. Both may matter to users.
Related terms
- Markov Chain
- Availability
- Reliability
- repair rate
- common-cause failure
Learn next
Read availability and reliability. Draw a small service model and explicitly mark which degraded states still satisfy the user-facing requirement.
More in AI and machine learning
- Dense feature - A dense feature is an input whose value is almost always present and meaningful, such as age or order total, as opposed to a sparse feature that is empty or...
- Density-based clustering validation - Density-Based Clustering Validation, or DBCV, is a score for assessing clustering solutions using density-based ideas of connection within groups and...
- Density-based spatial clustering of applications with noise - Density-based spatial clustering of applications with noise, known everywhere by its initials DBSCAN, is a clustering method that groups records packed...
- Dependency network (graphical model) - A dependency network is a probabilistic graphical model that describes each variable through a conditional distribution given selected other variables.
- Depth - Depth is how many layers or levels a model has, counting from input to output, and more depth lets a model build more complicated ideas from simpler ones.
- Description logic - Description logic is a family of formal knowledge-representation languages for describing classes of things, their relationships and individual instances.
Sources
Heimann, Mittal and Trivedi, Availability and Reliability Modeling for Computer Systems: https://scholars.duke.edu/publication/802867. Trivedi, Markov Modeling in Reliability: https://onlinelibrary.wiley.com/doi/abs/10.1002/9781118445112.stat03635. Trivedi and Bobbio, Reliability and Availability Engineering, chapter 9 author slides: https://drupal-s3fs-prod.s3.eu-west-1.amazonaws.com/resources/academic/7916/6115/4922/greenbook-slide-chapter9.pdf. Slides 15–19 read for transition rates, the repairable two-state model, steady availability and exponential sojourns. The Wiley chapter remained inaccessible; the Duke abstract was read. Worked rates are invented and independently checked.
Previous: Dependability Next: Dependency-directed backtracking