both-backends-support-safe-hypothetical-reasoning
IN derived (depth 2)
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
Summary
Both storage backends let you explore "what would happen if" scenarios safely. The PostgreSQL backend runs real changes inside a transaction and then rolls them back, while the in-memory backend simply discards changes by never writing them to disk. This means you can test the consequences of retracting or adding beliefs without risking actual data corruption in either environment.
Justifications
SL — Transaction rollback (PgApi) and write-flag gating (SQLite) achieve the same safe-simulation guarantee through backend-appropriate mechanisms
Antecedents (all must be IN):
- pg-what-if-is-safely-simulated — PgApi's what-if operations achieve safe simulation: mutations are performed against real PostgreSQL data for accurate cascade analysis, then rolled back within a transaction to guarantee zero persistent side effects — combining fidelity with safety.
- write-false-prevents-persistence — Functions using `_with_network(write=False)` can mutate the in-memory network (as `what_if_retract` does) but changes are never saved to SQLite; write-or-not is declared upfront and never conditional.
Dependents
These beliefs depend on this one:
- storage-layer-is-backend-agnostic-and-safe — 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.