The DS, explained
This is the narrative version of Doc 01, Doc 02, and Doc 04 — the story, not the full specification. Read this first; go to Docs when you need the normative version of a claim.
Imagine running the door at an enormous, always-open club. Thousands of faces a minute, and your job is to spot the regulars of the last hour — not the person who came every night in 2019 and stopped, not the one who showed up once tonight, but who's showing up a lot, recently. You can't write anything down per person — millions of possible faces, one notepad, fixed size. You must answer instantly. And memory has to fade on its own, because the club never closes for you to erase the notepad.
Notice that's really three questions about the same face, asked at the same moment: how often (frequency), how recently (decay), and have I seen this one already tonight (first-sighting). Existing structures answer these separately, each with its own bookkeeping. EpochSketch's premise is that because all three are about the same key at the same instant, one structure can answer all three — in one memory access.
The fusion is literal, not architectural — all three answers live in one 64-bit word, packed by bit position, read or written together in a single atomic operation.
The count field is never decremented, and nothing ever sweeps the table to age entries out. Every read recomputes freshness on the spot: estimate = count >> age, where age is how many ticks have passed since the slot's stored epoch. Two reads of the same untouched slot can return two different answers — not because anything changed, but because time did.
Each bucket holds 8 slots. When a new key needs one and all 8 are occupied, the incoming key doesn't just wait — it challenges the weakest resident slot for its spot, a contest Doc 04 calls "the audition." Two designs were pre-registered and run head-to-head against a frozen HeavyKeeper baseline; the table below is the verdict, not the derivation.
| Option | Mechanism | Outcome |
|---|---|---|
| A · shipped | Hash-derived "chip" schedule (M3) — the challenger's own hash decides how much it damages the incumbent on a loss | Passed the pre-registered gate; ships in the production engine |
| C · reference | HeavyKeeper-style RNG lottery | Frozen as the baseline it was measured against — not adopted |
Every eviction outcome that isn't a clean win fails toward "first sighting." A dropped increment or a lost eviction never inflates a count — the structure would rather undercount a key it's unsure about than silently overcount one it isn't tracking at all.
Named to prevent scope creep:
No build step, no server — send traffic, step the epoch clock, and watch the raw 64-bit word for a slot flip bit by bit. The chip inspector dissects every eviction attempt: who won, who got chipped, why.