Safeguarding, Welfare & Integrity

• F17.01.01 Shipped

  Safeguarding officer registry per club and federation

  ✅ PL-F1701a
• F17.01.02 Shipped

  Mandatory safeguarding training tracking (coaches, officials, volunteers)

  ✅ PL-F1701a
• F17.01.03 Shipped

  Background check workflow automation (DBS/police vetting)

  ✅ PL-F1701a
• F17.01.04 Shipped

  Background check status tracking and expiry alerts

  ✅ PL-F1701a
• F17.01.05 Shipped

  Parental consent management for minors (registration, photos, travel)

  ✅ PL-F1701a
• F17.01.06 Shipped

  Incident reporting (abuse, bullying, neglect — confidential)

  ✅ PL-F1701a
• F17.01.07 Shipped

  Incident escalation workflow (club > federation > authorities)

  ✅ PL-F1701b
• F17.01.08 Shipped

  Risk assessment tools for youth events

  ✅ PL-F1701b
• F17.01.09 Shipped

  Adult-to-child ratio enforcement at events

  ✅ PL-F1701b
• F17.01.10 Shipped

  Complaint handling procedure with defined timelines

  ✅ PL-F1701b
• F17.01.11 Shipped

  Full audit trail on all safeguarding records

  ✅ PL-F1701b
• F17.01.12 Shipped

  Safeguarding policy versioning and acknowledgement tracking

  ✅ PL-F1701b

• F17.02.01 Shipped

  Player emergency contact access at events (for authorized officials)

  ✅ PL-F1702a
• F17.02.02 Shipped

  Medical conditions/allergies flag (opt-in, visible to event medical staff)

  ✅ PL-F1702a
• F17.02.03 Shipped

  Incident reporting at events (injury, accident, medical emergency)

  ✅ PL-F1702a
• F17.02.04 Shipped

  First aid requirements checklist per competition level

  ✅ PL-F1702a
• F17.02.05 Shipped

  Medical staff registration per competition

  ✅ PL-F1702b
• F17.02.06 Shipped

  Heat/extreme weather policy triggers and alerts

  ✅ PL-F1702b
• F17.02.07 Shipped

  Incident-to-insurance-claim linkage

  ✅ PL-F1702b

> **Omtaggning 2026-09-06 (D-INTEGRITY `c948eac0.m-1`).** `[DONE]`-taggarna nedan avsåg det

• F17.03.01 Shipped

  Match integrity monitoring (unusual result patterns)

  ✅ c948eac0.m-5 — regelstyrd, DETERMINISTISK mönsterdetektering över färdigspelade resultat: den slutna katalogen ranking_deviation｜dead_rubber｜repeated_deviation som RENA funktioner med deklarerade konstanter (rankingdifferensen 300 ELO, körlängden 3, historikfönstret 365 d), förbundets tre kontroller (flag_threshold_bps default 6500 bps, ranking_deviation_mode, dead_rubber_enabled) bakom integrity:configure, timsvepet integrity_monitoring_scan_tick som bokför VARJE utvärderad match (också den rena) och är flaggornas ENDA producent, flaggkön FLG-<ÅÅÅÅ>-<NNNN> med basis som RÄKNADE indata och de tre verben begin-assessment｜dismiss｜escalate, samt eskaleringen som föder ett riktigt INT--ärende med källan automatic_flag. Ingen severity, ingen sannolikhetsmodell, ingenting publikt (legacy: PL-F1703a)
• F17.03.02 Shipped

  Suspicious activity reporting (anonymous)

  ✅ c948eac0.m-1 — publik tipskanal (POST /v1/public/integrity/tips) med referenstoken, honeypot, IP-tak och tokenuppföljning; avgränsning: integritetskategorier, inte D-SAFE:s trygghetskanal (legacy: PL-F1703a)
• F17.03.03 Shipped

  Investigation case management

  ✅ c948eac0.m-1 — INT-<ÅÅÅÅ>-<NNNN>, femstegs-FSM och överlämning till D-DISCIPLINE:s case-spine via den reserverade intagsrollen integrity_officer (legacy: PL-F1703a)
