03.2 · Mask Schedules

Parent: Document 03 (D2 Experiment Plan), Step 0.2 — “design candidate chip-mask schedules on paper; tabulate against Option C’s curve.” Status: ✅ Banked. Verdict: M3 primary, M1 fallback, M2 eliminated on paper (§6). The simulation validates M3/M1 against Option C; it does not search for new schedules (anti-overfitting rule, Doc 03 Step 0.2). Prerequisite reading: Doc 03.1 (Option C reference) — especially §3 (the target curve) and Appendix A (shifts).

1. The puzzle, precisely stated

Option A is forbidden pow(), floats, and RNG calls. Its only probabilistic instrument:

Take k designated bits of the hash mix. Are they all zero? — an event with probability exactly 1/2ᵏ (each bit of a quality hash is an independent fair coin).

Consequently Option A can only express the probabilities 1, 1/2, 1/4, 1/8, … — a staircase where each step halves. Option C’s curve 1.08⁻ᵉᶠᶠ is smooth. Step 0.2 designs the mapping eff → k (the mask schedule) so the staircase hugs the smooth curve.

🧭 In plain terms: Option C can demand any lottery odds it likes — “win with 85.7% chance.” We can only demand “flip k coins; all must be heads.” Our whole freedom is choosing how many coins to demand based on how strong the victim is.

2. The conversion: from compoundings to halvings

We need 2⁻ᵏ ≈ 1.08⁻ᵉᶠᶠ. Solving for k:

k = eff × log₂(1.08) ≈ eff × 0.111 ≈ eff / 9

The exchange rate: every ~9 tally marks of victim strength buys one more required zero-bit (one more mandatory heads). Spot-check: eff 100 ⇒ k ≈ 11 ⇒ 1/2¹¹ = 4.88×10⁻⁴ vs C’s 4.54×10⁻⁴ — a 7% match from one division.

Everything below is merely “compute eff/9 cheaply in integer math.”

3. The candidates

ID	Rule	Cost	Character
M1	`k = min(eff >> 3, kcap)`	1 shift	÷8 instead of ÷9 ⇒ systematically ~12% over-protective in the exponent (protection grows slightly faster than C’s)
M2	`k = min(bitlen(eff), kcap)`	1 clz instruction	logarithmic ⇒ p ≈ 1/eff — a different curve family, see §6
M3	`k = min((eff × 227) >> 11, kcap)`	1 mul + 1 shift	fixed-point fit of the exact 0.111 slope (227/2048 = 0.1108, slope error 0.2%)

Fixed-point arithmetic (technique note, for the toolbox): to multiply by a fraction without floats, choose numerator / 2^s ≈ fraction, then compute (x × numerator) >> s. Here 0.111 ≈ 227/2048 (s = 11). This is the standard idiom for fractional math on integer hardware; it will reappear whenever we need curve math on the hot path.

Cap: kcap = 20 tentatively (p = 1/2²⁰ ≈ 9.5×10⁻⁷ per attempt ≈ “never,” per-attempt). Rationale and safety argument in §7; entropy budget in §8.

4. The master tabulation (the deliverable of Step 0.2)

p = chip probability per attempt. C column from Doc 03.1 §3. ᶜᵃᵖ marks where kcap=20 binds.

eff	Option C: 1.08⁻ᵉᶠᶠ	M1: k, p	M2: k, p	M3: k, p
1	0.926	0, 1.0	1, 0.5	0, 1.0
3	0.794	0, 1.0	2, 0.25	0, 1.0
10	0.463	1, 0.5	4, 0.0625	1, 0.5
30	0.0994	3, 0.125	5, 0.0313	3, 0.125
100	4.54×10⁻⁴	12, 2.44×10⁻⁴	7, 7.81×10⁻³	11, 4.88×10⁻⁴
300	9.4×10⁻¹¹	20ᶜᵃᵖ, 9.5×10⁻⁷	9, 1.95×10⁻³	20ᶜᵃᵖ, 9.5×10⁻⁷
1,000	3.7×10⁻³⁴	20ᶜᵃᵖ, 9.5×10⁻⁷	10, 9.77×10⁻⁴	20ᶜᵃᵖ, 9.5×10⁻⁷
10,000	~10⁻³³⁴	20ᶜᵃᵖ, 9.5×10⁻⁷	14, 6.1×10⁻⁵	20ᶜᵃᵖ, 9.5×10⁻⁷

Readings:

M3 vs C: near-perfect through eff ≈ 180 (the 7% match at eff 100 is the showcase row), then diverges only where the cap binds (§7).
M1 vs C: same staircase as M3 at low eff; by eff 100 it demands one extra zero-bit (k 12 vs 11) — 2× more protective than C there. Direction of error: occupants slightly stickier ⇒ marginally slower slot recycling. Acceptable fallback; M3 is strictly a better fit at equal (trivial) cost.
At eff 1–3, all schedules give p = 1 vs C’s ~0.9/0.8: we chip near-dead occupants slightly more eagerly than C. Safe direction — the affected occupants are mice/ghosts by definition — and it marginally speeds new-elephant admission. Logged as a known, benign divergence.

