Document 03 — Data Isolation

Complete Data Separation by Design

Every feast's financial data is isolated. Your numbers stay yours.

Visual Overview

How Isolation Works

Each feast operates in its own secure data silo. No feast can see, access, or modify another feast's information.

Feast A
Transactions
Tithers
Reports
No Cross-Access
Feast B
Transactions
Tithers
Reports
Hierarchy

Scope Hierarchy

Data visibility is controlled at four distinct levels. Each level sees only what it should.

01
Feast Level
Sees only their own feast's transactions, tithers, reports, attendance, and budget. Completely isolated from every other feast.
02
District Level
Sees aggregated data from all feasts in their district only. Cannot drill down into individual feast transactions unless permitted.
03
Area Level
Sees aggregated data from all districts in their area only. A broader view, but still limited to their geographic scope.
04
Provincial Level
Sees aggregated data from all areas, providing a full provincial overview. The only level with complete top-down visibility.
Practical Examples

Real-World Isolation

Concrete examples of how data isolation protects every level of the hierarchy.

Finance Officer of District 1 cannot see District 2's transactions
Feast Builder of Feast A cannot view Feast B's tithe records
Area Builder of Area North cannot access Area South's reports
Each level's financial account is completely independent
Access Control

Role Access Matrix

A complete breakdown of what each role can and cannot see across the hierarchy.

Role Own Feast Data Other Feast Data District Aggregate Area Aggregate Provincial Aggregate
Feast Finance ✓ ✕ ✕ ✕ ✕
Feast Builder ✓ ✕ ✕ ✕ ✕
District Builder ✓ — ✓ ✕ ✕
District Finance ✓ — ✓ ✕ ✕
Area Builder ✓ — ✓ ✓ ✕
Area Finance ✓ — ✓ ✓ ✕
Provincial Team ✓ ✓ ✓ ✓ ✓

✓ Full Access    — Within own scope only    ✕ No Access

Under the Hood

How It Works Technically

Data isolation is not just an application feature — it is enforced at the database level and cannot be bypassed.

PostgreSQL Row Level Security
RLS policies are defined on every table. Each row is tagged with feast_id, district_id, or area_id and filtered automatically based on the authenticated user's scope.
Filtered by auth.uid()
Every database query is automatically filtered by the authenticated user's ID. The system looks up the user's role and scope, then returns only matching rows.
Role & Scope Verification
The user's role (e.g., feast_builder) and scope (feast_id, district_id, area_id) are checked against every data request. Mismatches return empty results.
Cannot Be Bypassed
Even direct API calls are blocked. RLS is enforced at the database level by PostgreSQL itself — no application code can override it. Security is structural, not optional.