Skip to content

Error Budget Register

A tracking artifact — instantiates Tolerance Stack Management

A living ledger that holds the system's total allowable deviation as a shared budget, tracks how much each contributor has drawn, and forces a rebalance when the running total nears the limit.

Allocation on paper decays the moment work begins: a contributor overruns its slice, a change eats into another's margin, a waiver quietly spends budget nobody was watching. Error Budget Register is the persistent artifact that keeps the shared variation budget live — a running account of the total allowable deviation, how much each contributor has actually consumed, and how much remains — so the stack is governed continuously rather than only at design time. Its defining property is temporal: where an allocation sheet decides the split once, the register tracks the burn-down over the life of the system and turns "we're running out of margin" from a late surprise into a metered, visible balance. It is the account into which every consumed tolerance and every granted waiver is posted.

Example

An optical instrument has a total end-to-end wavefront error it must not exceed for its images to resolve — the system's fit limit expressed as an error budget. That budget is subdivided across contributors: the primary mirror figure, the alignment of the secondary, thermal deformation, detector flatness, and so on. The Error Budget Register holds each contributor's allocation and its measured-to-date consumption. Mid-build, the mirror-polishing vendor reports it can only hold about 80% of its allocated figure error; the register immediately shows the running root-summed total crossing an amber threshold with two contributors still unmeasured. Rather than discovering the shortfall at first light, the team sees it on the ledger, invokes the rebalancing rule — reclaiming unused margin from the detector line, which came in better than budgeted — and books the vendor's shortfall as a controlled waiver against the reclaimed slack, not as an untracked erosion.

How it works

The register is a standing account with one row per contributor: allocated share, consumed-to-date, and remaining margin, plus a rolled-up total combined by whatever accumulation rule the system uses. It is posted to continuously — measurements, design changes, and waivers all debit the budget — and it carries thresholds (say, amber at 80%, red at 95% of limit) that trigger action before the limit is breached. Crucially, a waiver is not an approval that disappears; it is an entry that draws down the shared balance, so its cost is visible to everyone who might later need that margin.

Tuning parameters

  • Combination rule — how per-row consumption rolls into the total (linear sum, root-sum-square, or an imported stack result). A conservative roll-up trips early; an aggressive one hides erosion until late.
  • Threshold levels — where amber and red sit relative to the limit. Tight thresholds force early rebalancing but cry wolf; loose ones give little warning.
  • Reserve policy — whether a block of budget is held unallocated as a margin against surprises, and how jealously it's guarded from being spent early.
  • Posting discipline — what events must debit the register (only measurements, or also estimates, changes, and waivers). The looser this is, the more the ledger drifts from reality.
  • Reclamation rule — whether under-consumed margin can be returned to the pool and redistributed, or stays with its original owner.

When it helps, and when it misleads

Its strength is making a shared budget behave like an account instead of a wish: consumption is metered, waivers are charged rather than forgiven, and the rebalancing conversation happens on a threshold rather than at integration. Treating margin as an explicit, spendable error budget — a discipline long standard in optical and pointing-system engineering — is what keeps local teams from treating their allocation as a private entitlement.[1]

It misleads when the ledger is trusted past its inputs: a register rolled up with a root-sum-square total when the contributors are actually correlated will read green while the real stack is red, lending false comfort. It also decays silently if posting discipline lapses — an unrecorded change makes every remaining number a fiction. And it can be gamed, with teams front-loading optimistic "consumed" figures to protect their slice. The discipline is to reconcile the register against measured integration results periodically, and to treat the roll-up's independence assumptions as claims to be checked, not defaults.

How it implements the components

  • variation_budget — it holds the global fit limit as an allocable, drawn-down balance and reports the remaining allowance at any moment.
  • rebalancing_rule — it carries the thresholds and the reclaim/redistribute logic that fire when accumulated consumption approaches the limit.
  • exception_and_waiver_control — it books each waiver as a debit against the shared budget, so a local exception consumes visible margin rather than vanishing as an isolated sign-off.

It does not set the initial split across contributors — that allocation is authored by Variation Budget Allocation Sheet — nor does it measure the integrated error itself, which is the job of Integration Acceptance Test.

Notes

An allocation sheet and a register are easy to conflate but do different jobs across time: the sheet decides the split once, the register tracks the spend continuously. Keeping them distinct is what lets a team re-budget an overrun without re-opening the whole allocation, and lets the allocation be improved without losing the live consumption history.

References

[1] The error budget is standard practice in optics and precision pointing: a total allowable error is subdivided and its consumption tracked so that no contributor's overrun goes unnoticed. The same accounting discipline underlies reliability "error budgets" in other engineering fields. ↩