pg-multi-tenancy-is-referentially-complete

OUT derived (depth 2)

PgApi's multi-tenant isolation with composite primary keys and application-level BFS propagation prevents all cross-project data leakage and ensures consistent truth maintenance — unless antecedent references stored as JSONB arrays lack foreign key constraints, allowing phantom node references within a project.

Summary

The system's multi-tenant database design was thought to fully prevent data from leaking between projects, but this claim has been retracted. The core concern is that node references stored as JSON arrays inside the database aren't enforced by foreign key constraints, so a belief could reference nodes that don't actually exist within its project, creating phantom dependencies that undermine the integrity of truth maintenance.

Justifications

SL — Multi-tenant isolation (depth-1) and consistent propagation semantics (depth-0) are undermined if JSONB reference arrays can point to nonexistent nodes without database-level enforcement

Antecedents (all must be IN):

  • pgapi-is-sql-native-multi-tenant — PgApi operates as a SQL-native multi-tenant implementation: all operations execute directly against PostgreSQL with no in-memory Network object constructed, composite primary keys on all tables provide project-level isolation, and each public method is a single committed transaction.
  • pgapi-bfs-propagation-in-python — PgApi implements BFS propagation in application-level Python (not stored procedures), using JSONB containment queries (`@>`) against GIN indexes to find dependents

Unless (any of these IN defeats this justification):

  • pg-antecedent-refs-have-no-fk-constraints — Antecedent and outlist references in `rms_justifications` are JSONB arrays without foreign key constraints; nonexistent referenced nodes default to truth value OUT via `truth_cache.get(a, "OUT")`.

Details