A fleet of workers each reads exactly two values at start-up — what must a per-identity read baseline record for a departure to be visible?

## What a baseline actually is here A per-identity read baseline is a compact description of what this one caller's reads have looked like, built from the store's own record of reads and kept so that a new read can be compared against it. It is not a threshold and it is not a score. It is a shape, and its only job is to make the word "unusual" mean something specific for this identity rather than for the estate. The fleet in question makes this concrete: every worker reads exactly two values at start-up — a queue password and a downstream token — and never reads again. That is an unusually tight shape, which is what makes it valuable: almost any abuse of one of those credentials has to leave the shape to do anything. ## The fields, and the departure each one buys | Recorded field | Departure it makes visible | What it does not see | |---|---|---| | Set of names read | a read outside the job's need | more reads of the same two names | | Reads per start | a caller re-reading in a loop | one extra read spread over a week | | Starts per day, with spread | a fleet reading far more than it deploys | a slow, steady drift upwards | | Source ranges seen | the same credential used from elsewhere | a thief inside the fleet's own network | | Hours of day seen | a 3am read on a midday service | abuse during business hours | | List calls seen | a first-ever listing of a branch | a caller reading names it already knows | Two points about that table are worth saying out loud in an interview. First, **every row has a blind column** — no single dimension catches everything, which is why the baseline is a set of fields rather than one number. Second, the rows are not independent: a read from a new source at a new hour of a new name is one event crossing three dimensions, and that is the shape of a finding worth escalating, where any one alone is usually an explanation waiting to happen. ## Why it has to be per identity - An estate-wide average is dominated by whichever callers are busiest, and the worker you are looking for contributes a rounding error to it. - Different identities have honestly different shapes. A gateway that fetches per request and a worker that fetches twice at start cannot share a threshold without making one of them permanently noisy and the other permanently invisible. - The comparison you want to make is "unlike **itself**", not "unlike its peers" — a fleet of identical workers happens to give you both, but most estates are not that tidy. ## Record the window, not just the shape A baseline observed over one week of a newly deployed fleet has seen the deploy pattern of one week. It has not seen the quarterly batch, the disaster-recovery rehearsal, the annual key ceremony or the night the on-call engineer restarted everything. All of those are normal, and all of them will look like departures the first time they happen. So store the observation window alongside the shape, and treat the first departure in a dimension as a question rather than an alert. The discipline that makes this work in practice is: 1. Write down what the identity is **for** — what its job actually needs — before you look at what it did. If the recorded shape is wider than the job, that gap is itself the finding. 2. Keep the spread, not the mean. A 50th and a 99th percentile of starts per day tells you whether 40,000 reads is impossible or merely unusual; an average tells you neither. 3. Re-derive the shape when the fleet changes deliberately, and record that you did, so a later reader knows which change explains the step. ## What this leaves out on purpose The baseline says nothing about whether the read was good or bad. It says only that the read is or is not like this identity's other reads. It also depends entirely on the store's record carrying, per event, the caller identity, the source, the time, the name and the outcome — if any of those is missing, the corresponding dimension of the baseline cannot exist, and the honest answer to "could we have detected this?" is no. Getting that record produced and kept trustworthy is a different problem from reading shapes out of it, and it is worth separating the two in an interview answer rather than blurring them together. Finally: a baseline is not a control. Nothing about it stops a read. It converts a permitted read into a question, and the value of the whole exercise is how quickly and how specifically that question can be asked.