Privacy & Security

Memory & Privacy Model

ekkOS implements a privacy-by-architecture model where data isolation is enforced at the database level through Row-Level Security (RLS). This ensures complete privacy without relying on application-level promises.

The Core Promise

ekkOS only shares what you intentionally allow — and only as anonymized strategy patterns, never as code or content. Everything else stays private by architecture.

Overview

ekkOS implements a privacy-by-architecture model where data isolation is enforced at the database level through Row-Level Security (RLS). This ensures that:

All user data is isolated by user_id
Even service role keys cannot bypass RLS policies
Pattern sharing is opt-in and anonymized
Zero-access backend: company cannot read user memory

Row-Level Security (RLS) Enforcement

All tables in the ekkOS memory system enforce RLS policies that restrict access based on user_id:

Events Table

CREATE POLICY "Users can only see their own events"
ON events FOR SELECT
USING (auth.uid() = user_id);

Episodes Table

CREATE POLICY "Users can only see their own episodes"
ON learning_episodes FOR SELECT
USING (auth.uid() = user_id);

Patterns Table

CREATE POLICY "Users see their own patterns + collective"
ON patterns FOR SELECT
USING (
  auth.uid() = user_id OR
  (visibility = 'collective' AND never_promote = false)
);

Key Point: These policies are enforced at the database level. Even if application code has bugs, RLS prevents unauthorized access.

Pattern Visibility Flags

Each pattern has a visibility field that controls who can see it:

visibility = 'private'

Default. Only the pattern owner can see and use this pattern. Not visible to team or collective.

visibility = 'team'

Visible to all users in the same organization. Scoped by org_id.

visibility = 'collective'

Shared anonymously with all ekkOS users. Only abstract pattern templates are shared, never raw data.

Important

Setting visibility = 'collective' does NOT share your data. Only the abstract pattern template (problem/solution structure) is shared after anonymization.

never_promote Behavior

The never_promote boolean flag prevents a pattern from being considered for collective learning, even if visibility = 'collective'.

When never_promote = true:

Pattern is excluded from collective memory queries
Pattern is not considered for pattern evolution
Pattern remains private to owner (or team if visibility allows)

This gives users granular control: they can mark patterns as "never share" even if they're set to collective visibility.

How Anonymization Works

When a pattern is promoted to collective memory, the system performs the following anonymization steps:

1. Data Extraction

Extract only the abstract problem/solution structure. Remove all:

• File paths and names
• Project identifiers
• User-specific context
• Code snippets
• Credentials or secrets

2. Pattern Template Creation

Convert the pattern into a generic template:

Problem: "When [generic condition], apply [generic solution]"

Solution: "[Abstract strategy without specific data]"

3. Metadata Removal

Remove all metadata that could identify the source:

• Original user_id (replaced with null)
• Timestamps (normalized to relative time)
• Source episode IDs
• Project context

Result: The collective memory contains only abstract strategy patterns that cannot be traced back to any individual user or project.

Multi-Tenant Scoping Rules

For team/org visibility, patterns are scoped by org_id:

-- Team visibility RLS policy
CREATE POLICY "Team patterns visible to org members"
ON patterns FOR SELECT
USING (
  visibility = 'team' AND
  org_id IN (
    SELECT org_id FROM user_orgs 
    WHERE user_id = auth.uid()
  )
);

This ensures that team patterns are only visible to users who belong to the same organization, maintaining privacy boundaries within enterprise deployments.

API Reference

When creating or updating patterns via the API, you can set visibility:

Create Pattern with Visibility

POST /api/v1/patterns
{
  "title": "Fix authentication timeout",
  "problem": "...",
  "solution": "...",
  "visibility": "private",  // or "team" or "collective"
  "never_promote": false
}

Update Pattern Visibility

PATCH /api/v1/patterns/{id}
{
  "visibility": "collective",
  "never_promote": true  // Opt out of collective learning
}

Best Practices

1. Default to Private

Always create patterns as private by default. Only change visibility when you're certain the pattern is safe to share.

2. Review Before Sharing

Before setting visibility = 'collective', ensure the pattern contains no:

• Project-specific names or paths
• Credentials or secrets
• Personal information
• Proprietary code or logic

3. Use never_promote for Sensitive Patterns

If a pattern might contain sensitive information, set never_promote = true even if visibility is set to collective. This provides an extra layer of protection.