• F17.03.04 Shipped

  Equipment verification at events (boule homologation check via QR)

  ✅ c948eac0.m-2 — domarens kontroll på tävling (POST /v1/equipment-homologation/inspections, mandatet homologation:inspect) med serienummer ELLER QR-token som handtag, RÄKNAT utfall (approved｜expired｜revoked｜superseded｜level_not_covered｜unknown｜ambiguous｜not_published), kontrollpunkter ur förbundets kravprofil och flaggning till m-1:s tipskö (legacy: PL-F1703a)
• F17.03.05 Shipped

  Equipment confiscation tracking

  ✅ c948eac0.m-4 — beslaget som en spårbar sak: BSL-<ÅÅÅÅ>-<NNNN> ur en radlåst serie, fött ur den UNDERKÄNDA kontrollen (ett approved-utfall kan aldrig beslagtas; ett beslag per kontroll är en DB-invariant), FSM:en confiscated → stored → returned｜forfeited utan ångring, förvaringskedjan som append-only RADER, ärendekopplingen som EN sanning, beslags-/återlämningskvittot som en A4-handling utan QR, de sju additiva kedjeorden och svepet equipment_confiscation_custody_tick (30/90 dygn, största fönstret bär beskedet) (legacy: PL-F1703b)
• F17.03.06 Shipped

  Integration with betting integrity bodies (where applicable)

  ✅ c948eac0.m-6 — förbundets EGEN organkatalog (alert_exchange｜reporting_obligation｜case_escalation, tenant-data och aldrig hårdkod), det SIGNERADE larmintaget (POST /v1/public/integrity/betting-alerts/{intake_ref} — signaturen ÄR auth, HMAC-SHA256 över "{timestamp}.{råa body}", hemligheten FÖRSEGLAD och visad exakt en gång med 24 h roterande överlappsfönster, fyra BYTE-IDENTISKA opaka 404 och idempotensen som en DB-invariant), larmkön LRM-<ÅÅÅÅ>-<NNNN> med m-5:s tre verb och den LOGGADE payload-läsningen, eskaleringen till ett riktigt INT--ärende med källan external_body, rapporteringspliktens materialiserade perioder med en MÄTT rapport som FRYSES med sin content_hash (JSON/CSV) och deklarerar sina egna luckor, incidentrapporten ÅÅÅÅ-INC-NNNN för incident_only, samt överlämningen av ett AVGJORT ärende som en BOKFÖRD handling med ett fryst paket och sin kvittens. Avgränsning: huset SÄNDER ingenting till ett organ (D-14 — :report bokför att en människa skickat filen; utgående avisering är ett bokfört ⊘ utan ägare), och ingenting av det här är publikt utom intaget, som är uteslutet MED SKÄL ur partnerprojektionen (legacy: PL-F1703b)
• F17.03.07 Shipped

  Audit trail on all integrity actions

  ✅ c948eac0.m-1 — hashkedjad, append-only integritetslogg per förbund med GET /v1/integrity/audit/verify och det nattliga svepet integrity_audit_chain_verify (legacy: PL-F1703b)

**Status:** tvistlösningen byggs om greenfield i **D-DISPUTE** (`docs/migration/initiatives/D-DISPUTE.md`).

• F17.04.01 Shipped

  Formal dispute submission (club vs club, player vs federation, etc.)

  ✅ cc7d5a81.m-1 — intaget (POST /v1/disputes ⇒ draft, PATCH på utkastet, POST …/submit) med typade parter (member｜org_node｜federation, exakt två, en per sida) och namn-ögonblicksbild; numret TV-<ÅÅÅÅ>-<NNNN> allokeras EXAKT vid inlämningen ur en radlåst serie och återanvänds aldrig (legacy: PL-F1704a)
• F17.04.02 Shipped

  Dispute classification (financial, sporting, administrative, conduct)

  ✅ cc7d5a81.m-1 — de fyra orden som en SLUTEN mängd i domänpaketet, med registrets fyra MÄTTA kort (classification_counts, räknade i servern över den aktiva mängden inom aktörens scope) (legacy: PL-F1704a)
