Privacy Architecture
Most platforms promise privacy
in a Terms of Service.
We enforce it in the database.
See how Mentor makes individual mentoring data architecturally invisible to leadership — not hidden behind an access control that someone could override, but genuinely impossible to retrieve.
The Problem
Policy promises erode the moment
someone has admin access.
NDAs can be overridden. Access controls can be escalated. When there is a technical path to view individual data, trust erodes — even if no one takes it. The existence of the path is the problem.
Policy-Based Privacy
- Access controls (revocable)
- NDAs and contracts
- Trust-based promises
- Admin override possible
Architecture-Based Privacy
- Database-level enforcement
- Minimum group size thresholds
- No admin override by design
- Impossible, not just prohibited
How We Enforce It
Three layers of architectural enforcement.
Privacy is not a feature we built on top. It is embedded in row-level security policies, minimum group size thresholds, and hierarchical scope rules.
What each person sees
What You See
Full personal detail
- Your session notes
- Your patterns
- Your commitments
- Your growth areas
What Leaders See
Aggregated only
- Team engagement trend (8+ people)
- Department alignment direction
- Aggregate commitment follow-through
- Group development themes
How data flows through the privacy gate
Your Session
Private by default
Processing
Encrypted in transit
Privacy Gate
Enforced at database
Your Private View
Full detail, only you
Team Aggregates
Groups of 3+ only
Scope-based visibility by hierarchy level
The enforcement in pseudocode
-- Users can only read their own mentoring data
CREATE POLICY user_isolation ON mentoring_data
FOR SELECT USING (
user_id = auth.uid()
);
-- No admin override. No backdoor query.
-- The database rejects the request before
-- application code is involved.FUNCTION enforce_minimum_group_size(data, group)
IF group.member_count < MIN_CLUSTER_SIZE (3)
RETURN null
-- Data is hidden, not shown as zero.
-- Leaders never know this group exists.
RETURN aggregate(data)
-- Only pre-computed averages and trends.
-- Individual records never leave the table.FUNCTION resolve_visible_scope(leader, hierarchy) scope = leader.position_in_hierarchy -- Company-wide: aggregated across all departments -- Department: only teams within their department -- Team: only their direct reports (if 3+ members) RETURN filter_to_scope(scope) -- Leaders see only what their position permits. -- No escalation path. No request form.
What This Means
Privacy that serves everyone.
For Employees
Your mentoring stays yours
Session content, personal patterns, and growth reflections are never visible to anyone in your organization. Not your manager. Not HR. Not the CEO.
No one can access your individual sessions
There is no admin panel, no override, no emergency access that reveals individual mentoring data. The database physically cannot return it.
Your growth is private by default
Every piece of personal data is isolated at the row level. Privacy is not a setting that someone turns on. It is the architecture itself.
For Leaders
Real signal from real engagement
Because employees know their privacy is protected architecturally, they engage honestly. Your aggregate data reflects reality, not performance theater.
Aggregate patterns you can act on
See department-level themes, commitment follow-through rates, and engagement direction. Enough to lead well. Never enough to surveil.
Trust that compounds over time
When people trust the system, participation deepens. Richer data produces sharper organizational signal. Privacy is not a constraint on leadership visibility. It is the foundation of it.
Built on verifiable commitments
Privacy your people can verify.
Not just believe.
Deploy Mentor to a team of 25. See how architectural privacy changes the quality of engagement when people know their mentoring is genuinely theirs.