Chronological Backtracking Log¶
Document — instantiates Constraint-Guided Backtracking
An append-only, reason-annotated record of every choice, failure, and rollback in the order it happened, so a dead branch is never retried and any contradiction can be traced to its cause.
The Chronological Backtracking Log is the search's append-only, reason-annotated ledger: a running written record that timestamps every choice made, every constraint that killed a branch, and every rollback, in the exact order they occurred — so that a branch already shown to fail is never blindly retried, and any later contradiction can be traced back to the choice responsible for it. Its defining idea is durable, reason-bearing history: it is a record read after the fact, not a live controller. It never proposes a move or steers the next step; it remembers what was tried and why it failed so the search does not have to relearn its own dead ends.
Example¶
A traveler is assembling a complicated multi-leg itinerary — six countries in three weeks — under visa, timing, and onward-ticket constraints, adding one city at a time. She keeps a log:
- Day-2 slot: route via Tashkent — FAIL: transit visa needed, 10-day processing exceeds the 4-day gap. Rolled back Tashkent.
- Day-2 slot: try Almaty — OK, visa-free 30 days.
- Day-4 slot: add Delhi — FAIL: onward-ticket rule, no confirmed exit booked. Rolled back Delhi.
- Day-4 slot: try Kathmandu — OK.
Two weeks later the whole plan breaks when a passport-validity rule bites on the final leg. Instead of re-deriving everything from scratch, she reads the log and sees exactly which early city choice the failure traces to. And because "Tashkent — transit visa, 10-day processing" is written down as a reason, she never wastes a second afternoon re-attempting Tashkent. The log did none of the planning; it made the planning auditable and un-repeatable-in-the-bad-sense.
How it works¶
- Append on every event. Each commitment, failure, and rollback is written as a new entry — the log is never edited in place, only extended, so the true order survives.
- Carry the reason. Every failure line records the specific constraint that killed the branch, not just that it died.
- Consult before retrying. Before a branch is re-attempted, the log is checked; an entry marking it already-failed means skip it.
- Flag conditional reopenings. A branch that failed under a constraint that may later change is recorded as closed-unless-constraints-change, so it is not permanently lost.
Tuning parameters¶
- Granularity — log every micro-step, or only milestone forks. Fine logs are exhaustive but noisy; coarse logs are readable but can miss the responsible choice.
- Reason detail — a bare failure code versus a full explanation. Richer reasons make the trace more useful and cost more to write.
- Retention / rotation — how long entries are kept before archiving. Longer memory prevents more repeats but grows the record.
- Authoring mode — auto-instrumented (emitted by the search) or hand-kept (written by a person), trading fidelity against effort.
- Structure — freeform notes versus a fielded schema, which decides how mechanically the log can be queried.
When it helps, and when it misleads¶
Its strength is turning a chaotic search into an auditable one: it kills the "same invalid branch retried because nobody recorded why it failed" pathology outright, and it gives any later contradiction a paper trail back to its cause. It is what makes a reversible search learnable rather than merely exhaustive.
Its defining failure mode is staleness. A recorded failure is only valid while its justifying constraint holds; if that constraint is later relaxed, the branch it closed may now be viable, yet a naive reader still treats the old entry as final — the log misleads by being trusted past its expiry.[n1] A second, quieter misuse is letting the log grow so verbose that no one reads it, at which point it stops preventing repeats. The guarding discipline is to tie each closure to the constraint that justified it and re-open closures whose constraint has changed, rather than treating the ledger as permanent truth.
How it implements the components¶
The Chronological Backtracking Log fills the history-and-reason slice of the archetype — the durable record of what already happened:
visited_branch_record— the append-only ledger of which branches were tried and whether they remain closed is exactly this record, and it is what prevents re-exploring a known dead end.constraint_explanation_trace— each failure entry names the constraint that caused it, so a downstream contradiction can be traced to the responsible choice.
It does not display the branch topology, show the open frontier, or set the order alternatives are tried — partial_solution_state, alternative_branch_queue, and branch_ordering_policy are Decision-Tree Search Diagram, its nearest twin. The diagram is a simultaneous spatial map of where the search stands now; this log is a sequential written history of what already happened.
Related¶
- Instantiates: Constraint-Guided Backtracking — the log is the archetype's traceability record of tried branches and their failure reasons.
- Sibling mechanisms: Decision-Tree Search Diagram · Recursive Depth-First Backtracking · Undo-Stack Protocol · Forward-Checking Table · Hypothesis-Tree Review · Constraint-Satisfaction Solver Pass
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: An append-only, reason-annotated record of every choice, failure, and rollback in the order it happened, so a dead branch is never retried and any contradiction can be traced to its cause, making its operative form a durable record, ledger, register, or trace whose value depends on preserving actual state or history.
Independent corroboration: The frozen evidence defines Chronological Backtracking Log as 'An append-only, reason-annotated record of every choice, failure, and rollback in the order it happened, so a dead branch is never retried and any contradiction can be traced to its cause', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Algorithmic search supplied chronological backtracking, dead-branch recording, and contradiction tracing through a sequence of choices.
Related originating lineages:
- Mathematics — Proof search contributes reason annotations that link contradictions to earlier assumptions.
Review resolution: Constraint solving and search provide the primary reason-bearing backtracking lineage. Mathematical proof search supplies contradiction justifications, while the append-only human-readable log is an Encyclopedia synthesis that transfers the method beyond software.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
[n1] A recorded failure is a no-good — a combination proven not to work. In a truth-maintenance system, each no-good is stored with the justification that produced it, so that if the justifying assumption is later retracted the no-good is automatically re-examined rather than trusted forever. The log's "closed-unless-constraints-change" flag is the low-tech version of the same idea. ↩