Skip to main content

The 'Safe batches of three' release rules for the math geeks

At Salary Confidential, our safe batches of three logic is defined by a single release rule designed to preserve respondent anonymity at all times.

If you like a bit of modular arithmetic with your privacy guarantees, here it is.

Release function

The system evaluates the release state RR based on the following logic:

R(r,N)=1iff(r=N)    (r6    rmod3=0    Nr3)R(r, N) = 1 \quad \text{iff} \quad \Big( r = N \Big) \;\lor\; \Big( r \ge 6 \;\land\; r \bmod 3 = 0 \;\land\; N - r \ge 3 \Big)

Equivalently, the number of released responses is:

released(r,N)={r,r=N0,r<63min(r3,N33),r6\text{released}(r,N)= \begin{cases} r, & r = N \\ 0, & r < 6 \\ 3 \cdot \min\left(\left\lfloor \frac{r}{3}\right\rfloor, \left\lfloor \frac{N-3}{3}\right\rfloor\right), & r \ge 6 \end{cases}

Where:

rr = number of responses received
NN = total survey size (expected responses)
mod\bmod = the modulo operator (remainder after division)

What this function guarantees

Rather than restating the formula, it’s more useful to understand the single invariant it enforces:

Responses are released only when doing so cannot cause a singleton or pair to appear at survey close.

From that invariant follow three practical consequences:

  • Minimum threshold No individual response rows are released before six responses exist. At three responses, the requester may see aggregated preview metrics only (“tiny peek”), never raw rows.

  • Batch structure When releases begin, responses are revealed only in complete groups of three.

  • Remainder safety A release is allowed only if, after the release, at least three responses remain outstanding (whether already collected or not).

Everything else in the system is a direct consequence of this rule.

Why release behavior differs at six responses

At r=6r = 6, whether the system releases three responses or six depends entirely on the survey’s total size NN.

The system always chooses the largest safe release — meaning the biggest group of responses that can be revealed without creating a singleton or pair at survey close.

Example: N=7N = 7, r=6r = 6

  • Releasing all six would leave 11 outstanding response.
  • A singleton at close would be unsafe.
  • So the system releases 3 responses.
  • The remaining 4 unlock together at final close.

Example: N=9N = 9, r=6r = 6

  • Releasing all six leaves 33 outstanding responses.
  • Three is itself a safe batch.
  • So the system releases all 6 responses.

Same number of responses received.
Different outcomes — because the remaining capacity is different.

That distinction is deliberate.

Why this rule remains safe if the survey size changes

The release logic depends only on the current values of:

  • rr — responses received
  • NN — total expected responses

Because of this, it behaves predictably even if the survey size changes while it is running.

Adding response slots can make previously unreleased responses become eligible for release — but it can never make an unsafe release possible.

Example: growing a survey from 8 to 9 slots

  • Suppose a survey has N=8N = 8 and r=6r = 6.
  • The system releases 3 responses.
  • Releasing all six would leave 22 outstanding, which would be unsafe.

Now suppose one slot is added and the survey becomes N=9N = 9:

  • At the same r=6r = 6, releasing all six is now safe.
  • Releasing six leaves Nr=3N - r = 3 outstanding responses — a full safe batch.
  • The system immediately unlocks the remaining three.

Nothing about the responses changed. Only the safety of releasing them did.

What matters is not when responses arrived, but whether releasing them at a given moment would leave an unsafe remainder.

Relationship to early-close surveys

This same invariant extends into early-close surveys, where a requester manually shrinks the effective size of a survey by closing it before all responses are collected.

When a survey is closed early, we evaluate how much of the remaining data can be safely released given what has already been revealed, without violating the same no-singleton / no-pair rule described above.


If you’d like to go deeper

These articles provide context into the technical approach we take to make the data more resistant to identification and de-anonymization:

Updated January 27, 2026