Federation Reporting & Compliance

Reports are described as ReportTemplate documents with configurable sections, deadlines and frequency. Each template maps section types — membership, competitions, financial, umpires, sponsors, government — to data extractors that pull live KPIs out of the platform on generation. Output is a GeneratedReport with typed sections so the same data can be rendered as PDF, exported as Excel or fed into a downstream API, and every revision is tracked so an auditor can reconstruct exactly what was submitted on what date.

Deadline tracking runs as a scheduled job. ReportDeadline rows define the cadence (annual, quarterly, on-demand) and the recipient federation level; the reminder workflow nudges responsible users at configurable intervals before due, escalates to the parent OrgNode if the deadline slips, and logs every reminder in audit. The aggregation endpoint stitches child reports into parent reports — club totals roll into national, national into continental, continental into FIPJP — using the OrgNode hierarchy of the calling tenant, so a national federation does not need to handcraft its FIPJP submission from scratch.

Government reporting maps onto national-sport-council schemas (for example Riksidrottsförbundet's required fields in Sweden) through a GovernmentReportSection type that knows the destination format. Sponsor reporting consolidates participation data, exposure metrics — impressions, clicks, declared value — into a SponsorSection that can be exported to a sponsor portal or emailed as a branded PDF. Audit-ready data is enforced through an is_audit_ready flag on reports plus revision tracking on every supporting document; if the underlying data changes after submission the report regeneration shows the delta. The compliance checklist automatically scores each tournament against required criteria (jury seated, insurance valid, medical certificate present, anti-doping notification sent) with action items for anything missing.

The GDPR Article 33/34 data-breach workflow is a separate but related lifecycle: a DataBreachNotification record opens at incident detection with a 72-hour countdown, requires affected-records count, risk classification and remediation plan, and emits regulator-ready exports (Datainspektionen / CNIL / equivalent) plus affected-data-subject notifications when the risk threshold is met.