Your data and who can see it
A plain-language summary of the access rules the platform actually enforces today. It claims nothing broader than what the rules do.
The starting point
- Your rows are yours: data you enter belongs to your account. Other users see nothing unless a specific access rule allows it.
What companies can see about workers
- In scouting views, worker information appears in an anonymised form, and contact details are never shown without the worker's permission.
- Employers cannot read a worker's saved locations.
- Worker documents are not shown to employers or agencies without the worker's consent — at most, counts that the worker agreed to share.
What workers can see about companies
- Workers see what a company chooses to publish: public needs and offers appear only after moderation.
Messages
- A conversation is visible only to its participants. Colleagues from the same company who are not participants see nothing — not even that the conversation exists.
- If an extra person is granted access (for example the object owner), that access lasts only while the grant is active. When it is revoked, access ends, and the history stays recorded.
Administrators
- A small set of platform administrators can see the operational queues needed to run the platform, such as support and review queues. Administrator pages are restricted and fail closed.
If something looks wrong
- The access rules in the database are the source of truth, and this page follows them. If something here does not match what you see, contact us — a person will review it.
Permission matrix: who can see and change what
The table below lists the main product surfaces and, for each role, what that role can see and what it can change. It is written from the actual access rules in the database and in the route guards — each row points to the exact rule that enforces it. Where a rule is narrower than a short label can express, the row's note explains the boundary in plain words.
| Surface | Worker | Company owner / manager | Team owner | Administrator |
|---|---|---|---|---|
| Profile and account dataYou see your own profile. Other users cannot open it directly.You change only your own profile. Administrators can correct records when needed.Rule: supabase/migrations/0001_initial_schema.sql#profiles_select · supabase/migrations/0001_initial_schema.sql#profiles_update | See: own onlyChange: own only | See: own onlyChange: own only | See: own onlyChange: own only | See: yesChange: yes |
| Worker card in scoutingCompanies see an anonymised preview only — no name and no contact details without the worker's permission. The worker sees their own full card.Only the worker (and, when needed, an administrator) can change the card.Rule: supabase/migrations/0001_initial_schema.sql#workers_select · supabase/migrations/0001_initial_schema.sql#workers_update · apps/web/lib/scouting/scout-safe-view.ts · apps/web/lib/visibility/worker-profile-visibility.ts | See: own onlyChange: own only | See: limitedChange: no | See: noChange: no | See: yesChange: yes |
| Work journal entriesThe worker sees their own entries. A manager of the organisation the entry belongs to can read it for review.Entries cannot be rewritten after saving. The worker adds their own entries; managers add review results, not edits.Rule: supabase/migrations/0013_work_journal_m1.sql#journal_entries_select · supabase/migrations/0013_work_journal_m1.sql#journal_entries_insert · supabase/migrations/0034_manager_review_evidence_result.sql · apps/web/lib/journal/confirm-actions.ts | See: own onlyChange: own only | See: limitedChange: limited | See: limitedChange: limited | See: yesChange: no |
| Team and company membershipYou see your own memberships; owners and managers see the memberships of their own organisation.You manage your own membership records; administrators handle corrections.Rule: supabase/migrations/0013_work_journal_m1.sql#engagement_contexts_select · supabase/migrations/0013_work_journal_m1.sql#manages_organization · supabase/migrations/0032_engagement_context_provisioning_rpc.sql | See: own onlyChange: own only | See: limitedChange: no | See: limitedChange: no | See: yesChange: yes |
| Team capability summaryOnly the team's owner or manager sees the summary of their own team. It is derived from members' existing skill records — counts only.Nobody edits it directly — it is a summary for viewing only.Rule: supabase/migrations/20260705220000_team_brigade_org_spine.sql#get_team_capability_summary_v1 | See: noChange: no | See: noChange: no | See: own onlyChange: no | See: yesChange: no |
| Posted needs (demand)The company that posted a need sees its own needs. Administrators see the review queue.The poster updates their own need. Status changes follow a fixed, guarded review sequence — even for administrators.Rule: supabase/migrations/0028_customer_requests.sql#customer_requests_select · supabase/migrations/0028_customer_requests.sql#customer_requests_update · supabase/migrations/20260705150000_customer_requests_status_transition_guard.sql#customer_requests_status_transition_guard | See: noChange: no | See: own onlyChange: own only | See: own onlyChange: own only | See: yesChange: limited |
| Worker demand boardWorkers see approved needs in a reduced, structured form: role, country, team size, start period and the company name — no free text and no contact details. This surface returns nothing to non-worker accounts, including administrators.For viewing only — nothing on the board can be changed from here.Rule: supabase/migrations/20260702170000_worker_demand_approved_route_model_a.sql#list_open_demand_for_workers | See: limitedChange: no | See: noChange: no | See: noChange: no | See: noChange: no |
| Conversations and messagesOnly the participants of a conversation see it (plus platform administrators on support paths). Colleagues who are not participants see nothing.You send your own messages; sent messages cannot be edited or deleted.Rule: supabase/migrations/0021_communication.sql#conversation_messages_select · supabase/migrations/20260705170000_conversation_counterpart_identity.sql#conversation_counterpart_identities · apps/web/lib/communication/contact-permission.ts | See: limitedChange: own only | See: limitedChange: own only | See: limitedChange: own only | See: yesChange: own only |
| Project handover notesOnly people who manage the project (and administrators) see handover notes.Project managers add notes; existing notes are not rewritten.Rule: supabase/migrations/20260705230000_project_handover_passport.sql#phe_select · supabase/migrations/20260601091000_project_object_client_context.sql#can_manage_project | See: noChange: no | See: limitedChange: limited | See: limitedChange: limited | See: yesChange: yes |
| Follow-up tasks (internal notes)Internal operator notes — visible to administrators only.Written only through controlled admin actions.Rule: supabase/migrations/20260705235000_follow_up_tasks.sql#fut_select · supabase/migrations/20260705235000_follow_up_tasks.sql#create_follow_up_task_v1 | See: noChange: no | See: noChange: no | See: noChange: no | See: yesChange: limited |
| Admin panelsRestricted to platform administrators; the gate fails closed.Only administrators act here.Rule: apps/web/lib/auth/superadmin.ts#requireSuperadmin | See: noChange: no | See: noChange: no | See: noChange: no | See: yesChange: yes |
| Projects, objects and rostersProject managers see their own projects' rosters; workers see their own assignments.Assigning or ending a worker on a project goes only through the gated project actions, by that project's managers.Rule: supabase/migrations/20260609120000_project_worker_assignment_gate.sql#assign_worker_to_project · supabase/migrations/20260609120000_project_worker_assignment_gate.sql#end_worker_project_assignment · supabase/migrations/20260601091000_project_object_client_context.sql#project_worker_assignments | See: own onlyChange: no | See: own onlyChange: own only | See: limitedChange: limited | See: yesChange: yes |
| Service requestsRequester and provider each see their own side of a request; administrators can review.Sending, answering or withdrawing a request is done by its own two parties only.Rule: supabase/migrations/20260627145318_service_offering_requests.sql#service_offering_requests · supabase/migrations/20260627174500_requester_identity_for_provider.sql#requester_identities_for_provider | See: own onlyChange: own only | See: own onlyChange: own only | See: own onlyChange: own only | See: yesChange: no |
| Company profilesAny signed-in user can see company rows; workers additionally see the identity of companies whose demand was approved for the board.A company profile is edited by its owner; the platform team can adjust status.Rule: supabase/migrations/0001_initial_schema.sql#companies_select · supabase/migrations/20260702170000_worker_demand_approved_route_model_a.sql#list_open_demand_for_workers | See: yesChange: no | See: yesChange: own only | See: yesChange: no | See: yesChange: yes |
The "Rule" line under each row names the file in the codebase (a database policy, function or route guard) that enforces the row. These references are technical on purpose — they let anyone check that this page claims nothing broader than what the rules actually do.
Who can message whom
Every direct conversation must match exactly one of the rules below. There is no generic "allowed" — each permission names the real relationship behind it, and the default is closed.
- People who already share an active conversation can continue it.Rule: apps/web/lib/communication/communication-eligibility.ts#allowed_existing_conversation
- A company and a worker with a real employment or engagement link can message each other.Rule: apps/web/lib/communication/communication-eligibility.ts#allowed_engagement
- A company can open a conversation with a scouted worker only if the company owns the related need, the worker is on its shortlist, and the worker is currently contactable.Rule: apps/web/lib/communication/communication-eligibility.ts#allowed_scouting_shortlist · apps/web/lib/communication/communication-eligibility.ts#evaluateCommunicationRequest
- Platform administrators can open support conversations.Rule: apps/web/lib/communication/communication-eligibility.ts#allowed_admin
- In every other case there is no permission: no relationship means no contact. Phone numbers and email addresses are never part of this — messaging opens an in-app conversation only.Rule: apps/web/lib/communication/communication-eligibility.ts#no_permission
To ask a question or make a request about your data, get in touch with us — a person will review it.
This page is informational only and is not legal advice.