The first rule of reading a prediction comes from the handbook itself: never assume the predicted number represents the field reliability the user will measure. The models are point estimates regressed from historical data under specific conditions; a National Academies review of the method collects case studies where measured-to-predicted ratios ranged from roughly one-half to twelve, and worse in extremes. The number's power is relative, not absolute, and the handbook says so in as many words.
The questions the numbers answer
Read relatively, the prediction answers real questions with real authority:
| Question | Where to look |
|---|---|
| Does the design meet its allocation? | System λ vs the allocated budget, with margin quantified |
| Where is the reliability going? | The Pareto of contributors: boards, then parts, then factors |
| Which design change is worth it? | Delta between predictions of the current and proposed design |
| Is the thermal design adequate? | π_T sensitivity of the hot parts; TJ excursions priced in failures |
| Is the parts policy right? | π_Q leverage: what screening buys, what commercial grades cost |
| Where does redundancy pay? | Blocks whose predicted rates break the availability model downstream |
| Which clock is the number on? | Operating-hour vs calendar MTBF; duty cycle and dormancy declared |
| What happens in year one? | Early-life (first-year) estimates where the model set provides them |
The comparison discipline is what makes these answers trustworthy, and it is worth being precise about why it works. Two predictions run on the same model set, the same environment category, the same quality scale and the same thermal basis carry the same modelling error, so most of that error divides out of the difference between them. That cancellation is a working assumption about shared inputs, not a property of the handbook, and it survives only for the factors the two runs actually share: where the change under study is the environment, the quality grade or the model set, the suspect factor is the one that moved, nothing cancels, and the comparison inherits the handbook's absolute error in full. Inside those limits the discipline is enough, which is why the method outlived its critics: an obsolete model can still rank two architectures correctly, and ranking is what most programme decisions actually need.
What kind of number you are holding
Two subtleties about what kind of number a prediction hands you. First, a handbook rate is a point estimate, but not always the same kind. MIL-HDBK-217F publishes one rate per part and says nothing about its dispersion. Telcordia SR-332 publishes a mean rate and a standard deviation for every part, from which an upper confidence level (UCL) rate is computed at a confidence the analysis states; the standard deviation and the UCL arrived with Issue 2 of the procedure, and 90% remains the level most analyses default to. The distinction bites at roll-up: mean rates add up the tree and UCL rates do not. Dispersions combine in quadrature rather than linearly, on the procedure's assumption that the part-level uncertainties are independent, so an assembly's UCL rate is recomputed from the assembly's own mean and standard deviation; sum the parts' UCL rates instead and the result is a larger, more conservative number wearing a confidence label that is not its own. Second, the constant-rate result deliberately says nothing about the first months of service; where infant mortality matters commercially, warranty exposure, launch-year return rates, the telecom-lineage models provide a separate early-life calculation that estimates the elevated first-year behaviour and the credit earned by burn-in. It answers a different question than the steady-state MTBF, and mature reports quote the two side by side without letting either impersonate the other.
| Kind of rate | Behaviour at roll-up |
|---|---|
| Mean rate | Adds up the tree |
| Upper confidence level (UCL) rate | Does not add: recomputed at each level from that level's own mean and standard deviation |
| Early-life / first-year estimate | Separate calculation; quoted beside the steady state, never instead of it |
Margin against the allocation
One number deserves special respect: the margin against allocation. A prediction that lands over its budget is not a curiosity; it is an early warning with time still on the clock. The response is ordered and familiar: attack the Pareto leaders (cooler, softer-driven, better-screened, or fewer parts), renegotiate the allocation across siblings if one block is structurally hard, or escalate to an architecture change while one is still affordable. The allocation side of the same comparison dispositions that divergence from the other direction.
Quote the margin in the units it was measured in, because the two conventions do not agree. The worked example's box predicts 20.56 f/10⁶ h against a 40,000-hour allocation, and that allocation is a rate budget of λgoal = 10⁶ / 40,000 = 25.0 f/10⁶ h. Measured on the rate, the margin is (25.0 − 20.56) / 25.0 = 0.178, near enough 18%; measured on the MTBF, the same result reads as (48,600 − 40,000) / 40,000 = 0.215, a little over 21%. One box, one budget, two headline percentages, and only the second belongs next to a contractual figure written in hours.
A comfortable margin is a prompt to audit the inputs, not a result to bank. A prediction that clears its allocation by a wide margin has three ordinary explanations before it has a fourth called good design, and all three are input errors that flatter the answer:
| Usual cause of a large margin | What it looks like | The test |
|---|---|---|
| An optimistic environment factor | The whole box predicted in the mildest environment it ever sees, the harsh phases never modelled | Re-run the roll-up at the worst declared phase environment: if the margin disappears, the mission needs segmenting, not celebrating |
| A quality claim the supply chain will not honour | Screening levels assumed in π_Q that procurement has neither specified nor priced | Every part claimed above commercial grade names its screening specification on the parts list, or reverts to the commercial factor |
| A parts list that is missing lines | The prediction's line count short of the released BOM, or the board-level terms (printed wiring assembly, solder connections, connectors) never added | Reconcile line for line against the released BOM, and confirm the roll-up carries its board-level models |
Two smaller checks close the gap. Confirm both sides of the comparison run on the same clock and the same unit, because an operating-hour prediction set against a calendar-hour budget can manufacture a factor of three on its own: the worked example's box moves from 48,600 hours to roughly 147,000 on exactly that change. And treat any part carrying a zero rate as a defect until proven deliberate, because a handful of silent zeros is where a flattering margin usually hides. Only once those come back clean is the margin a property of the design, and then it is worth spending deliberately: rebalance toward a sibling that needs it, buy a cheaper part grade, or hold the difference as reserve against the design changes still ahead.
What a released prediction contains
A prediction becomes a deliverable the moment somebody else has to act on it, and at that point the number is the smallest part of the package. IEEE 1413 exists for this reason: it frames a prediction report around its inputs, assumptions, data sources and uncertainties, so that a reader can judge the estimate instead of trusting it. A released prediction a reviewer cannot re-run from the document in front of them is not a prediction; it is an assertion with a decimal point. Seven things make it re-runnable:
| Part of the deliverable | What it carries | Why a reviewer wants it |
|---|---|---|
| The parts list, with a source per line | Every line: handbook category and subcategory, quantity, quality level, complexity data where the class needs it, and the rung of the data hierarchy its rate came from (own field data, manufacturer, handbook table, or databook), one evidentiary basis per rate | Without provenance per line there is no telling a modelled rate from an asserted one, and no way to catch the same field evidence being counted twice |
| Environment and temperature assumptions | The environment category per mission phase with phase durations, the duty cycle and the clock the result is quoted on, ambient and case temperatures, junction temperatures for the hot parts, and whether each came from the thermal analysis or from a handbook default | These are the largest multipliers in the model: unstated, they leave the result unfalsifiable |
| Quality claims and their evidence | The π_Q claimed for each part class with the procurement evidence behind it: screening specification, source control drawing, or the vendor qualification it rests on | A quality claim with no purchasing behind it is the single most common reason a margin evaporates in production |
| Model set and revision | Which models produced which parts of the tree (MIL-HDBK-217F Notice 2, NSWC-11, a field-data databook), every mixed pedigree declared, the units in force, and any assumption standard applied, such as ANSI/VITA 51.1 for 217F Notice 2 | Two analysts reach two numbers from one design when this line is missing, and a mixed-pedigree roll-up reconciles only when the mix is written down |
| The roll-up by indenture | λ and MTBF at part, board, unit and system level, each level summing to its parent, with the Pareto at each level and the scope decisions stated: redundant groups carried at the effective rate the reliability block diagram computes for them rather than at the sum of their members, one-shot items held on the per-demand side, wear-out items evaluated separately | The Pareto is the actionable half of the analysis, and stated exclusions are what stop a reader assuming the sum covers the whole system |
| Allocated versus predicted | Margin per element against its allocated budget, on the same unit, clock and mission time the allocation was written in | This is the compliance statement the programme actually reads; everything else is the working behind it |
| Date and configuration baseline | The design revision, BOM issue and thermal analysis issue the number was computed from, and the date it was computed | A prediction is only ever true of one configuration: without the baseline nobody can tell whether it still describes the hardware |
The pre-release check
The review that catches errors is short and mostly arithmetic. These are the findings it actually produces:
| Check | The error it catches |
|---|---|
| Add the tree up again | A board total that does not reproduce its own part lines, or boards that do not reproduce the system total: usually a line lost between worksheet and report |
| Count the lines against the released BOM | Missing parts, and the board-level models (printed wiring assembly, solder connections, connectors) left out of the roll-up |
| Look at every zero and every blank rate | An unsupported environment or an unmodelled part class returning a perfect part |
| Check the unit on every imported rate | FIT read as f/10⁶ h or the reverse: a factor of 1,000 in either direction |
| Check the clock on both sides of the comparison | An operating-hour prediction argued against a calendar-hour budget or calendar-hour field data |
| Check the quality evidence for every part above commercial grade | A π_Q the parts list claims and the purchase order does not support |
| Check the hot parts against the current thermal analysis | Junction temperatures left over from the previous design revision |
| Check that no redundant group was summed | Series arithmetic across redundancy, which belongs to the reliability block diagram and not to the roll-up |
| Check the baseline date against the current BOM issue | A correct prediction of a configuration the programme no longer builds |
None of these findings is sophisticated, and that is the point: predictions fail review on bookkeeping far more often than on modelling. Run the list before the report leaves the team, because every item on it is cheaper to find internally than in front of a customer.