Database a constraint or function in the engine's database · API what the gateway returns and refuses · Certification checked before production keys · Commitment our policy, kept by process
Below five, ordinary workplace knowledge can re-identify answers. The full argument is on the why n≥5 page.
Database The aggregates_firewall CHECK constraint, created in migration 0001_iwe_reference_core.sql, rejects any shown result with fewer than five respondents. A withheld row may not carry a value, an interval or a standard deviation. No export, admin role or support process can retrieve a number that was never stored. The first round for an organisation cannot start with fewer than five people on its roster.
Where a screening questionnaire indicates possible severe distress, a correct guess about who it is costs more, so the floor doubles.
Database The severe_floor CHECK constraint in migration 0004_deep_dive_admin.sql means a severe-distress count for fewer than ten people cannot be written. It belongs to the deep-dive layer, which is not sold yet.
An average of 71 from eight people is a different fact from an average of 71 from eighty. The interval says how different.
Database The engine computes the interval when it computes the result and stores it on the same row. It uses the t-distribution multiplier from a lookup function, iwe.t975, for groups up to 30, and 1.960 from 31 upward. API Every shown row returns ci_low and ci_high with its value. Certification We do not issue production keys until the interval is shown wherever the value is. The method is on the confidence intervals page.
A result from five to nine people is real, and it is also fragile. It says so.
Database Each result row gets a method label when it is computed: design for ten or more people and indicative for five to nine. The column cannot be empty, and it accepts only three labels: design, indicative and model. The engine does not write model today; it is reserved for model-based estimates. API The label travels in every API row and in the OWHS export. Certification An indicative row must carry a provisional badge in your interface.
A blank invites guessing. A stated refusal protects people.
Database The firewall constraint requires a coded reason on every withheld row. Reasons come from the OWHS suppression-reason list: below-floor, safeguarding and low-completion. Today the engine writes below-floor. API Withheld rows are returned with suppressed: true and every value field null. There is no parameter that returns them any other way. Certification A withheld row must appear as withheld, with its reason and no number anywhere in the page.
An average from 30% of a workforce is a different fact from one at 80%. Self-selection is the biggest threat to an honest survey, so the denominator is always shown.
API Every result row carries n, headcount and completion_rate.
The person answering sees a completion screen with no score, trend or comparison. The employer and the licensee see organisation-level results only.
API No endpoint returns one person's answers or scores to the licensee, the employer or us. In the hosted check-in, answers go from the person's browser straight to the IWE. In a headless integration, the licensee's server collects the answers and passes them on. To send one invitation and one reminder, a licensee's system can ask whether one person has answered the current round. The IWE has no endpoint that lists who took part, and participation reaches the employer only as a count and a rate.
A comparison is only as honest as the data behind it.
Commitment We will only show a comparison built from real, consented, like-for-like results with these same rules applied. We will not use purchased norms. Today the IWE shows no external benchmark at all. In August 2026 we removed the one interpretation band that had no published basis (migration 0018_org_only_units_and_no_invented_bands.sql).
Someone who is struggling should see where to get help, whatever product they are in and whatever tier it pays for.
Database Safeguarding items and safeguarding routes are kept out of every employer-visible result (migrations 0011_benefits_catalogue.sql and 0017_employer_reportable_guard.sql). The employer never learns that a safeguarding route was shown. API The check-in page we host always carries a support panel: Samaritans on 116 123, Mind on 0300 123 3393, and the person's workplace EAP. It is served from our origin, and the host product has no setting to edit or remove it. Commitment Signposting is external-first and never paywalled. A headless integration draws its own screens, and a licensee may not edit or remove the signposting there either.
It measures and signposts. It does not diagnose or treat, and it is not a medical device.
Database Mood and anxiety screener items are flagged as never employer-reportable. The function that computes results skips them, and a trigger refuses to open a round that includes them (migration 0017_employer_reportable_guard.sql). Certification We do not certify a results view that describes a diagnosis.
There are three layers, so a failure in one is caught by another.
Dashboards sometimes show fewer numbers than a buyer wants. Small groups wait for a fifth respondent. The interval makes some improvements look less dramatic than a bare average would. We publish the rules anyway, because measurement that flatters its buyer is no use to anyone. If your vendor's dashboard has never told you no, that is worth thinking about.
v1.0, 28 September 2026: first public statement of the ten rules. Changes to these rules only ever make them stricter.