Roster attributes and cuts

Roster attributes let you cut a poll's results by department, location, tenure band and manager without asking respondents any of those questions. You import the values from the headcount spreadsheet the organisation already keeps, they're attached to each person's ballot when you send it, and your browser can filter results by them behind the same floor of five that guards every other cut. Use them when the self-reported version is unreliable, or when four demographic questions would eat a fifteen-question survey.

The only new thing the server learns is a department beside an email it already held, in a table our own operations role can't read. The link it must never have, response to person, still doesn't exist. What changes is what your browser can do with the results, and that's where the floor does its work.

When to use it

A consultant running an engagement against a client's real org chart, not against how people describe their own team.
A pulse where "which department are you in" gets a different answer from the one HR would give.
Any survey where the questions are precious and four of them shouldn't go to demographics.
A recurring series where you want the same cuts every wave without re-asking.

If you'd rather ask respondents, the self-reported route is Demographic cohorts and minimum thresholds. The two are separate dimensions and never merge; a roster cut is labelled "Department (roster)" so you always know which claim you're reading.

Importing a roster

Attributes ride a contact list. When you create a list from a CSV, the dialog reads the header row and looks for four columns.

Department from a header reading department, dept, team, division, business unit or function.
Location from location, site, office, country, city, region or workplace.
Tenure band from tenure band, tenure, length of service, service band or years of service.
Manager from manager, line manager, reports to, supervisor or manager name.

A sheet with no header row has no attributes. Guessing which text column is a department would silently mislabel a whole roster, so the dialog doesn't. Every match is shown on the review step, where a line like "department: 6 values · location: 3 values · tenure band: 5 values · manager: 14 values" tells you what it found, followed by the note that a group smaller than five stays out of any chart.

Two rules at import:

Tenure band is a label, not a date. The dialog suggests a vocabulary ("< 1 year", "1-2 years", "2-5 years", "5-10 years", "10+ years") and doesn't enforce it. Band it in your spreadsheet before you import. We don't take a hire date because a date is more sensitive than the band, and we don't need it.
A manager is a name. A manager cell that looks like an email address is skipped and the review step names the row. A manager's address would sit inside ciphertext an admin can hand to someone outside the workspace, so it's refused rather than carried.

Values are trimmed, capped at 80 characters, and matched case-insensitively. "Engineering" and "engineering " are one group, displayed with the casing seen first.

What happens when you send

Roster attributes are attached at send time, and only on email magic-link distribution. That's the one method with a per-recipient ballot to attach anything to. Access codes are deliberately not tied to an address, and an open link has no recipient at all, so on those polls the distribution panel says: "Roster cuts need email magic links. Access codes aren't tied to an address on purpose, so there's no ballot to attach a department or a manager to."

Before anything is attached, the roster you're sending to is collapsed so that no combination of values can point at one person. This is the part worth understanding, because it's where the protection lives.

Why "minimum five" on its own isn't enough. The floor of five stops a chart from showing a group of four. It does nothing about a combination. If one person on the roster is the only one who is in Legal, in Dublin, with more than ten years, reporting to Chen, then a chart of Legal is fine, a chart of Dublin is fine, and the response that carries all four values together is still one identifiable person to anyone who can read responses individually. Four authoritative attributes make a much sharper fingerprint than four self-reported ones, because HR picked them.

Why it has to happen before sealing. A ballot, once encrypted in the respondent's browser, can't be reopened by anyone but a key holder and can't be re-sealed by us at all. Whatever protection exists has to be applied before the ciphertext is written, or it doesn't exist.

So at dispatch, over the roster being sent to:

Each attribute is checked on its own. Any value shared by fewer than five people on the roster is dropped from everyone who has it. A department of three vanishes as a department.

Then the combination is checked. If the full set of values on somebody's ballot would be shared by fewer than five people, the least useful attribute is dropped from those people, in a fixed order: manager first, then tenure band, then location, then department. The count is redone and the step repeats until every non-empty combination is shared by at least five.

A dropped value is simply absent. It's not replaced by "Not reported", because a "not reported" bucket is itself a group, and it's exactly the group of people whose real value was too rare to show.