5. What the staircase costs (and the optional smoothing)

Even M3 can only land on powers of ½, so pointwise it wobbles within ~±41% (a factor of 2^±½) around C’s smooth curve — visible in the eff 30 row (0.125 vs 0.0994). Whether distributional outcomes (error CDFs, recall, admission time) feel this wobble is exactly what the simulation measures; the gate (Doc 03 §4.1) is on outcomes, not on curve equality.

Pre-registered refinement, used only if the staircase shows in results — M3+ dithering: spend one extra hash bit (or the fractional part of the fixed-point product, which we currently discard) to choose between k and k+1 in proportion to the fraction, recovering the smooth curve in expectation. Named now so that reaching for it later is a logged plan-step, not a silent search.

6. The plot twist: M2 is eliminated on paper

M2 (k = bitlen(eff)) yields p ≈ 1/(2·eff)…1/eff — the harmonic family, not the geometric one. The table shows it crossing C’s curve in the worst possible way:

Over-protective where it hurts admission: at eff 10 it is ~7× stickier than C (0.0625 vs 0.463); weak occupants linger, slots recycle slowly, and new-elephant admission time — the headline metric D2 exists to protect — degrades.
Under-protective where it hurts elephants: at eff 1,000 it is ~10³⁰× more permissive than C; a determined challenger stream chips a count-N occupant roughly once per N attempts — precisely the “grindable by sheer volume” failure Doc 03.1 §3 rejected the harmonic curve for.

Verdict: M2 is removed from the simulation candidate set. Recorded honestly: M2 is the schedule currently running in the demo simulator, chosen there for visual legibility (its probabilities are readable at demo scale). The tabulation caught our own demo default being wrong for production — the paper-before-code rule paying for itself on first use. The simulator stays on M2 as a teaching aid with a caption noting it is not the shipping schedule; the harness tests M3 and M1 only.

7. Why the cap is believed safe (to be verified, not assumed)

For eff > ~180, kcap = 20 makes M1/M3 more permissive than C (9.5×10⁻⁷ per attempt vs C’s effectively-zero). The two-case argument for why this cannot matter:

The occupant is alive: it refills thousands of tallies per epoch. Maximum erosion at one-in-a-million per attempt is statistical dust against the refill rate; net count still climbs.
The occupant is fading: decay halves it each silent epoch; from eff 10,000 it falls below the cap region (≈180) within ~6 epochs, after which normal curve-matched rules apply. The cap only governs keys whose fate is already sealed by their own traffic.

This argument is precisely what the elephant-recall metric (Doc 03 §2.2) exists to confirm or refute. If recall dips in cap-heavy workloads, the pre-registered response is raising kcap (bits permitting, §8) — not redesigning schedules.

8. Entropy budget (feeds Step 0.3)

A 64-bit hash funds: bucket index (16 bits at 65,536 buckets) + fingerprint tag (16 bits) = 32 bits consumed ⇒ 32 spare bits for the chip draw. kcap = 20 fits with 12 bits to spare (some of which Step 0.3 will spend on per-attempt mixing). Note: the demo simulator runs a 32-bit hash and 4 buckets — a legibility choice; the budget above describes the real layout.

9. Hand-off to Step 0.3

The schedules consume “k uniformly random bits.” Step 0.3 must specify which bits those are and how they stay random across attempts — including the fix for the static-pairing bug found in review (same key + unchanged victim ⇒ frozen draw): the mix must include a per-attempt-varying component. That specification, with its “why this is sufficient” argument, is the next document.

Appendix — check-your-understanding exercises (with answers)

Using M3, eff = 50: what are k and p, and how does p compare to C? k = (50 × 227) >> 11 = 11350 >> 11 = 5 ⇒ p = 1/32 ≈ 0.031. C: 1.08⁻⁵⁰ ≈ 0.021. The staircase lands one half-step permissive (~1.5×) — a typical wobble from §5, safe direction here debatable and small; the outcome metrics adjudicate.
Why does every schedule return p = 1 for eff ≤ (roughly) 8? Because k rounds to 0 there (50/9 < 1 only below 9; specifically eff>>3 = 0 for eff ≤ 7, and (eff×227)>>11 = 0 for eff ≤ 9), and “zero coins must all be heads” is vacuously true. A near-dead occupant is chipped on every attempt — faster recycling of mice than even C provides.
Why is a multiply-and-shift acceptable on the miss path when we banned pow and floats? The ban is about cost and determinism: integer mul+shift is ~1–4 cycles and bit-exact on every platform; pow is hundreds of cycles of float math with platform-varying last bits. The rule was never “no arithmetic” — it is “no slow, non-reproducible arithmetic.”