Multi-Tenant Data Isolation
Every entity carries a tenant identifier with automatic filter enforcement at the query level. One state's data is physically isolated from another, by design.
Key benefits
- · Tenant identifier on every entity, enforced automatically
- · Unique constraints include tenant partition (no collision across tenants)
- · Cross-tenant data queries structurally impossible at the ORM layer
- · Filter disable requires deliberate architectural exception (for shared reference data)
The guarantee
Every entity in VCPMS — claims, payments, documents, offenders, Payees, every one — carries a TenantId field. ABP’s MustHaveTenant filter enforces tenant scoping at the ORM layer on every query. A programmer would have to make a deliberate, architecturally-exception-tagged override to query across tenants.
Why this matters for states
State programs hold highly sensitive data — medical records, crime-scene information, protected PII about trauma survivors. Cross-state leakage would be a serious compliance event. VCPMS makes cross-state leakage not a matter of query discipline but a matter of physics at the query layer: the filter runs before any query executes.
Unique constraints
Uniqueness constraints in the database include the tenant partition. For example, the “ShortName” identifier (“VC-2025-0142”) is unique per tenant, not globally — so Oklahoma and Maine can both have VC-2025-0142 records without any conflict.
Auditability
Deliberate cross-tenant filter overrides are few (e.g., shared AI knowledge articles viewable across tenants), explicit in the code, and code-reviewable. No implicit cross-tenant queries can exist.