• F17.04.03 Shipped

  Escalation pathway (club > region > national > continental > FIPJP)

  ✅ cc7d5a81.m-1 + cc7d5a81.m-2 — instansordningen är konfig-data HÄRLEDD ur förbundets egna org_node_levels (ingen hårdkodad kedja: ett förbund med org-djup 0 får inga org-nodssteg, och det är rätt svar), sedan m-2 i fallande djup (djupast först) med GET/PUT …/instance-chain bakom dispute:configure. RÖRELSEN är POST …/{id}/escalate: ett INSTANSBYTE och aldrig en status (FSM:en fick med flit inget escalated-läge), där to_step_key är en försäkran mot serverns NextStep, målnoden HÄRLEDS som förfadern på stegets djup och vägen läses som instance_path[] + …/instance-history (räknad, aldrig lagrad). Är nästa steg överstatligt sker den cross-tenanta överlämningen i samma transaktion — fail-closed myndighetsresolution, ett FRYST kuvert med exakt fjorton PII-minimerade nycklar, F1-6-typen dispute_referral med sitt hookpar, peer-länken och EN kedjepost i båda tenanterna — med mottagning, avvisning + återvändande, tillbakadragande och frysning av ärendet under tiden. Myndighetens beslut i sakfrågan är sedan cc7d5a81.m-4 LEVERERAT: referral-vägen (/v1/disputes/referrals/{id}/decision…) med SAMMA beslutssöm och en DecisionContext driver överlämningen accepted → concluded, nollar active_referral_id (frysningen hävs) och skriver kedjeposter i BÅDA tenanterna, allt eller inget. ⊘ kvar: vidarehöjning CEP → FIPJP (forwarded, m-5); adminytans flik *Eskalering* är cc7d5a81.m-2.t-2 (legacy: PL-F1704a)
• F17.04.04 Shipped

  Mediation workflow (assigned mediator, timeline, resolution)

  ✅ cc7d5a81.m-3 — rundan är en RAD med egen livscykel (dispute_mediation, round 1, 2, 3 …; två samtidigt öppna är omöjliga i DATABASEN, inte i ett if), öppnad och nerlagd genom ärendets egna verb open-mediation/end-mediation (den senare KRÄVER sin motivering) och avslutad med close. Medlaren är en identitet med ett MANDAT (den nya capabilityn dispute:mediate + SYSTEM-rollmallen dispute_mediator = EXAKT två mandat; federation_admin breddas aldrig): medlemskap → mandat → jäv prövas FÖRE första skrivningen, de två negativen svarar BYTE-IDENTISKT 422 dispute_mediator_not_eligible (annars vore rutten ett existens-orakel över förbundets människor) och namnet lagras som ögonblicksbild. Kandidatlistan går genom husets ENDA mandatsöm och märker en jävig kandidat i stället för att sålla bort henne. Tidsplanen är en LÄSNING — sex steg i mockupens ordning, done｜active｜waiting｜overdue räknade av en REN funktion ur rundans egna fakta och den injicerade klockan; overdue finns inte som kolumn, och därför finns inget jobb. Parternas inlagor bär author_kind ∈ {party, recorded} (en klubb utan konto FÖRETRÄDS, och raden säger vem som registrerade), FRYSES vid inlämningen (en rättelse är en NY inlaga med nästa seq) och delgivningen ÄR läsrätten: submitted_at är stämpeln, det finns ingen notis att vänta på. Förlikningen RÄKNAS, den skrivs inte — mediation → settled har inget verb: två accept ⇒ förslaget agreed, rundan settled och tvisten settled i SAMMA transaktion, skyddat av unique (proposal_id, side) + ärendets versionslås. Höjningen ur medling har EN väg (m-2:s egen POST …/escalate, som avslutar rundan som failed med höjningens grounds — allt eller inget). Nio kedjeactions med allowlist (kedjan bär has_*, aldrig texten) och GDPR-modulen ALIASERAR de fem tabellernas fritext, aldrig nollar den. YTAN (cc7d5a81.m-3.t-2): adminfliken Medling i /tvister är LEVANDE — tidsplanen RAD FÖR RAD ur serverns timeline[] (ytan bär ingen egen steglista och jämför aldrig en frist mot klientens klocka), medlarpanelen med den mandatresolvade kandidatlistan där den JÄVIGA kandidaten står utgråad MED sitt skäl, inlagorna med författartypen i klartext, mötena, förlikningen och mockupens tre knappar *Registrera förlikning* · *Byt medlare* · *Medlingen misslyckades — höj till nästa instans*; registrets kolumn *Medlare* visar serverns namn-ögonblicksbild och — utan runda. m-1:s ⊘ tvist-flik-medling-agare och tvist-medlare-agare är BORTA. ⊘ kvar: bilagor/bevis i medlingen har ingen fillagring i huset — raderingspipen är EN transaktion utan efter-commit-fas och kan inte riva bytes ur ett objektlager, så ⊘:et bär ägaren D-GDPR (byte-raderingsvägen: raderingsmodulen bokför blob-referenser som ett FAKTUM i sin transaktion, ett svep river bytes efter commit och deletion_proof redovisar deferred(blob_purge) tills det skett) följt av ett D-DISPUTE-ytdelta när förmågan finns — cc7d5a81.m-4 D-13 prövade de två alternativen och förkastade en D-DISPUTE-egen raderingsmekanism utanför D-GDPR:s pipe (legacy: PL-F1704a); den sökbara medlemsväljaren är omfördelad till ett ägarbeslut om medlemsuppslaget (enumerering)
