Which cluster this is
This is the largest component under Common blocks · 95% · Either user · All groups. “Either” requires 95% overlap for at least one endpoint of each link. It does not mean that every pair of users shares 95% of both histories.
The evidence for an inherited package
- The matches include the original answer timestamp, card ID, rating and duration. Sharing card content alone cannot explain these identical events.
- Every one of the 13,784 shared events appears in 34–43 users. Together these events account for 588,219 review rows across the component.
- 24 users retain all 46 deck IDs from the reference hierarchy; 22 retain its parent links too. The IDs were allocated within 160 milliseconds in November 2020, shortly after the inherited review history ends. This is an allocation clue, not an individual import date.
- 21 users retain the same 2,730 reviewed card IDs with the same note and deck assignments.
- Four histories contain only the inherited events. Of the other 39 users, 35 add reviews only after the inherited history ends; four also have earlier or interleaved activity. All 200,511 events outside the inherited set are unique to one user within this component.
Anki explicitly supports exporting review history with scheduling information. Its import documentation describes adopting another deck author's learning progress. That provides a supported mechanism for this pattern. Export documentation · Import documentation
Why some histories match in blocks instead of containing the whole history
Twenty-one users are missing some inherited reviews. Across them, all 4,493 missing rows belong to 1,229 whole card histories. Every affected card has a later learning restart; there are no partially missing old card histories and no restart exceptions.
The exact dataset builder revision keeps only the last learning sequence of each card. Its filtering explains the observed gaps: restarting a card can remove its inherited history from this export, splitting long chronological matches into separate blocks. The filtered export alone cannot prove whether every missing row remains in the original raw collection.
Shared history versus individual activity
Each distinct event is counted once. shared by multiple users, present in one user only. UTC calendar-year aggregates.
| Year | Shared events | Individual events |
|---|---|---|
| 2017 | 142 | 0 |
| 2018 | 3,817 | 0 |
| 2019 | 3,807 | 8,265 |
| 2020 | 6,018 | 22,865 |
| 2021 | 0 | 5,964 |
| 2022 | 0 | 20,673 |
| 2023 | 0 | 38,236 |
| 2024 | 0 | 104,508 |
What we can use next
The 13,784-event signature, its ownership across users, the common deck hierarchy and later learning restarts identify an inherited history family. For data quality, flag shared review events and preserve the later personal reviews. Excluding entire users would discard 200,511 unique reviews; no filtering or training experiment has been performed.
To name the deck or confirm its distribution route, we would need deck names, note content, an original package or import records. This export contains only entity IDs and their relationships. In 14 users, none of the reference reviewed cards remains in current card metadata; review logs can survive deletion, so metadata absence does not refute the shared history.