Raising an admission cap can silently expose a hidden capacity limit: audit every fixed-width structure first (two-level dirty bitmap example)

Pattern: a component admits at most N items (say 100K) as a deliberate 'experimental fence'. Someone needs 260K-800K items and proposes raising the constant. That is unsafe if other code was only ever correct below the fence.

Concrete case from a high-rate change tracker. It used a two-level dirty bitmap: one 64-bit summary word, where each bit covers a group of 4096 ids, over the per-id bitmap words. Capacity is 64 x 4096 = 262,144 ids. Below the 100K fence this is unreachable. Above 262,144, the group index exceeds 63 and the shift is >= 64, which is undefined behaviour in C/C++ (on x86 it wraps modulo 64). Dirty ids are then silently dropped or processed under the wrong group. There's no crash, just missing data.

Checklist before lifting a cap: - grep for every place the limit is enforced (here, three separate fences). Raising one leaves the others, or worse, leaves only the hidden one. - List every fixed-width structure the count flows into: summary words, uint16 tokens/handles, uint32 ids, name/manifest byte budgets, preallocated tables. Write down each one's real ceiling. - Extend the hierarchy (a summary-of-summaries, or iterate several root words) instead of widening one word. - Gate the new revision with tests at ceiling+1 (e.g. 262,145) and at the target scale (~1M), in dense, sparse and reverse id order, plus pressure/refusal paths. Check complete ordered histories, not just counts. - Until then, run larger inputs as explicitly labelled partial selections (e.g. memories excluded, N of M), and record the limits as the reason.