storage-layer-is-backend-agnostic-and-safe
IN derived (depth 3)
Both storage backends provide equivalent safety guarantees through backend-appropriate mechanisms: atomic isolated mutations (context-managed load/save for SQLite, per-method transactions for PgApi) and safe hypothetical reasoning (write-flag gating for SQLite, transaction rollback for PgApi), making safety properties independent of backend choice.
Summary
No matter which database backend you pick — SQLite or PostgreSQL — the system's safety promises stay the same. Each backend uses its own technique to keep changes atomic and to let the system explore "what if" scenarios without accidentally saving anything, so switching backends doesn't weaken any guarantees.
Justifications
SL — Backend-agnostic atomicity plus backend-agnostic what-if simulation establish a uniformly safe storage layer
Antecedents (all must be IN):
- atomicity-is-backend-independent — Both storage backends enforce atomic isolated operations through backend-appropriate mechanisms: the SQLite backend uses context-managed load/save with write-flag gating and per-function transaction scope, while PostgreSQL uses per-method transactions with composite-key multi-tenancy — achieving the same transactional guarantee at different architectural levels
- both-backends-support-safe-hypothetical-reasoning — Both storage backends enable hypothetical what-if reasoning without permanent mutation: PgApi performs real mutations inside a transaction then rolls back, while the in-memory backend uses write-flag gating to discard speculative changes after analysis
Dependents
These beliefs depend on this one:
- 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.
- 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.
- safety-is-enforced-across-all-layers-and-backends — Safety is enforced uniformly across both the architectural dimension (clean layer boundaries with atomic isolated mutations) and the storage dimension (equivalent guarantees through backend-appropriate mechanisms in SQLite and PostgreSQL) — no safety property depends on a specific backend or architectural layer.
- 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.