Selective Revalidation Worklist¶
Worklist artifact — instantiates Change-Scoped Revalidation
Turns the affected set into an ordered, scheduled to-do list of exactly which items to re-derive after a change — in dependency order, at a cadence matched to the change rate — and nothing outside it.
Once the impact analysis has drawn the boundary of what a change could affect, someone still has to actually re-derive those items — and re-derive them in an order that does not check a thing before the thing it depends on. Selective Revalidation Worklist is that operational list: the affected closure rendered as concrete, assignable work items, sequenced so that upstream facts are re-established before the downstream facts that rest on them, and regenerated on a cadence matched to how often changes arrive. Its defining move is selection with an order: it is not the collection of all available checks (that is a regression test suite) and not the boundary itself (that is the impact analysis) — it is the dated, ordered plan for clearing exactly the affected set, and only that set.
Example¶
A data team changes the definition of one upstream column — "active user" now excludes trials — in a warehouse table that dozens of downstream models, metrics, and dashboards read from. Re-validating every asset in the warehouse after every definition change is impossible; trusting that nothing else moved is how a headline metric silently breaks. The Selective Revalidation Worklist is what they work instead. Starting from the impact analysis's affected set — the transitive closure of everything that reads "active user," directly or through an intermediate model — it produces an ordered checklist: the three intermediate models that recompute the metric are revalidated first, then the ≈16 dashboards that read those models, then the two exec reports that snapshot the dashboards. Items with no downstream dependents are checked last or in parallel; items outside the closure are not on the list at all.
The cadence is tied to the pipeline: the worklist is regenerated on every merged definition change and cleared before the next nightly run publishes. What the team gets is not a vague "audit the dashboards" but a dated, ordered, assignable list — and the assurance that when it is cleared, exactly the affected set was rechecked, in an order where nothing was validated against a parent that had not been validated yet.
How it works¶
- Take the closure as given; do not recompute it. The worklist consumes an affected set produced upstream (an impact analysis or a dependency traversal). Its job begins where scoping ends, so its correctness is inherited from that boundary.
- Order the set topologically. Sequence items so each is revalidated only after the facts it depends on — otherwise a downstream check passes against an upstream value that is itself about to change, and the pass means nothing.
- Make each item assignable and closeable. Concrete work units, each with an owner and an explicit done-state, so "the affected set was rechecked" becomes a verifiable claim rather than a vibe.
- Bind regeneration to the change rate. Regenerate per change for fast-moving systems; batch to a scheduled window where changes cluster — so the list never lags the state it is supposed to cover.
Tuning parameters¶
- Selection safety margin — how generously the affected set is drawn before ordering. A wider, safer selection is less likely to omit a truly-affected item but costs more rechecking; a tight selection is cheap but risks an unsafe omission.
- Ordering strictness — strict topological order versus opportunistic parallelism. Strict order guarantees no check runs against an un-revalidated parent; relaxing it raises throughput at the risk of rework when a parent later fails.
- Cadence coupling — how tightly regeneration tracks the change stream: per-change, per-batch, or periodic. Tighter coupling keeps the list fresh but multiplies runs.
- Item granularity — one work unit per artifact versus per assertion within it. Finer items parallelize better and localize failures; coarser items are less to track.
- Carry-over policy — what happens to items not cleared before the next change lands: reset, merge into the new list, or block the next change until the current list clears.
When it helps, and when it misleads¶
Its strength is that it makes "we rechecked what mattered" a checkable claim: a closed worklist is evidence, and the dependency ordering quietly prevents the subtle bug of validating a child against a parent that is itself about to move. It is cheaper than full revalidation and safer than trusting the presumption blindly — the affordable middle the archetype is built around.
Its correctness, though, is entirely inherited: the worklist is only as safe as the closure it is handed, and an omission in the impact analysis becomes an item that never appears on the list — and an item that never appears is never missed. The classic failure is an unsafe selection: trimming the list to hit a deadline, dropping items that "probably didn't change." Regression test selection research calls a selection safe only when it includes every check the change could affect;[n1] a worklist that is not provably safe has traded cost for hidden risk, and the tidy checklist makes that risk look retired. The discipline that keeps it honest is to derive the list from an explicit dependency map rather than intuition, hold the selection to the safety standard (a superset of the truly-affected set), and pair it with a boundary-escape sample that rechecks a few out-of-scope items to catch closures that leaked.
How it implements the components¶
revalidation_rule— the rule that turns an affected set into concrete work: what counts as re-derived for each item, and the done-state that closes it.dependency_order— the list is sequenced topologically, so no item is revalidated before the items it depends on.revalidation_cadence— the schedule on which the list is regenerated and cleared, bound to the system's change rate.
It does not decide what may be retained unchecked — that is Persistence Exception Register — nor draw the affected closure it consumes (Impact Analysis and Dependency Closure Traversal), nor automate the whole loop (Truth-Maintenance System).
Related¶
- Instantiates: Change-Scoped Revalidation — the worklist is the re-derive side: the ordered plan for clearing exactly the affected set.
- Consumes: Impact Analysis — supplies the affected closure the worklist orders and schedules; where a Dependency Closure Traversal exists, it supplies the same input.
- Sibling mechanisms: Persistence Exception Register · Truth-Maintenance System · Impact Analysis · Regression Test Suite · Requirements Traceability Matrix · Dependency Graph · Data Diff and Merge Tool · Cache Invalidation Review · Change Impact Report · Boundary Escape Sampling · Dependency Closure Traversal
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Selective Revalidation Worklist operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it turns the affected set into an ordered, scheduled to-do list of exactly which items to re-derive after a change — in dependency order, at a cadence matched to the change rate — and nothing outside it.
Independent corroboration: The frozen evidence defines Selective Revalidation Worklist as 'Turns the affected set into an ordered, scheduled to-do list of exactly which items to re-derive after a change — in dependency order, at a cadence matched to the change rate — and nothing outside it', so its operative form is Representation, Specification & Plan.
Nearest alternative: Protocol, Workflow & Routine — Selective Revalidation Worklist includes features of a repeatable ordered procedure or handoff sequence that coordinates action, but its defining operation is a static representation, map, specification, schema, or prospective plan that externalizes information.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Impact-based revalidation after a controlled change belongs to engineering configuration management and verification practice.
Related originating lineages:
- Computer Science & Software Engineering — Dependency graphs and incremental builds formalize rechecking only affected downstream artifacts.
- Operations Research — Precedence-constrained scheduling supplies the dependency order and cadence optimization.
- Organizational & Management Science — Scheduled worklists and accountable owners convert impact analysis into an executable assurance process.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: turns the affected set into an ordered, scheduled to-do list of exactly which items to re-derive after a change — in dependency order, at a cadence matched to the change rate — and….
Review resolution: The blind reviewers agree that engineering_design is the primary origin and differ only on alternate origin disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain cross_disciplinary_synthesis because the combined record shows material contributions from several lineages. The broader reach of multi_domain records portability separately from historical provenance, and encyclopedia_synthesis=true preserves the affirmative synthesis judgment where either reviewer identified one.
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¶
The worklist inherits its safety from the closure it is handed: it faithfully clears whatever set it is given, in the right order, but it cannot detect an affected item the impact analysis failed to include. That blind spot is structural, not a defect of execution, which is why the worklist is paired with boundary-escape sampling — the one mechanism whose job is to look outside the declared scope for leaks the closure missed.
[n1] In regression test selection, a selection is called safe when it includes every test whose outcome the change could alter, omitting only tests provably unaffected — a property formalized in the regression-test-selection literature. A revalidation worklist inherits the same standard: its cheapness is only legitimate if the selected set is a superset of the truly-affected one. ↩