pg-what-if-is-safely-simulated
IN derived (depth 1)
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.
Summary
The what-if analysis in PgApi gives you accurate predictions of what would happen if you changed a belief, without actually changing anything. It works by running real database mutations inside a transaction and then rolling back, so you get the full cascade effects computed by the actual propagation engine rather than an approximation, but the database ends up exactly as it was before.
Justifications
SL — Transaction rollback bridges the gap between accurate simulation and mutation safety
Antecedents (all must be IN):
- pg-what-if-uses-transaction-rollback — `what_if_retract`/`what_if_assert` perform real mutations inside a transaction, collect cascade effects, then rollback — reusing the propagation engine without duplicating logic.
- pg-api-what-if-never-mutates — `PgApi.what_if_retract()` and `what_if_assert()` are read-only operations — they return cascade analysis (changed/went_in/went_out) without modifying database state, verified by checking `get_status()` before and after
Dependents
These beliefs depend on this one:
- 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