FA-12006 / Optimization solver contracts / Open access

Branch and bound prunes against an infeasible incumbent · case 01

Branch and bound prunes against an infeasible incumbent.

Verified by executionVariant 1 · 6 checks per implementationDownload source bundle ↓JSON ↗

ROOT CAUSE

An objective estimate is treated as a feasible incumbent.

THE FAILURE

An objective estimate is treated as a feasible incumbent.

Unsuccessful approach: Checking feasibility but using strict inequality needlessly explores equal bounds under single-optimum semantics.

Case contract

Minimization, one optimum required: prune iff incumbent is feasible and node lower bound>=incumbent objective.

Why this case matters

This deterministic solver-step model isolates an algorithmic invariant used by iterative optimization implementations.

1 / The failure

Exit 1

"""Failure Map reference implementation. Python standard library only."""
import json

N = 1
observations = []
def solve(lower, incumbent, feasible):
    return lower >= incumbent
def check(label, actual, expected):
    observations.append({"check": label, "actual": actual, "expected": expected, "passed": actual == expected})
check('infeasible estimate', solve(10*N, N, False), False)
check('equal bound', solve(N, N, True), True)
check('strictly dominated', solve(N+1, N, True), True)
check('possible improvement', solve(N-1, N, True), False)
check('negative objectives', solve(-N, -N-1, True), True)
check('infeasible equal', solve(N, N, False), False)
print(json.dumps({"observations": observations, "passed": all(x["passed"] for x in observations)}, ensure_ascii=False))
raise SystemExit(0 if all(x["passed"] for x in observations) else 1)

Boundary fixture	Actual	Expected	Outcome
infeasible estimate	`True`	`False`	Failed
equal bound	`True`	`True`	Passed
strictly dominated	`True`	`True`	Passed
possible improvement	`False`	`False`	Passed
negative objectives	`True`	`True`	Passed
infeasible equal	`True`	`False`	Failed

SHA-256 / c575cd37eaa374a43e7e3e247ed3ac87f164dd972862b868297f20da24977bd1

2 / The unsuccessful fix

Exit 1

"""Failure Map reference implementation. Python standard library only."""
import json

N = 1
observations = []
def solve(lower, incumbent, feasible):
    return feasible and lower > incumbent
def check(label, actual, expected):
    observations.append({"check": label, "actual": actual, "expected": expected, "passed": actual == expected})
check('infeasible estimate', solve(10*N, N, False), False)
check('equal bound', solve(N, N, True), True)
check('strictly dominated', solve(N+1, N, True), True)
check('possible improvement', solve(N-1, N, True), False)
check('negative objectives', solve(-N, -N-1, True), True)
check('infeasible equal', solve(N, N, False), False)
print(json.dumps({"observations": observations, "passed": all(x["passed"] for x in observations)}, ensure_ascii=False))
raise SystemExit(0 if all(x["passed"] for x in observations) else 1)

Boundary fixture	Actual	Expected	Outcome
infeasible estimate	`False`	`False`	Passed
equal bound	`False`	`True`	Failed
strictly dominated	`True`	`True`	Passed
possible improvement	`False`	`False`	Passed
negative objectives	`True`	`True`	Passed
infeasible equal	`False`	`False`	Passed

SHA-256 / 8b6bd09ec4884f6e5316d4693d81310b764caecfa545038c2f8cfa02f2fd7714

HELD IN THE MEMBER ARCHIVE

The verified repair and its recorded checks are member-only.

This mechanism has 6 recorded checks per implementation. The open-access tier publishes the failure and the unsuccessful fix; the repaired source that passes every check, and the observations that prove it, are available to members.

Every case sharing this mechanism uses the same contract and the same repair, so this one record is held back for all of them.

Member access is invitation-based. Sign in with your invited account to inspect the repair.

Verification & scope

Controlled finite inputs and explicit one-step contracts; this is not a production solver or a numerical stability benchmark. This reproducer isolates one failure mechanism. Results cover the supplied fixtures. Variants within a family share a test contract and should remain grouped when constructing evaluation splits. Related mechanisms with a shared evaluation_group must also remain together; these controlled models are not independent production incidents.

Observations recorded using Python 3.12.14 at 2026-09-29T14:38:52.992535+00:00.

Case digest / bb24d7f4300c2c04caf2c3ccf6a860ec470086335413c5b6ef1c506f4cd6b200