The Operating System Spec | Data Model, Event Model, RBAC, Tenant Isolation
Most senior care platforms publish brochures. We publish the spec. The eight canonical entities below are the spine of every workflow on SeniorCRE® — clinical, financial, workforce, compliance, and investor. The event model is the durable interface between them. The RBAC matrix and tenant isolation pattern are how we guarantee that an operator's data never leaves their boundary, even when the application layer has a bug.
1. Data dictionary (canonical entities)
The eight tables below own the truth. Every other table on the platform is a child, join, or computed projection.
2. Event model
Domain events are how the canonical entities talk to the rest of the platform. Every event is durable, append-only, and replayable. The same event stream feeds the audit log, the investor rollup, and the threshold monitors.
3. RBAC matrix — 33 roles
Roles are a Postgres enum ( app_role ) and are checked at the database layer via server-side access helpers and related server-side access helpers helpers. Permissions cascade through the entity hierarchy: a regional director inherits read access to every property in their region; a property administrator does not see siblings.
4. Tenant isolation pattern
Isolation is enforced at the database, not the application. Three rules:
Operator/tenant isolation policies are version-controlled in migrations and the application connects under a non-owner database role, so Row-Level Security fails closed — a missed application check returns zero rows, never another operator's data. Per-facility isolation is enforced in the application layer today, with extension to database RLS under active evaluation alongside automated cross-facility isolation tests. The pgTAP suites ( 001-rls-enabled.sql , 002-auth-tenant-isolation.sql , 003-compliance-audit.sql ) were authored against the prior Supabase schema and are being ported to…
5. Audit log
The audit log is append-only at the schema level (no update or delete grants on audit_events ) and is generated by triggers on every canonical table. Each row carries the actor, the operator, the table, the row id, the operation, the JSON diff, and the timestamp. This is the same evidence base used for state survey response and the SOC 2 Type II report (Type I and Type II in progress).
https://seniorcre.com/operating-system-spec