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

How data flows through the privacy gate

Scope-based visibility by hierarchy level

The enforcement in pseudocode

Row-Level Security Policy
-- 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.
Minimum Group Size Enforcement
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.
Hierarchical Scope Enforcement
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

AES-256-GCM field-level encryption on all mentoring data
GDPR rights enforced: access, portability, erasure, rectification
Zero-trust engineering access. No default read on personal data
Raw audio deleted immediately after session transcription
Annual transparency report commitment

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.