• F17.04.05 Shipped

  Decision documentation with rationale

  ✅ cc7d5a81.m-4 — beslutet är ett DOKUMENT med egen rad och egen livscykel (dispute_decision, draft → communicated; ett utkast per ärende och en delgivning per instans är omöjliga att dubbla i DATABASEN, inte i ett if), aldrig ett statusord på tvisten: en tvist kan avgöras hos distriktet, överklagas och avgöras igen ovanför, och båda dokumenten måste gå att läsa var för sig. DELGIVNINGEN ÄR FRISTENS START och stämpeln är SERVERNS — communicated_at + appeal_window_ends_at = communicated_at + 21 dygn (dispute.AppealWindowDays, en KODKONSTANT med mockupens *»21 days from service«* som källa; per-tenant-längd är ett icke-mål) skrivs i delgivningens EGEN transaktion, där fullständighetskravet fäller ett ofullständigt utkast 422 med fältpekare och NOLL skrivningar. Kanterna awaiting_decision → decided → appeal_window_open｜closed har INGA verb (domän-interna actioner utanför TransitionActions()): en fri »beslutad«-knapp hade låtit någon skriva att en tvist avgjorts utan ett beslut att läsa. Sista-instans-regeln läser SAMMA rena NextStep som höjningen ⇒ closed med appeal_available: false i stället för en frist mot en instans som inte finns. Omröstningen är RÄKNADE tal, aldrig röster per ledamot (vote_summary/unanimous HÄRLEDS i servern, EN-DASH; tvistnämnder är ofta förtroendevalda UTAN konto, och ledamöternas namn behöver inte bo i beslutsraden för att avgörandet ska vara dokumenterat) och deciding_body_label är en ögonblicksbild. Den som avgör bär ett EGET mandat (dispute:decide på federation_admin/district_admin; dispute_mediator breddas ALDRIG) med jävets tre ben prövade i SÖMMEN — part · medlare i någon runda · myndighetens part — och mandatet prövat FÖRE jävet. Myndighetens beslut i sakfrågan går genom referral-vägen med SAMMA söm och en DecisionContext ⇒ överlämningen concluded, active_referral_id nollad och kedjeposter i BÅDA tenanterna, allt eller inget. Beskedet dispute_decision_communicated (in_app, PII-fria variabler) har MÄTT utfall per sida på beslutsraden — en part utan konto ger null och kansliets service_note, aldrig ett »skickat« om något huset inte skickade, och fristen startar ändå: att låta en trasig kanal flytta en rättslig frist hade gjort fristen till en egenskap hos e-postservern. Fönstret kan ta slut: run-job dispute_appeal_window_lapse_tick (*/15 * * * *, SYSTEMAKTÖR, single-fire i WHERE, UTC-dagen EFTER sista dagen) är kantens ENDA väg och m-4:s ENDA nya jobb. Åtta kedjeactions med allowlist (kedjan bär fields[] och has_*, aldrig texten) och GDPR-modulen ALIASERAR beslutets fem fritextfält medan tal, datum, stämplar och notisutfall står kvar. YTAN (cc7d5a81.m-4.t-2): adminfliken Beslut i /tvister är LEVANDE (?flik=beslut + ?tvist=<id>, eller myndighetens ?overlamning=<id> mot referral-vägen — samma formulär, annan datakälla, aldrig två sanningar om samma avgörande) — mockupens SEX faktakort (*Tvist · Beslutande organ · Beslut · Delgivet · Överklagandefrist · Prejudikatstatus*) fält för fält ur GET …/decision, sektionen *Motivering (obligatorisk)* (rättslig grund · omröstningens tre tal + skiljaktig mening · beslutsskäl) med serverns 422-fältpekare VID fältet, »Spara utkast« (PATCH med If-Match) och »Delge beslutet till parterna«, vars bekräftelsedialog återger fristen ur SERVERNS appeal_window_days — ytan bär inget eget tal — varefter beslutet står i LÄSLÄGE med fristen, notisutfallet per sida i klartext och *Skapa prejudikat →*. Varje knapp är fail-closed (renderas bara när serverns allowed_actions bär verbet) och 409 dispute_decision_frozen｜dispute_lifecycle_error｜dispute_instance_frozen, 403 dispute_conflict_of_interest samt 412/428 (⇒ *»Ladda om ärendet«*) renderas VID åtgärden i role="alert". Registret fick samtidigt sina nya statusetiketter *Hos nämnden · Beslutat · Beslutat — överklagandefrist · Avslutad (beslut)* — den sista HÄRLEDD i presentern ur decision != null, till skillnad från m-3:s *Avslutad (förlikning)*. m-1:s ⊘ tvist-flik-beslut-agare är BORTA ur DOM:en. ⊘ kvar: överklagandet cc7d5a81.m-5 (legacy: PL-F1704b)
