An allocation's output looks like a modest table (factor, share, allocated rate, allocated MTBF per element), but it reads as three different documents at once: an arithmetic object with invariants to check, one half of the programme's earliest health gauge, and a requirements set in waiting.
The allocation table and its invariants
| Column | What it is | The check it must pass |
|---|---|---|
| Weight / factor | The method's raw output per element | Traceable to its source (count, prediction, rating sheet, or declared scheme) |
| Share | Normalised weight | Shares at each split sum to 1 |
| Allocated FR | share × parent budget | Children sum exactly to the parent, level by level |
| Allocated MTBF | The same number in human units | Same unit and mission-time conventions as the prediction side |
The conservation check (children sum to parent at every level) is the allocation's equivalent of a balanced ledger, and the first thing to re-verify after any structure edit: an element added after the split carries no budget until its parent's allocation is deliberately re-applied, and a removed element takes its share to the grave unless the level is re-run. The second invariant is coverage: every element that will ever be predicted, tested, or bought against a reliability clause has a budget line and an owner. Gaps here are not rounding errors; they are future contract disputes.
Allocated against predicted
The margin view (allocated versus predicted, per element) is where the allocation earns its keep, and it reads differently than the prediction side of the same comparison: prediction asks "is my estimate credible", allocation asks "is the obligation distributed survivably".
| Question | Where to look |
|---|---|
| Which owners are in trouble? | Elements whose prediction exceeds their budget; the earlier this list exists, the cheaper it is |
| Is the pain distributed sensibly? | Margin per element: uniform squeeze versus one element carrying the whole shortfall |
| Where is hidden slack? | Elements predicting far under budget: candidates for rebalancing or reserve |
| Is the architecture viable at all? | A whole level infeasible after rebalancing → redundancy or target renegotiation, not more allocation |
| Are we comparing honestly? | Same unit, same clock, same mission time on both sides |
Cadence matters more than precision here. The comparison is only alive if it is re-run when either side moves (a refreshed prediction, a structure change, a rebalance), and each divergence is dispositioned as one of exactly four outcomes: rebalance among siblings, redesign the element, restructure the architecture, or renegotiate the target. A margin table without dispositions is a weather report.
From budgets to requirements
The allocation's terminal form is contractual: each budget becomes a requirement ("MTBF shall exceed 83,700 hours under the stated operating conditions") with three attachments that separate a real requirement from a number in a table. Conditions: the unit, clock, environment and mission time the figure is quoted at, inherited verbatim from the allocation's declarations. A verification route: how compliance will be shown at each stage, by prediction during design, by test or demonstration later, by field data eventually, because an unverifiable requirement is a decoration. Traceability: the requirement points back to its element and its parent's budget, so when a rebalance changes the number, the requirement updates rather than forking into competing versions.
Flowed to a supplier, the same package becomes the reliability clause of a subcontract, which is the quiet reason allocation discipline pays for itself: the programme's reliability case ends up standing on requirements whose lineage runs unbroken from the contract's single top number down to every signature on the tree.