Pruning Audit Log¶
Audit artifact — instantiates Bounded Search Pruning
An after-the-fact record of every branch that was cut — the bound, the assumptions behind it, and the exact condition that would put the branch back in play.
Pruning Audit Log is the memory of a search that pruned itself. It authors no exclusion of its own; it records the exclusions other mechanisms made, one entry per cut branch, capturing what was dropped, the bound or proof that justified dropping it, the assumptions that bound relied on, and — the entry's most important field — the specific condition that would reopen the branch. The one idea that makes this mechanism itself, and not any of the pruners around it, is that it is a retrospective accountability record: its value is that a reviewer, weeks later, can reconstruct why an option disappeared and tell whether it should come back, without re-running the search. Where a pruning mechanism decides what to cut, the log decides nothing — it makes the cutting reviewable and reversible.
Example¶
An aerospace team is searching a large design space for a satellite bus structure — thousands of combinations of material, wall thickness, and rib layout — and prunes aggressively along the way to keep the study tractable. Every prune is written to the log. One entry reads: region "thin-wall aluminum, no ribs" excluded on 12 March; lower-bound mass-margin analysis showed it fails the launch-load case; assumes the 6g quasi-static load spec and the current payload mass; reopen if payload mass drops below 180 kg or the load spec is relaxed. Months later the mission's payload is descoped and comes in lighter. A reviewer filters the log for entries whose reopening condition mentions payload mass, finds this region, and reinstates it for a fresh look — and it turns out to be the lightest viable design. Nothing in the log did the pruning or the reopening; it simply preserved enough context that a stale exclusion could be caught and undone instead of silently costing the mission its best option.
How it works¶
- Log at the moment of the cut. Each prune writes an entry as it happens — branch identifier, the bound or certificate used, the assumptions in force, and a timestamp.
- Record the reopening condition, not just the reason. Every entry states the concrete change — a relaxed constraint, a new datum, a revised objective — that would make the branch worth revisiting.
- Make it queryable. Entries are structured so a reviewer can filter by assumption or trigger ("show every prune that assumed the old load spec") when the world changes.
- Stay out of the decision. The log never prunes and never reopens on its own; it surfaces which exclusions have gone stale so a human or an upstream mechanism can act.
Tuning parameters¶
- Capture depth — how much context each entry stores. Rich entries make later review reliable but cost effort at every prune; thin entries are cheap but can leave an exclusion un-reconstructable.
- Reopening-trigger specificity — how precisely the reopen condition is stated. A sharp trigger ("payload < 180 kg") makes stale prunes findable; a vague one ("if assumptions change") is nearly useless later.
- Retention and granularity — whether every micro-prune is logged or only consequential ones. Logging everything is complete but noisy; logging only big cuts is readable but can miss the one that mattered.
- Review cadence — how often the log is swept for entries whose triggers have fired. Frequent sweeps catch stale exclusions early; rare ones let good branches stay buried.
When it helps, and when it misleads¶
Its strength is accountability and reversibility: it turns pruning from an opaque narrowing into a reconstructable record, so excluded options can be defended, challenged, and — when assumptions shift — recovered. It is the difference between a search whose prunings are provenance-tracked and one whose lost branches are simply gone.[n1]
It misleads when its presence is mistaken for the safety it only documents. A thorough log does not make a prune correct; it records the prune, sound or not, and a beautifully audited exclusion built on a bad bound is still a bad exclusion. The classic misuse is treating the existence of an audit trail as evidence that pruning was done well — a checkbox that launders unjustified cuts. Worse, if reopening conditions are logged but never checked, the log becomes a graveyard of recoverable options nobody revisits. The guarding discipline is to periodically sweep the log against current assumptions and actually reopen the branches whose triggers have fired, treating the record as a live worklist rather than a compliance artifact.
How it implements the components¶
exclusion_audit— it is the audit itself: the structured, per-branch record of what was pruned, on what bound, under which assumptions, and when.branch_reopening_rule— each entry carries the concrete condition that would reinstate its branch, making stale exclusions findable and reversible after the fact.
It does not itself decide which branches to cut or define the requirements they must meet — the pruning_rule and the objective_and_constraint_reference are authored by the pruning mechanisms such as the Legal Issue Pruning Matrix. The log records their exclusions; it never makes one.
Related¶
- Instantiates: Bounded Search Pruning — the Pruning Audit Log is the accountability layer that keeps a pruned search reviewable and its exclusions reversible.
- Consumes: the exclusions emitted by the pruning mechanisms — for example Dominance Filtering or Bound-Based Candidate Screening — recording each with its bound, assumptions, and reopening condition.
- Sibling mechanisms: Admissible Heuristic Search · Bound-Based Candidate Screening · Constraint Propagation · Diagnostic Tree Pruning · Dominance Filtering · Legal Issue Pruning Matrix · Branch and Bound · Feasibility Certificate Check
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Pruning Audit Log operates as a persistent ledger, log, register, or case record that preserves history and traceability because it an after-the-fact record of every branch that was cut — the bound, the assumptions behind it, and the exact condition that would put the branch back in play.
Independent corroboration: The frozen evidence defines Pruning Audit Log as 'An after-the-fact record of every branch that was cut — the bound, the assumptions behind it, and the exact condition that would put the branch back in play', 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: Specialized
Rationale: Recording branches removed by bounds and their reinstatement conditions arises from algorithmic search and pruning.
Related originating lineages:
- Operations Research — Mathematical optimization developed branch-and-bound pruning and auditable bounding arguments.
Review resolution: Both blind reviewers agree on computer_science as the primary origin. Explicit reconciliation resolves origin_mode_disagreement. The merged alternate lineages retain only domains the reviewers identified as materially formative; domain_reach=specialized records later applicability separately from origin breadth.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Provenance — a durable record of where a result came from and under what assumptions — is the property that lets a decision be re-examined rather than merely trusted. A pruning audit log is provenance for exclusions: it does not make a cut correct, only reconstructable and, when needed, reversible. ↩