in this dispute module is there so , as this module is not completely implemented , so now we need to implement like whole flow , so as i am having zero knowledge in this section , so we need to make the flow , in that how dispute will raise how to assign and how to assign to compilance person , like to solve the dispute , and when the dispute will escalate then how it will go to supervisor or higher authority , so i need to complement how flow and and implementation plan , then will confim you to implement , as per now don't imple ment just explain me and give me the plan I read the existing dispute code (dispute_core, the chargeback LiveViews, the workers) and nothing below has been implemented. This covers the domain, what you already have, the gaps, the target flow and a phased plan. 1. The business flow A dispute/chargeback is a cardholder telling their bank "I don't recognise this charge" or "I never got the goods". Your company is the acquirer, the bank side that serves the merchant. The money is pulled back from the merchant unless they can prove the sale was legitimate. Cardholder complains → Issuer bank → Card scheme (Visa/MC) ↓ chargeback filed ACQUIRER (you) receives it, debits merchant ↓ Merchant sends evidence → you "represent" to scheme ↓ Scheme accepts (we win) or rejects → Pre-arbitration → Arbitration ↓ Resolved: recovered or written off Two things drive everything: Deadlines. Every stage has a response deadline set by the scheme, typically 7–45 days. If you miss it, you lose automatically. Money. A lost dispute is a real debit against the merchant, or a loss for you if the merchant can't pay. 2. What you already have Roughly 70% of the mechanics exist. Area Exists today Case record chargeback_cases table, status flow dispute → received → representment → pre_arbitration → arbitration → resolved/written_off Intake CSV import, Mastercom API sync, manual creation, merchant API, retrieval requests Assignment assigned_to column, Team Queue vs My Queue, AutoAssignmentWorker (least-loaded analyst) Escalation escalated_at flag, EscalationRuleWorker (days past due or unassigned) SLA SlaMonitorWorker raises alerts when a case is past due Evidence and audit evidence upload, dispute_case_events (append-only timeline) Money resolve/write-off creates a merchant adjustment through settlement Screens Dashboard, Queues, Approval Queue, Rules, Workflows, Analytics, Reason Codes and more 3. The gaps No roles in the flow. "Analyst", "Compliance", "Supervisor" and "Head" don't exist as concepts. assigned_to is just a user id. You can assign to anyone, and anyone with dispute.case.view can act. Escalation is only a flag. escalated_at is set, but nobody is told, there's no escalation target and no level. It only appears in a tab, and nobody is responsible for escalated cases. No approval gate. The Approval Queue moduledoc says it directly: "nothing gates on a human sign-off". An analyst can resolve, write off or file arbitration alone. Write-offs of large amounts need maker-checker. Raising a dispute has no proper front door. Cases are created by import or sync. There's no clear intake path for a merchant or support agent raising one, with validation (duplicate check, transaction lookup, within the allowed time window). No compliance review step. Nothing models "this needs compliance or fraud review before we respond". No reassignment control or workload limits. Auto-assign only fills the Team Queue, with no handover rules, leave cover or skill routing. SLA is a single date. There's no per-stage SLA or "warning at 80%" level. 4. Proposed target flow Roles (using the existing Authorization.can? permission system, so no new auth framework): Role Permission Can do Dispute Analyst (L1) dispute.case.work Work assigned cases, add evidence, represent, propose resolution within a limit Compliance Officer dispute.case.compliance Review flagged cases (fraud, AML, suspicious merchant), approve or reject and add findings Supervisor (L2) dispute.case.supervise Reassign, approve pre-arb or arb and write-offs up to a limit, handle escalations Head of Disputes (L3) dispute.case.approve_high Approve high-value write-offs, final arbitration decisions Admin existing Rules, workflows, thresholds The case journey: 1. RAISE Sources: scheme file/API | merchant/support (manual "dispute" stage) | retrieval request → validate (txn exists, not duplicate, within time window) → set response_due_date from scheme rules, set priority (amount, merchant risk) 2. ASSIGN Team Queue → auto-assign (least loaded, by scheme/skill) or supervisor manual assign → analyst notified; SLA clock visible 3. WORK (Analyst) gather evidence → merchant response → decide: ACCEPT (write-off) or CONTEST (representment) Optional branch: "Needs compliance review" → Compliance queue → findings → back to analyst 4. ESCALATE (manual or automatic) L1 → L2 Supervisor → L3 Head (see triggers below) 5. SCHEME STAGES representment → pre-arbitration → arbitration (pre-arb and arbitration require supervisor approval before filing) 6. RESOLVE recovered / written off → amount over limit requires approval (maker-checker) → settlement adjustment created, transaction hold cleared Escalation triggers (these extend the existing rules engine): Time: 80% of the SLA elapsed gives the assignee a warning. A breach escalates to the supervisor. 24 hours after that it goes to the Head. Value: amount above a threshold goes to the supervisor or Head regardless of time. Stage: entering pre-arbitration or arbitration needs supervisor approval. Manual: the analyst clicks "Escalate" with a required reason. Compliance can also escalate on a finding. Unassigned: idle in the queue past a limit goes to the supervisor to assign. Approval limits (configurable; the numbers are placeholders for you to confirm): Action Analyst Supervisor Head Write-off / accept up to 500 up to 10,000 unlimited File pre-arbitration needs approval approves – File arbitration – recommends approves 5. Implementation plan Phase A: Roles and assignment (small) Add the permissions above and enforce them in dashboard actions and the API (assign, resolve, write-off, file_*). A role-based eligible-user list for assignment (instead of "every user"), plus an assign/reassign UI that requires a reason. A schema change is not needed. Reuse assigned_to and dispute_case_events. Phase B: Real escalation (medium) Migration: add escalation_level (0–3), escalated_to, escalation_reason to chargeback_cases. A level-based escalation policy: pick the target by role and level, record events, notify through the existing AlertsCore. Extend EscalationRuleWorker for the time, value and stage triggers, with SLA warnings at 80%. A "My Escalations" queue for supervisors and the Head. Phase C: Approvals (maker-checker) (medium) New table dispute_approvals (case, action, requested_by, amount, required_role, status, decided_by, reason). Resolve, write-off, pre-arb and arbitration become "request approval" when over the limit. The approver approves or rejects, and only then does the action run. Rework the Approval Queue to show real pending approvals. Configurable limits, stored in the existing parameters. Phase D: Compliance review (medium) Add a compliance_review sub-state, either as a status or as a flag plus its own table dispute_compliance_reviews (findings, outcome). A Compliance queue screen. Cases come back to the analyst after review. Phase E: Intake (medium) A proper "Raise Dispute" form (transaction lookup by RRN or ID, duplicate and time-window validation, auto SLA and priority). Hook it into the existing create_dispute/1, and optionally the merchant API. Phase F: Polish (small) Per-stage SLAs, notifications (email/in-app), analytics by analyst and escalation level, tests for each phase. Suggested order: A → B → C → E → D → F. A, B and C give you the assign, escalate and supervisor flow you asked about. They can also ship independently. 6. Questions for you or the business These change the design, so please confirm them before I start: Are the roles above right? Do you have a Compliance team distinct from Supervisors, and who is the "higher authority"? What are the approval amount limits and SLA days? The numbers above are placeholders. Does Compliance review apply to every dispute or only flagged ones, such as fraud reason codes or high-risk merchants? Does the merchant raise disputes themselves, or only your support and ops staff? Should I start with Phases A–C only? That is the smallest useful slice. Once you confirm, I'll write the detailed design for the first phase (migrations, functions and screens) and then implement it.