• F17.04.06 Shipped

  Precedent case database (searchable by type)

  ✅ cc7d5a81.m-4 — rättsprincipen är REDAKTIONELLT skriven och MEKANISKT vaktad, aldrig automatgenererad ur motiveringen: nämnden skriver heading/summary/keywords[] själv ur ett DELGIVET beslut (ett utkast vore ett påstående om vad nämnden kanske kommer fram till), ett prejudikat per beslut (DB-invariant). Anonymiseringsvakten är en REN funktion som prövas vid POST, PATCH och :publish — den sista gången på det LAGRADE innehållet — och fäller ärendenumret, en parts hela namn, varje namnled om ≥ 4 RUNOR (tre hade fällt »BK«/»IF«/»FC«), en kontaktadress och medlarens namn; 422 precedent_not_anonymised bär FÄLTPEKAREN och namnger ALDRIG matchen — ett 422 som ekade partens namn hade utfört just det röjande vakten finns för. Faller den vid publiceringen sker noll skrivningar och inget serienummer förbrukas. Referensen PREJ-<ÅÅÅÅ>-<NN> myntas ur den RADLÅSTA serien EXAKT vid publiceringen (ett utkast har null — ett nummer i en publicerad serie som aldrig publicerades är ett hål någon måste förklara) och backas aldrig. Ett tillbakadraget prejudikat står KVAR och sökbart MED sitt skäl: den som läst principen ska se att den inte längre gäller, och varför; withdrawn är terminalt. SÖKNINGEN är SERVERNS — ?q= mot en GENERERAD tsvector med GIN-index, plus typ/år/instans och MÄTTA classification_counts — och mandatet prövas TENANT-VITT: en klubbadministratör läser hela förbundets praxis (det är hela poängen), medan status är en BEGÄRAN som skärs mot vad aktören FÅR se ⇒ en TOM mängd, aldrig ett 403. Projektionen pekar ALDRIG tillbaka på ärendet (ingen case_id, ingen decision_id, inget ärendenummer, inte ens för handläggaren) och dispute_precedent står därför UTANFÖR raderingsmodulen, byte-identisk efter en radering och redovisad som n/a(anonymised_by_construction) i deletion_proof — aldrig ett tyst keep. YTAN (cc7d5a81.m-4.t-2): adminfliken Prejudikat i /tvister är LEVANDE (?flik=prejudikat&q=&klass=&ar=&instans=) — sökfältet är en SERVERFRÅGA (debounce, aldrig en klientsållning), typchipsen bär serverns MÄTTA classification_counts (»—« utan svar, aldrig 0), tabellen *Referens · Typ · Rubrik · År · Instans · Läs (anonymiserat) →* har de tre riktiga tillstånden laddar · tomt · fel, och detaljvyn visar rubrik, sammanfattning, nyckelord och status med — bakom dispute:decide — *Redigera · Publicera · Dra tillbaka* (skälet ett RIKTIGT fält, aldrig en window.prompt). Prejudikatformuläret (nått ur beslutet) bär den redaktionella regeln som hjälptext och renderar 422 precedent_not_anonymised VID fältet utan att återge det matchade ordet, och detaljvyn saknar varje länk tillbaka till ärendet — inte ens för handläggaren. m-1:s ⊘ tvist-flik-prejudikat-agare är BORTA ur DOM:en. ⊘ kvar: ingen PUBLIK yta (k-anonymitet i en liten klassificering ett visst år är ett ÄGARBESLUT med D-DISCIPLINE:s alias-apparat som underlag) och prejudikatets följd av ett ändrat beslut ovanför är cc7d5a81.m-5 (legacy: PL-F1704b)
