You published an activity-cluster merge six weeks ago and new evidence splits it - what do you owe the people who acted on it?
answer
- same reach as the original claim
- which claim changed, which observations stand
- linkage retracted, indicators still valid
- who inferred their own risk from it?
- raise the bar for publishing a linkage
basics
~20 sCorrect it with at least the reach of the original claim, and be precise: the shared indicators still stand, the linkage does not. Then fix what let a merge built on commodity overlap be published.
solid answer
~50 sRetract at the same reach as the original: the same sharing community, the same customers, the same distribution marking. Be surgical about what failed - the observables you shared are still valid observations, so blocklists and hunts can stay; what collapses is the claim that one operator did both, and everything anyone inferred from it about capability, intent or their own risk. Say which evidence supported the merge, which new evidence broke it, and name the decisions worth revisiting. Then treat it as a process failure rather than an analyst's mistake: a documented merge standard requiring independent non-commodity overlap, a named approver for anything published as a linkage, and a deliberate separation between the label you track internally and the claim you assert externally. Speed of retraction is what protects credibility in a sharing community; silence is what destroys it.
go deeper
Know that shared cluster judgements get revised, and that a correction has to reach the same people as the original claim rather than sitting in an internal ticket.
Be able to separate the two payloads: the observations you shared remain valid, while the linkage claim is what collapses. Explain why an undifferentiated retraction makes recipients discard good indicators.
Show the correction you would actually send - what was withdrawn, what it rested on, what broke it, what still stands, and which downstream hunts and risk conclusions need redoing.
Own the system: a written merge standard, a separation between internal tracking labels and published linkage claims, a named approver, and an honest account of the incentives - community standing, an executive's desire for a named adversary - that push toward premature merging.
## Separate the two things you published A published cluster carries two distinguishable payloads, and they fail independently: - **Observations** - the domains, hashes, certificates and behaviours you saw. These remain true. Nobody needs to unblock anything. - **A linkage claim** - that these intrusions were one operator. This is what the new evidence kills. An undifferentiated "we were wrong" retraction is worse than useless: recipients cannot tell whether to keep their blocks, and some will discard good indicators. Lead with what still stands. ## Reach, not gesture The correction goes to everyone who received the original, by the same route, under the same distribution marking. If it went to a sharing community, the correction goes to the community. If customer briefings quoted it, those customers get told directly. A footnote in the next quarterly report is not a retraction; it is an attempt to be technically honest without being heard. ## What to actually say 1. **The claim being withdrawn**, stated plainly - not softened into ambiguity. 2. **What the merge rested on** and why that turned out to be commodity - shared access from a supplier, a reseller's hosting, a library default fingerprint. 3. **What broke it** - the specific disconfirming evidence. 4. **What still stands** - the indicators, and any narrower cluster that survives. 5. **Which downstream decisions to revisit** - anyone who concluded they were targeted by a capable data-theft crew, when what actually reached them was a miner sharing a supplier, has a risk picture to redo. That is the real harm of a bad merge: it transfers the intent of the worst intrusion onto the least serious one. ## The organisational question underneath The interesting answer is not the apology; it is what changes so the next merge is not published on the same footing. - **A merge standard, written down.** Independent non-commodity overlap, ideally after the access stage, recorded per merge with the observables that carried it. - **A separation between tracking and asserting.** Internal cluster labels are cheap and revisable by design; a published linkage is a claim your readers will act on. Those should not be the same artefact promoted silently. - **A named approver** for external linkage claims, whose job is to ask "what is this joined on, and who else could have that?" - **A publication delay for linkage specifically.** Indicators are perishable and should go out fast; linkage claims age well and lose almost nothing by waiting for a second case. - **A review cadence for live clusters**, because the natural drift is accretion - each new case looks like it belongs, and nobody re-reads the original basis. ## The pressures you should name This is a judgment under real constraints, and an interviewer wants to hear you acknowledge them. Sharing communities reward contribution, so there is standing to be gained by publishing linkage first. Executives want a coherent named adversary because it makes a risk story tellable. Sales and marketing, in a vendor, want the branded group. Each of those pushes toward premature merging, and none of them absorbs the cost when it is wrong - the cost lands on the defenders who reshaped their programme around a crew that did not exist. ## Why fast retraction is the credibility-preserving move In a trust-based sharing community your value is that your claims can be relied on, which means being known for correcting them. Teams that quietly let a wrong linkage stand get discovered eventually - usually by the peer whose own evidence never fitted - and what they lose is not one claim but the presumption of good faith behind all of them. A team that publishes "we split this, here is why" within days of knowing has demonstrated exactly the property that makes its future claims worth ingesting. ## What you still do not do Do not overcorrect into never publishing linkage. The transfer of knowledge between defenders is the whole point of sharing. The correct outcome is a higher bar, an explicit statement of what the linkage rests on, and a visible willingness to unwind it - not silence.
- A colleague argues that retracting publicly will cost the team more credibility than quietly letting it stand. How do you answer?The claim is already in other people's hunts and risk assessments, so "quietly" is not an option that exists - it only decides who discovers the error and when. In a sharing community the currency is reliability, and a team known for correcting itself is the one whose future claims get ingested. The alternative trades a small, controllable embarrassment for the loss of good-faith presumption across everything else you publish.
- What in the publication process would you change first?Separate the indicator release from the linkage claim. Indicators are perishable and should go out immediately; a linkage claim loses almost nothing by waiting for a second corroborating case and a named approver asking what it is joined on. That single split removes most of the time pressure that produces premature merges without slowing anything operationally useful.
- How do you keep this from being pinned on the analyst who made the merge?Because it was not an analyst decision, it was a process gap: the merge standard was unwritten, the internal label was promoted to an external claim with no review, and the incentive was to publish first. Fixing the analyst fixes nothing and teaches the team to hide revisions - which is the far more expensive failure, since unwound clusters are how clustering is supposed to work.
saying these in an interview costs you the question
- Retracts everything, including still-valid indicators
- Corrects it in a footnote nobody who read the original will see
- Treats the wrong merge as one analyst's error
- Assumes recipients will notice the change themselves
- Concludes the team should stop publishing linkage at all