When a test management tool records which revision of a case an execution ran against, what does that pinned revision let you answer later, and what does it not fix?

## What a pin actually is Recording a result creates an **execution record**: the outcome, who recorded it, when, against which build, usually a comment and any evidence attached. A repository that pins the revision stores one more thing on that record - an identifier for the exact version of the case text that was rendered at the moment the verdict was formed. That is a small field with a large consequence. Without it, an execution points at a case, and a case is a moving object. With it, an execution points at a case *as it was*, and the pair is stable no matter what happens to the master afterwards. The pin matters most in a **live-reference** repository, where the cycle renders the master's current text every time an item is opened. There, the pin is the only provenance that survives an edit. In a snapshot repository the cycle's own copy already plays that role, which is why the two mechanisms are often confused: they answer the same question by different means. ## What the pin lets you answer - **What was on screen.** Render the case at the pinned revision and you see the instructions the tester followed, not the rewrite that landed afterwards. - **Whether drift happened at all.** If the pinned revision equals the current one, the result and the displayed text agree and nothing needs investigating. - **Which results are suspect.** Sweep a cycle for items whose pinned revision is behind the master, and you have the exact set worth a second look - instead of re-running everything or trusting everything. - **Whether one cycle is internally consistent.** Two results on the same case at different pinned revisions mean the cycle was executed against two different texts, which the totals silently combine. - **Which of two versions a defect describes.** A ticket raised from an execution can quote the pinned text rather than a moving definition. ## What the pin does not do 1. **It does not stop the drift.** Pinning is a record, not a lock. The master keeps changing, later testers keep seeing the newer text, and the cycle keeps mixing cohorts. The pin makes that visible, which is different from making it not happen. 2. **It does not judge materiality.** A pin tells you two texts differ and which was in force; it cannot tell you whether the difference was a spelling fix or a rewritten expected result. That classification is the human step, and it is the whole job when you are deciding what to re-run. 3. **It does not invalidate anything.** No mainstream repository silently resets a result to untested because the case gained a revision, and it should not - discarding evidence automatically is worse than flagging it. 4. **It does not gate the cycle.** Nothing prevents closing a cycle whose items all ran against superseded revisions. A pin is provenance, not a quality gate. 5. **It does not necessarily cover the whole screen.** A case can pull in content that is resolved live at render time, and files it points at can be replaced in place. The pin covers the case's own text; anything the case merely references is only as stable as the thing at the other end of the pointer. ## Granularity, and where pins get thin Products differ in how finely they pin, and the difference decides how much the field is worth: | Pin granularity | What it buys | Where it falls short | |---|---|---| | Per execution | exact provenance per verdict | nothing, if the revision is renderable | | Per cycle | one baseline for the whole cycle | hides items added or edited later | | None, but a change timestamp | drift is detectable by comparison | the old text may not be renderable | | None at all | nothing | drift is undetectable after the fact | The last row is the one to watch for, because it is invisible in normal use. A repository with no pin and no cycle-level copy looks perfectly ordinary right up to the day someone asks which steps a passing result referred to, and the honest answer is that nobody can know. A pin also has to be **renderable** to be worth anything. Storing a revision number is cheap; being able to display the case as it stood at that number is the feature. If the trail behind the case is trimmed while executions still reference old revisions, the pins become dangling numbers - a promise of provenance that cannot be redeemed. ## How to use it in practice When a cycle has been running through a period of case churn, the pin turns a vague worry into a bounded task: list the items whose pinned revision is behind, diff each against the current text, keep the ones where only wording moved, and re-execute only where the expected result changed. That is a handful of items rather than a whole cycle, and it is defensible because each decision points at a specific pair of texts.