Who can see what
The constraints are in the database, not in a policy document.
People are being asked to say true things about colleagues they will see tomorrow. That only works if the guarantees are real, so most of them are enforced where they cannot be reconfigured by an administrator in a hurry.
Facets is two products behind one login, and they make two different promises. Peer and upward feedback is developmental: it goes to the person it is about, and no account can read an individual’s ratings. The manager tools are a performance record: a manager writing down what they think of someone who reports to them. This page covers both in that order, and the section after them explains why they cannot be joined.
Who sees what, role by role
Team members and raters
Their own answers, while the survey is open, through their personal link. Afterwards, their own individual note. Nothing about anyone else as an individual.
The team lead
The roster, how many people have started and submitted — as counts, never names against a status — and the shared team pack once released. No individual peer scores, no individual notes, no written comments.
A facilitator, when one is attached
Everything the lead sees, plus data-quality signals, unusual rating patterns between specific pairs, and anything the automated checks flagged. A facilitator exists to put a human between a machine-written report and a person reading it about themselves.
Managers and HR
Nothing from the feedback side, in that capacity. A manager who is also a member of the team gets exactly what every other member gets, and nothing more. There is no role, no setting and no export that hands a manager another person’s peer ratings or their individual note.
The manager tools are a different matter and are covered below: there a manager records goals, bands and written assessments about named people, and those records are theirs to read and to export. What they never contain is anything from the feedback side.
The tables holding raw peer ratings, comments, nominations, and members’ self-assessments have no read policy for any signed-in account at all. They are reachable only by server code holding a service credential, after it has verified either a member’s single-use token or a staff role. Adding a “let managers see scores” feature would not be a settings change; it would be a schema migration and a visible one.
Every access to a released report is written to an audit log.
The manager tools: who can see what
A different product with a different promise, described separately because conflating them is exactly the mistake this page exists to prevent.
The manager
Their own roster and everything on it: goals, quarterly bands, 1:1 notes, colleague input and assessments, for the people who report to them. Another manager’s records are not theirs to see: the row-level rules make a manager’s query for another manager’s person look identical to asking for a person who does not exist. The one way past that wall is deliberate and visible — an owner or admin of the workspace can open a record to read it, never to change it, and every open is logged with their name and the date and shown to the manager who keeps the record.
The person being assessed
There is no in-app view for them yet, which is a gap rather than a feature. The assessment exports as a document written to be handed over — fairness notes first, the rationale beside the band, and a closing line naming what fed it. Separately: in most places a written characterization of an employee is personal data that person can ask to see, and the app says so wherever a manager types about someone.
Colleagues who are asked for input
They are told, in bold, before they type: their manager will read what they write, with their name on it, and will use it when writing this person’s assessment. There is no anonymity offered here, because with two or three respondents it could not be delivered. Declining is a real button, the manager learns only that somebody declined, and any half-written draft is discarded.
Teammates on an idea board
An idea board is a manager asking their team one question and answering what comes back, and it makes a third promise rather than borrowing one of the two above. Each board carries one of four settings for names, chosen before anybody posts and fixed from that moment: hidden from teammates but seen by the manager; hidden from everyone, the manager included; shown to everyone; or each person’s own choice, post by post, which is the default. People write under the setting they were shown, which is the reason it cannot be changed underneath them afterwards.
On the setting that hides names from everyone, it is the database that withholds them. Who wrote what is kept in its own table, and the rule admitting a manager to that table does not hold for such a board — so the manager, the logged admin path and the export all get no rows at all, rather than a page that knows the answer and declines to show it.
Votes and reactions are counts under every one of the four settings. Nobody sees who voted, the manager included, and there is no setting that changes it. An owner or admin can open a board to read it by the same logged path they open a People record by, with their name and the date recorded and shown to the manager who runs it.
If the manager has switched GIFs on, the picker searches GIPHY from our servers and we serve the chosen image from ours, so GIPHY is told the words somebody typed and no account identifier, and the browser of anyone reading the board never contacts it.
Nothing on a board is part of any performance record. No board table references a People record in either direction, so an idea cannot become a goal, a line in a check-in, or evidence in an assessment; a manager who wants to act on one copies the words across by hand, into their own.
Us, and HR
There is no HR role and no organization-wide view on a single manager plan. On the Organization plan, owners and admins can open any manager’s record through the logged path above; there is still no export of everyone at once and no view that reads across records without opening each one. Our own operator console can reach account and billing metadata and is blocked at the column level from every table on this side — assessments, goals, colleague input and the rest — with a test that fails the build if a new table is added without someone deciding which side of that line it is on.
Why the two cannot be joined
Not by policy. Exactly one table joins the two, and it is the record of a summary somebody chose to send — described below. No other table on either side references the other, and no policy lets even that one be read back through into the review or its raters. There is no join to write, so nobody writes one by accident.
One route exists and it belongs to the person the feedback is about. After reading their own leadership brief they can tick the parts they want to pass on, add a note, and send it to their manager. What lands is a copy. Three parts are not shareable at all — the paraphrased themes from what colleagues wrote, the gap between how they see themselves and how others do, and the exact rater counts, which on a small group narrow it too far.
Attaching an incoming summary to someone’s record is a manual act. The system knows the sender’s email address and could match it automatically; doing so would be the first automatic connection between a developmental review and a performance record, which is the one thing this architecture exists to prevent.
The honest limits of anonymity
On a three-person team, anonymity is arithmetic, not a promise.
Written comments are never quoted back to the people they are about.
A team’s named facilitator does read what was written, in full.
On a small idea board, not signing can be as visible as signing.
Data protection law may reach further than our promises.
Where AI is involved, and where it is not
Scoring is entirely deterministic. No model decides a number, a threshold, or whether a result is shown to you.
A language model may be used to write the narrative parts of a team pack or a leadership brief. When it writes a team pack it is given the team-level aggregates and nothing else: no individual ratings, no per-rater information, and none of the written answers anyone submitted. It cannot reproduce a colleague’s phrasing because it was never shown any. For a leadership brief it receives the scored evidence pack — scores, gaps, response counts — together with the written comments, with the writer’s identity removed and only once enough people have responded for anything to be reported. It never receives the confidential box for the facilitator. It is instructed to paraphrase and never quote, and the checks below hold it to that.
On a leadership review a model may also write one or two follow-up questions to a rater, and may ask for an example. For that it is shown only what that one rater has said — their ratings and their comments, never anyone else’s, never the leader’s self-ratings, and never the confidential box. Each question passes a fixed set of checks before it is shown: it may not ask the rater to name or single out a colleague, use a trait word, speak in the first person, or ask more than one thing. A question that fails is replaced by a fixed one. The brief writer is then instructed to describe a particular example only when more than one person raised it and to fold a single person’s example into the pattern it illustrates — an instruction, held to by review, not something a check can measure.
A pack or a brief it writes then has to pass the same automated checks as the template version: every score-like number matched against the underlying data, no trait adjectives, no ranking language, no speculation about motive, no causal claim about your results, and no six-word run shared with anything anyone wrote. A team pack that fails is replaced by the deterministic version rather than released — there is no review step between it and the whole team. A brief that fails is regenerated or held for a human.
Your ratings and comments are not used to train anyone’s model. If no AI provider is configured, the deterministic template writes the brief instead — and it is a complete brief, not a degraded one.
Practical details
Access links
A member’s link contains a random token, and only a one-way hash of it is stored. Nobody — including us — can look up an existing link and read it back. A lost link has to be re-issued, which invalidates the old one.
Where data lives
A managed Postgres database and a hosting provider, both in the United States. Transactional email goes through a third-party sending provider, and where a language model writes a pack or a draft the request goes to an AI provider. These are named individually in the privacy policy.
Deletion
A team or a review can be deleted, and that removes the underlying ratings with it. Ask through the contact form and it will be done; a self-serve control is on the list.
This page describes how the product behaves. The privacy policy is the legal document.
Questions about any of this are welcome
If something here is not specific enough to satisfy your legal or security review, say what you need and you will get a straight answer, including where the answer is “not yet”. Ask through the contact form. The security page covers the infrastructure underneath all of this — where it runs, what encrypts it, what the backups guarantee, and the controls that do not exist yet.
If you were invited to answer a survey or asked about a colleague and want to see, correct or delete what is held about you, that form reaches us directly — no account needed, and no need to go through whoever invited you.