The floor is counted over the roster you're sending to, not over who eventually answers. That's the only set known at send time. It composes correctly with the floor on the chart: a department of six where two people answer gives a group of two, which the results page then refuses to show.

Right after sending, a message tells you what the collapse did. Either "Roster attributes attached to 38 of 40 ballots. Groups smaller than five are left out so nobody can be picked out of a chart", or, if nothing survived, "No roster attributes were attached. Every group was smaller than five, so nothing could be sealed without making somebody identifiable." You find out now, not three weeks later when a cut is empty.

A resend hands the same person the same values, even if you've edited the roster since. One employee never appears under two departments in one wave.

What respondents see

Nothing new. The attributes travel to the respondent's browser with their ballot and are sealed into the encrypted response there, beside the answers. They're not shown, not editable through the form, and never sent to us in readable form. The response record on our side is still ciphertext with no timestamp and no link to a person.

Cutting results by roster

Once results are open and your browser has decrypted them, the results tab offers Filter by roster beside any demographic filters, with one selector per attribute that actually arrived. A dimension nobody carries isn't offered, because the roster was collapsed before sealing and only the decrypted responses know what's left.

Each roster dimension shows a coverage line: how many of the responses in view carry a value for it at all. Without that number a department chart summing to 32 of 40 reads as eight people who didn't answer, which is a different and wrong story. The eight had a value too rare to keep.

A cut with fewer than five responses stays locked, with no count. The same floor as a self-reported cohort, on a new path, tested separately.

Share a slice doesn't carry a roster filter yet. If you open the dialog with a roster cut active it says so and starts from all responses. Roster cuts reach outsiders through the published document instead.

The cut catalog

When you publish results, the signed document carries a fixed catalog of cuts, computed in the same pass from the same decrypted responses that drew your charts:

One cut per value of each roster attribute present.
One cut per option of each self-reported demographic question on the poll.
Three standard pairs: department by location, department by tenure band, and location by tenure band. Manager is in no pair. A manager already sits inside a department, so the pair adds nothing a single cut doesn't say, and manager pairs would almost never clear the floor.
A coverage cut per dimension, over every response carrying any value for it.

Every cut clears five. A cell that doesn't is left out entirely rather than marked, for the same reason a dropped value is absent rather than bucketed. The catalog is trimmed to a fixed cap of cuts if a roster is very large, so one document degrades instead of failing to publish.

There is no ad hoc slicing in the document. Your live filter stays in your browser; the catalog is what leaves it.

Why a cut can be missing

Fewer than five people in that group among the responses. The chart is locked, or the cut isn't in the catalog.
The value was dropped at send time, because fewer than five people on the roster shared it or shared the combination it was part of.
The poll was sent by access code or open link, so nothing was attached.
The person wasn't on the contact list you sent to, so their ballot carried no attributes.
The catalog reached its cap. Cuts are trimmed in a stable order, so the same responses always give the same catalog.

Across waves of a series

Each wave attaches the roster as it stood when that wave was sent. Somebody who moves from Support to Engineering between wave 2 and wave 3 counts in Support for the first two and in Engineering from the third. Nothing else is possible: an earlier wave's ballots are sealed and can't be rewritten, and suppressing "movers" would need to know which response moved, which is the link that doesn't exist.

What you get instead is an honest caveat. Every send stamps a fingerprint of the collapsed roster, and on the series trend page a wave whose roster differs from the previous wave's carries the note: "The roster changed between this wave and the one before it, so some people are counted under a different department, location or manager." The first wave never carries it, and a wave that attached no roster isn't read as a change.

Limits and gates

Magic-link distribution needs an active plan or trial, so roster cuts do too.
Four attributes, fixed. No custom columns.
Email magic links only. Access-code and open-link polls attach nothing and say so.
The floor of five applies at send time over the roster and again on every chart and every catalog cut. It can't be lowered.
Values are capped at 80 characters; a manager that looks like an email address is refused.
A respondent's sealed values aren't authenticated. Someone could edit their own before submitting and move their answer between two groups that both already clear the floor. That's the same property self-reported demographics have always had.
Attributes on lists synced from Slack come only from what a CSV supplies.