Two games can reuse a round ID without sharing one event
Published — UTC
A round identifier can be unique within one game or data system without being unique across every export. Removing rows by the printed ID alone can delete a different event that happens to use the same label.
Two R-7 records
Consider these original fictional records. The game labels and amounts are invented.
| Source | Game ID | Round ID | Return |
|---|---|---|---|
| Feed A | G-Blue | R-7 | 3 |
| Feed A | G-Green | R-7 | 9 |
| Feed A | G-Blue | R-7 | 3 |
Under this example's stated identity scheme, the first and third rows describe one event; the middle row describes another. Their combined settled return is 12, not 3, 9 or 15. A key of source + game ID + round ID preserves the distinction.
Ask the exporter which fields identify an event
Do not impose that key on a real export without its field definition. A supplier may use account, session, transaction type or another namespace. A refund can also be a separate transaction associated with a round, so matching its round ID does not automatically make it a duplicate of an award.
Python's set reference provides the basic distinct-value operation. The choice of fields supplied to that operation is the editorial decision being illustrated here.
Retain a duplicate log
Record the key definition and keep removed source rows in an audit copy. If two rows share the full defined key but disagree on amount or status, mark a version conflict instead of selecting the larger return.
Three shortcuts produce three different errors
Summing all rows gives 3 + 9 + 3 = 15, counting Blue twice. Keeping the first row for the short label R-7 gives only 3; keeping the last distinct amount for that label might give only 9. Both lose a real event under this example's stated key. The correct two-event sum is 3 + 9 = 12.
Save the duplicate relationship explicitly: row 3 is a copy of row 1, with the same source, game, round and settled fields. Retaining it in a raw audit file is compatible with excluding it from the calculated total.
A second source can be a copy, not another namespace
The example key assumes Feed A owns its event identifiers. In a real workflow, Feed B might republish Feed A's records. Prefixing every row with a different download source could then count one event twice. Use the documented originating-event identity or a verified mapping between exports; do not infer independence merely from two filenames.
Separate a revision from an extra credit
If a later version changes Blue's settled return from 3 to a final total of 2, the two-event total becomes 2 + 9 = 11. A linked −1 adjustment produces the same total from the earlier 12. Applying the replacement and adjustment together would incorrectly reduce it to 10. The export's field definition must say which representation it uses.
A stake debit, award credit and refund may each have a unique transaction ID while sharing one round. Deduplicate at the level being measured. A count of rounds and a sum of monetary transactions require different keys. If equal full keys carry conflicting amounts without version information, stop the merge for those rows and preserve the conflict rather than selecting an amount arbitrarily.