Delta Repair with Sanity Check

• The paper introduces a delta-rule framework that generates tuple-deletion repairs verified by a stability check ensuring that no delta rule remains satisfiable.
• It formalizes four repair semantics—independent, step, stage, and end—highlighting tradeoffs between minimality, cascade behavior, and computational complexity.
• Experimental evaluations demonstrate that repair size and performance vary significantly with each semantics, confirming the need for multiple repair semantics.

Searching arXiv for the cited work and closely related papers on delta-based repair and sanity-check frameworks. In the Delta Rules framework for declarative database repairs, candidate tuple deletions are represented explicitly in delta relations and are accepted only when the resulting database is stable. Under this reading, “Delta Repair with Sanity Check” consists of generating tuple-deletion repairs through delta rules, then validating the resulting state by requiring that no delta rule remains satisfiable. The framework is designed for tuple-deletion repairs, is highly expressive, and supports Denial Constraints, Causal Rules, and database-trigger-like behavior; its central claim is that there is no one-size-fits-all repair semantics in this setting, so multiple semantics are defined and compared (Gilad et al., 2020).

1. Formal basis: Delta Rules and tuple-deletion repair

A database is assumed over base relations $\mathbf{R}=(R_1,\ldots,R_k)$ together with delta relations

$\mathbf{\Delta} = (\Delta_1,\ldots,\Delta_k),$

where each $\Delta_i$ has the same schema as the corresponding base relation $R_i$ (Gilad et al., 2020). The intended meaning is operational and declarative at once: tuples appearing in $\Delta_i$ are tuples of $R_i$ that should be deleted.

A delta rule has the form

$$\Delta_i(\mathbf{X}) :- R_i(\mathbf{X}), Q_1(\mathbf{Y}_1), \ldots, Q_\ell(\mathbf{Y}_\ell)$$

where each $Q_j$ is either a base relation in $\mathbf{R}$ or another delta relation in $\mathbf{\Delta}$ (Gilad et al., 2020). If the body holds, then the tuple $\mathbf{\Delta} = (\Delta_1,\ldots,\Delta_k),$0 should be deleted. Because delta atoms may occur in rule bodies, deletions can cascade across relations and across previously derived deletions. A repaired database is therefore obtained by removing tuples from $\mathbf{\Delta} = (\Delta_1,\ldots,\Delta_k),$1 and adding corresponding tuples to $\mathbf{\Delta} = (\Delta_1,\ldots,\Delta_k),$2.

This formulation is more general than a single integrity-constraint repair operator. It is meant to encode complex, cross-relational repair logic and to provide explicit semantics for cascaded deletion patterns that, in practice, may otherwise be left implicit in trigger execution or application logic (Gilad et al., 2020).

2. Stability as the sanity check

The framework’s closest analogue to a sanity check is the notion of a stable database. Given a database $\mathbf{\Delta} = (\Delta_1,\ldots,\Delta_k),$3 over $\mathbf{\Delta} = (\Delta_1,\ldots,\Delta_k),$4 and a delta program $\mathbf{\Delta} = (\Delta_1,\ldots,\Delta_k),$5, $\mathbf{\Delta} = (\Delta_1,\ldots,\Delta_k),$6 is stable if no rule of $\mathbf{\Delta} = (\Delta_1,\ldots,\Delta_k),$7 is satisfied:

$\mathbf{\Delta} = (\Delta_1,\ldots,\Delta_k),$8

A candidate repair is therefore not validated merely by deleting some tuples; it is validated only if the post-repair state leaves no applicable delta rule (Gilad et al., 2020). In procedural terms, one may view the repair-generation process as: choose tuples to delete, add them to $\mathbf{\Delta} = (\Delta_1,\ldots,\Delta_k),$9, and then check whether the resulting state is stable.

The related notion of a stabilizing set makes this precise. A set $\Delta_i$0 is a stabilizing set if

$\Delta_i$1

