A team average is a disguise, and small groups make thin disguises. With three respondents, anyone who knows their own answer and one colleague's mood can often deduce the third's, the "small cell" problem that statistical disclosure control has studied for decades (Hundepool et al., Handbook on Statistical Disclosure Control, ch. 5 on frequency tables). UK official statistics treat small cells as disclosive as a matter of routine: the Government Statistical Service's guidance for survey tables says plainly to "suppress or combine unsafe cells, i.e. where there are one or two units contributing to the cell" (GSS/GSR disclosure control guidance).
The legal frame agrees. The ICO's anonymisation guidance tests identifiability against "all the means reasonably likely to be used, such as singling out" (ICO, How do we ensure anonymisation is effective?). In a workplace, colleagues' background knowledge, who was on leave, who has been struggling, is always a means reasonably likely to be used. A three-person "anonymous" average fails that test on an ordinary Tuesday.
Five is where single-insider deduction stops being trivial: a respondent who knows their own answer still faces four unknowns. It sits above the GSS "one or two units" definition of an unsafe cell with margin for the insider problem, and it is the number most employee-survey vendors converge on in their help documentation, typically stated, rarely justified (see Lattice, Effectory, Betterworks).
Two honest caveats most pages will not tell you. First, five is a floor, not a cloak: repeated cross-tabulation (team by tenure by site) can rebuild small cells from individually compliant queries, so the floor must apply per displayed cell, not per query. Second, for severe-distress screening measures five is not enough, because the stakes of a correct guess are higher, so the Open Workplace Health Standard applies n ≥ 10 to those, and this engine implements that as a second schema constraint.
Almost every tool implements its threshold in application code: an if statement decides whether to display the number. The number itself exists, in the database, in exports, in whatever an "enterprise data access" feature or a support engineer with production access can reach. The promise is one product decision away from broken.
The structural alternative, verbatim from this engine's schema:
constraint aggregates_firewall check (
(not suppressed and n >= 5 and value is not null)
or (suppressed and value is null and ci_low is null and ci_high is null
and sd is null and suppression_reason is not null) )
A below-threshold average is unrepresentable. The database rejects the row; no privileged query, export flag or admin override can return a number that was never stored. What is stored, deliberately, is the fact of withholding and a coded reason (below-floor, safeguarding, low-completion, from the OWHS suppression-reason codelist), so a dashboard can say honestly "withheld to protect anonymity" rather than showing a blank that invites guessing.
The interactive demo lets you shrink a simulated team below five and watch the value cease to exist, including the stored reason. For small groups above the floor, the companion page covers the other half of honesty: confidence intervals for small-team scores. The full set of constraints is stated in the honesty rules.
Intelligent Wellbeing Engine (IWE) and Wellbeing Engine (wellbeingengine.io) are trading styles of All Toogether Ltd, registered in England and Wales, company no. 14775309, registered office Jactin House, 24 Hood Street, Manchester, United Kingdom, M4 6WX. The Intelligent Wellbeing Engine (IWE) is workplace wellbeing measurement software. It is not an insurance product or service, and nothing on this site is insurance or financial advice.
A dedicated licensing entity is being established.