Dispute Resolution

F17.04 8 features Planned

At a glance

Dispute Resolution gives the petanque ecosystem a single, fair, well-documented path for handling conflicts — between clubs, between players and federations, between national bodies, or up the chain to FIPJP — with structured submissions, neutral mediation, reasoned decisions, transparent appeals and a searchable precedent database. The subsystem keeps every party informed, every deadline visible, and every ruling defensible long after the case is closed.

How it works

Anyone with standing can open a formal dispute. The submission form asks for parties involved, the relevant facts, supporting documents, and a classification: financial, sporting, administrative or conduct-related. The classification drives the routing rules — a sporting dispute about a refereeing decision goes one way, a financial dispute about licence fees goes another.

The escalation pathway is configured per tenant but follows a familiar shape: club first, then region or district, then national federation, then the continental body, and finally FIPJP for cases that cross borders or set new precedent. At each level the dispute is owned by a named handler with clear deadlines for acknowledgement, response and decision. Parties can see exactly where their case sits and what happens next.

Mediation is the default first attempt before formal adjudication. The system assigns a neutral mediator, opens a private workspace for the parties, sets a timeline, and records whether mediation succeeded, partially succeeded or failed. If mediation fails, the case is moved to the appropriate decision body. Decisions are documented with full rationale, citing the rules applied and the evidence weighed, and published — redacted where necessary — to the precedent database, which is searchable by classification, level and outcome.

Appeals are a first-class concept. Each decision lists the appeal window, the appeal body, and the grounds on which an appeal can be lodged. The same audit trail captures every step from initial submission to final decision, so a dispute decided at FIPJP level can be reconstructed years later in detail.

Key capabilities

Formal dispute submission for any party combination with structured classification
Configurable escalation pathway from club to FIPJP with per-level handlers and deadlines
Mediation workflow with assigned mediator and tracked outcome
Decision documentation with rationale and rules cited
Searchable precedent database, redacted where needed
Defined appeal process with windows, bodies and grounds
Full audit trail from submission to final decision

In practice

Two clubs disagree over the eligibility of a transferred player at a regional final. The losing club opens a dispute, classifies it as sporting, attaches the licence document and match sheet, and submits. The regional handler acknowledges within 48 hours and proposes mediation; both clubs accept and a neutral mediator from a different region opens a shared workspace.

Mediation reaches a partial agreement on procedure but not on the result. The case escalates to the national disputes panel, which issues a documented decision citing two prior precedent cases pulled directly from the database. The losing club lodges an appeal within the published window; the appeal is scheduled, the parties prepare, and the audit trail follows the case all the way through.

Features in this subsystem

ID	Status	Features
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)