The Operating Infrastructure Spec.Read it. Audit it. Then decide.

This excerpt shows how SeniorCRE represents governed entities and lineage in a validation environment. The operator establishes the definition, source authority, decision context, reconciliation, adjudication, lineage, and preservation rules. The tables do not declare enterprise truth on the operator's behalf.

Status as of November 13, 2026: designed architecture, not yet implemented in any community; illustrative records, no operator-production deployment, no operator-production connector, and no independent outcome or security validation. Production acceptance remains a documented operator decision.

1. Data dictionary (canonical entities)

The eight rows below are representative technical entities. They become governed only when the operator declares what each means, which source has authority for the decision, how disagreement is reconciled, and how the decision is preserved with lineage.

2. Event model

These representative events show the intended lineage envelope: what changed, who or what produced it, which decision context consumed it, and what alternate valid value was preserved. They are designed architecture, not operator-production throughput evidence.

3. RBAC matrix — 33 roles

The matrix documents role and scope design built; not validated. Authorization sits between decision and execution; role membership alone does not authorize a consequential action. Operator policy, data scope, and acceptance testing govern production access.

4. Tenant isolation pattern

The validation architecture applies three isolation rules:

1. Governed records carry operator scope. The validation design makes scope explicit either directly or through the entity hierarchy.
2. Validation policies are deny-by-default. Production acceptance requires operator-specific policy and isolation testing.
3. Policies call server-side access helpers only. The functions read auth.uid(), resolve the user's operator membership and role, and return a boolean. They never accept user-provided IDs.

-- Canonical isolation policy (illustrative)
create policy "operator_read_residents"
on public.residents
for select
to authenticated
using ( public.is_operator_member(operator_id) );

create policy "operator_write_residents"
on public.residents
for insert
to authenticated
with check (
  public.is_operator_member(operator_id)
  and role-based access checks
);

-- server-side access helpers helper (excerpt)
create or replace function public.is_operator_member(_operator_id uuid)
returns boolean
language sql stable security definer
set search_path = public
as $$
  select exists (
    select 1
    from public.operator_members
    where user_id = auth.uid()
      and operator_id = _operator_id
  )
$$;

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 Aurora + WorkOS in CI — remaining work, not claimed as done. The test that fails most often in CI is the one that catches a new table shipped without tenant isolation — by design.

5. Audit log

The validation design uses append-only lineage events carrying actor, operator, entity, operation, change, and timestamp. This is designed architecture, not a completed operator-production audit trail. SeniorCRE does not claim SOC 2 certification or its own SOC 2 report.