A match can have several protection layers. The game validates actions against its authoritative state. A platform provides account and service signals. A league may add its own client requirements and review process. A community server may run plugins with local policies. These layers need not see the same facts or impose the same consequences.
Section: Know which observation a layer owns.
The game server knows its accepted inventory and simulation. Client protection sees parts of the local software environment. An account service can know historical enforcement records. A replay reviewer sees whatever the recording retained. Each observation has a time, scope, and source.
Provenance records where information came from and how it was obtained. Keep the originating event identifier, game version, server state, and detector version when forwarding a signal. Otherwise, a later service may misinterpret a copied report as a new measurement.
Section: Three reports can describe one event.
Label a toy event A. The game logs it, a plugin forwards it, and a player report references it. That creates three notifications. Their common origin means they still describe one event.
Clarification: A different event identifier means another record. It does not show that the two events have unrelated causes, or that either event proves cheating.
A later event B adds another observation. Now there are two distinct events. Distinct does not automatically mean statistically independent: both might have been affected by the same game bug or network condition.
Correlation means observations vary together. When several detectors share inputs or assumptions, their mistakes can occur together too. Count unique events and evaluate the combined policy on legitimate cases. Do not turn a copied signal into extra confidence merely by routing it through additional services.
Alternative: Preserve the original event identity across services. Combine its context before deciding how much weight it deserves.
Section: Count overlapping signals once.
Suppose twenty observed cases contain four flagged only by signal A, two flagged by both A and B, three flagged only by B, and eleven flagged by neither. A flags six cases and B flags five. Their intersection is the two cases shared by both sets. Their union is the nine distinct cases flagged by at least one: six plus five minus the two counted twice.
P(B given A) asks a narrower question: among the six cases already flagged by A, how many were also flagged by B? Here it is two out of six, not two out of twenty. Changing the overlap changes that answer. These counts describe an invented sample; they do not prove that any case is cheating. Multiplying P(A) by P(B) gives the intersection only when the events are independent, an assumption shared detector inputs can violate.
Section: Matchmaking risk is different from a cheating verdict.
A trust score summarizes risk or expected match quality for a policy. It may guide matchmaking or prioritize review. It is not necessarily an assertion that the account cheated in a particular match.
Valve’s published CS:GO Trust Factor explanation illustrates that distinction: it describes matchmaking using account and play observations, while leaving changing details undisclosed. An account score does not replace an explanation of which check failed in an enforcement decision.
New accounts, shared hardware, changing devices, and unusual but permitted play can complicate such signals. Keep the scope of a consequence tied to the evidence and documented enforcement policy. A community server’s local removal is different from a platform-wide sanction.
Section: Why online services ban modified consoles.
A console proves what software it booted with a signed report from its security processor, the remote attestation that Lesson 13.6 follows. A console running modified software cannot produce a valid report, because the modified software cannot reach the signing key and cannot make the boot measurements match software it is not.
Why ban the console rather than just ignore the report? A modified console can run cheats in matches with other people, run pirated games, and send the service messages that genuine software never would, so nothing it says can be trusted. Banning it by its unique ID, and sometimes the account, protects other players and the store. The ban is the service’s decision under the terms of service the owner accepted, not a technical malfunction.
Attestation is one layer, not the whole defence. Well-designed online games still check every action on the server, as Chapter 9 describes, because no check on the client is perfect. A server that believes a console’s claim about where a player is standing has the same weakness as one that believes a PC’s.
Section: Delayed enforcement has tradeoffs.
A ban wave applies accumulated enforcement decisions in a batch. Grouping cases can give investigators time to validate them and make immediate detector feedback less revealing. The delay also allows further harm unless other controls prevent or mitigate it.
Use durable case records and preserve the version of the check that led to each decision. If an update causes a false-positive cluster, pause enforcement based on the affected check, investigate its shared cause, and correct affected cases. A general recovery process should exist before a large batch is applied.
Review queues need clear prioritization and limited data access. A report can be valuable without being sufficient evidence for a ban. Repeated reports from the same source or the same incident should not automatically increase the penalty. The purpose of layering is to add useful coverage and context, not to hide responsibility behind a majority of flags.