Skip to main content
MeetCost’s permission model starts from a single arithmetic fact and builds every disclosure rule from it. Because pay is stored per individual, a per-participant cost breakdown is functionally a salary disclosure — in a two-person meeting a breakdown reveals the other person’s salary exactly. Everything on this page follows from that. Read it before you change any default; the defaults are conservative because the risk is real, and the unsafe configurations require a deliberate choice.

​
The five roles

✅ always on   ·   ❌ never, not configurable   ·   ⚙️ admin-configurable Anyone with no role assignment is a participant. A directory sync that adds a person therefore grants them nothing.
Organiser is per-meeting, not a rank. Being the organiser of a meeting raises a participant to organiser for that meeting only, so they can see what they are about to spend. It confers no standing reporting rights — a participant who organises one meeting has no access to reports.

​
Report scope

Scope is derived from the caller’s role. It is never a query parameter, so there is no request a client can construct that widens it. Reports are aggregate by construction. There is no per-person spend ranking anywhere in the product or in the CSV export — that is individual productivity scoring, which is explicitly out of scope. The CSV export contains no column that identifies an individual’s cost.

​
The three protections

Three independent mechanisms prevent a cost figure from being reversed into a salary. Each closes a specific channel.
1

Per-person breakdown is off below Admin

Turning it on shows Organisers, Team leads, and Finance who cost what within a meeting. It is off by default at every level below Admin, and enabling it requires a deliberate admin action.Stops: reading an individual’s rate straight off a meeting summary.
2

Small-meeting suppression

Even when breakdowns are enabled, they are withheld entirely for meetings with fewer than small_meeting_threshold participants (default 5).Stops: using a small meeting — where each person is a large share of the total — to isolate one person’s cost.
3

Total banding

For meetings below the same threshold, non-admin viewers see the total rounded to two significant figures and labelled approximate.Stops: the inference channel that the first two protections leave open. In a two-person meeting, total − my own cost = the other person's exact rate, and every participant knows their own salary. Suppressing the breakdown does nothing about this; the subtraction is done on paper. Banding removes the precision that makes it work, at the cost of a little accuracy on small meetings.
This third protection is not in the original specification — it was added because the specification names the inference risk and the first two protections do not close it. It is controlled by band_small_meeting_totals and can be switched off. There is no good reason to switch it off.

​
Raw pay access

Raw pay means the underlying salary figures, not computed costs. These are distinct things.
  • Admin may always read and export raw pay.
  • Finance / HR may read raw pay only if finance_can_view_raw_pay is enabled. It is off by default, and cost reporting does not require it.
  • Nobody else, at any setting.
Every reveal writes one audit row per person revealed, not one row per request. A single “exported 400 rows” entry would not answer “who has seen my salary?” — which is the question the log exists to answer.

​
Should participants see the cost?

The strongest behaviour lever is a cost summary that everyone in the meeting receives. It is also the biggest cultural risk: the same notification that makes a team reconsider a standing meeting can read as surveillance. Three options were considered: MeetCost ships option (c). participants_see_cost is off by default, meaning organiser-only. An admin can turn it on.
Involve HR and, where you have one, your works council before enabling participants_see_cost. This is a consultation question, not a configuration question.

​
Configuration reference

Configure via the admin UI under Rates & policy, or with the API:
Every change is audited with a before-and-after value.

​
Verifying the policy holds

The role matrix and all three protections are encoded as tests:
If you change a default, that file shows exactly what you have changed and what behaviour it previously asserted.