is stable (Gilad et al., 2020). This makes stability a filter on candidate repairs rather than a separate optimization criterion. The paper further proves the following proposition: for every database $\Delta_i$2, program $\Delta_i$3, and semantics $\Delta_i$4, both $\Delta_i$5 and $\Delta_i$6 are always stabilizing sets. A stabilizing repair therefore always exists (Gilad et al., 2020).

A common misconception is to equate stability with minimality. The framework explicitly separates these notions. Stability is the admissibility condition; minimality, operational fidelity, determinism, and runtime depend on which semantics is chosen.

3. Repair semantics: independent, step, stage, and end

Because different applications require different notions of repair, the framework defines four semantics rather than a single canonical one (Gilad et al., 2020).

Semantics	Core idea	Complexity / property
Independent	Smallest stable deletion set	NP-hard
Step	Single-rule immediate cascading deletion	NP-hard
Stage	Batched derivation and deletion by round	PTIME; unique fixpoint
End	Derive all deltas first, delete only at fixpoint	PTIME

The independent semantics $\Delta_i$7 is the smallest subset $\Delta_i$8 such that $\Delta_i$9 contains no satisfying assignment for any rule in $R_i$0 (Gilad et al., 2020). This is the global minimum-repair view: delete as few tuples as possible, ignore operational firing order, and require stability of the final database.

The step semantics is the most operational. At each step $R_i$1, one applicable rule instance is chosen non-deterministically and the resulting tuple is deleted immediately:

$R_i$2

$R_i$3

Other relations remain unchanged (Gilad et al., 2020). The result $R_i$4 is the minimum-size set of deletions obtainable by some sequence of single-rule activations. This corresponds closely to immediate, row-by-row cascading deletion.

The stage semantics is a batched version of step semantics. At each stage $R_i$5, all currently derivable delta tuples are added together:

$R_i$6

$R_i$7

The result is $R_i$8 (Gilad et al., 2020). This semantics is deterministic, converges to a unique fixpoint, and is computable in PTIME. The convergence result is formalized by the proposition that stage semantics always converges to a unique fixpoint.

The end semantics is the baseline datalog-style semantics. Delta tuples are derived first, while base relations stay unchanged:

$R_i$9

$\Delta_i$0

Only at the final fixpoint $\Delta_i$1 are the base tuples deleted:

$\Delta_i$2

The result is $\Delta_i$3, and this semantics is also in PTIME (Gilad et al., 2020).

The main size and containment results are structural. For every $\Delta_i$4,

$\Delta_i$5

and

$\Delta_i$6

By contrast, step and stage are incomparable in general: there are cases where $\Delta_i$7 and cases where $\Delta_i$8 (Gilad et al., 2020). The overall tradeoff is explicit: independent is the strongest notion of minimum repair but hardest to compute, end is the easiest and most permissive but can over-delete, and step and stage are intermediate semantics with different cascade behavior.

4. Computation, provenance, and hardness

The computational profile of the framework follows directly from the semantics. Independent semantics and step semantics are NP-hard, while stage and end are in PTIME (Gilad et al., 2020). The independent-semantics hardness is shown by reduction from Vertex Cover.

For the NP-hard cases, the paper gives concrete algorithms. The independent-semantics algorithm uses provenance represented as a Boolean formula. It builds DNF provenance for derivations of delta tuples, negates it, and solves a Min-Ones SAT instance (Gilad et al., 2020). The satisfying assignment with the fewest true negated variables yields the minimum stabilizing set. This gives a logical account of repair selection: only assignments that satisfy the negated provenance formula correspond to valid repairs.

The step-semantics algorithm uses a provenance graph and a greedy benefit heuristic. The procedure builds a provenance graph of derivations, computes a “benefit” for each tuple, traverses layers in topological order, chooses tuples whose deletion maximizes benefit, and removes affected derivations (Gilad et al., 2020). The graph is therefore not merely an implementation device; it acts as a validation structure for breaking all derivations of delta tuples that would otherwise remain active.

