Skip to content

ADR-007: Privacy Model — Readability Transparent, Trust Private

Status: Accepted Date: 2026-03-10 Context: Multiplayer introduces two new signal types: peer readability (Mirror Match — how well players predict each other) and trust ratings (Trust Circle — who you'd delegate decisions to). These signals have different privacy requirements.

Decision

Two distinct privacy models:

  1. Readability = transparent. All session participants can see each other's readability scores and prediction accuracy. RLS on peer_readability_scores allows read access for all session participants.

  2. Trust = private. Trust ratings are never shown to the person being rated. RLS on trust_edges only allows users to read their OWN trust data (trust they've given, not received). Trust data aggregates into delegation_preferences via EMA, also private.

Rationale

Readability and trust serve different purposes and need different privacy guarantees to produce honest signal:

  • Readability is fun. Seeing "Alex predicted your choice correctly!" creates positive social dynamics. Even being "misread" is interesting, not threatening. Transparency encourages engagement.
  • Trust must be honest. If players knew their trust ratings were visible, they'd rate diplomatically instead of honestly. The DTA needs truthful delegation preferences — "I trust Sarah's judgment on governance but not Jordan's" — and that only works if ratings are private.

Alternatives Considered

  • Both transparent: Would make trust ratings performative and useless. Players would avoid giving low trust scores to avoid social friction.
  • Both private: Would remove the fun social element of readability. "Did my friend predict my choice?" is a core engagement loop.
  • Anonymous trust (show aggregate, not individual): Considered but even aggregate trust scores could be reverse-engineered in small groups (3-4 players).

Consequences

  • Trust data is the first truly private signal in the system — players must understand it's never shared.
  • The DTA uses trust topology (delegation preferences, reciprocal pairs) as social context in predictions, but this context is never exposed to other players.
  • Future features that display trust-related information must go through careful privacy review.

How We Got Here

When multiplayer was being designed (Week 9), the initial assumption was that all social signals would be transparent — readability AND trust. The reasoning was "more transparency = more engagement."

The problem surfaced when we thought through what trust ratings would look like in small groups. In a 4-person Beacon Collective game, if trust ratings were visible, you'd know that Sarah rated you a 2/5 on governance trust. That creates social friction — not because the rating is wrong, but because relationships aren't designed for that level of quantified candor. People would self-censor, rating everyone 4/5 to avoid conflict.

This was framed as "the Matt problem" — a specific scenario where the DTA needs to know whose proposals to scrutinize vs. support. Trust Circle (WHO to trust/distrust, carrying ~80% of the signal) and peer prediction rationale (WHY, ~20%) together give the DTA the social context it needs. But this only works if trust ratings are honest, which means they must be private.

The two-model approach (transparent readability, private trust) emerged from recognizing these are fundamentally different types of social signal:

  • Readability is a game mechanic. "Did I predict Alex?" is competitive and fun. Being unpredictable is interesting, not threatening. This signal benefits from visibility because it drives engagement.
  • Trust is a governance input. "Do I trust Jordan's judgment on resource allocation?" is consequential and personal. This signal benefits from privacy because honesty requires safety.

The RLS implementation enforces this at the database level — not just the UI. Even if someone queries the API directly, they can only see trust edges they've created, never trust edges about them. This was intentional: privacy guarantees must be structural, not cosmetic.

Key files: - peer_readability_scores table — RLS allows session participant reads - trust_edges table — RLS restricts to own data only - delegation_preferences table — aggregated via EMA, private