Allocation in practice is a top-down ritual with a fixed grammar: fix the target, fix the structure, choose the method the data can support, weight honestly, cascade, feasibility-check, release. Each pass is quick; the value is in doing it deliberately and in expecting to do it again.
1. Fix the system-level target
The cascade can only be as good as the number at its top, so the first step is forensic: establish what the target is, where it binds, and in what currency.
| The target comes from | What it converts to |
|---|---|
| A contractual MTBF or failure-rate clause | The rate budget directly; check the clause's clock (operating vs calendar hours) |
| An availability requirement plus a repair concept | λ* = (1/A − 1)/MTTR; write the maintainability assumption down beside the budget |
| Mission-success probability over a defined mission | λ* = −ln(R*)/t at the declared mission time |
| Safety targets on critical functions (from the FHA) | Probability budgets for the specific functions, allocated alongside, not instead of, the basic-reliability budget |
Two disciplines at this step save months later. Declare the unit and the clock once (the same declarations the prediction side makes), because the allocated-versus-predicted comparison dies quietly when the two sides quote different currencies. And where both a basic-reliability target and mission-critical safety targets exist, keep them as separate budget lines: a box can be reliable enough for the logistics case and still too failure-prone for the safety case, and one number cannot police both.
2. Establish the allocation structure
The tree the budget cascades down is not the CAD tree or the cost breakdown; it is the ownership structure: every element on it must have exactly one owner who can sign for a number. Practical consequences: elements are drawn at the boundaries where responsibility changes hands (in-house team, subcontractor, COTS vendor); shared services that several branches depend on, a power bus, a cooling loop, a system computer, get their own budget lines rather than being smeared across their consumers; and the structure is the same one the prediction rolls up, so the two flows meet on identical elements.
| Structuring rule | Why |
|---|---|
| One owner per element | A budget nobody signs is a wish |
| Split at responsibility boundaries | Budgets become flow-down requirements verbatim |
| Shared services are elements | Otherwise their failures are double-counted or orphaned |
| Same spine as prediction | Allocated-vs-predicted must compare identical nodes |
3. Choose the method per level
Method choice is a per-level decision, not a per-programme one, and mixing methods across levels is normal practice, not a compromise: at the system level a prediction may already exist (ARINC), one level down only judgement does (feasibility of objectives), and a consortium boundary may impose a contractual split (weighted factor) regardless of engineering.
| Situation at this level | Sensible method |
|---|---|
| Nothing known yet | Equal apportionment, flagged as provisional |
| Part counts only | Equal failure rate |
| Judgement available, data thin | Feasibility of objectives |
| Duty cycles and criticality differ between children | AGREE |
| Predictions exist for the children | ARINC |
| The split is negotiated or contractual | Weighted factor |
4. Gather the weights honestly
The pipeline is only as honest as its weights. Part counts should come from the current structure, not last quarter's. ARINC weights inherit every defect of the prediction they read; an ARINC allocation over a stale or padded prediction is that garbage, scaled. And ratings deserve process: written ground rules per factor (what earns a 3, what earns an 8), scored independently by more than one engineer where the stakes justify it, reconciled openly, and archived with the allocation, because six months later the question will not be "what is B's share" but "why is B's share 35%", and the ratings sheet is the only good answer.
| Weight source | Honesty check |
|---|---|
| Part counts | From the current BOM revision |
| Predicted rates (ARINC) | Prediction current, same units, same mission time |
| FOO ratings | Written criteria · independent scoring · rationale archived |
| Explicit weights | The scheme's justification written next to the numbers |
5. Apply and cascade
Compute shares, allocate the budget, and hand each child its number as its own goal; then repeat one level down, child by child, until the tree bottoms out. Two boundary rules govern the descent. Stop where design freedom stops: a COTS unit's budget cannot exceed what its datasheet or field history supports, allocating 200,000 hours to a unit whose vendor demonstrates 90,000 is not ambition, it is a feasibility finding waiting to be escalated. And stop at the level where verification will happen: a budget below the level anyone will ever predict, test or measure against is bookkeeping without a customer.
6. Feasibility-check every budget
An allocation that has not been checked against reality is a wish list with arithmetic. Every budget line gets held against the best available evidence (similar-equipment experience, an early parts-count prediction, vendor data), and the failures of that check are the point of the exercise:
| Finding | Response |
|---|---|
| One child's budget is infeasible, siblings have slack | Rebalance: shift rate allowance between siblings, re-run the level |
| The whole level is infeasible | Escalate: the architecture cannot meet the target; redundancy (an RBD decision) or target renegotiation |
| Everything passes comfortably | Suspect the target, then bank the slack as management reserve rather than gifting it |
The reserve point is worth making explicit: mature programmes deliberately allocate slightly tighter than the requirement, holding back a few percent of the rate budget, so that the first surprise consumes reserve instead of reopening every sibling's contract.
7. Release and re-allocate
Budgets earn their keep only when released as formal requirements ("MTBF shall exceed X hours at the stated conditions") flowed to design teams and suppliers, each with a named verification route (early: prediction; later: test, demonstration, or field data). From that moment the allocation is under change control: it gets re-run at design milestones, when the structure changes, when predictions move materially, or when a feasibility finding forces a rebalance, and each re-run updates the existing requirements traceably rather than spawning parallel truths. An allocation last touched at the proposal is not a baseline; it is an artefact.