The paper characterizes the theoretical cost of provenance-based methods as exponential in provenance size, while also reporting them as practical in the evaluated settings (Gilad et al., 2020). This formalizes the framework’s main methodological tradeoff: more restrictive semantics with stronger global optimality criteria typically require more expensive reasoning over derivational structure.

5. Expressive scope and relation to constraints and triggers

The framework is intended to capture several classes of repair logic within one rule-based language (Gilad et al., 2020). For Denial Constraints, the paper uses the standard form

$\Delta_i$9

where $R_i$0 is a conjunction of comparisons such as

$R_i$1

with $R_i$2 (Gilad et al., 2020). These constraints are translated into delta rules so that any violating tuple may be deleted. In this setting, independent semantics behaves like classic minimum repair—delete at least one tuple from each violating set—while step semantics can mimic this behavior by using one rule per tuple position.

The paper also states that delta rules, together with suitable semantics, can express causal dependencies, especially non-recursive ones (Gilad et al., 2020). This broadens the framework beyond purely declarative integrity repair to repair scenarios in which one correction causes others.

A major practical motivation is SQL “after delete, delete” triggers. Step semantics corresponds most closely to fine-grained trigger firing, while stage semantics corresponds to batched cascading trigger behavior (Gilad et al., 2020). The paper notes that DBMS trigger firing order can be implementation-dependent, citing MySQL trigger creation order and PostgreSQL alphabetical order in some situations. The significance is not merely operational: implementation-dependent trigger order can yield different repairs, whereas the Delta Rules semantics makes the cascade behavior explicit.

The comparison with HoloClean clarifies the framework’s repair model. HoloClean repairs cells probabilistically and does not support cascade deletion; by contrast, the delta-rule framework treats constraints as hard, deletes tuples rather than repairing cells, and guarantees no remaining Denial Constraint violations under its semantics (Gilad et al., 2020).

6. Empirical behavior and the broader meaning of “sanity check”

The experimental evaluation is conducted on an MAS / Academic Search database with over 124K tuples and on TPC-H with 376,175 tuples (Gilad et al., 2020). The results show that repair size depends strongly on semantics. For integrity-constraint-like programs, independent semantics often gives much smaller repairs; end and stage often delete many more tuples; and step sometimes matches independent or stage, depending on cascading structure (Gilad et al., 2020). The paper gives concrete examples: in Program 4, end and stage had 956 deletions while step and independent had only 1; in Program 10, all semantics gave the same large result, 24,798 tuples.

Runtime exhibits the expected tradeoff. The reported average runtimes on MAS programs are 16.9 s for end, 21.1 s for stage, 73 s for independent, and 389.5 s for step (Gilad et al., 2020). End and stage are therefore the fastest, while independent and step are more expensive because they manipulate provenance.

The paper’s validation perspective also benefits from comparison with other arXiv uses of the term “sanity check.” In lattice QCD, a sanity check based on Lüscher’s finite-volume formula and the effective range expansion is introduced to rule out clearly inconsistent claims about $R_i$3 bound states; failure of the consistency conditions indicates that the lattice spectrum is not yet trustworthy enough to support a bound-state claim (Iritani et al., 2017). A closely related critique emphasizes that a sanity check is necessary but not sufficient: it can rule out obviously false results but cannot prove correctness on its own (Aoki et al., 2017). In visualization question answering, a sanity check framework uses a rule-based decision tree and a sanity check table to separate true “seeing” from “recall” and bias (Li et al., 14 Apr 2025). In overrefusal testing for LLMs, DDOR combines delta debugging with multi-oracle validation to filter intrinsically unsafe or ambiguous prompts before using them for evaluation or prompt repair (Zhou et al., 2 Jun 2026).

This suggests a shared methodological pattern across otherwise unrelated domains: a candidate output is first produced by a generative or operational mechanism, then filtered by a consistency criterion that excludes states known to be invalid. In Delta Rules, that role is played by stability. Stability does not select a unique repair and does not by itself determine optimality, but it is the admissibility condition that prevents a “repair” from leaving derivable deletions unresolved (Gilad et al., 2020).