• F17.04.07 Shipped

  Appeal process with defined timelines

  ✅ cc7d5a81.m-5 — överklagandet är ett OBJEKT med egen rad och egen livscykel (dispute_appeal, received → leave_granted → decided · leave_denied · withdrawn), aldrig ett statusord på tvisten: ett ärende kan överklagas instans efter instans, och varje omgång måste gå att läsa för sig efteråt. Numret ÖK-<ÅÅÅÅ>-<NN> myntas ur en RADLÅST serie EXAKT vid inlämningen och har ingen skrivväg. TRE partiella unika index är reglerna, inte ett if — ett överklagande per BESLUT, ett LEVANDE per ärende, HÖGST EN omprövning per instanssteg — och ett tillbakadraget yrkande faller ur alla tre (det ska gå att överklaga igen inom fristen). FRISTEN PRÖVAS TVÅ GÅNGER (FSM:en appeal_window_open och KLOCKAN mot beslutets frusna fönster, genom SAMMA rena LapseBoundary som svepet och läsningen): ett ärende vars frist gick ut i förrgår kan stå kvar som öppet om jobbet legat nere, och att lita på statusen ensam hade gjort jobbets drifttillstånd till en rättslig frist. »Inlämnad dag N av M« LAGRAS ALDRIG — det RÄKNAS ur tre lagrade fakta (beslutets communicated_at, yrkandets filed_at, beslutets FRYSTA appeal_window_days), och migrationen bär med flit ingen kolumn. PRÖVNINGSTILLSTÅNDET är en MOTIVERAD handling med dispute:decide prövat FÖRE jävets FYRA ben, där det fjärde är m-5:s: den som DELGAV det överklagade beslutet får inte avgöra om det får prövas — men får mycket väl fatta det NYA beslutet efter en beviljad omprövning (samma organ prövar igen per definition). Benet bor i EN namngiven funktion som både handlaren, allowed_actions och sömmen läser. Beviljat tillstånd återför tvisten i husets ENDA avgörandemaskin (under_appeal → awaiting_decision) och byter instans genom den DELADE rörelsen — en historikrad med den nya arten appealed, eller HELA överlämningen med sitt F1-6-ärende mot ett peer-steg; escalate breddas ALDRIG med under_appeal. Nekat tillstånd och tillbakadragande AVSLUTAR tvisten i samma transaktion med handlingens motivering som outcome_reason (appeal_decided är ett TRANSITLÄGE). Appellinstansens avgörande slår igenom: delgivningen superseder det omprövade beslutet (m-5 är det ordets ENDA skrivare, och regeln ligger där av NÖDVÄNDIGHET — m-4:s partiella unika index fäller annars skrivningen), binder yrkandet och drar tillbaka ett publicerat prejudikat med en KONSTANT, nummerfri motivering; prejudikatets appeal_state (none｜under_appeal｜superseded_by_appeal) HÄRLEDS och lagras aldrig. Vidarehöjningen forwarded (POST /v1/disputes/referrals/{id}/forward) öppnar en NY överlämning mot nästa steg i FÖRBUNDETS ordning, allt eller inget över tenantgränsen. Sex kedjeactions med allowlist (id:n, enum-ord, tal, has_* — aldrig grunderna eller ett partsnamn), två notistyper med MÄTT utfall per sida, GDPR-modulen ALIASERAR yrkandets fyra fritextfält medan numret, arten, datumen och statusen står kvar, och inget nytt jobb (huset bär EXAKT två dispute-jobb; ett ärende i under_appeal kan aldrig stängas av klockan). YTAN ÄR LEVERERAD i cc7d5a81.m-5.t-2: adminfliken *Överklagande* i /tvister (?flik=overklagande) med mockupens sex kolumner ur SERVERN, *»Inlämnad dag N av M«* ur svarets TVÅ tal (ytan räknar aldrig en frist), de fem statusetiketterna som ikon + TEXT + färg, prövningstillståndet och tillbakadragandet fail-closed på allowed_actions med sin obligatoriska motivering som ett RIKTIGT fält — och eftersom det var mockupens SISTA obyggda flik togs hela ⊘-flikmekanismen bort med den (ingen flik bär längre aria-disabled). ⊘ kvar: bevisbilagor ägs av D-GDPR:s byte-raderingsväg följt av ett D-DISPUTE-ytdelta (legacy: PL-F1704b)
