Mutation Budget Cap¶
Budget constraint — instantiates Adaptive Mutation Rate Management
Sets a hard ceiling on the total amount of variation a system may spend in a window — rationed per unit by its risk — so exploration can never exhaust resources or blast-radius, regardless of what the rate policy wants.
Every rate policy answers "how much variation, per step?" Mutation Budget Cap answers a different question: "how much variation, in total, can we afford before we must stop?" It sets a hard ceiling on the cumulative amount of variation a system may spend within a window — a count of mutations, experiments, injected faults, or compute-hours — and rations that ceiling across units according to each unit's risk. Its defining move is that it bounds the integral, not the rate: whatever a schedule or feedback controller wants to do step by step, the cap is the wall the total spend hits. It is a governor of exposure and expense, letting exploration run freely inside a boundary it can never cross.
Example¶
A site-reliability team runs chaos experiments — deliberately injecting latency and failures into live services to find weaknesses before real outages do. Unbounded, that experimentation could itself cause the incidents it is meant to prevent. So they impose a mutation budget: each service gets a weekly allowance of injected-failure "spend," and every experiment debits it. The allowance is sized by the service's risk profile — a stateless image-resizer with graceful fallbacks gets a generous budget, while the payments ledger gets a near-zero one that requires explicit sign-off to touch at all.
When a team burns through a service's weekly allowance by Thursday, the platform simply refuses further injections against it until the window resets, no matter how promising the next experiment looks. The cap does not care which experiments run or in what order; it only guarantees that total disruption per service, weighted by how much damage that service can do, stays under a line the organization chose in advance. Exploration stays vigorous where it is safe and tightly rationed where it is not.[n1]
How it works¶
- Define the budget unit. Count what variation costs in the terms that bind — mutations attempted, experiments launched, fault-minutes injected, evaluation compute.
- Set a ceiling per window. Allocate a fixed total per time period, subsystem, or campaign.
- Debit on spend. Each act of variation draws down the remaining budget; when it hits zero, further variation is blocked or queued to the next window.
- Ration by risk. Size each unit's allowance from its risk profile, so high-blast-radius units get little rope and safe ones get plenty.
Tuning parameters¶
- Budget size — the total allowance per window. Generous budgets let exploration breathe; tight ones protect resources and safety at the cost of discovery.
- Window length — the period over which the cap applies and resets. Short windows throttle bursts; long windows permit them but risk front-loading.
- Risk-weighted allocation — how sharply a unit's allowance scales with its risk. Steep weighting starves dangerous units; flat weighting treats all alike.
- Refill policy — whether unused budget rolls over or is forfeited. Rollover rewards restraint but permits large saved-up bursts.
- Hard versus soft cap — whether the ceiling blocks outright or merely requires escalation to exceed. Soft caps preserve an override for genuine need.
When it helps, and when it misleads¶
Its strength is that it makes exploration affordable and safe by construction: no matter how aggressive the rate policy, cumulative cost and blast-radius are bounded, and the risk weighting concentrates that budget where variation is cheap to get wrong. It converts "don't over-experiment" from a hope into an enforced limit.
Its failure mode is that a cap is only as wise as its number. Set by habit rather than need, a tight budget starves genuinely valuable exploration long after the risk that justified it has passed; set too loose, it provides false assurance. Caps also invite gaming — splitting one large mutation into many small ones to stay under a per-item count while spending the same total risk. And a uniform cap that ignores the risk profile is worst of both worlds, over-restricting safe units and under-restricting dangerous ones. The discipline is to tie the ceiling to a real, revisited risk profile rather than a round number, and to measure spend in units that can't be trivially subdivided.
How it implements the components¶
Mutation Budget Cap realizes the resource-and-exposure bounding side of the archetype — the components that limit how much variation is affordable:
mutation_budget— it defines and enforces the ceiling itself: the total variation spend allowed per window, debited as variation occurs.unit_risk_profile— it rations that ceiling by each unit's risk, giving safe units a large allowance and dangerous ones a small, guarded one.
It does not set the per-step mutation_rate_schedule (that's Annealing Temperature Schedule) or read a stagnation_signal to decide when to vary (that's Plateau-Triggered Rate Boost); a cap bounds the total amount, not the rate or the timing.
Related¶
- Instantiates: Adaptive Mutation Rate Management — this cap is how the archetype keeps variation from exhausting resources or safety margin.
- Sibling mechanisms: Adaptive Learning-Rate or Noise Schedule · Annealing Temperature Schedule · Plateau-Triggered Rate Boost · Protected Elite Set · Random Restart Pulse · Rollback Checkpoint · Sandboxed Mutation Test
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: Mutation Budget Cap operates as a standing rule, threshold, contractual commitment, or policy constraint governing future conduct because it sets a hard ceiling on the total amount of variation a system may spend in a window — rationed per unit by its risk — so exploration can never exhaust resources or blast-radius, regardless of what the rate policy wants.
Independent corroboration: The frozen evidence defines Mutation Budget Cap as 'Sets a hard ceiling on the total amount of variation a system may spend in a window — rationed per unit by its risk — so exploration can never exhaust resources or blast-radius, regardless of what the rate policy wants', so its operative form is Rule, Policy & Commitment.
Nearest alternative: Control, Automation & Runtime — The cap can automatically block further variation, but its primary form is the standing budget constraint governing what may be spent.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: A fixed allowance that risky changes consume until exhausted closely follows the error-budget practice of site-reliability engineering.
Related originating lineages:
- Biology & Ecology — Mutation-rate and variation language materially frames exploration as a bounded evolutionary resource.
- Engineering & Design — Risk and blast-radius caps contribute operational safety constraints.
- Systems Thinking & Cybernetics — Viability and feedback regulation contribute windowed limits and stop conditions.
Review resolution: Both independent reviews agree on primary origin computer_science; reconciliation resolves secondary fields (reported_ambiguity, alternate_origin_disagreement). Alternate origins retained (biology_ecology, engineering_design, systems_cybernetics) are the union of reviewer-supported formative lineages with explicit rationales, not a list of later application domains. Present-day breadth is represented separately as domain_reach=multi_domain; origin_mode=cross_disciplinary_synthesis records the historical relationship among lineages. Confidence is conservatively reconciled to medium, and encyclopedia_synthesis=true preserves either reviewer's finding that the encyclopedia generalized the mechanism.
Attribution caveat: A hard windowed mutation budget is a synthetic governance control rather than a standard named evolutionary algorithm. The exact mutation-budget mechanism is an encyclopedia synthesis over SRE error budgets and evolutionary variation.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
[n1] The error budget in site-reliability engineering — a fixed allowance of tolerated unreliability that risky changes draw down until it is exhausted — is the same governing pattern applied to reliability: it caps how much disruption may be spent in a window and forces a stop when the allowance runs out. ↩