The Operating Infrastructure 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
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 intended to serve state survey response and SOC 2 examination when an attestation is issued (readiness in progress; no report has been issued).
Frequently asked questions
- Who is this spec for?
- Engineering, data, and security leaders at multi-site operators, PE platform teams, REITs, and integration partners. It is the technical evidence base buyers reference when evaluating a system of record over $250K ARR.
- Is this the full schema?
- No — it is the canonical-entity excerpt. The full schema is hundreds of tables. The eight entities documented here are the spine; every other table is a child, join, or computed projection of these.
- How is RBAC enforced?
- A Postgres enum (app_role) plus server-side access helpers (e.g., server-side access helpers) gate every mutation. The function set is enforced at the database layer via multi-layer tenant isolation policies on every public table.
- How is tenant isolation enforced?
- Every public table carries operator_id (directly or transitively). multi-layer tenant isolation is enabled on every table. Policies call server-side access helpers tied to auth.uid() and the operator hierarchy. A bug in application code cannot leak data across tenants because the database refuses to return it.
- Is the event model durable?
- Yes. Events are emitted by database triggers and edge functions into an append-only event table, then fanned out to subscribers (audit, billing, investor monitor, etc.). The event table is the same source the audit log reads from.
https://seniorcre.com/operating-system-spec