• F17.04.08 Shipped

  Full audit trail on dispute proceedings

  ✅ cc7d5a81.m-1 — hashkedjad, append-only granskningslogg per förbund (dispute_audit_chain/dispute_audit_entry) med husets kedjeform, metadata som allowlist per action (PII kan inte hamna där), EN skrivväg i anroparens transaktion, GET /v1/disputes/audit med RÄKNAD kedjekolumn, on-demand-omräkningen GET /v1/disputes/audit/verify (broken_at_seq) och nattsvepet dispute_audit_chain_verify med append-only digesthistorik, larm en gång per brott och ingen självläkning (legacy: PL-F1704b)

**Status:** F17.05.02 (para-klassificeringen) har fått sin FÖRSTA greenfield-leverans —

• F17.05.01 In progress

  Gender equity reporting (participation rates, leadership positions) — se greenfield-raderna F17.05.01/.05 nedan

  🔨 cc3657f5.m-5 (backend + kontrakt i t-1, adminytan /inkludering i t-2)
• F17.05.02 In progress

  Disability classification management for para-petanque — se greenfield-raderna nedan

  🔨 cc3657f5.m-1 + m-2 + m-3 (anpassade tävlingar kvar i m-4)
• F17.05.03 In progress

  Adaptive equipment registry — pre-rebuild-systemet är BORTTAGET; greenfield i D-PARA m-6, se raderna F17.05.03/.04 nedan

  🔨 cc3657f5.m-6 (register + de två lånesömmarna i t-1, fliken *Adaptiv utrustning* i t-2)
• F17.05.04 In progress

  Inclusion policy tracking per federation — pre-rebuild-systemet är BORTTAGET; greenfield i D-PARA m-6, se raderna F17.05.03/.04 nedan

  🔨 cc3657f5.m-6 (arvsprojektionen + revisionspåminnelsen i t-1, fliken *Inkluderingspolicy* i t-2)
• F17.05.05 In progress

  Diversity dashboards (age, gender, disability, geography) — se greenfield-raderna F17.05.01/.05 nedan

  🔨 cc3657f5.m-5 (backend + kontrakt i t-1, mångfaldsfliken på /inkludering i t-2)
• F17.05.06 Planned

  Accessibility audit tools for venues — pre-rebuild-systemet är BORTTAGET; ägs av D-VENUE (/anlaggning), konsolen LÄNKAR dit och kopierar aldrig deras data

  ⏳ D-VENUE

• F17.06.01 Shipped

  Anonymous reports via encrypted form with secure reference token

  ✅ PL-F1706a
• F17.06.02 Shipped

  Whistleblower protection per EU Directive 2019/1937 (7-day ack, 3-month feedback, retaliation protection)

  ✅ PL-F1706a
• F17.06.03 Shipped

  Background check requirements for coaches and officials (role-based, per-tenant)

  ✅ PL-F1706a
• F17.06.04 Shipped

  Per-nation safeguarding policy with categories, legal basis, translations, and acknowledgement

  ✅ PL-F1706a
• F17.06.05 Shipped

  Safeguarding officer assignment with scope (club/district/federation), certifications, and notification preferences

  ✅ PL-F1706b
• F17.06.06 Shipped

  Mandatory coach safeguarding training tracking with completion, verification, expiry, and compliance checking

  ✅ PL-F1706b
• F17.06.07 Shipped

  Confidential safeguarding incident tracker with severity, confidentiality levels, timeline, and officer assignment

  ✅ PL-F1706b