Choose your reading route
eduKateSG · Why Mathematics? · Markov Reward Models for Reliability and Performability: Availability, Capacity, Cost and Mission Accomplishment
Start with the question, audit the worked example, or jump to the assumptions and practice. Every chapter stays open for uninterrupted reading.
Understand the question
Define the quantity and follow the mechanism.Route 2 · Chapters 6–10
Reproduce the example
Audit the numbers one step at a time.Route 3 · Chapters 11–15
Check assumptions
See where design and calibration matter.Route 4 · Chapters 16–20
Explore applications
Connect the method to a concrete investigation.Route 5 · Chapters 21–25
Study and verify
Practise, inspect failure cases and read further.
Full chapter index · Practice and checking · Mathematics Learning Hub
Why mathematics is important becomes visible when a system is not simply working or failed. A degraded system may still deliver reduced capacity, lower safety margin or slower service. A Markov reward model attaches a value, capacity, cost or success indicator to each stochastic state, then combines state probabilities with those rewards through time.
This guide develops instantaneous and cumulative rewards, availability as a special case, throughput, downtime cost, transition rewards and performability. It shows how one state model can answer several questions by changing the reward definition. It also explains the limits: rewards encode human choices, Markov timing may be unrealistic, and an expected score can hide a small probability of severe loss.
Full chapter index
Chapters 1–5 · Understand the question
Chapters 6–10 · Reproduce the example
Chapters 11–15 · Check assumptions
Chapters 16–20 · Explore applications
Chapters 21–25 · Study and verify
CHAPTER 1 OF 25 · Understand the question
1. Why binary reliability can be too coarse
A system with two of three processors may deliver useful but reduced service. Calling every degraded state failed discards performance information. This is the central mathematical mechanism in why binary reliability can be too coarse. Write the quantities and assumptions before using software, then reproduce the calculation or geometric argument in a small example. Calling every partial state successful can hide critical limits. Define service levels explicitly. The useful habit is to keep the physical question, the probability model and the numerical method in separate columns so that a correct computation is not mistaken for complete evidence.
Did You Know? A result can be numerically stable and still answer the wrong question if the failure event, denominator or transformation changes. Test one nearby case and predict the direction of change before recalculating. Save inputs, intermediate values and units so a second reader can audit the path.
For practice, turn the example into a sensitivity check. Change one defensible input while holding the others fixed, compare the new result with the original and explain why it moved. Then construct a counterexample in which the shortcut fails. End with two sentences: what the mathematics supports, and what remains uncertain.
Start with the operational question behind underlying markov chain. The base model uses states and transition rates for failure, repair or reconfiguration. In the illustrative case, States can represent three, two, one or zero working modules. Draw the relevant graph, density, boundary or timeline before calculating; the picture should use the same variables and sign convention as the equations. Memoryless transition times may not match ageing or scheduled repair. Validate the state process first.
A student should be able to rebuild the result without hidden settings. Record the sampling rule or optimisation criterion, the exact failure definition, and the evidence used for every distribution or parameter. Compare a transparent baseline with the advanced method. If they disagree, investigate the mechanism before deciding which answer is more credible.
This chapter belongs to a larger decision, so translate the number carefully. State one action the evidence permits and one action it does not. A parent or educator can ask which school ideas are doing the work: algebra organises relationships, probability represents uncertainty, calculus describes local change, and computing repeats the documented rules at scale.
Treat state reward rates as a model-checking problem rather than a vocabulary exercise. Assign each state i a reward rate r_i such as capacity per hour, availability indicator or cost rate. Full service may earn 1, degraded service 0.6 and failed service 0. Recompute the example from the raw values and label every unit. Reward numbers are modelling choices, not physical constants. Document units and rationale.
The strongest check uses evidence the model did not choose for itself. Hold out later observations, an independent simulation set or a known-answer benchmark. Report errors where decisions are sensitive, especially near the failure boundary, instead of relying on one global accuracy score. A method that performs well on easy safe cases can still fail at the rare cases that motivated the analysis.
Now change one assumption and make a directional prediction before running the calculation. If the result moves the opposite way, inspect the sign convention, transformation, density ratio or constraint. This prediction-first routine develops transferable problem-solving skills because it connects symbolic work to a testable expectation.
The mathematics of instantaneous expected reward becomes useful only when its mechanism is explicit. At time t, expected reward rate is sum_i p_i(t)r_i. Consider the worked illustration: If state probabilities are 0.8,0.15,0.05 and rewards 1,0.5,0, the expected rate is 0.875. Preserve the original inputs, calculate step by step and compare with a second method whenever an analytic or high-budget reference exists. The mean hides the distribution across states. Report critical-state probabilities too.
There are three uncertainties to keep apart. Sampling or numerical uncertainty comes from finite computation. Parameter uncertainty comes from estimating inputs. Model-form uncertainty comes from simplified physics, distributions or dependence. Reducing the first does not automatically reduce the other two. A credible report names all three and shows which one drives the decision.
For a practical investigation, create a small reproducible notebook or spreadsheet with a frozen data sheet, formula sheet, diagnostics sheet and decision note. Another student should be able to change one input and obtain the same update without guessing what the model meant.
Primary source: https://doi.org/10.1109/TC.1980.1675654. Read it for the method and its assumptions; do not transfer its performance claims automatically to another model.
Use cumulative reward to practise sensitivity analysis. Expected cumulative reward to time T integrates the instantaneous expected reward rate from 0 to T. Integrating capacity gives expected delivered work under the model. Before accepting the result, identify the quantity that would change the conclusion most. Interchanging expectation and nonlinear utility needs care. Keep reward definition linear and explicit.
A simple baseline is essential. It reveals whether the advanced method is improving accuracy or only adding complexity. Compare model calls, wall time, uncertainty and failure-mode coverage under one declared budget. Repeat stochastic calculations with several seeds; a favourable single run is not evidence of dependable efficiency.
Students can extend the example by adding correlation, a second failure mode or a modest measurement error. Explain which part of the formula changes and which remains fixed. This exercise shows how mathematics transfers from a clean textbook case to engineering and computing without pretending that the classroom model is a certified design tool.
Build a small counterexample for availability as a reward. Set reward 1 in up states and 0 in down states to recover expected availability at time t. The initial example is: Several degraded states can be counted up or down according to the success criterion. Then create a nearby case where the usual shortcut becomes unreliable. Different thresholds produce different availability. Publish the classification rule.
Counterexamples are positive learning tools. They reveal the conditions that make a method work and help students recognise when a software output deserves a pause. Keep the counterexample small enough to plot or enumerate. Check sign, support, bounds and conservation of probability before adding complexity.
When writing the conclusion, separate a documented fact from an interpretation and from an illustrative scenario. Cite the primary method paper for the factual mechanism, use the local calculation for the illustration, and label any recommendation as conditional on the stated model. This keeps career and engineering advice age-appropriate and honest.
Connect capacity reward to a real decision while protecting the boundary between calculation and judgement. Use actual capacity levels rather than a binary indicator. States with 100, 60 and 0 requests per second receive those rates. First verify the arithmetic, then translate it into an allowed action and an action the evidence does not support. Nominal capacity may not equal user-perceived service. Validate capacity measurements.
The audit should include the original question, input provenance, failure convention, algorithm settings, convergence or stopping rule, and a sensitivity result. For an adaptive method, also preserve the sequence of choices. For an optimisation, preserve every constraint. For Bayesian updating, preserve the prior and observation model. These records turn a result into something another person can challenge and improve.
A final transfer question is useful: where else would the same mathematical idea appear? Density ratios appear in survey correction and machine learning, probabilistic constraints in planning, and conditional probability in medical testing. The context changes, but transparent assumptions and reproducible checks remain valuable.
Negative reward or cost rates can represent downtime, energy or staffing. A failed state may cost $500 per hour while degraded service costs $80 per hour. This is the central mathematical mechanism in cost reward. Write the quantities and assumptions before using software, then reproduce the calculation or geometric argument in a small example. Money values can omit safety and equity consequences. Keep separate dimensions where needed. The useful habit is to keep the physical question, the probability model and the numerical method in separate columns so that a correct computation is not mistaken for complete evidence.
Did You Know? A result can be numerically stable and still answer the wrong question if the failure event, denominator or transformation changes. Test one nearby case and predict the direction of change before recalculating. Save inputs, intermediate values and units so a second reader can audit the path.
For practice, turn the example into a sensitivity check. Change one defensible input while holding the others fixed, compare the new result with the original and explain why it moved. Then construct a counterexample in which the shortcut fails. End with two sentences: what the mathematics supports, and what remains uncertain.
Start with the operational question behind transition rewards. A one-time reward or cost can be attached to a transition such as failure, repair or switchover. In the illustrative case, Each restart may incur a setup cost. Draw the relevant graph, density, boundary or timeline before calculating; the picture should use the same variables and sign convention as the equations. Double counting occurs if the same cost appears in state and transition rewards. Maintain a reward ledger.
A student should be able to rebuild the result without hidden settings. Record the sampling rule or optimisation criterion, the exact failure definition, and the evidence used for every distribution or parameter. Compare a transparent baseline with the advanced method. If they disagree, investigate the mechanism before deciding which answer is more credible.
This chapter belongs to a larger decision, so translate the number carefully. State one action the evidence permits and one action it does not. A parent or educator can ask which school ideas are doing the work: algebra organises relationships, probability represents uncertainty, calculus describes local change, and computing repeats the documented rules at scale.
Treat performability as a model-checking problem rather than a vocabulary exercise. Performability combines stochastic system behaviour with user-oriented accomplishment or performance levels. A mission can end at full, partial or failed accomplishment. Recompute the example from the raw values and label every unit. One scalar performability measure may hide unacceptable outcomes. Report the full level distribution.
The strongest check uses evidence the model did not choose for itself. Hold out later observations, an independent simulation set or a known-answer benchmark. Report errors where decisions are sensitive, especially near the failure boundary, instead of relying on one global accuracy score. A method that performs well on easy safe cases can still fail at the rare cases that motivated the analysis.
Now change one assumption and make a directional prediction before running the calculation. If the result moves the opposite way, inspect the sign convention, transformation, density ratio or constraint. This prediction-first routine develops transferable problem-solving skills because it connects symbolic work to a testable expectation.
The mathematics of mission success rewards becomes useful only when its mechanism is explicit. A terminal reward can represent whether a mission objective was completed. Consider the worked illustration: Landing safely with reduced capability differs from total mission loss. Preserve the original inputs, calculate step by step and compare with a second method whenever an analytic or high-budget reference exists. Reward weights should not substitute for safety constraints. Use hard limits before optimisation.
There are three uncertainties to keep apart. Sampling or numerical uncertainty comes from finite computation. Parameter uncertainty comes from estimating inputs. Model-form uncertainty comes from simplified physics, distributions or dependence. Reducing the first does not automatically reduce the other two. A credible report names all three and shows which one drives the decision.
For a practical investigation, create a small reproducible notebook or spreadsheet with a frozen data sheet, formula sheet, diagnostics sheet and decision note. Another student should be able to change one input and obtain the same update without guessing what the model meant.
Use transient versus steady state to practise sensitivity analysis. Transient rewards describe a finite mission; steady-state rewards describe long-run behaviour when a limiting distribution exists. A two-hour flight should not use infinite-horizon averages blindly. Before accepting the result, identify the quantity that would change the conclusion most. Rare absorbing failure can make steady-state interpretation inappropriate. Match horizon to decision.
A simple baseline is essential. It reveals whether the advanced method is improving accuracy or only adding complexity. Compare model calls, wall time, uncertainty and failure-mode coverage under one declared budget. Repeat stochastic calculations with several seeds; a favourable single run is not evidence of dependable efficiency.
Students can extend the example by adding correlation, a second failure mode or a modest measurement error. Explain which part of the formula changes and which remains fixed. This exercise shows how mathematics transfers from a clean textbook case to engineering and computing without pretending that the classroom model is a certified design tool.
A second primary source is https://doi.org/10.1109/TC.1980.1675609. Compare the problem definition, estimator and validation rather than quoting one result in isolation.
Build a small counterexample for matrix solution. With initial row vector p0 and generator Q, p(t)=p0 exp(Qt). The initial example is: Multiplying p(t) by reward vector r gives expected instantaneous reward. Then create a nearby case where the usual shortcut becomes unreliable. Numerical solvers need probability-conservation checks. Verify against a small analytic chain.
Counterexamples are positive learning tools. They reveal the conditions that make a method work and help students recognise when a software output deserves a pause. Keep the counterexample small enough to plot or enumerate. Check sign, support, bounds and conservation of probability before adding complexity.
When writing the conclusion, separate a documented fact from an interpretation and from an illustrative scenario. Cite the primary method paper for the factual mechanism, use the local calculation for the illustration, and label any recommendation as conditional on the stated model. This keeps career and engineering advice age-appropriate and honest.
Connect uniformization to a real decision while protecting the boundary between calculation and judgement. Uniformization converts a continuous-time chain into a Poisson-weighted discrete transition process for stable computation. Choose a rate at least as large as every exit rate. First verify the arithmetic, then translate it into an allowed action and an action the evidence does not support. Truncation error must be controlled. Report tolerance and tail bound.
The audit should include the original question, input provenance, failure convention, algorithm settings, convergence or stopping rule, and a sensitivity result. For an adaptive method, also preserve the sequence of choices. For an optimisation, preserve every constraint. For Bayesian updating, preserve the prior and observation model. These records turn a result into something another person can challenge and improve.
A final transfer question is useful: where else would the same mathematical idea appear? Density ratios appear in survey correction and machine learning, probabilistic constraints in planning, and conditional probability in medical testing. The context changes, but transparent assumptions and reproducible checks remain valuable.
Differentiate or perturb failure and repair rates to see which transitions drive expected reward. A faster degraded-state repair can improve delivered capacity. This is the central mathematical mechanism in sensitivity to transition rates. Write the quantities and assumptions before using software, then reproduce the calculation or geometric argument in a small example. Local sensitivity does not capture missing states. Combine with structural review. The useful habit is to keep the physical question, the probability model and the numerical method in separate columns so that a correct computation is not mistaken for complete evidence.
Did You Know? A result can be numerically stable and still answer the wrong question if the failure event, denominator or transformation changes. Test one nearby case and predict the direction of change before recalculating. Save inputs, intermediate values and units so a second reader can audit the path.
For practice, turn the example into a sensitivity check. Change one defensible input while holding the others fixed, compare the new result with the original and explain why it moved. Then construct a counterexample in which the shortcut fails. End with two sentences: what the mathematics supports, and what remains uncertain.
Start with the operational question behind sensitivity to rewards. Changing reward weights can alter rankings even when the state process is unchanged. In the illustrative case, Two designs may swap order when capacity and cost weights change. Draw the relevant graph, density, boundary or timeline before calculating; the picture should use the same variables and sign convention as the equations. Hidden value choices can masquerade as technical facts. Show a reward-weight scenario table.
A student should be able to rebuild the result without hidden settings. Record the sampling rule or optimisation criterion, the exact failure definition, and the evidence used for every distribution or parameter. Compare a transparent baseline with the advanced method. If they disagree, investigate the mechanism before deciding which answer is more credible.
This chapter belongs to a larger decision, so translate the number carefully. State one action the evidence permits and one action it does not. A parent or educator can ask which school ideas are doing the work: algebra organises relationships, probability represents uncertainty, calculus describes local change, and computing repeats the documented rules at scale.
Treat distribution, not only mean as a model-checking problem rather than a vocabulary exercise. Two systems can have equal expected reward but different probabilities of catastrophic loss. One design may alternate between perfect and failed while another stays moderately degraded. Recompute the example from the raw values and label every unit. Mean reward alone cannot express risk aversion. Report quantiles or threshold probabilities.
The strongest check uses evidence the model did not choose for itself. Hold out later observations, an independent simulation set or a known-answer benchmark. Report errors where decisions are sensitive, especially near the failure boundary, instead of relying on one global accuracy score. A method that performs well on easy safe cases can still fail at the rare cases that motivated the analysis.
Now change one assumption and make a directional prediction before running the calculation. If the result moves the opposite way, inspect the sign convention, transformation, density ratio or constraint. This prediction-first routine develops transferable problem-solving skills because it connects symbolic work to a testable expectation.
The mathematics of repair and maintenance policies becomes useful only when its mechanism is explicit. Policy choices change transition rates and sometimes rewards. Consider the worked illustration: Prioritising repair of the most capacity-critical module can improve cumulative output. Preserve the original inputs, calculate step by step and compare with a second method whenever an analytic or high-budget reference exists. Optimising expected output may conflict with safety constraints. Apply constraints before policy search.
There are three uncertainties to keep apart. Sampling or numerical uncertainty comes from finite computation. Parameter uncertainty comes from estimating inputs. Model-form uncertainty comes from simplified physics, distributions or dependence. Reducing the first does not automatically reduce the other two. A credible report names all three and shows which one drives the decision.
For a practical investigation, create a small reproducible notebook or spreadsheet with a frozen data sheet, formula sheet, diagnostics sheet and decision note. Another student should be able to change one input and obtain the same update without guessing what the model meant.
Use model validation to practise sensitivity analysis. Compare predicted state occupancy, transitions and delivered performance with independent logs. Observed time in degraded states checks both rates and rewards. Before accepting the result, identify the quantity that would change the conclusion most. Matching average capacity can hide wrong transition sequences. Validate state paths as well as totals.
A simple baseline is essential. It reveals whether the advanced method is improving accuracy or only adding complexity. Compare model calls, wall time, uncertainty and failure-mode coverage under one declared budget. Repeat stochastic calculations with several seeds; a favourable single run is not evidence of dependable efficiency.
Students can extend the example by adding correlation, a second failure mode or a modest measurement error. Explain which part of the formula changes and which remains fixed. This exercise shows how mathematics transfers from a clean textbook case to engineering and computing without pretending that the classroom model is a certified design tool.
Build a small counterexample for practice activity. Build a three-state up/degraded/down chain, assign rewards 1,0.5,0 and calculate expected reward from a supplied probability vector. The initial example is: Change the degraded reward and explain why state probabilities stay fixed. Then create a nearby case where the usual shortcut becomes unreliable. The classroom rates are fictional. Keep process and value layers separate.
Counterexamples are positive learning tools. They reveal the conditions that make a method work and help students recognise when a software output deserves a pause. Keep the counterexample small enough to plot or enumerate. Check sign, support, bounds and conservation of probability before adding complexity.
When writing the conclusion, separate a documented fact from an interpretation and from an illustrative scenario. Cite the primary method paper for the factual mechanism, use the local calculation for the illustration, and label any recommendation as conditional on the stated model. This keeps career and engineering advice age-appropriate and honest.
Connect parent and educator guidance to a real decision while protecting the boundary between calculation and judgement. Markov rewards connect matrices, weighted averages, integrals, state diagrams and decision values. Ask why the same chain can answer availability or cost with different rewards. First verify the arithmetic, then translate it into an allowed action and an action the evidence does not support. A single score should not conceal severe outcomes. Begin with three coloured states.
The audit should include the original question, input provenance, failure convention, algorithm settings, convergence or stopping rule, and a sensitivity result. For an adaptive method, also preserve the sequence of choices. For an optimisation, preserve every constraint. For Bayesian updating, preserve the prior and observation model. These records turn a result into something another person can challenge and improve.
A final transfer question is useful: where else would the same mathematical idea appear? Density ratios appear in survey correction and machine learning, probabilistic constraints in planning, and conditional probability in medical testing. The context changes, but transparent assumptions and reproducible checks remain valuable.
Reward is not necessarily money, expected reward is not guaranteed performance and steady-state results do not automatically apply to finite missions. A reward vector expresses a chosen measure. This is the central mathematical mechanism in common misconceptions. Write the quantities and assumptions before using software, then reproduce the calculation or geometric argument in a small example. Changing rewards does not change transitions unless policy also changes. Separate dynamics and valuation. The useful habit is to keep the physical question, the probability model and the numerical method in separate columns so that a correct computation is not mistaken for complete evidence.
Did You Know? A result can be numerically stable and still answer the wrong question if the failure event, denominator or transformation changes. Test one nearby case and predict the direction of change before recalculating. Save inputs, intermediate values and units so a second reader can audit the path.
For practice, turn the example into a sensitivity check. Change one defensible input while holding the others fixed, compare the new result with the original and explain why it moved. Then construct a counterexample in which the shortcut fails. End with two sentences: what the mathematics supports, and what remains uncertain.
Start with the operational question behind when the model needs extension. Non-Markov durations, continuous performance, history-dependent policies and large state spaces may require semi-Markov, simulation or aggregation methods. In the illustrative case, A repair appointment at a fixed time is not exponential. Draw the relevant graph, density, boundary or timeline before calculating; the picture should use the same variables and sign convention as the equations. State explosion can make exact matrices impractical. Use approximation with error checks.
A student should be able to rebuild the result without hidden settings. Record the sampling rule or optimisation criterion, the exact failure definition, and the evidence used for every distribution or parameter. Compare a transparent baseline with the advanced method. If they disagree, investigate the mechanism before deciding which answer is more credible.
This chapter belongs to a larger decision, so translate the number carefully. State one action the evidence permits and one action it does not. A parent or educator can ask which school ideas are doing the work: algebra organises relationships, probability represents uncertainty, calculus describes local change, and computing repeats the documented rules at scale.
Treat research and next reading as a model-checking problem rather than a vocabulary exercise. Meyer introduced performability for degradable computing systems, and Meyer, Furchtgott and Wu applied it to the SIFT computer. Read capability functions and state modelling together. Recompute the example from the raw values and label every unit. A historical aircraft-computer example does not set modern reward values. Reproduce a three-state reward calculation.
The strongest check uses evidence the model did not choose for itself. Hold out later observations, an independent simulation set or a known-answer benchmark. Report errors where decisions are sensitive, especially near the failure boundary, instead of relying on one global accuracy score. A method that performs well on easy safe cases can still fail at the rare cases that motivated the analysis.
Now change one assumption and make a directional prediction before running the calculation. If the result moves the opposite way, inspect the sign convention, transformation, density ratio or constraint. This prediction-first routine develops transferable problem-solving skills because it connects symbolic work to a testable expectation.
Continue with the Mathematics Learning Hub and the previous reliability article. These links own broader probability ideas and the immediately preceding rare-event geometry.
The mathematics of frequently asked questions becomes useful only when its mechanism is explicit. FAQs should cover state rewards, transition rewards, availability, capacity, cumulative reward, performability, horizons and validation. Consider the worked illustration: Each answer should state units and value choices. Preserve the original inputs, calculate step by step and compare with a second method whenever an analytic or high-budget reference exists. Avoid ranking designs from a hidden reward vector. Publish Q, rewards and horizon.
There are three uncertainties to keep apart. Sampling or numerical uncertainty comes from finite computation. Parameter uncertainty comes from estimating inputs. Model-form uncertainty comes from simplified physics, distributions or dependence. Reducing the first does not automatically reduce the other two. A credible report names all three and shows which one drives the decision.
For a practical investigation, create a small reproducible notebook or spreadsheet with a frozen data sheet, formula sheet, diagnostics sheet and decision note. Another student should be able to change one input and obtain the same update without guessing what the model meant.
Quick answers
What should I calculate first? Start with the estimand or failure event, then a simple baseline.
Does the advanced method guarantee accuracy? No. It needs input, numerical and model checks.
Which school mathematics matters? Algebra, graphs, probability, functions and careful units all contribute.
How can a student practise safely? Use fictional or open benchmark data and preserve every intermediate value.
What makes a career claim responsible? Describe how the mathematics is used without promising admission, salary or employment.
Extended practice laboratory
Practice case 1: Why binary reliability can be too coarse
Setup: Use this chapter’s illustrative case: Calling every degraded state failed discards performance information.
Task: Define service levels explicitly.
Checking target: Calling every partial state successful can hide critical limits.
Practice case 2: Underlying Markov chain
Setup: Use this chapter’s illustrative case: States can represent three, two, one or zero working modules.
Task: Validate the state process first.
Checking target: Memoryless transition times may not match ageing or scheduled repair.
Practice case 3: State reward rates
Setup: Use this chapter’s illustrative case: Full service may earn 1, degraded service 0.6 and failed service 0.
Task: Document units and rationale.
Checking target: Reward numbers are modelling choices, not physical constants.
Practice case 4: Instantaneous expected reward
Setup: Use this chapter’s illustrative case: If state probabilities are 0.8,0.15,0.05 and rewards 1,0.5,0, the expected rate is 0.875.
Task: Report critical-state probabilities too.
Checking target: The mean hides the distribution across states.
Practice case 5: Cumulative reward
Setup: Use this chapter’s illustrative case: Integrating capacity gives expected delivered work under the model.
Task: Keep reward definition linear and explicit.
Checking target: Interchanging expectation and nonlinear utility needs care.
Practice case 6: Availability as a reward
Setup: Use this chapter’s illustrative case: Several degraded states can be counted up or down according to the success criterion.
Task: Publish the classification rule.
Checking target: Different thresholds produce different availability.
Practice case 7: Capacity reward
Setup: Use this chapter’s illustrative case: States with 100, 60 and 0 requests per second receive those rates.
Task: Validate capacity measurements.
Checking target: Nominal capacity may not equal user-perceived service.
Practice case 8: Cost reward
Setup: Use this chapter’s illustrative case: A failed state may cost $500 per hour while degraded service costs $80 per hour.
Task: Keep separate dimensions where needed.
Checking target: Money values can omit safety and equity consequences.
Practice case 9: Transition rewards
Setup: Use this chapter’s illustrative case: Each restart may incur a setup cost.
Task: Maintain a reward ledger.
Checking target: Double counting occurs if the same cost appears in state and transition rewards.
Practice case 10: Performability
Setup: Use this chapter’s illustrative case: A mission can end at full, partial or failed accomplishment.
Task: Report the full level distribution.
Checking target: One scalar performability measure may hide unacceptable outcomes.