Incomplete result sets during backtracking with the cut operator

Direct answer

Under ISO Prolog (ISO/IEC 13211-1), a cut ! discards all choice points created since the clause containing it was entered. When the cut sits inside a nested goal, pruning is still scoped to that clause's activation: it removes choice points created by goals called before the cut within the same clause body (including choice points inside those nested subgoals), but it never reaches across the predicate boundary to prune choice points belonging to the caller of the current predicate.

Scope of pruning in nested goals

Consider:

p :- q, !, r.
p :- s.

When p is called and the first clause is entered, any choice points created by q (and by goals q itself calls) are discarded once ! executes. The cut also discards the choice point for the second clause of p, because that alternative was created when p was entered. What it does not touch are choice points that existed in the goal that called p — cut is not "deep" across predicate boundaries.

You can verify the scoping behavior with a tracer such as SWI-Prolog's gtrace/0, watching choice points disappear at the cut port, or with a minimal test:

p :- q, !, fail.
p :- r.
q.
r.

?- p.   % fails: the cut committed to clause 1, so r is never tried

Without the cut, p succeeds via r; with it, the query fails. That difference is the signature of a red cut.

When a red cut produces an incomplete result set

A red cut — one that changes the computed answer set — yields incomplete results whenever it commits the engine to a clause before the conditions distinguishing that clause from later alternatives are fully established. The classic pattern:

p :- a, !, b.
p :- c.

If a and c can both hold but b fails, the second clause — a logically valid solution — is never explored. The cut fired on the strength of a alone, and b's failure cannot reopen the pruned alternative.

Other concrete scenarios:

• Non-exclusive guards. Clause conditions that are not mutually exclusive (e.g., X >= Y vs. a fallback clause) become red cuts if the guard does not truly partition the input space, or if later goals in the committed clause can fail.
• Cut before a disjunction. p :- !, (a ; b). commits before either branch is tried; if a fails and b would also fail while another clause of p would succeed, that solution is lost.
• Negation-as-failure idioms. p :- q, !, fail. p. intentionally prunes — correct only if q succeeding truly means p must fail for all bindings.

Green vs. red: a practical check

A cut is green only if every condition determining clause applicability has already succeeded before the !, so no valid answer can lie beyond it. The reliable verification: run your query with and without the cut and compare the full answer sets (e.g., via findall/3). Identical answers with fewer inferences means green; any missing answer means red. Where possible, prefer ->/2 if-then-else or the soft cut *->/2, which make the commit semantics explicit and avoid most accidental red cuts. Note also that a cut inside a catch/3 goal does not prune choice points outside the catch scope — worth remembering when cuts and exception handling mix.