Choose Recheck or Regenerate to Avoid Doing the Wrong Work

When a domain research project evolves, “run it again” is ambiguous. You may want fresh evidence for yesterday's finalists, or you may want new candidates from today's revised vocabulary. Choosing the wrong action can consume effort while producing an answer to the wrong question.

DNS Lister distinguishes those operations. Search snapshots remain unchanged when lists change. Recheck All retests the original names, while Run Again with These Settings regenerates candidates from the current lists. Review this behavior in the current help.

Identify what is allowed to change

For a recheck, the candidate inventory should remain fixed while its observation time advances. For regeneration, the candidate inventory may change because source lists changed. State which one you intend before initiating the operation.

A hypothetical naming team has a saved search built from twenty modifiers and thirty nouns across two extensions. Its intended original matrix contains 1,200 combinations. The team then replaces five nouns with eight new ones, leaving thirty-three nouns in the current list.

Rechecking the snapshot concerns its original full domains. Regenerating from the revised lists concerns a matrix of 20 × 33 × 2 = 1,320 intended combinations. The extra 120 combinations are only the net difference; the inventories also include removed and newly introduced strings.

Protect finalists from vocabulary edits

Suppose a finalist used one of the five removed nouns. Editing the list does not mean the finalist should disappear from the decision process. Keep its exact full-domain string in the approved shortlist and obtain fresh evidence for it separately if needed.

Without this distinction, a regenerated run may accidentally omit the very name a stakeholder asked you to verify. A polished new results page cannot compensate for that missing task.

Also preserve extension choices. If the revised experiment adds another TLD, the additional full domains are new research. Do not attach old observations to them merely because their stems appeared in the earlier snapshot.

Avoid interpreting better answers as better vocabulary

A later run may obtain more usable answers because conditions changed, even when its language did not improve. Conversely, revised vocabulary may generate better naming candidates despite similar answer quality. Separate those dimensions when explaining the outcome.

DNS Lister discusses DNS and registration observations in How We Check. An unresolved result followed by a conclusive result represents improved evidence; it does not by itself prove that the domain's registration state changed.

If the team wants to compare vocabulary quality, use the same naming criteria and make inventory differences explicit. If it wants to assess freshness, compare the shared exact domains with their observation times.

Make the rerun record small but clear

Use labels such as original-scope recheck and revised-vocabulary search in your own notes. Record the original input revision, the current revision if applicable, and selected extensions. These labels are workflow documentation, not assumptions about native integrations or special product metadata.

Before reporting, ask whether the operation answered the intended question. Are all approved finalists included? Are new suggestions distinguishable from refreshed old ones? Are unresolved entries still represented honestly?

If both tasks matter, do both as separate research steps. Refresh the finalist evidence near the purchase decision and investigate the revised language as a new experiment. That preserves history and avoids making the same output carry incompatible meanings.

Use DNS Lister's recheck or regeneration action according to the inventory you intend to investigate. The filter-versus-coverage article explains another common scope confusion, and runtime estimation helps plan the work without turning a vendor-reported peak into a deadline guarantee.