RG Reporting and Audit · Turbo Stars

The evidence pyramid

Layer	Artefact	The question it answers
Per player	The protection timeline: markers, cases, interventions, tools, exclusions, suppression states — append-only	"Walk me through this player"
Per case	Signals → proportionate response → escalation logic → outcome, per the playbook	"Why this response, why then"
Per period	The standing report: completeness, speed, outcomes, negative checks	"Is the function working"
Per system	Gate verifications: suppression, exclusion enforcement, register integration — demonstrated, not asserted	"How do you know nothing leaks"

The pyramid builds bottom-up from the event schema's protection family: if the events are first-class and append-only, every layer above is a query; if they are not, every layer is a project.

The three reconciliations

Markers to cases. Every fired marker resolves to a case, every case to an action or reasoned no-action. The delta is the audit's first query and the function's daily zero.
Suppression to sends. The protected population against the outbound logs, across every channel and export path — verified continuously by the gate architecture, sampled independently for the report.
Exclusion to access. The excluded population against login, registration and payment events — zero exceptions, with the register integration's health monitored fail-closed per the implementation standard.

Honest effectiveness

The outcome section borrows every honesty rule this Academy has already established: matched windows and baselines (the cohort discipline), censoring acknowledged, denominators stated, activity never presented as outcome. Two RG-specific additions: segment the effectiveness reads by marker family (an intervention set that works on escalation markers may do nothing for chasing), and report the uncomfortable numbers — repeat escalations, declined tools — because their absence from a report reads as concealment, not success.

Retention and access

Protection records are retained per the market's schedule (configuration rows, per the matrix), access-controlled tightly — this is the most sensitive data class the operator holds — and never repurposed: the one-way rule one final time. The retention question interacts with data-protection rights in ways that need counsel per regime; the operating posture is that the protection trail survives account closure for as long as the regime requires, because the duty it evidences did.

The rehearsal cadence

Twice yearly, played straight: five players pulled by risk criteria, timelines walked; negative checks run live; one historical date reconstructed; everything timed. Findings become the function's improvement backlog. The operations that rehearse discover their leaks in private; the ones that do not, discover them in the finding — and the difference between those two documents is the entire argument of this cluster.

Continue reading: RG operations — the function this evidence describes. Regulatory reporting — the same lineage discipline across every domain.

RG audit — common questions

What does a regulator actually review in an RG audit?

Cases, not policies. The reviewer pulls specific players — often ones who later suffered harm or complained — and walks the timeline: what markers fired, when, what the operator did, how fast, and whether the response escalated appropriately. The policy document frames the expectations; the case files decide the finding. An operation whose evidence is assembled per player in minutes has a different audit than one that greps five systems per question.

What must the per-player protection timeline contain?

Every marker with its firing signals, every case with its handling and clock, every intervention with its content and the player's response, every tool event (limits set, changed, removed — with the mandated delays honoured), every exclusion event, and every promotional suppression state change. Append-only, reconstructable for any date — the event-schema discipline applied to the domain where 'what did you know and when' is the literal audit question.

Which aggregate numbers belong in the standing RG report?

The completeness and speed numbers first: markers fired vs cases opened (must reconcile), marker-to-intervention time distribution, queue age. Then the outcome set: tool uptake, behaviour change on matched windows, repeat escalations, exclusion volumes and re-entry patterns. Then the negative checks: promotional sends to protected players (zero, verified, with the verification method stated) and exclusion enforcement exceptions (zero, likewise). Revenue impact appears as context, never as a performance measure.

How should effectiveness be reported without flattering yourself?

With the same honesty rules as every measurement page in this Academy: matched windows and declared baselines for behaviour change, censoring acknowledged (recent interventions are unresolved, not successful), and the denominator always stated. The temptation specific to RG reporting is activity-as-outcome — messages sent, tools offered — which reads to a reviewer as exactly what it is. Report what changed, not what was attempted.

What is an audit rehearsal for RG?

The same drill as the consent rehearsal: twice a year, someone plays the reviewer. Pull five players by risk criteria and walk their timelines end to end; run the negative checks live (a protected player's absence from every send path, demonstrated); reconstruct one historical date. Time everything. The rehearsal's product is the gap list — and the operations that run it stop fearing the real letter.

Proving the protection.