Basis-Candidate Pruning Workflow¶
Pruning workflow — instantiates Independent Generator Validation
Walks a bloated candidate set down to a minimal independent core by cutting each member a dependency witness shows the rest already reproduce, re-testing after every single cut.
Basis-Candidate Pruning Workflow is the orchestrating process that turns a long list of supposed generators into a minimal set in which every survivor earns its place. It does not measure dependence itself — it consumes the verdicts of detectors and decides what to do with them: keep, merge, relabel, or drop. Its defining move is that a member is removed only when a concrete dependency witness shows the others already reconstruct it, and the whole set is re-tested after every cut — because dependence is a property of the set, not of a member, and removing one candidate can turn a borderline-redundant neighbour into a load-bearing one. Cut on evidence, then re-screen: that discipline is what separates a defensible reduction from lopping off whatever happened to look correlated.
Example¶
A research group has a 30-item questionnaire meant to measure several supposedly distinct constructs, and wants the shortest form that loses no real dimension. The workflow declares the item set and the reconstruction rule (an item is redundant if its responses are recovered from a combination of the others within tolerance), then runs the screen. Item 14 turns out to be almost perfectly predicted by items 6 and 22 — a witness with explicit weights — so it is dropped. Crucially, the set is re-screened: with item 14 gone, item 22 is no longer redundant (it had been carrying part of what 14 duplicated), so it stays. The loop continues until every remaining item contributes a direction the rest cannot. The output is not "30 items" but "≈17 items, each with a recorded reason it survived," plus a short list of merges where two items were folded into one.
How it works¶
The distinguishing shape is the loop, not any single test:
- Declare and screen. Fix the working candidate set, hand it to a detector, and collect the dependency witnesses.
- Cut one, not all. Remove (or merge, or relabel) the single best-witnessed redundant member — never every correlated member at once, because two mutually-redundant candidates each look droppable while only one actually is.
- Re-test the survivors. Re-run the screen on the smaller set; dependencies reshuffle, and a previously redundant member often becomes independent.
- Stop on a clean pass. Halt when every survivor is witnessed independent, and record why each was kept.
Tuning parameters¶
- Cut order / greediness — most-redundant-first, or a considered order. Greedy is fast but order-dependent; the surviving set can differ with the sequence.
- Merge vs. drop vs. relabel — whether a dependent candidate is deleted, folded into the member it duplicates, or renamed to expose the conflation. Merging preserves information a bare drop discards.
- Stopping slack — halt at a strictly minimal set, or leave deliberate redundancy for robustness. Tighter is leaner but more fragile.
- Protected members — candidates a domain requires kept even when redundant (a regulated field, a mandated control). Protects meaning at the cost of minimality.
- Re-test cadence — re-screen after every cut (safest) or in batches (cheaper, riskier).
When it helps, and when it misleads¶
Its strength is converting "we have thirty of these" into a minimal set where each survivor carries a recorded, witnessed justification — and forcing evidence before a cut rather than intuition. It also surfaces merges the raw list hid.
Its failure modes are those of any greedy reduction. Because cut order matters, a purely greedy pass can be unstable[1] — a different order yields a different survivor set — and cutting all correlated members in one pass over-prunes, destroying a real degree of freedom because two candidates that each duplicate the other can lose only one, not both. The classic misuse is running it backwards: pruning to hit a target count or to shrink a slide, then hunting for a redundancy story to justify it. The discipline that guards against all three is the loop itself — one witnessed cut at a time, re-test, and keep the witnesses on file.
How it implements the components¶
candidate_generator_set— declares and curates the working set the whole screen operates on, tracking merges and relabels as it shrinks.minimal_retention_rule— the keep / merge / relabel / drop decision applied to each witnessed member, with the stopping condition.redundancy_pruning_or_redesign_path— executes the actual reduction, or escalates a genuinely tangled set to a redesign.
It does not produce the evidence it acts on: the dependency witnesses and rank verdicts come from detectors such as Gaussian Elimination Pivot Check, Nullspace Dependency Certificate, and Condition-Number Dashboard, and the criterion and tolerance it prunes against are fixed by Independence Proof Obligation Template.
Related¶
- Instantiates: Independent Generator Validation — this workflow is the decide-and-reduce spine of the screen.
- Consumes: Gaussian Elimination Pivot Check and Nullspace Dependency Certificate supply the per-member dependency witnesses; Independence Proof Obligation Template supplies the criterion and tolerance.
- Sibling mechanisms: Gaussian Elimination Pivot Check · Feature Collinearity Heatmap · Condition-Number Dashboard · Gram-Schmidt Orthogonalization Trace · Independence Proof Obligation Template · Independent-Axis Design Review · Nullspace Dependency Certificate · Rank-Revealing Decomposition · Residualization Contribution Test · Singular-Value Threshold Scan · Variance-Inflation Review
Editorial Notes¶
Form Classification¶
Form family: Analysis, Modeling & Optimization
Rationale: The mechanism repeatedly detects dependencies, removes one well-witnessed redundant candidate, and recomputes on the survivors until a minimal independent core remains, so its operative form is an optimization algorithm.
Nearest alternative: Decision, Gate & Allocation — Each iteration selects a member to cut, but those dispositions are internal steps in a formal pruning computation rather than independent case decisions.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Mathematics
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Linear algebra removes redundant generators only when the remaining set still spans and independence is preserved.
Related originating lineages:
- Computer Science & Software Engineering — Algorithmic linear algebra supplies executable rank tests and pruning workflows.
- Data Science & Analytics — Feature-pruning workflows operationalize iterative keep, merge, and drop decisions.
- Statistics & Experimental Design — Stepwise selection supplies warnings about order and sample instability.
Review resolution: Mathematics is the agreed primary through independent spanning-set reduction. Computational linear algebra, feature pruning, and stepwise-selection diagnostics materially shape the one-cut-and-retest workflow, which both reviewers identify as synthesized.
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¶
Dependence is a property of the set, so the order of removals is load-bearing and easy to get wrong: two candidates can each be redundant with the other, yet the set genuinely needs one of them. A workflow that drops "all the redundant-looking ones" at once will silently delete a real dimension. Re-testing after each single cut is the cheapest guard against it.
References¶
[1] Harrell, F. E., Jr. Regression Modeling Strategies: With Applications to Linear Models, Logistic and Ordinal Regression, and Survival Analysis. 2nd ed. Springer Cham (2015). Warns that greedy stepwise variable selection is unstable and can yield fragile selected models. registry ↩