pgapi-partial-api-coverage
OUT premise — entries/2026/04/28/reasons_lib-pg.md
Reason OUT: All PgApi feature issues closed: #51 (challenge/defend/compact), #55 (what-if), #60 (coverage gaps), #63 (queries), #64 (export), #65 (namespace), #66 (import), #67 (maintenance), #68 (derive), #69 (dedup), #70 (repos/list-negative). Only #133 (N+1 perf) remains as optimization.
PgApi implements core operations (add/retract/assert/search/nogood/explain) but defers simulation, dialectics, namespace support, import/export, and maintenance operations to future work
Summary
The database API layer covers the essential reasoning operations needed for day-to-day use but is missing several advanced features. This means simulation, argumentation, multi-namespace support, and bulk import/export aren't available yet, limiting the system to basic belief management without the more sophisticated analytical capabilities.
Dependents
These beliefs depend on this one:
- OUT backend-agnostic-operational-assurance — The system's comprehensive operational assurance — spanning temporal self-correction, end-to-end reliability, and external control — holds identically across both storage backends with equivalent safety guarantees, provided PgApi achieves full API parity with the SQLite path.
- OUT backend-independent-self-correction — The complete self-correction pipeline — contradiction resolution through dependency-directed backtracking, staleness detection through source hash comparison, and ongoing belief currency management — operates identically across all storage backends, making the system's self-maintaining properties a deployment-independent guarantee rather than a backend-specific capability.
- IN complete-architecture-is-backend-portable — The deterministic lifecycle-complete architecture — with its predictable state trajectories, gapless lifecycle monitoring, and uniform safety enforcement — operates identically across all storage backends, achieving full portability between SQLite and PostgreSQL.
- IN dual-backend-atomicity-is-feature-complete — Both storage backends provide atomic isolated operations with complete API coverage — the SQLite backend's context-managed mutations and PgApi's per-method transactions cover the same full set of operations
- IN dual-storage-backends-are-interchangeable — Both SQLite and PostgreSQL backends can be used interchangeably for any operation, with identical safety guarantees through backend-appropriate mechanisms and complete API surface coverage, so applications can switch backends without behavioral changes.
- OUT operational-profile-spans-all-backends — The safe, assured, resource-bounded operational profile holds identically across all storage backends — the same safety, assurance, and resource-efficiency guarantees apply uniformly to both SQLite and PostgreSQL deployments.
- OUT pgapi-achieves-implementation-parity — PgApi achieves full behavioral parity with the in-memory Network implementation: it reimplements the core algorithms (entrenchment scoring, nogood resolution, BFS propagation, dialectics) in SQL with BFS propagation executed in application-level Python.
- OUT pgapi-is-complete-sql-reimplementation — PgApi is a complete SQL-native reimplementation of the in-memory Network: it re-implements core algorithms (BFS propagation, entrenchment scoring, nogood resolution) directly in SQL with multi-tenant composite keys and per-method transaction semantics, achieving full behavioral parity.
- IN rich-governance-spans-all-backends — The system's exception-safe rich lifecycle governance — deterministic, lifecycle-complete, and spanning revision through source integrity — operates identically across all storage backends, achieving full behavioral parity between SQLite and PostgreSQL for metadata-enabled lifecycle management.
- IN storage-is-fully-production-grade-across-backends — Both storage backends achieve fully production-grade operation — concurrent access optimization (WAL mode, derived FTS5 indexes), equivalent safety guarantees (atomic isolated mutations through backend-appropriate mechanisms), and multi-tenant isolation — when both backends provide complete API coverage.
- OUT verified-correctness-extends-to-all-backends — Verified production correctness — spanning all belief origins with deterministic state trajectories and full maintenance loop observability for indefinite independent verification — extends identically across both SQLite and PostgreSQL storage backends with no backend-specific safety gaps.