A case subtree was cloned for a release a year ago and the repository kept no ancestry - how do you work out which copies correspond to which originals?
answer
- ancestry is rarely recorded
- match on step text before titles
- a clone batch shares one timestamp
- silent failures: renamed and split cases
- stamp a generated key at clone time
basics
~20 sReconstruct it from evidence: a stamped lineage key if one exists, then step text, then title, then the creation batch. Reconstruction is lossy and decays with time, which is why the key belongs on the copy at clone time.
solid answer
~40 sYou reconstruct lineage rather than read it, and the reconstruction degrades as the copies diverge. Work down the evidence in order of reliability: a stamped lineage or external key matches exactly; step and expected-result text matches well early and worse as the copies are edited; titles match until somebody renames one; and the creation timestamp only tells you which *batch* a case belongs to, since a clone writes the whole subtree at once. Folder position is the weakest signal of all, because release trees get reorganised precisely because the releases diverge. Whatever you recover, stamp it - write the reconstructed value into a field on every matched case so the next person reads it instead of deriving it again, and so cases the reconstruction could not match are visibly unmatched.
go deeper
Recall that a cloned case does not carry a queryable link to its source, so the correspondence has to be worked out from the content afterwards.
Explain the evidence ladder - a stamped key, then normalised step text, then title within the matching folder - and why creation timestamps only identify the clone batch.
Emphasise that reconstruction fails silently on renamed and split cases, so the output must separate matched, unmatched and ambiguous rather than reporting a single number.
Argue for stamping identity at the moment of copying as a standing rule, since the information is free then and permanently expensive to recover later.
## What evidence survives a clone A clone leaves no ancestry you can query. The copy is a new record, and any provenance note the product writes is unindexed prose at best. So a year later, matching copies to originals is detective work over whatever survived: - **A stamped lineage or external key**, if someone had the foresight to write one. Exact, order-independent, and unaffected by later edits. - **Step and expected-result text**, which starts as a perfect match and decays with every edit to either side. - **Titles**, which are the most convenient signal and the most edited one. - **Creation timestamps**, which group the clone batch rather than the case - a whole subtree is written in one action. - **Folder position**, which survives only until either tree is reorganised. ## Reconstructing lineage, most reliable first 1. **Match on a stamped key** where one exists. Done, and correct. 2. **Match on normalised step text** - strip whitespace and case, hash the concatenated steps and expected results, and join on the hash. This catches everything untouched since the clone, which is usually most of the tree. 3. **Match on title within the corresponding subtree**, restricting the candidate set to the two folders you believe correspond. Restricting the scope is what makes a weak signal usable. 4. **Fall back to a human pass** for the remainder: the cases edited on both sides are exactly the interesting ones, and they are the ones no automatic rule will match. ## Why reconstruction is lossy The failures are silent, and that is what makes them dangerous. A title match that finds nothing returns nothing - it does not announce that a case was renamed. A text match on a case that was split into two returns one of the halves, or neither, with no signal that the other exists. A match by position quietly pairs the wrong cases after a folder move. None of these raise an error, so a reconstruction always looks more complete than it is. The practical consequence: treat the output as **matched, unmatched, and ambiguous**, and never let the unmatched pile disappear. Cases that could not be matched are the ones most likely to be the diverged, interesting ones. ## Stamp it at clone time Everything above exists only because the value was not written when it was free to write. At clone time you know, for certain and at no cost, which copy came from which original. A good lineage value is: - **Generated, not derived** - never built from the title, the folder or the release name, because derived values change exactly when you needed them to hold still. - **Identical across all copies** of one logical case, so the whole sibling set is one filter away. - **Never reused** for a different logical case, even after the original is gone. - **Written into a field you can filter and export**, not a free-text note nobody indexes. Once that value exists, the reconstruction problem disappears permanently - and so does the expensive half of carrying a fix across releases, since finding the siblings becomes a lookup rather than an investigation.
- Why is matching on title alone unsafe a year after the clone?Titles get edited. A copy renamed for its release, a typo fixed on one side, or a case split in two all break the match, and they break it quietly - the match returns nothing, or returns the wrong sibling, and nothing in the repository flags that it guessed.
- What makes a good lineage value?Something generated and meaningless: created once, never reused, never derived from the title, folder or release name, and stored in a field you can filter and export. Derived values change when the thing they were derived from changes, which is precisely the moment the match had to keep working.
saying these in an interview costs you the question
- Assumes the repository records what each copy was cloned from
- Matches on title alone and ignores renamed cases
- Trusts identifier ordering to imply which copy is newer
- Reports a reconstruction without listing the unmatched cases