{ "version": "1.8.0", "slug": "restaurant-delivery-dispute-payout-recovery-desk", "title": "LeakLedger — Restaurant Delivery Dispute & Payout Recovery Desk", "vertical": "Restaurant / hospitality operations — third-party delivery margin recovery (DoorDash, Uber Eats, Grubhub order-error dispute filing, payout-to-POS reconciliation, promo/fee audit) for multi-unit restaurant groups", "seed": { "s": "restaurant-delivery-dispute-payout-recovery-desk", "t": "LeakLedger — Restaurant Delivery Dispute & Payout Recovery Desk", "v": "Restaurant / hospitality operations — third-party delivery margin recovery (DoorDash, Uber Eats, Grubhub order-error dispute filing, payout-to-POS reconciliation, promo/fee audit) for multi-unit restaurant groups", "r": "High", "m": "M" }, "product": { "slug": "restaurant-delivery-dispute-payout-recovery-desk", "project_name": "LeakLedger", "project_type": "done-for-you, outcome-priced restaurant delivery-margin recovery desk", "vertical": "Restaurant / hospitality operations — third-party delivery margin recovery (DoorDash, Uber Eats, Grubhub order-error dispute filing, payout-to-POS reconciliation, promo/fee audit) for multi-unit restaurant groups", "audience": "owner, CFO, or controller economic buyers at QSR/fast-casual/pizza/wings/virtual-brand restaurant groups running 5-75 locations with 15-40% of sales through third-party delivery (ICP #1 beachhead, DoorDash-only pilot scope); secondary buyer: outsourced restaurant accounting firms reselling the desk to their own multi-unit clients (ICP #2, referral channel)", "geography": "United States — pilot cohort launches DoorDash-only nationwide (no state-specific program gate for this business), with Uber Eats and Grubhub coverage added at the day-90 checkpoint once the pilot cohort's win-rate and minutes-per-dispute economics are proven", "scale_expectation": "8 groups maximum for the founding pilot cohort regardless of inbound Leakage Scan demand; hire Recovery Analyst #2 only once minutes-per-dispute-batch-of-25 is <=30 minutes AND win rate >=50% have both held for 4 consecutive weeks; a standing pause on new onboarding after 20 clients until COGS/group, rework rate, escalation rate, and cycle time are measured for a full month within target bands — continuous weekly-cycle demand, not a single filing deadline", "core_workflows": [ "Delivery Leakage Scan & pilot intake", "Nightly statement/POS ingestion and error-charge detection", "Dispute drafting, analyst review, and portal submission inside platform deadline windows", "Weekly POS-to-payout reconciliation and variance handling", "Monthly Recovered-Dollars Statement and quarterly ops-improvement review" ], "discovery": { "one_line_purpose": "On LeakLedger, a restaurant group grants read-only DoorDash/Uber Eats/Grubhub merchant-portal roles and a POS export and gets back, within 5 business days, a free Delivery Leakage Scan quantifying forfeited-and-expired versus still-recoverable dollars. If the group engages, LeakLedger ingests every order and deduction nightly, files every eligible Error Charge dispute inside the platform's Dispute Window with evidence, reconciles every payout against POS weekly, and a Recovery Analyst personally reviews and submits every dispute batch and owns every escalation through to a weekly Leakage Report and a monthly Recovered-Dollars Statement.", "primary_users": [ "owner/CFO/controller economic buyer who owns the delivery-channel P&L line", "Recovery Analyst (the trained human who reviews every dispute batch and owns every escalation)", "DoorDash/Uber Eats/Grubhub merchant support (external counterparty that receives filed disputes and reconciliation follow-up)" ], "jobs_to_be_done": [ "When delivery is 25%+ of my revenue, make sure every order-error charge the platform assigns me is actually mine to eat, not a forfeited-by-default dispute I never got to make", "When a customer-refund charge lands on my statement, catch it before the 14-day (DoorDash) or 30-day (Uber Eats) window closes — nobody on staff has time to watch three portals every week", "When my bank deposit never matches what my POS says I sold on delivery, get a weekly number I can actually trust instead of a monthly guess", "When I ask 'is our promo spend configured the way we set it up', get an answer instead of an assumption" ], "value_prop": "LeakLedger turns a restaurant group's third-party delivery revenue into a fully disputed, reconciled, and defensible margin line — the group grants named-role portal access and a POS feed; LeakLedger ingests every order and deduction nightly, files every eligible dispute inside the deadline with evidence, reconciles every payout against POS weekly, and a Recovery Analyst personally reviews and submits every batch and owns every escalation. LeakLedger is paid a share of recovered dollars plus a modest per-location reconciliation retainer, never hourly.", "competitors": [ "Loop AI ($6M seed 2024 -> $14M Series A Feb 2026, 300+ brands) — sells a reconciliation/dispute SaaS platform the brand's own team must operate; enterprise sales motion, mid-market gets a login not an outcome", "Voosh (SaaS + automation, free-trial-led; published case studies: $108,561/80-location Wendy's franchisee/6mo, $19,727/28-location KFC franchisee/5mo) — still a dashboard/co-pilot, no accountable human desk", "Otter / DTiQ — order aggregation + camera-anchored dispute management, hardware-tied to their loss-prevention stack", "Delaget (PAR) — QSR back-office analytics and 3PD reconciliation reporting, enterprise brand-level deployments not buyable by a 12-location group this week", "The status quo: a GM or owner manually working DoorDash/Uber Eats portals between other duties, or more commonly not working them at all — the default competitor behind most operators' near-zero filing rate" ], "differentiation": "Done-for-you delivery-margin recovery, not software the operator must run: outcome-priced (20-25% of recovered dollars, never hourly), a Recovery Analyst's personal review-and-submit sign-off on every dispute batch, a free Leakage Scan diagnostic entry point, and mid-market positioning (5-75 locations) purpose-built for the segment enterprise SaaS and hardware-anchored vendors don't reach.", "positioning_statement": "For 5-75-location restaurant groups losing 2.5-3% of revenue to unfiled DoorDash/Uber Eats/Grubhub error-charge disputes and unreconciled payouts, LeakLedger is the done-for-you recovery desk that turns portal access and a POS export into a weekly Leakage Report, filed disputes inside every deadline, a reconciled payout, and a monthly Recovered-Dollars Statement — unlike SaaS the operator's team must operate, or the default of nobody filing anything." }, "assumptions": [ { "id": "restaurant-delivery-dispute-payout-recovery-desk-a1", "statement": "Multi-unit operators will engage a paid, contingency-priced recovery desk once a free Leakage Scan on their own DoorDash statements shows a concrete, quantified recoverable-dollar figure.", "confidence": "medium", "impact_if_wrong": "severe", "revisit_trigger": "First 8 pilot Leakage Scan readout calls — reject the wedge if a willingness-to-engage signal is absent." }, { "id": "restaurant-delivery-dispute-payout-recovery-desk-a2", "statement": "A weekly dispute-filing cycle can hit the 5-business-day Leakage Scan turnaround and same-week filing target from DoorDash statements plus a POS export alone, without a custom POS integration at launch.", "confidence": "medium", "impact_if_wrong": "high", "revisit_trigger": "First 5 pilot groups' first full weekly cycle run manually-assisted." }, { "id": "restaurant-delivery-dispute-payout-recovery-desk-a3", "statement": "A sustained dispute Win Rate of >=55% (floor 40%) is achievable at scale by a done-for-you desk, matching the ~60% rate cited anecdotally by systematic disputers in trade press.", "confidence": "low", "impact_if_wrong": "high", "revisit_trigger": "First full 30-day pilot's win-rate measurement by reason code (pilot pricing is pure contingency, so this does not threaten downside even if wrong)." }, { "id": "restaurant-delivery-dispute-payout-recovery-desk-a4", "statement": "Scan-to-pilot conversion reaches roughly 40% and pilot-to-paid conversion roughly 60% among qualified 5-75-location groups (>=15% delivery mix, >=$1,000/mo recoverable).", "confidence": "low", "impact_if_wrong": "severe", "revisit_trigger": "Day-90 pilot-cohort conversion measurement (see launch-plan.md 90-day checkpoint)." }, { "id": "restaurant-delivery-dispute-payout-recovery-desk-a5", "statement": "Annual retention lands near 85% once a client converts, driven primarily by the reconciliation retainer's stickiness rather than the dispute success fee alone.", "confidence": "low", "impact_if_wrong": "medium", "revisit_trigger": "First cohort's annual-renewal cycle (12+ months post-launch — tracked but not a near-term go/no-go gate)." } ], "unknowns": [ { "id": "restaurant-delivery-dispute-payout-recovery-desk-u1", "question": "What is the true Leakage-Scan-to-engaged-group conversion rate among warm, qualified 5-75-location operators at founding pilot pricing?", "blocks": "Pricing hypothesis; scaling decision past the 8-group pilot cap.", "resolution_path": "8-group pilot cohort with an explicit 25%-of-recovery pilot offer, measured against the day-90 checkpoint in launch-plan.md." }, { "id": "restaurant-delivery-dispute-payout-recovery-desk-u2", "question": "How much does rulebook maturity (Layer 3 of ai-engine-spec.md) actually reduce Recovery Analyst minutes-per-dispute-batch by day 90?", "blocks": "Unit-economics model; analyst-throughput assumptions (12+ groups/analyst at day-90 automation).", "resolution_path": "Instrument analyst minutes per dispute batch from pilot 1; compare against the 25min->15min-per-batch-of-25 target in launch-plan.md." }, { "id": "restaurant-delivery-dispute-payout-recovery-desk-u3", "question": "Will DoorDash or Uber Eats move toward fairer auto-adjudication of error charges, shrinking the disputable pool faster than the reconciliation/promo-audit retainer line can absorb the revenue shift?", "blocks": "Long-run revenue mix between success-fee and retainer lines; the core wedge's multi-year durability.", "resolution_path": "Weekly rulebook-diff monitoring (ai-engine-spec.md Layer 3) against platform policy pages; tracked in R1 of the risk register." } ], "expert_panel": [ { "role": "Product Strategy", "key_concern": "Is the DoorDash-only Dispute Desk narrow enough to sell in weeks without multi-platform integration work?", "recommendation": "Launch scoped to DoorDash-only, manual CSV statement pulls acceptable week 1; add Uber Eats and Grubhub only after the pilot cohort clears the day-90 checkpoint.", "dissent": "May understate the eventual three-platform reconciliation story to prospects who assume full coverage from day one." }, { "role": "Software Architecture", "key_concern": "Are we defaulting to a client-facing dashboard the pilot doesn't need yet?", "recommendation": "Single deployable modular monolith; spreadsheet-grade dispute queue and email/PDF delivery only at launch, no client-facing portal.", "dissent": "May read as under-built to an accounting-firm referral partner expecting a branded dashboard." }, { "role": "Frontend / UX", "key_concern": "Is the evidence chain (POS order to error charge to filed dispute to outcome) visible in every analyst-facing view?", "recommendation": "Every dispute batch renders its source POS citation, the platform rulebook citation, and the analyst sign-off in one glance.", "dissent": "Adds density a newly hired analyst might call cluttered before ramping." }, { "role": "Backend / Data", "key_concern": "Is the audit trail append-only and reconstructable for an invoice dispute or a client billing question years later?", "recommendation": "Immutable audit log for every dispute lifecycle state transition (order ID, evidence hash, submitter, timestamp, outcome); this log is also the invoice substantiation.", "dissent": "More write-path discipline than plain CRUD; requires schema discipline as new POS systems are onboarded." }, { "role": "AI / ML", "key_concern": "Are dispute drafts and reconciliation figures grounded in the platform rulebook and POS records, never a free-form guess?", "recommendation": "Retrieval-first drafting citing the specific POS field and rulebook reason code; deterministic date-math (14/30-day countdowns) and dollar arithmetic in code, never the model; mandatory Recovery Analyst gate before any dispute submission.", "dissent": "Slower per-dispute than a fully automated filer; may frustrate a client expecting instant auto-file on every line." }, { "role": "Security", "key_concern": "Is one client's order and payout data isolated from every other client's, and is credential-sharing structurally blocked?", "recommendation": "Row-level auth, per-client retrieval partitioning, log-scrubbing of consumer PII not needed for dispute evidence, and a hard code-level guard that blocks any workflow from ever storing a shared portal password.", "dissent": "None recorded this run." } ], "strategy": { "business_model": "Recovery success fee: 20% of recovered dollars on an annual agreement, 25% during the 30-day pilot/month-to-month (never hourly); reconciliation desk retainer: $99/location/month, waived during the pilot; free Delivery Leakage Scan as the lead magnet; no setup fee", "revenue_streams": [ "Recovery success fee (20-25% of dollars actually recovered)", "Reconciliation desk retainer ($99/location/month, waived during pilot)", "Free Delivery Leakage Scan (lead magnet, not a revenue line)" ], "moat": [ "Outcome ledger — thousands of labeled dispute outcomes per platform per reason code, which prices win probability better than any cold model", "The accountable submission desk — someone must hold the portal role, meet deadlines, and answer for evidence integrity; operators outsource accountability, not text generation", "Cross-client pattern intelligence — platform policy shifts detected in hours across the whole book", "Switching inertia — the reconciliation history that makes month 13's report meaningful" ], "gtm": [ "Founder-led educational content (10-post first-30-days series on dispute mechanics, deadlines, and platform policy) anchored to the free Leakage Scan", "LinkedIn outbound to franchisee owners/CFOs", "Franchisee-association relationships and restaurant accounting-firm referral partnerships", "SEO/AEO content owning 'dispute DoorDash error charge'-class queries" ], "pricing_hypothesis": "20-25% success fee plus $99/location/month retainer clears a 37% pilot-pricing gross margin rising to 64% by day 90 and 75% by year 1 as ingestion/drafting/reporting automate — see financial-model.csv", "kill_criteria": [ "Dispute Win Rate below 40% sustained across the pilot cohort with no salvageable reason-code segment", "DoorDash/Uber Eats move to fair, fully automated error-charge adjudication with no material disputable pool remaining and the reconciliation retainer alone cannot sustain unit economics", "Scan-to-pilot conversion below 15% after 20 qualified Scans (signals the wedge, not just the GTM motion, is off)" ] }, "security": { "stride": [ { "threat": "Spoofing", "scenario": "An unauthorized actor gains a named portal role under a false pretext", "mitigation": "Named-role grants only via the client's own platform admin console, verified at onboarding, revocable by the client at any time" }, { "threat": "Tampering", "scenario": "A dispute is filed with fabricated or altered evidence", "mitigation": "No-assertion-without-artifact rule enforced at the AI-workbench prompt layer plus 100% analyst review at launch (ai-engine-spec.md Layer 4/6)" }, { "threat": "Repudiation", "scenario": "A client disputes an invoice, claiming a recovery wasn't really ours to bill", "mitigation": "Immutable audit log ties every invoice line to a platform-confirmed dispute or reconciliation outcome, timestamped" }, { "threat": "Information disclosure", "scenario": "Consumer PII (names/addresses) from delivery orders leaks or is over-retained", "mitigation": "Field-level minimization at ingestion, encryption at rest, DPA-governed handling, access logging" }, { "threat": "Denial of service", "scenario": "Ingestion pipeline fails silently, missing a dispute deadline", "mitigation": "Automated completeness check gate plus the >=3-day filing buffer rule; missed-feed alerts route to the exception queue" }, { "threat": "Elevation of privilege", "scenario": "An analyst account is used to access another client's data", "mitigation": "Row-level auth and per-client retrieval partitioning; analysts own whole client groups by assignment, not ad hoc access" } ], "privacy_posture": "Service-provider posture under a signed DPA with each client; consumer PII from delivery orders minimized at ingestion and retained only as long as needed for dispute evidence and audit.", "compliance_targets": [ "CCPA/state-privacy service-provider hygiene", "Platform ToS compliance (named-role access only)" ], "data_classifications": [ "Consumer PII (order-level)", "Client financial data (statements, payouts)", "Audit/evidence records" ] }, "devops": { "ci_cd": "Standard git-based CI with a gold-standard eval suite gating any prompt/rulebook/model version change before production cutover (ai-engine-spec.md Layer 10)", "environments": [ "local/dev", "staging (rulebook + eval regression)", "production" ], "observability": [ "Structured logs per ingestion/detection/dispute/reconciliation event", "Weekly win-rate and coverage dashboards", "Exception-queue alerting" ], "testing_pyramid": [ "Unit (deadline math, reconciliation math)", "Component (classification/exception routing)", "E2E (intake through filed dispute)" ], "accessibility_tests": [ "Automated contrast check against brand.md token values", "Manual keyboard walk of the landing page before every deploy" ], "performance_budget": "Landing page <=120KB, zero external requests, LCP <=2.5s mid-tier mobile, INP <=200ms, CLS <=0.1 (DESIGN-STANDARD.md §7)" }, "accessibility_i18n_ethics": { "wcag_target": "WCAG 2.2 AA", "locales": [ "en-US" ], "rtl_support": false, "ethical_risks": [ "Overstating a specific dollar recovery figure before a client's own Scan has run", "Filing a dispute the evidence doesn't actually support to hit a win-rate target" ], "ethical_guardrails": [ "No client-facing dollar figure ships without deterministic-math tie-out (ai-engine-spec.md Layer 5/7)", "No-assertion-without-artifact rule structurally blocks unsupported dispute drafts" ] }, "governance": { "ownership": [ { "area": "Dispute drafting and rulebook accuracy", "owner": "founder / AI engine spec owner" }, { "area": "Client relationship and escalations", "owner": "Recovery Analyst" } ], "docs_required": [ "compliance-checklist.md", "delivery-playbook.md", "ai-engine-spec.md" ], "naming_conventions": [ "Ubiquitous language per brand.md and microsite.lexicon — one term per concept across every artifact" ], "change_control": "Rulebook version bumps require founder review before reaching production drafting; pricing changes require the same review; any change affecting the no-recovery-no-fee guarantee requires legal review before it ships to a client-facing artifact." }, "executive_review": { "consensus": "Launch the DoorDash-only pilot immediately; the evidence bar (trade press quantification, funded competitor category, platform policy specifics, a live government lawsuit) clears the go/no-go threshold decisively.", "dissent": "Software Architecture flagged the risk of appearing under-built to an accounting-firm partner expecting a dashboard; accepted as the correct MVP tradeoff.", "first_10_steps": [ "Sign entity/banking and draft the service agreement + DPA templates", "Stand up the Postgres canonical schema", "Build the DoorDash statement parser and validate against sample data", "Build the deterministic 14-day deadline calculator", "Build the Dispute Drafting Agent with the evidence-sufficiency gate", "Publish the landing page with the Delivery Leakage Calculator", "Build the outbound list of 50 groups", "Make 5 warm Scan offers", "Deliver the first 3-5 Leakage Scans", "Sign the first 2 pilots and grant portal access" ], "go_no_go": "GO", "top_3_risks": [ "Platforms move toward fair, fully automated error-charge adjudication, shrinking the dispute pool", "Dispute Win Rate lands materially below the 40% floor", "POS/data integration long tail eats margin faster than the implementation-fee gate can offset" ] }, "metrics": { "north_star": "Recovered $/location/month (target >=$150 by day 90 of any client's engagement)", "leading": [ "Delivery Leakage Scans requested", "Scan-to-pilot conversion rate", "Dispute Win Rate by platform/reason code" ], "lagging": [ "Annual retention rate", "Gross margin per client group", "ARR" ], "guardrails": [ "100% of deduction lines dispositioned weekly (hard gate)", "Zero disputes missed inside their deadline", "Zero evidence-integrity violations" ] }, "risk_register": [ { "id": "restaurant-delivery-dispute-payout-recovery-desk-r1", "risk": "Platforms move toward fair, fully automated error-charge adjudication", "likelihood": "medium", "impact": "high", "mitigation": "Revenue mix shifts to reconciliation retainer + promo/fee audit; weekly rulebook-diff monitoring", "owner": "founder", "contingency": "Expand to adjacent marketplaces (ezCater, grocery delivery)" }, { "id": "restaurant-delivery-dispute-payout-recovery-desk-r2", "risk": "Dispute Win Rate below the 40% floor", "likelihood": "medium", "impact": "high", "mitigation": "Contingency-only pilot pricing caps client downside; per-reason-code tracking finds salvageable segments", "owner": "Recovery Analyst", "contingency": "Pivot the offer toward reconciliation-first with disputes as upside" }, { "id": "restaurant-delivery-dispute-payout-recovery-desk-r3", "risk": "POS/data integration long tail eats margin", "likelihood": "high", "impact": "medium", "mitigation": "Restrict pilots to Toast/Square/Olo; implementation-fee gate for exotic stacks", "owner": "founder", "contingency": "Decline out-of-scope POS clients until an adapter is built" } ], "roadmap": [ { "phase": "Days 1-30", "weeks": "1-4", "outcomes": [ "3-5 Scans delivered", ">=2 pilots signed with portal access" ], "exit_criteria": [ "First disputes filed inside deadline windows", "Weekly report template validated with pilot clients" ], "kill_criteria": [ "Zero willingness-to-engage signal across the first cohort of Scan readouts" ] }, { "phase": "Days 31-90", "weeks": "5-13", "outcomes": [ "8-pilot cohort complete", ">=4 converted to annual" ], "exit_criteria": [ "Uber Eats coverage added", "Analyst at <=15 min/dispute-batch-of-25" ], "kill_criteria": [ "Win Rate below 40% sustained with no salvageable reason-code segment" ] } ] }, "project_site": { "slug": "restaurant-delivery-dispute-payout-recovery-desk", "app_name": "LeakLedger recovery desk", "archetype": "margin recovery desk", "archetype_label": "delivery-platform dispute & reconciliation desk", "reader_role": "Owner / CFO / Controller", "one_sentence_app": "LeakLedger is a delivery-margin recovery desk for restaurant-group owners, CFOs, and controllers who need every eligible DoorDash/Uber Eats/Grubhub error charge disputed and every payout reconciled before the platform's dispute window quietly forfeits the money.", "homepage_sequence": [ "scene", "workflow", "instrument", "offer", "proof", "qualification", "objections" ], "hero": { "frame_label": "Restaurant delivery operations · margin recovery & reconciliation desk", "eyebrow": "Owner/CFO/controller / a DoorDash error-charge line just grew, or a payout didn't match POS", "interface_title": "LeakLedger recovery desk", "primary_panel_title": "Dispute #LL-2026-004821 · DoorDash order-error charge · Day 11 of 14 dispute window", "primary_panel_body": "Open cycle run: match this order to its POS record, draft the dispute with cited evidence, then stage it in the Recovery Analyst's queue for review and submission before the window closes.", "side_panel_title": "Before this ships", "side_panel_items": [ "Order matched to POS record with a cited, timestamped fact", "Evidence-sufficiency check passed or exception logged in the Exception Queue", "Recovery Analyst has signed off on the dispute reason and evidence bundle" ], "status_metric": "REVIEW", "status_label": "analyst release gate active" }, "language": { "problem_heading": "The owner/CFO's moment", "mechanism_heading": "Inside the LeakLedger recovery desk", "proof_heading": "Why this survives a platform's silence or an invoice question", "offer_heading": "What leaves the room", "objection_heading": "The hard questions", "qualification_heading": "Who should not use this", "cta_close": "Get your free Delivery Leakage Scan — reviewed by a real Recovery Analyst, filed and reconciled through to recovered dollars." }, "modules": [ { "name": "Delivery Leakage Scan", "job": "Turns a group's DoorDash statements (plus POS export if available) into a quantified forfeited-vs-recoverable dollar report within 5 business days.", "artifact": "leakage scan report" }, { "name": "Weekly Leakage Report", "job": "One-page weekly reconciliation of disputes filed, recovered, and pending, by location, with Win Rate.", "artifact": "weekly leakage report" }, { "name": "Dispute batch", "job": "Holds the POS evidence, platform rulebook citation, and Recovery Analyst sign-off behind every filed dispute.", "artifact": "dispute batch record" }, { "name": "Reconciliation Run", "job": "Weekly POS-to-payout certification with every variance routed to the Exception Queue.", "artifact": "reconciliation run record" }, { "name": "Recovered-Dollars Statement", "job": "Monthly invoice-basis statement tying every billed dollar to a confirmed recovery.", "artifact": "recovered-dollars statement" } ], "checkpoints": [ { "label": "Client Account activated", "pass": "All six intake items verified, ClientActivated event emitted", "fail": "Incomplete intake blocks activation and routes to founder follow-up" }, { "label": "Dispute submitted inside deadline", "pass": "Recovery Analyst sign-off recorded with >=3-day buffer", "fail": "Below-buffer item escalates to priority review same day" } ], "signature_scene": "A Recovery Analyst's dispute-review queue: one drafted Dispute open, its POS citation and evidence bundle visible alongside the Dispute Window countdown, one click from either approval-and-submission or a return to the Exception Queue with a logged reason." }, "ddd": { "slug": "restaurant-delivery-dispute-payout-recovery-desk", "project_name": "LeakLedger", "business_understanding": { "summary": "LeakLedger — a restaurant group grants named-role DoorDash/Uber Eats/Grubhub merchant-portal access and a POS export and LeakLedger ingests every order and deduction nightly, flags every eligible Error Charge, drafts every Dispute with cited evidence, files it inside the platform's Dispute Window, reconciles every payout against POS weekly, and a Recovery Analyst personally reviews and submits every dispute batch and owns every escalation through to a weekly Leakage Report and a monthly Recovered-Dollars Statement.", "customer_profile": "QSR/fast-casual/pizza/wings/virtual-brand restaurant groups, 5-75 locations, >=15% delivery mix (beachhead); includes franchisees of major brands (McDonald's, Wendy's, KFC franchisees documented in trade press and vendor case studies) and regional independents; secondary: restaurant accounting firms reselling to their own multi-unit clients", "customer_pain": "Every location generates dozens of small platform deductions weekly — order-error adjustments (25-100% of item price + tax on DoorDash), customer-refund charges, promo/fee mismatches, and occasional missing payouts. Filing a dispute means logging into each platform's portal, order by order, inside a 14-day (DoorDash) or 30-day (Uber Eats) window, often with evidence attached. No GM has the time; the owner just sees a shrinking net deposit. Trade reporting quantifies the bleed at 2.5-3% of revenue caught in disputes (Restaurant Business, 2025) — roughly 20% of already-thin delivery profit — and most mid-size operators file close to zero of it.", "paid_outcome": "A weekly Leakage Report, every eligible dispute filed inside its deadline with evidence, a weekly POS-to-payout reconciliation certifying the match and flagging gaps, a monthly Recovered-Dollars Statement (the invoice basis), and a store/item error heat map the operator's ops team can act on.", "value_creation": "AI compresses per-order extraction, POS matching, error-charge eligibility scoring, dispute drafting, and variance detection into minutes of compute; deterministic code owns every deadline countdown, amount threshold, and dollar computation; humans own Recovery Analyst sign-off on every dispute batch and every platform-support escalation; the platform binds them with an immutable audit trail and per-client isolation.", "why_ai_native": "The detect-draft-file-reconcile loop is only economical with a bounded AI layer feeding deterministic rules: a 20-location group generates 1,500-3,000 delivery orders weekly and dozens-to-hundreds of deduction lines across three portals with different schemas, deadlines, and evidence rules — manually that's 10-20 analyst-hours/week per group, which is why nobody does it. The AI engine collapses that to a review-and-submit chokepoint of roughly 2 hours/week per group at launch, and every model generation improves extraction and evidence-sufficiency judgment without re-platforming.", "assumptions": [ "Restaurant groups will grant named-role portal access rather than insist on credential sharing", "A DoorDash-only pilot scope is narrow enough to prove the model before multi-platform expansion" ], "operational_risks": [ "Analyst review backlog during a deadline-heavy week", "Platform statement format drift breaking the ingestion parser" ], "validation_questions": [ "What is the real Recovery Analyst review time per dispute batch at pilot volume?" ] }, "domain_discovery": { "actors": [ { "actor": "Owner / CFO / Controller (economic buyer)", "role": "Owns the delivery-margin recovery engagement; supplies portal access and POS export; authorizes named-role grants", "goals": [ "Recover every legitimately disputable delivery dollar on time", "Avoid losing GM/manager hours to portal-watching", "Trust the weekly net-delivery-margin number" ], "decisions": [ "Whether to engage LeakLedger", "Which platform/POS access to grant", "Whether to sign the authorized-agent service agreement" ], "pain_points": [ "No time for a per-order portal watch across three platforms", "Doesn't know which error charges are legitimate vs. disputable" ] }, { "actor": "Recovery Analyst", "role": "Reviews AI-drafted dispute batches and reconciliation output; signs off before any submission or client-facing report ships; owns every escalation", "goals": [ "Release only evidence-backed, correctly reasoned disputes", "Protect the client's standing with the platform", "Recover as much of every eligible charge as possible inside the deadline" ], "decisions": [ "Approve, edit, or reject a drafted dispute", "Decide whether an unresolved item needs a platform-support escalation or an exception-queue disposition" ], "pain_points": [ "Volume spikes ahead of a deadline-heavy week", "Ambiguous evidence cases requiring judgment calls" ] }, { "actor": "Client's Own Accountant (external, referral-only)", "role": "Books LeakLedger's operational reports into the client's formal financial records", "goals": [ "Receive a clean, tie-out-verified monthly statement" ], "decisions": [ "How to book recovered dollars and retainer fees" ], "pain_points": [ "Receiving a statement without clear substantiation" ] }, { "actor": "DoorDash / Uber Eats / Grubhub merchant support (external)", "role": "Receives filed disputes and reconciliation-related correspondence; approves, denies, or requests more evidence", "goals": [ "Process disputes per published policy" ], "decisions": [ "Approve or deny each dispute" ], "pain_points": [ "High dispute volume across the platform's whole merchant base" ] } ], "glossary": [ { "term": "Error Charge", "definition": "A platform-assessed deduction for an order-error/refund adjustment charged to the merchant.", "context": "Detection", "example": "DoorDash charges 25-100% of item price + tax for a reported missing item.", "notes": "Never called 'chargeback' internally — that term is reserved for card-network disputes, out of scope.", "used_by": "Detection; Disputing; Client Reporting & Billing" }, { "term": "Dispute", "definition": "A filed, evidenced contest of an Error Charge submitted through a named portal role.", "context": "Disputing", "example": "A Dispute citing a POS ticket showing the item was rung and packed.", "notes": "One Dispute per Error Charge.", "used_by": [ "Disputing", "Client Reporting & Billing" ] }, { "term": "Dispute Window", "definition": "The platform-defined deadline within which a merchant may contest an Error Charge.", "context": "Detection", "example": "DoorDash: 14 days from delivery; Uber Eats: 30 days from order date.", "notes": "Always deterministic date-math, never LLM-estimated.", "used_by": [ "Detection", "Disputing" ] }, { "term": "Recovery Analyst", "definition": "The trained human who reviews and submits every Dispute batch and owns every escalation.", "context": "Disputing", "example": "n/a", "notes": "Never called 'reviewer' or 'agent' in client-facing copy — 'agent' is reserved for AI components internally.", "used_by": [ "Disputing", "Reconciliation", "Client Reporting & Billing" ] }, { "term": "Leakage Report", "definition": "The weekly client-facing deliverable summarizing disputes filed, recovered, and pending, plus Win Rate.", "context": "Client Reporting & Billing", "example": "n/a", "notes": "Never called 'statement' — that term is reserved for the monthly Recovered-Dollars Statement.", "used_by": [ "Client Reporting & Billing" ] } ], "decisions": [ { "decision": "Whether to activate a Client Account", "who": "Founder / Recovery Analyst", "inputs": [ "Completeness checklist result" ], "rule": "No activation until all six intake items pass the gate", "output": "ClientActivated event or a logged rejection", "risk": "Premature activation on incomplete data" }, { "decision": "Whether to submit a drafted Dispute", "who": "Recovery Analyst", "inputs": [ "Evidence-sufficiency score", "Deadline buffer" ], "rule": "No submission without analyst sign-off and >=3-day buffer", "output": "DisputeSubmitted event or a return to draft", "risk": "Missed deadline if review backs up" } ], "events": [ { "event": "ClientActivated", "meaning": "A Client Account has passed the completeness gate and is ready for ingestion.", "trigger": "ActivateClientAccount command succeeds", "downstream": [ "[PLACEHOLDER] owner to complete" ] }, { "event": "DisputeWon", "meaning": "A platform has confirmed a filed Dispute's recovery.", "trigger": "Outcome Tracking Agent polls a confirmed win", "downstream": "RecoveryLedgerEntry created; invoice basis updated" } ] }, "subdomains": [ { "name": "Detection & Disputing", "type": "core", "description": "Nightly ingestion, error-charge classification, deadline computation, evidence-backed dispute drafting, analyst review, and portal submission.", "reason": "This is the paid outcome's first gate — the dispute filed inside the deadline is the recovered dollar.", "business_value": "Direct revenue driver; every weekly Leakage Report starts here.", "recommendation": "Build in-house, deterministic-rules-first for all dollar math and deadlines.", "ai_involvement": "Extraction, order-to-POS matching, dispute drafting, evidence-bundle assembly", "human_involvement": "Recovery Analyst review and submission of every batch; escalation ownership", "risks": [ "Missed deadline causing a forfeited charge", "Insufficient evidence causing a platform rejection" ], "validation_questions": [ "What is the real analyst review time per dispute batch at volume?" ] }, { "name": "Reconciliation", "type": "core", "description": "Weekly POS-to-payout certification and promo/fee variance detection across all connected platforms.", "reason": "Differentiates LeakLedger from a bookkeeper who reconciles monthly totals at best.", "business_value": "Drives the reconciliation retainer revenue line and client trust in the net-delivery-margin number.", "recommendation": "Build in-house; deterministic variance math only, never LLM arithmetic.", "ai_involvement": "Anomaly explanation, variance-cause hypothesis drafting", "human_involvement": "Recovery Analyst review of variances >$200; report sign-off", "risks": [ "Wrong number delivered to a client", "Missed payout gap" ], "validation_questions": [ "How often does a flagged variance resolve to a genuine platform error vs. a mapping gap?" ] }, { "name": "Client Reporting & Billing", "type": "core", "description": "Weekly Leakage Report assembly, monthly Recovered-Dollars Statement, and success-fee/retainer invoicing tied to the recovery ledger.", "reason": "This is the trust-and-invoice-substantiation layer that makes outcome pricing credible.", "business_value": "Directly drives renewal and reduces invoice disputes.", "recommendation": "Build thin tooling on top of the deterministic reconciliation and dispute-outcome data.", "ai_involvement": "Report narrative drafting from deterministic figures only", "human_involvement": "Recovery Analyst sign-off before every report or invoice sends", "risks": [ "Tie-out failure reaching a client", "Invoice dispute over what counts as 'recovered'" ], "validation_questions": [ "What's the actual rework rate on reports before they clear the tie-out gate?" ] }, { "name": "Platform Rulebook", "type": "supporting-may-become-core", "description": "Versioned, citation-anchored DoorDash/Uber Eats/Grubhub dispute-policy library with weekly diff detection.", "reason": "Could become core as it matures into a licensable, cross-client data asset (win-probability-by-reason-code).", "business_value": "Compounds with every dispute outcome and every policy diff detected.", "recommendation": "Build thin at launch; invest as the outcome ledger grows.", "ai_involvement": "Diff detection drafting against platform help-center pages", "human_involvement": "Founder/ops-lead review before a rulebook version bump reaches production drafting", "risks": [ "Stale rulebook drafting disputes against outdated policy" ], "validation_questions": [ "How often does a platform change policy without clear notice?" ] }, { "name": "Outreach & Sales", "type": "generic", "description": "Leakage Scan intake, LinkedIn/outbound, franchisee-association and accounting-firm partnerships.", "reason": "Off-the-shelf tooling (HubSpot free, Calendly) deliberately keeps engineering focus on the recovery engine.", "business_value": "Pipeline generation, not the core moat.", "recommendation": "Buy, don't build.", "ai_involvement": "None at launch", "human_involvement": "Founder-led", "risks": [ "Low conversion if the Scan isn't compelling" ], "validation_questions": [ "What is the real Scan-to-pilot conversion rate?" ] } ], "core_domain_analysis": { "primary_core": "Detection & Disputing", "secondary_cores": [ "Reconciliation", "Client Reporting & Billing" ], "supporting_may_become_core": [ "Platform Rulebook" ], "generic_do_not_distract": [ "Outreach & Sales", "CRM/pipeline tracking" ], "rationale": "The paid outcome is a filed, won, and reconciled recovered dollar, so Detection & Disputing is the primary core. Reconciliation and Client Reporting & Billing are secondary cores because the weekly discipline and invoice-substantiation trust are the human-plus-AI moat that differentiates LeakLedger from software the operator's team would have to run. The Platform Rulebook could become core as it matures into a licensable, multi-platform outcome-ledger asset, but starts as supporting. Outreach & Sales uses off-the-shelf tooling deliberately to keep engineering focus on the detect-dispute-reconcile-report engine." }, "bounded_contexts": [ { "name": "Intake", "purpose": "Turn a client's granted portal roles and POS feed into a completeness-checked, active Client Account ready for ingestion.", "subdomain": "Detection & Disputing (core)", "type": "core", "owned_language": [ "named-role grant", "POS export", "Leakage Scan" ], "owns": [ "Client onboarding lifecycle", "Completeness-gate state" ], "does_not_own": [ "Order matching", "Dispute drafting" ], "primary_actors": [ "Owner / CFO / Controller" ], "entities": [ "ClientAccount", "PortalGrant" ], "value_objects": [ "CompletenessScore" ], "aggregates": [ "ClientAccountAggregate" ], "domain_services": [ "Intake completeness checker" ], "application_services": [ "ReceiveScanIntake", "ActivateClientAccount" ], "commands": [ "ReceiveScanIntake", "ActivateClientAccount" ], "domain_events": [ "scan.intake_received", "ClientActivated" ], "policies": [ "Auto-flag a missing required intake item against the six-item completeness checklist" ], "specifications": [ "IntakeCompletenessSpec" ], "invariants": [ "A ClientAccount cannot activate until all six intake items pass the completeness gate" ], "ai_agents": [ "Extraction Agent" ], "human_roles": [ "Owner / CFO / Controller" ], "data_owned": [ "ClientAccount", "PortalGrant" ], "inputs": [ "Named-role portal grants", "POS export schedule", "location roster", "promo calendar", "menu/price file" ], "outputs": [ "Activated ClientAccount ready for nightly ingestion" ], "external_integrations": [ "DoorDash Merchant Portal (named role)", "POS export (Toast/Square/Olo/CSV)" ], "risks": [ "Incomplete roster/POS data blocks the Leakage Scan" ], "interfaces": [ "-> Ingestion" ] }, { "name": "Ingestion", "purpose": "Nightly pull and normalization of platform statements and POS exports into the canonical order/deduction/payout model.", "subdomain": "Detection & Disputing (core)", "type": "core", "owned_language": [ "canonical order model", "statement line" ], "owns": [ "Statement/POS parsing", "Normalization state" ], "does_not_own": [ "Eligibility scoring", "Dispute drafting" ], "primary_actors": [ "Extraction Agent" ], "entities": [ "DeliveryOrder", "PlatformStatementLine" ], "value_objects": [ "ConfidenceScore" ], "aggregates": [ "DeliveryOrderAggregate" ], "domain_services": [ "Statement parser", "POS schema mapper" ], "application_services": [ "IngestPlatformStatements", "IngestPOSExport" ], "commands": [ "IngestPlatformStatements", "IngestPOSExport" ], "domain_events": [ "OrderIngested", "StatementNormalized" ], "policies": [ "Below-threshold field mapping routes to the Exception Queue" ], "specifications": [ "CanonicalSchemaCompletenessSpec" ], "invariants": [ "A DeliveryOrder cannot advance to Detection until required fields are present or exception-logged" ], "ai_agents": [ "Extraction Agent" ], "human_roles": [], "data_owned": [ "DeliveryOrder", "PlatformStatementLine" ], "inputs": [ "Platform statement exports", "POS exports" ], "outputs": [ "Normalized canonical order/deduction/payout records" ], "external_integrations": [ "DoorDash Developer API (where available)", "Uber Eats reporting", "Toast/Square/Olo POS exports" ], "risks": [ "Malformed export silently mis-extracted", "Portal format drift" ], "interfaces": [ "-> Detection", "-> Reconciliation" ] }, { "name": "Detection", "purpose": "Classify deductions, compute Dispute Window deadlines, and score win probability for each ErrorCharge.", "subdomain": "Detection & Disputing (core)", "type": "core", "owned_language": [ "Error Charge", "Dispute Window", "win-probability score" ], "owns": [ "Deduction classification", "Deadline computation" ], "does_not_own": [ "Dispute submission" ], "primary_actors": [ "Detection Agent" ], "entities": [ "ErrorCharge" ], "value_objects": [ "DeadlineWindow", "WinProbabilityScore" ], "aggregates": [ "ErrorChargeAggregate" ], "domain_services": [ "Deadline calculator", "Win-probability model" ], "application_services": [ "DetectErrorCharge", "ComputeDeadline" ], "commands": [ "DetectErrorCharge" ], "domain_events": [ "ErrorChargeDetected" ], "policies": [ "File >=3 days before Dispute Window close — deterministic, never LLM" ], "specifications": [ "DeadlineBufferSpec" ], "invariants": [ "No ErrorCharge deadline is ever computed by the LLM — deterministic date-math only" ], "ai_agents": [ "Detection Agent" ], "human_roles": [], "data_owned": [ "ErrorCharge" ], "inputs": [ "Normalized canonical order/deduction records", "Platform Rulebook" ], "outputs": [ "Flagged, deadline-scored ErrorCharge records" ], "external_integrations": [], "risks": [ "Missed eligible charge", "Wrong deadline computation" ], "interfaces": [ "-> Disputing" ] }, { "name": "Disputing", "purpose": "Draft, analyst-review, submit, and track Disputes through to a won/rejected outcome.", "subdomain": "Detection & Disputing (core)", "type": "core", "owned_language": [ "Dispute", "evidence bundle", "Recovery Analyst" ], "owns": [ "Dispute lifecycle", "Submission audit log" ], "does_not_own": [ "Payout reconciliation" ], "primary_actors": [ "Recovery Analyst", "AI workbench" ], "entities": [ "Dispute" ], "value_objects": [ "EvidenceBundle", "ConfidenceBand" ], "aggregates": [ "DisputeAggregate" ], "domain_services": [ "Dispute drafter", "Evidence-integrity checker" ], "application_services": [ "DraftDispute", "ReviewAndSubmitDispute", "TrackDisputeOutcome" ], "commands": [ "DraftDispute", "ReviewAndSubmitDispute" ], "domain_events": [ "DisputeDrafted", "DisputeSubmitted", "DisputeWon", "DisputeRejected" ], "policies": [ "No assertion in a Dispute without a POS/system artifact behind it" ], "specifications": [ "EvidenceSufficiencySpec" ], "invariants": [ "A Dispute cannot submit without Recovery Analyst sign-off on evidence sufficiency" ], "ai_agents": [ "Dispute Drafting Agent" ], "human_roles": [ "Recovery Analyst" ], "data_owned": [ "Dispute" ], "inputs": [ "ErrorCharge records", "POS evidence", "Platform Rulebook" ], "outputs": [ "Submitted Dispute with tracked outcome" ], "external_integrations": [ "DoorDash Merchant Portal", "Uber Eats Manager", "Grubhub for Restaurants" ], "risks": [ "Evidence-integrity failure damages platform standing", "Rejected dispute mishandled" ], "interfaces": [ "-> Client Reporting & Billing" ] }, { "name": "Reconciliation", "purpose": "Weekly POS-to-payout certification and variance handling.", "subdomain": "Reconciliation (core)", "type": "core", "owned_language": [ "Payout Reconciliation", "variance" ], "owns": [ "ReconciliationRun lifecycle", "Variance disposition" ], "does_not_own": [ "Dispute filing" ], "primary_actors": [ "Recovery Analyst" ], "entities": [ "PayoutVariance" ], "value_objects": [ "VarianceAmount" ], "aggregates": [ "ReconciliationRunAggregate" ], "domain_services": [ "Variance calculator" ], "application_services": [ "RunWeeklyReconciliation" ], "commands": [ "ReconcilePayout" ], "domain_events": [ "PayoutReconciled", "VarianceFlagged" ], "policies": [ "Any variance >$200 routes to the Exception Queue" ], "specifications": [ "TieOutSpec" ], "invariants": [ "No reconciliation figure is ever LLM-computed — deterministic math only" ], "ai_agents": [ "Anomaly Explanation Agent" ], "human_roles": [ "Recovery Analyst" ], "data_owned": [ "PayoutVariance" ], "inputs": [ "DeliveryOrder records", "Payout statements" ], "outputs": [ "Weekly ReconciliationRun with certified match or flagged variances" ], "external_integrations": [ "Platform payout statements", "POS sales totals" ], "risks": [ "Missed payout gap", "False-positive variance noise" ], "interfaces": [ "-> Client Reporting & Billing" ] }, { "name": "Client Reporting & Billing", "purpose": "Assemble tie-out-checked client reports and compute invoices from confirmed recoveries only.", "subdomain": "Client Reporting & Billing (core)", "type": "core", "owned_language": [ "Leakage Report", "Recovered-Dollars Statement", "tie-out" ], "owns": [ "Report/statement assembly", "Invoice computation" ], "does_not_own": [ "Dispute or reconciliation source data" ], "primary_actors": [ "Recovery Analyst" ], "entities": [ "LeakageReport", "RecoveredDollarsStatement", "Invoice" ], "value_objects": [ "TieOutStatus" ], "aggregates": [ "RecoveryLedgerEntryAggregate" ], "domain_services": [ "Tie-out checker", "Invoice computer" ], "application_services": [ "DeliverLeakageReport", "InvoiceRecoveredDollars" ], "commands": [ "DeliverLeakageReport", "InvoiceRecoveredDollars" ], "domain_events": [ "LeakageReportDelivered", "RecoveredDollarsInvoiced" ], "policies": [ "A report failing tie-out is blocked from delivery, never sent late-but-wrong" ], "specifications": [ "ReportTieOutSpec" ], "invariants": [ "No invoice line exists without a corresponding DisputeWon or PayoutReconciled ledger entry" ], "ai_agents": [ "Report Narrative Agent" ], "human_roles": [ "Recovery Analyst" ], "data_owned": [ "LeakageReport", "RecoveredDollarsStatement", "RecoveryLedgerEntry" ], "inputs": [ "DisputeWon/DisputeRejected events", "PayoutReconciled events" ], "outputs": [ "Delivered weekly report, monthly statement, monthly invoice" ], "external_integrations": [ "Stripe invoicing", "Email delivery" ], "risks": [ "Tie-out failure reaching a client", "Invoice dispute" ], "interfaces": [] } ], "context_map": [ { "upstream": "Intake", "downstream": "Ingestion", "relationship": "Customer-Supplier", "integration_pattern": "Domain event (ClientActivated) gates the first ingestion run", "translation_notes": "Canonical schema is the shared contract; no direct database coupling.", "pattern": "Customer-Supplier", "contract_type": "domain event", "data_exchanged": [ "[PLACEHOLDER] owner to complete" ], "events_exchanged": [ "ClientActivated" ], "ownership_boundary": "Downstream never writes to upstream's tables", "acl_notes": "Anti-corruption translation not needed — shared canonical schema", "business_reason": "Keeps each context's invariants enforceable independently", "failure_risks": [ "[PLACEHOLDER] owner to complete" ] }, { "upstream": "Ingestion", "downstream": "Detection", "relationship": "Customer-Supplier", "integration_pattern": "Domain event (OrderIngested) triggers deduction classification", "translation_notes": "Only normalized canonical records cross the boundary.", "pattern": "Customer-Supplier", "contract_type": "domain event", "data_exchanged": "Canonical order/deduction payload", "events_exchanged": [ "OrderIngested" ], "ownership_boundary": "Downstream never writes to upstream's tables", "acl_notes": "Shared canonical schema", "business_reason": "Keeps ingestion parsing independent of classification logic", "failure_risks": "Detection stalls if ingestion fails silently" }, { "upstream": "Detection", "downstream": "Disputing", "relationship": "Customer-Supplier", "integration_pattern": "Domain event (ErrorChargeDetected) triggers dispute drafting", "translation_notes": "Only eligibility-scored ErrorCharge records cross the boundary.", "pattern": "Customer-Supplier", "contract_type": "domain event", "data_exchanged": "ErrorCharge payload with deadline and win-probability score", "events_exchanged": [ "ErrorChargeDetected" ], "ownership_boundary": "Downstream never writes to upstream's tables", "acl_notes": "Shared canonical schema", "business_reason": "Keeps eligibility scoring independent of drafting logic", "failure_risks": "Late detection shrinks the filing buffer" }, { "upstream": "Disputing", "downstream": "Client Reporting & Billing", "relationship": "Customer-Supplier", "integration_pattern": "Domain events (DisputeWon/DisputeRejected) feed the recovery ledger", "translation_notes": "Only confirmed outcomes create RecoveryLedgerEntry records.", "pattern": "Customer-Supplier", "contract_type": "domain event", "data_exchanged": "Confirmed dispute outcome payload", "events_exchanged": [ "DisputeWon", "DisputeRejected" ], "ownership_boundary": "Billing never writes to Disputing's tables", "acl_notes": "Shared canonical schema", "business_reason": "No invoice line without a confirmed outcome", "failure_risks": "Ledger lag if outcome-tracking polling fails" }, { "upstream": "Reconciliation", "downstream": "Client Reporting & Billing", "relationship": "Customer-Supplier", "integration_pattern": "Domain event (PayoutReconciled) feeds the weekly Leakage Report", "translation_notes": "Only certified reconciliation runs cross the boundary.", "pattern": "Customer-Supplier", "contract_type": "domain event", "data_exchanged": "ReconciliationRun payload", "events_exchanged": [ "PayoutReconciled", "VarianceFlagged" ], "ownership_boundary": "Billing never writes to Reconciliation's tables", "acl_notes": "Shared canonical schema", "business_reason": "Keeps reconciliation math independent of report formatting", "failure_risks": "Report delayed if reconciliation run is late" } ], "external_integrations": [ { "system": "DoorDash Merchant Portal / Developer API", "direction": "bidirectional", "pattern": "named-role portal access at launch; API preferred for ingestion where available", "risk": "Portal format changes without notice", "owner_context": "Ingestion", "data_in": [ "[PLACEHOLDER] owner to complete" ], "data_out": [ "[PLACEHOLDER] owner to complete" ], "trigger": "Nightly ingestion; weekly dispute cycle", "internal_model": "Canonical order/deduction schema", "acl_strategy": "Parser + LLM normalization layer translates any export format to the canonical schema", "failure_strategy": "Malformed export routes to the Exception Queue", "audit_need": "Every submission timestamped in the audit trail" }, { "system": "Uber Eats Manager / reporting API", "direction": "bidirectional", "pattern": "named-role portal access at launch; API preferred where available", "risk": "96-hour late-report exemption misapplied", "owner_context": "Ingestion", "data_in": "Statements, order-error adjustments", "data_out": "Filed disputes only", "trigger": "Nightly ingestion; weekly dispute cycle", "internal_model": "Canonical order/deduction schema", "acl_strategy": "Parser + LLM normalization layer", "failure_strategy": "Malformed export routes to the Exception Queue", "audit_need": "Every submission timestamped" }, { "system": "Grubhub for Restaurants", "direction": "bidirectional", "pattern": "named-role portal access, added at day-90 checkpoint", "risk": "Statement format differs from DoorDash/Uber Eats", "owner_context": "Ingestion", "data_in": "Statements", "data_out": "Filed disputes only", "trigger": "Weekly cycle post day-90 rollout", "internal_model": "Canonical order/deduction schema", "acl_strategy": "Platform-specific parser added to the ingestion layer", "failure_strategy": "Exception Queue", "audit_need": "Every submission timestamped" }, { "system": "POS (Toast / Square / Olo)", "direction": "inbound", "pattern": "scheduled export or API at launch; CSV acceptable week 1", "risk": "Inconsistent schema across POS vendors", "owner_context": "Ingestion", "data_in": "Order-level sales records with timestamps", "data_out": "None", "trigger": "Nightly and weekly cycles", "internal_model": "Canonical order record", "acl_strategy": "Format-agnostic parser + LLM field mapping with confidence scoring", "failure_strategy": "Below-threshold mapping routes to analyst confirmation", "audit_need": "POS-change history retained per client" }, { "system": "Stripe (invoicing)", "direction": "outbound", "pattern": "Invoice generated from RecoveryLedgerEntry totals only", "risk": "Invoice line without a ledger-confirmed basis", "owner_context": "Client Reporting & Billing", "data_in": "None", "data_out": "Invoice line items", "trigger": "Monthly billing cycle", "internal_model": "RecoveryLedgerEntry", "acl_strategy": "Deterministic mapping from ledger to invoice line", "failure_strategy": "Invoice generation blocked if any line lacks a ledger reference", "audit_need": "Every invoice line traceable to a ledger entry" } ], "event_storm": [ { "seq": 1, "command": "ReceiveScanIntake", "event": "scan.intake_received", "actor": "Owner / CFO / Controller", "context": "Intake", "aggregate": "ClientAccount", "policy": "Six-item completeness checklist auto-enforced", "downstream": "Leakage Scan begins", "risk": "Incomplete portal/POS data blocks the Scan" }, { "seq": 2, "command": "ActivateClientAccount", "event": "ClientActivated", "actor": "Founder / Recovery Analyst", "context": "Intake", "aggregate": "ClientAccount", "policy": "No activation until completeness gate passes", "downstream": "Nightly ingestion begins", "risk": "Premature activation on incomplete data" }, { "seq": 3, "command": "IngestPlatformStatements", "event": "OrderIngested", "actor": "Extraction Agent", "context": "Ingestion", "aggregate": "DeliveryOrder", "policy": "Confidence-scored field mapping; below-threshold fields flagged", "downstream": "Detection begins", "risk": "Malformed statement silently mis-extracted" }, { "seq": 4, "command": "DetectErrorCharge", "event": "ErrorChargeDetected", "actor": "Detection Agent", "context": "Detection", "aggregate": "ErrorCharge", "policy": "Deadline computed deterministically; win-probability scored", "downstream": "Dispute drafting queued", "risk": "Missed eligible charge" }, { "seq": 5, "command": "DraftDispute", "event": "DisputeDrafted", "actor": "Dispute Drafting Agent", "context": "Disputing", "aggregate": "Dispute", "policy": "No assertion without a cited POS artifact", "downstream": "Recovery Analyst review queue", "risk": "Insufficient evidence drafted" }, { "seq": 6, "command": "ReviewAndSubmitDispute", "event": "DisputeSubmitted", "actor": "Recovery Analyst", "context": "Disputing", "aggregate": "Dispute", "policy": "100% review at launch; risk-tiered sampling later", "downstream": "Outcome tracking begins", "risk": "Deadline missed if review backs up" }, { "seq": 7, "command": "TrackDisputeOutcome", "event": "DisputeWon / DisputeRejected", "actor": "Outcome Tracking Agent", "context": "Disputing", "aggregate": "Dispute", "policy": "Rejected disputes get a root-cause tag feeding the rulebook", "downstream": "Recovery ledger entry created on a win", "risk": "Outcome polling gap delays the ledger" }, { "seq": 8, "command": "ReconcilePayout", "event": "PayoutReconciled / VarianceFlagged", "actor": "Reconciliation Agent / Recovery Analyst", "context": "Reconciliation", "aggregate": "ReconciliationRun", "policy": "Variance >$200 routes to the Exception Queue", "downstream": "Weekly Leakage Report assembly", "risk": "Missed payout gap" }, { "seq": 9, "command": "DeliverLeakageReport", "event": "LeakageReportDelivered", "actor": "Recovery Analyst (sign-off)", "context": "Client Reporting & Billing", "aggregate": "LeakageReport", "policy": "Tie-out gate must pass before send", "downstream": "Client receives weekly report", "risk": "Tie-out failure blocks or delays delivery" }, { "seq": 10, "command": "InvoiceRecoveredDollars", "event": "RecoveredDollarsInvoiced", "actor": "Client Reporting & Billing", "context": "Client Reporting & Billing", "aggregate": "RecoveryLedgerEntry", "policy": "No invoice line without a ledger-confirmed basis", "downstream": "Monthly statement and Stripe invoice", "risk": "Invoice dispute over recovery basis" } ], "critical_path": [ "Intake -> Ingestion -> Detection -> Disputing (draft, review, submit, track) -> Client Reporting & Billing, gated by a Recovery Analyst sign-off at every submission and every client-facing report or invoice", "Ingestion -> Reconciliation -> Client Reporting & Billing (parallel weekly cycle to the dispute path)" ], "exception_flows": [ "A DeliveryOrder has no matching POS record (or vice versa) -> routed to the Exception Queue for analyst disposition before any dispute can draft against it", "A POS export is missing for a location for >48 hours -> flagged in the Exception Queue and the client is notified before any deadline is put at risk" ], "escalation_flows": [ "A Dispute is rejected with an ambiguous or disputed platform reason -> escalates to a Recovery Analyst for a platform-support conversation", "A client indicates intent to pursue formal legal action against a platform -> hard stop, documented and handed to the client's own counsel; LeakLedger does not advocate legally" ], "retry_flows": [ "No dispute outcome recorded within the platform's typical resolution window (DoorDash: hours; Uber Eats: ~1 hour per platform messaging) triggers a status-check poll, held for analyst review if still pending after 5 business days" ], "manual_override_flows": [ "A Recovery Analyst can manually waive a flagged ErrorCharge with a logged reason (e.g., charge is legitimately the restaurant's fault) rather than force a dispute the evidence doesn't support" ], "commands": [ { "name": "ReceiveScanIntake", "issued_by": "Owner / CFO / Controller", "preconditions": [ "Service agreement + DPA signed", "Named-role portal access and POS export supplied" ], "aggregate": "ClientAccount", "success_event": "scan.intake_received", "failure_event": "scan.intake_rejected_incomplete", "authorization": "Client-authorized submission only", "validation": "Six-item completeness checklist", "audit": "Intake timestamp + submitted-access manifest logged" }, { "name": "ActivateClientAccount", "issued_by": "System (founder/analyst confirms)", "preconditions": [ "Completeness checklist passed" ], "aggregate": "ClientAccount", "success_event": "ClientActivated", "failure_event": "activation_blocked_incomplete", "authorization": "System gate", "validation": "IntakeCompletenessSpec", "audit": "Activation timestamp logged" }, { "name": "DraftDispute", "issued_by": "Dispute Drafting Agent", "preconditions": [ "ErrorCharge detected", "Evidence available in canonical model" ], "aggregate": "Dispute", "success_event": "DisputeDrafted", "failure_event": "INSUFFICIENT_EVIDENCE", "authorization": "System; drafting only, never submission", "validation": "EvidenceSufficiencySpec", "audit": "Draft rationale + cited fact logged" }, { "name": "ReviewAndSubmitDispute", "issued_by": "Recovery Analyst", "preconditions": [ "Dispute drafted", ">=3-day filing buffer remaining" ], "aggregate": "Dispute", "success_event": "DisputeSubmitted", "failure_event": "dispute_rejected_by_analyst", "authorization": "Recovery Analyst sign-off required on every submission", "validation": "Deadline-buffer + evidence-sufficiency check", "audit": "Submission ID + evidence hash + timestamp logged" }, { "name": "ReconcilePayout", "issued_by": "Reconciliation Agent / Recovery Analyst", "preconditions": [ "Week's orders and payout statement ingested" ], "aggregate": "ReconciliationRun", "success_event": "PayoutReconciled", "failure_event": "VarianceFlagged", "authorization": "System; analyst required for variance >$200", "validation": "TieOutSpec", "audit": "Reconciliation figures logged per location per week" }, { "name": "DeliverLeakageReport", "issued_by": "Client Reporting & Billing", "preconditions": [ "Tie-out check passed" ], "aggregate": "LeakageReport", "success_event": "LeakageReportDelivered", "failure_event": "report_blocked_tie_out_failed", "authorization": "Recovery Analyst sign-off", "validation": "ReportTieOutSpec", "audit": "Report version + sign-off logged" }, { "name": "InvoiceRecoveredDollars", "issued_by": "Client Reporting & Billing", "preconditions": [ "RecoveryLedgerEntry confirmed for the period" ], "aggregate": "RecoveryLedgerEntry", "success_event": "RecoveredDollarsInvoiced", "failure_event": "invoice_blocked_no_ledger_basis", "authorization": "System; deterministic from ledger", "validation": "Every invoice line traces to a ledger entry", "audit": "Invoice-to-ledger mapping logged" } ], "policies": [ { "name": "Deadline-buffer filing policy", "trigger": "ErrorCharge detected", "condition": "Fewer than 3 days remain before the platform's Dispute Window closes", "action": "Escalate to priority review in the Recovery Analyst's queue ahead of lower-urgency items", "context": "Disputing", "ai_involvement": "Deadline computation and queue prioritization", "human_approval": false }, { "name": "Evidence-integrity policy", "trigger": "Dispute drafting attempted", "condition": "A claim lacks a cited POS/system artifact", "action": "Draft returns INSUFFICIENT_EVIDENCE instead of a weak dispute; item routes to the Exception Queue", "context": "Disputing", "ai_involvement": "Draft or refuse to draft", "human_approval": true }, { "name": "Confidence-band routing policy", "trigger": "Dispute or match scored", "condition": "Evidence-sufficiency <0.5 or win-probability outside the high band", "action": "Never auto-queued for submission — routed to Exception Queue for manual evidence gathering or waive-with-reason", "context": "Disputing", "ai_involvement": "Score and route", "human_approval": true }, { "name": "Weekly coverage gate", "trigger": "Weekly cycle close", "condition": "Any statement deduction line not classified", "action": "Block cycle close until every line is disputed, waived-with-reason, or exception-queued", "context": "Client Reporting & Billing", "ai_involvement": "Coverage check", "human_approval": true } ], "aggregates": [ { "name": "ClientAccountAggregate", "root": "ClientAccount", "context": "Intake", "purpose": "Represents one client's onboarding, portal grants, and activation state.", "entities": [ "PortalGrant" ], "value_objects": [ "CompletenessScore" ], "invariants": [ "Cannot activate until the six-item completeness checklist passes" ], "commands": [ "ReceiveScanIntake", "ActivateClientAccount" ], "events": [ "scan.intake_received", "ClientActivated" ], "repository": "ClientAccountRepository (per-client partitioned)", "transaction_boundary": "One ClientAccount per commit" }, { "name": "DeliveryOrderAggregate", "root": "DeliveryOrder", "context": "Ingestion", "purpose": "Represents one normalized platform order matched (or not yet matched) to a POS record.", "entities": [ "PlatformStatementLine" ], "value_objects": [ "ConfidenceScore" ], "invariants": [ "Cannot advance to Detection until required fields are present or exception-logged" ], "commands": [ "IngestPlatformStatements", "IngestPOSExport" ], "events": [ "OrderIngested" ], "repository": "DeliveryOrderRepository (per-client partitioned)", "transaction_boundary": "One DeliveryOrder per commit; batch ingestion runs as sequential single-aggregate transactions" }, { "name": "ErrorChargeAggregate", "root": "ErrorCharge", "context": "Detection", "purpose": "Represents one detected, deadline-scored, eligibility-scored platform deduction.", "entities": [], "value_objects": [ "DeadlineWindow", "WinProbabilityScore" ], "invariants": [ "Deadline is always deterministic date-math, never LLM-computed" ], "commands": [ "DetectErrorCharge" ], "events": [ "ErrorChargeDetected" ], "repository": "ErrorChargeRepository (per-client partitioned)", "transaction_boundary": "One ErrorCharge per commit" }, { "name": "DisputeAggregate", "root": "Dispute", "context": "Disputing", "purpose": "Represents one dispute's full lifecycle from draft through submission to outcome — the unit the business files, tracks, and bills against.", "entities": [], "value_objects": [ "EvidenceBundle", "ConfidenceBand" ], "invariants": [ "Cannot submit without Recovery Analyst sign-off on evidence sufficiency" ], "commands": [ "DraftDispute", "ReviewAndSubmitDispute" ], "events": [ "DisputeDrafted", "DisputeSubmitted", "DisputeWon", "DisputeRejected" ], "repository": "DisputeRepository (per-client partitioned)", "transaction_boundary": "One Dispute per commit" }, { "name": "ReconciliationRunAggregate", "root": "ReconciliationRun", "context": "Reconciliation", "purpose": "Represents one week's POS-to-payout certification for one location.", "entities": [ "PayoutVariance" ], "value_objects": [ "VarianceAmount" ], "invariants": [ "No reconciliation figure is ever LLM-computed" ], "commands": [ "ReconcilePayout" ], "events": [ "PayoutReconciled", "VarianceFlagged" ], "repository": "ReconciliationRunRepository (per-client partitioned)", "transaction_boundary": "One ReconciliationRun per location per week" }, { "name": "RecoveryLedgerEntryAggregate", "root": "RecoveryLedgerEntry", "context": "Client Reporting & Billing", "purpose": "Represents one confirmed recovery (dispute win or reconciliation credit) and its fee computation — the invoice substantiation.", "entities": [ "Invoice" ], "value_objects": [ "TieOutStatus" ], "invariants": [ "No invoice line exists without a corresponding DisputeWon or PayoutReconciled event" ], "commands": [ "DeliverLeakageReport", "InvoiceRecoveredDollars" ], "events": [ "LeakageReportDelivered", "RecoveredDollarsInvoiced" ], "repository": "RecoveryLedgerRepository (per-client partitioned)", "transaction_boundary": "One RecoveryLedgerEntry per commit" } ], "ai_agents": [ { "name": "Extraction Agent", "context": "Ingestion", "responsibility": "Parses platform statements and POS exports of any format into the canonical order/deduction/payout schema.", "inputs": [ "Platform statement export", "POS export" ], "outputs": [ "Normalized canonical records with a per-field confidence score" ], "tools": [ "Python parsers", "Frontier LLM API for unstructured-format extraction" ], "forbidden_actions": [ "Never stores a shared portal password", "Never computes a final dollar figure used in a filing" ], "memory_scope": "Per-client, per-ingestion-batch; no cross-client memory", "retrieval_sources": [ "Platform Rulebook field-mapping conventions" ], "validations": [ "Completeness checklist per platform's required fields" ], "confidence_scoring": "Per-field confidence score; below-threshold fields routed to analyst confirmation", "escalation_triggers": [ "Confidence below 70% on a required field" ], "human_approval": "Not required for normalization itself; required before any downstream filing", "failure_modes": [ "Silent mis-extraction of a malformed row", "Format drift after a platform update" ], "audit_logs": [ "Intake timestamp + submitted-file manifest" ], "metrics": [ "Extraction/classification accuracy against gold-standard set", "Escalation rate to analyst confirmation" ], "versioning": "Version-pinned with the rulebook and eval suite; swaps gated by the eval suite (ai-engine-spec.md Layer 10)" }, { "name": "Detection Agent", "context": "Detection", "responsibility": "Classifies deductions against the Platform Rulebook and computes deadline/eligibility scores.", "inputs": [ "Normalized order/deduction records", "Platform Rulebook" ], "outputs": [ "Scored ErrorCharge records" ], "tools": [ "Rulebook retrieval", "Deterministic date-math library" ], "forbidden_actions": [ "Never computes a deadline via free-text generation" ], "memory_scope": "Per-client", "retrieval_sources": [ "Platform Rulebook" ], "validations": [ "DeadlineBufferSpec" ], "confidence_scoring": "Win-probability score per ErrorCharge", "escalation_triggers": [ "Ambiguous reason-code classification" ], "human_approval": "Not required for detection; required before dispute submission", "failure_modes": [ "Missed eligible charge", "Stale rulebook citation" ], "audit_logs": [ "Detection rationale + rulebook version logged" ], "metrics": [ "Extraction/classification accuracy against gold-standard set", "Escalation rate to analyst confirmation" ], "versioning": "Version-pinned with the rulebook and eval suite; swaps gated by the eval suite (ai-engine-spec.md Layer 10)" }, { "name": "Dispute Drafting Agent", "context": "Disputing", "responsibility": "Drafts the dispute reason, narrative, and evidence bundle for each ErrorCharge per the target platform's required format.", "inputs": [ "ErrorCharge record", "POS evidence", "Platform Rulebook reason taxonomy" ], "outputs": [ "Drafted Dispute with cited evidence and confidence score" ], "tools": [ "Frontier LLM API behind a vendor-neutral abstraction layer" ], "forbidden_actions": [ "Never asserts a fact without a cited POS/system artifact", "Never submits — drafting only" ], "memory_scope": "Per-client, per-dispute", "retrieval_sources": [ "Platform Rulebook", "gold-standard exemplar disputes" ], "validations": [ "EvidenceSufficiencySpec" ], "confidence_scoring": "Evidence-sufficiency score + win-probability score", "escalation_triggers": [ "Evidence-sufficiency <0.5 -> INSUFFICIENT_EVIDENCE output" ], "human_approval": "Required before every submission (Recovery Analyst)", "failure_modes": [ "Weak or unsupported dispute drafted", "Wrong reason-code selection" ], "audit_logs": [ "Draft rationale + cited artifact logged" ], "metrics": [ "Extraction/classification accuracy against gold-standard set", "Escalation rate to analyst confirmation" ], "versioning": "Version-pinned with the rulebook and eval suite; swaps gated by the eval suite (ai-engine-spec.md Layer 10)" }, { "name": "Outcome Tracking Agent", "context": "Disputing", "responsibility": "Polls platform portals for dispute outcomes and updates the Win Rate model.", "inputs": [ "Submitted Dispute records" ], "outputs": [ "Outcome-labeled Dispute records" ], "tools": [ "Portal polling / API where available" ], "forbidden_actions": [ "Never re-files a rejected dispute without analyst review" ], "memory_scope": "Per-client, book-wide for the win-probability model", "retrieval_sources": [], "validations": [ "Outcome must be platform-confirmed before ledger entry" ], "confidence_scoring": "n/a", "escalation_triggers": [ "No outcome recorded within the expected resolution window" ], "human_approval": "Not required for tracking; required for re-filing or escalation decisions", "failure_modes": [ "Outcome polling gap" ], "audit_logs": [ "Outcome timestamp logged" ], "metrics": [ "Extraction/classification accuracy against gold-standard set", "Escalation rate to analyst confirmation" ], "versioning": "Version-pinned with the rulebook and eval suite; swaps gated by the eval suite (ai-engine-spec.md Layer 10)" }, { "name": "Anomaly Explanation Agent", "context": "Reconciliation", "responsibility": "Drafts a cause hypothesis for each flagged PayoutVariance.", "inputs": [ "ReconciliationRun variance data" ], "outputs": [ "Cause-hypothesis narrative for analyst review" ], "tools": [ "Frontier LLM API" ], "forbidden_actions": [ "Never computes the variance amount itself — deterministic math owns that" ], "memory_scope": "Per-client, per-week", "retrieval_sources": [ "Prior variance root-cause tags" ], "validations": [ "Hypothesis must cite a specific order or statement line" ], "confidence_scoring": "n/a", "escalation_triggers": [ "Variance >$200" ], "human_approval": "Required for any variance >$200", "failure_modes": [ "Misattributed cause hypothesis" ], "audit_logs": [ "Hypothesis + analyst disposition logged" ], "metrics": [ "Extraction/classification accuracy against gold-standard set", "Escalation rate to analyst confirmation" ], "versioning": "Version-pinned with the rulebook and eval suite; swaps gated by the eval suite (ai-engine-spec.md Layer 10)" } ], "prompt_chain_map": [ "Extraction Agent (parse) -> Detection Agent (classify + score) -> Dispute Drafting Agent (narrative + evidence, only on a flagged ErrorCharge) -> Recovery Analyst gate -> submission", "Weekly order/payout data -> Anomaly Explanation Agent (variance hypothesis) -> Recovery Analyst review -> Report Narrative Agent (weekly Leakage Report draft) -> Recovery Analyst sign-off -> delivered report" ], "rag_map": [ "Platform Rulebook (versioned DoorDash/Uber Eats/Grubhub dispute-policy library with citation anchors) retrieved by the Detection Agent and the Dispute Drafting Agent for every classification and draft", "Gold-standard exemplar-dispute library retrieved by the Dispute Drafting Agent, restricted to platform/reason-code-matched exemplars" ], "ai_evaluation": [ "Gold-standard order-match and dispute-draft examples per platform used for regression testing on every prompt or rulebook version change", "Monthly red-team run: seeded fake deductions and unsupported assertions verify the classifier and reviewers catch them", "10% sampled re-verification of submitted disputes against a manually re-checked baseline" ], "hallucination_controls": [ "Retrieval-first classification and narrative drafting — every claim cites a specific POS field or Platform Rulebook reason code", "Deterministic date-math and dollar arithmetic in code, never the model", "Evidence-sufficiency scoring with mandatory analyst confirmation below threshold", "EvidenceSufficiencySpec rejects any dispute draft missing a required citation", "INSUFFICIENT_EVIDENCE is a valid, expected model output — the prompt is designed to prefer refusal over a weak dispute" ], "human_in_the_loop_plan": [ "Evidence gate: no dispute below the evidence-sufficiency threshold proceeds without analyst confirmation", "Submission gate: every dispute batch is analyst-reviewed and submitted through a named portal role — never auto-filed at launch", "Money gate: every weekly report and every invoice is human-signed with tie-out verification", "Dual review on any dispute or variance over $75/$200 respectively" ], "ai_audit_plan": [ "Every AI-drafted dispute and every AI-proposed variance hypothesis is logged with its confidence score and cited source before analyst review", "Weekly win-rate and rejection-reason review by platform and reason code", "Monthly red-team run against the hallucination-control suite" ], "prompt_versioning": "Prompts + schemas + the Platform Rulebook are model-agnostic and version-pinned together; a frontier-model swap is a config change gated by the gold-standard eval suite, not a rebuild (see ai-engine-spec.md Layer 10).", "human_roles": [ { "role": "Recovery Analyst", "responsibilities": [ "Review every dispute batch before submission", "Own every platform-support escalation", "Sign off on every weekly report and monthly statement" ], "contexts": [ "Disputing", "Reconciliation", "Client Reporting & Billing" ], "decisions_owned": [ "Dispute approve/edit/reject", "Variance disposition >$200", "Report/invoice release" ], "ai_support": [ "[PLACEHOLDER] owner to complete" ], "approval_authority": "Sole approver for submissions and reports up to $75/dispute and $200/variance; dual review above", "escalation_authority": "Can escalate to platform support or refer to the client's counsel; cannot give legal advice", "quality_metrics": [ "Win Rate >=55% (floor 40%) held for 4 consecutive weeks before queue volume increases" ], "workload_risks": [ "Volume spikes ahead of a deadline-heavy week can back up the review queue" ] }, { "role": "Founder / Ops Lead", "responsibilities": [ "Own the Platform Rulebook", "Approve rulebook version bumps", "Handle exotic-POS scoping and hiring gates" ], "contexts": [ "Detection", "Intake" ], "decisions_owned": [ "Rulebook diff acceptance", "Analyst #2 hiring gate", "New-POS-type acceptance" ], "ai_support": "AI drafts rulebook diffs against platform help-center pages; founder confirms before production use", "approval_authority": "Sole approver for rulebook version changes", "escalation_authority": "n/a", "quality_metrics": [ "Zero stale-rulebook disputes filed" ], "workload_risks": [ "Volume spikes ahead of a deadline-heavy week can back up the review queue" ] } ], "human_review_checkpoints": [ "Every dispute below the evidence-sufficiency threshold, and 10% of high-confidence disputes as a sample", "Every dispute over $75 and every variance over $200", "Every weekly Leakage Report and monthly Recovered-Dollars Statement before send (tie-out gate)", "Every rulebook version bump before it reaches production drafting" ], "escalation_matrix": [ "Dispute rejected with an ambiguous platform reason -> Recovery Analyst platform-support escalation same week", "Client indicates intent toward litigation against a platform -> documented file handed to the client's own counsel; LeakLedger steps back from legal advocacy" ], "manual_override_rules": [ "A Recovery Analyst may waive a flagged ErrorCharge with a logged reason when the evidence shows the charge is legitimately the restaurant's fault", "A Recovery Analyst may manually reclassify a dispute reason code when new evidence changes the correct Platform Rulebook citation" ], "separation_of_duties": [ "The analyst who drafts evidence review on a dispute >$75 is never the sole approver on that same submission without a second reviewer's sign-off" ], "quality_control_workflow": [ "Evidence gate -> submission gate -> money gate (the three permanent human-in-the-loop gates)", "10% random re-verification of submitted disputes", "Monthly seeded-error red-team runs against known failure patterns" ], "data_objects": [ { "name": "DeliveryOrder", "meaning": "One platform order matched (or not yet matched) to a POS record.", "owner_context": "Ingestion", "writers": [ "Extraction Agent" ], "readers": [ "Detection", "Reconciliation" ], "source_of_truth": "Ingestion context", "retention": "Life of the client engagement plus applicable audit-retention window", "privacy": "Consumer PII minimized at ingestion", "audit": "Every state transition timestamped" }, { "name": "Dispute", "meaning": "One filed, evidenced contest of an ErrorCharge.", "owner_context": "Disputing", "writers": [ "Dispute Drafting Agent", "Recovery Analyst" ], "readers": [ "Client Reporting & Billing" ], "source_of_truth": "Disputing context", "retention": "Life of the client engagement plus audit-retention window", "privacy": "Order-level, minimized PII", "audit": "Evidence hash + submitter + timestamp + outcome logged" }, { "name": "RecoveryLedgerEntry", "meaning": "One confirmed recovery (dispute win or reconciliation credit) and its fee computation.", "owner_context": "Client Reporting & Billing", "writers": [ "Client Reporting & Billing" ], "readers": [ "Billing/Stripe", "Client (via statement)" ], "source_of_truth": "Client Reporting & Billing context", "retention": "Life of engagement plus audit-retention window", "privacy": "Financial data only, no consumer PII", "audit": "Every invoice line traces to a ledger entry" } ], "read_models": [ "Weekly Leakage Report (per client)", "Exception Queue view (per analyst, severity-tiered)", "Dispute Window deadline dashboard (per client, all active windows)", "Win Rate / recovered-dollars scorecard (per client and book-wide)" ], "reporting_models": [ "Monthly Recovered-Dollars Statement (invoice basis)", "Store/item error heat map" ], "data_duplication_notes": [ "Order data is normalized once at Ingestion and never re-parsed downstream — Detection, Disputing, and Reconciliation all read the same canonical record", "Dispute outcome data is written once at Disputing and referenced (not copied) by Client Reporting & Billing" ], "data_retention": [ "Order and deduction data retained for the life of the client engagement plus the applicable audit-retention window", "Consumer PII not required for dispute evidence (e.g., full delivery address) dropped at ingestion", "Data deleted per the offboarding SOP on contract termination unless a legal hold applies" ], "data_quality_risks": [ "Platform statement format changes without notice", "POS export schema drift across Toast/Square/Olo", "Duplicate or conflicting order IDs across platform and POS records" ], "use_cases": [ { "name": "Weekly detect-dispute-submit cycle", "actor": "Recovery Analyst", "context": "Detection / Disputing", "goal": "Every eligible ErrorCharge disputed inside its Dispute Window with evidence", "preconditions": [ "Client onboarded with a signed service agreement", "Prior-cycle canonical records available" ], "main_flow": [ "Ingest nightly statement/POS deltas", "Detect and score ErrorCharges", "Draft disputes with evidence", "Recovery Analyst reviews and submits the batch", "Track outcomes" ], "alternative_flows": [ "A below-threshold evidence item routes to the Exception Queue before the batch can close" ], "business_rules": [ "No dispute is marked submitted without an analyst-approved evidence bundle on file" ], "aggregates": [ "DeliveryOrderAggregate", "ErrorChargeAggregate", "DisputeAggregate" ], "ai_role": "Extraction, classification, and drafting; never submission or final evidence judgment", "audit": "Every submission logged with evidence hash, submitter, and timestamp", "commands": [ "IngestPlatformStatements", "DetectErrorCharge", "DraftDispute", "ReviewAndSubmitDispute" ], "events": [ "OrderIngested", "ErrorChargeDetected", "DisputeDrafted", "DisputeSubmitted" ], "failure_handling": "Below-threshold evidence routes to the Exception Queue rather than blocking the whole batch", "human_role": "Recovery Analyst reviews and submits every batch", "success": "100% of eligible Error Charges disputed inside their Dispute Window with >=3-day buffer" }, { "name": "Weekly POS-to-payout reconciliation", "actor": "Recovery Analyst", "context": "Reconciliation", "goal": "Every location's weekly payout certified against POS, every variance disposed", "preconditions": [ "POS export received for the week", "Payout statement received for the week" ], "main_flow": [ "Ingest week's orders and payout statement", "Compute variance deterministically", "Route variances >$200 to analyst review", "Deliver the certified reconciliation as part of the weekly report" ], "alternative_flows": [ "A missing POS export blocks that location's reconciliation and routes to the Exception Queue" ], "business_rules": [ "No reconciliation figure is ever LLM-computed" ], "aggregates": [ "DeliveryOrderAggregate", "ReconciliationRunAggregate" ], "ai_role": "Variance-cause hypothesis drafting; never the variance computation itself", "audit": "Reconciliation figures logged per location per week", "commands": [ "IngestPOSExport", "ReconcilePayout" ], "events": [ "OrderIngested", "PayoutReconciled", "VarianceFlagged" ], "failure_handling": "A missing POS export blocks that location's reconciliation and routes to the Exception Queue, not the whole cycle", "human_role": "Recovery Analyst reviews and disposes every variance over $200", "success": "100% of locations' weekly payouts certified or exception-queued" } ], "invariants": [ { "invariant": "A Dispute cannot submit without Recovery Analyst sign-off on evidence sufficiency", "context": "Disputing", "aggregate": "DisputeAggregate", "why": "Prevents an unverified or unsupported claim from reaching a platform and damaging standing", "enforcement": "Application-service-level guard; no submission command executes without a recorded analyst-approval event" }, { "invariant": "No dollar figure in a filed dispute, reconciliation report, or invoice is ever LLM-computed", "context": "Disputing / Reconciliation / Client Reporting & Billing", "aggregate": "DisputeAggregate / ReconciliationRunAggregate / RecoveryLedgerEntryAggregate", "why": "Dollar arithmetic must be deterministic and auditable, never a model inference", "enforcement": "All dollar math runs in code against the canonical schema; the model only drafts narrative text" }, { "invariant": "An ErrorCharge's Dispute Window deadline is always deterministic date-math", "context": "Detection", "aggregate": "ErrorChargeAggregate", "why": "A missed deadline forfeits the money permanently; this cannot be left to model inference", "enforcement": "Deadline calculator runs in code, never the LLM" }, { "invariant": "A weekly Leakage Report cannot deliver without passing the tie-out gate", "context": "Client Reporting & Billing", "aggregate": "RecoveryLedgerEntryAggregate", "why": "A wrong number reaching a client destroys trust in the core deliverable", "enforcement": "ReportTieOutSpec blocks the delivery command on any mismatch against platform statement totals" }, { "invariant": "A ClientAccount cannot activate until the six-item completeness checklist passes", "context": "Intake", "aggregate": "ClientAccountAggregate", "why": "Prevents silent coverage gaps from an incomplete onboarding", "enforcement": "IntakeCompletenessSpec blocks the activation command" } ], "module_structure": { "tree": "src/{intake,ingestion,detection,disputing,reconciliation,reporting-billing,rulebook}/{domain,application,infra}", "modules": [ { "name": "intake", "purpose": "Client onboarding and completeness checking", "owned_domain": [ "ClientAccount" ], "application_services": [ "ReceiveScanIntake", "ActivateClientAccount" ], "infra_adapters": [ "Email/upload intake handler", "Object storage adapter" ], "public_interfaces": [ "ClientActivated event" ], "forbidden_deps": [ "Must not depend on disputing or billing internals" ] }, { "name": "ingestion", "purpose": "Statement/POS normalization", "owned_domain": [ "DeliveryOrder" ], "application_services": [ "IngestPlatformStatements", "IngestPOSExport" ], "infra_adapters": [ "Platform statement parsers", "POS export parsers", "LLM extraction client" ], "public_interfaces": [ "OrderIngested event" ], "forbidden_deps": [ "Must not depend on disputing internals" ] }, { "name": "detection", "purpose": "Deduction classification and deadline scoring", "owned_domain": [ "ErrorCharge" ], "application_services": [ "DetectErrorCharge" ], "infra_adapters": [ "Platform Rulebook retrieval" ], "public_interfaces": [ "ErrorChargeDetected event" ], "forbidden_deps": [ "Must not depend on billing internals" ] }, { "name": "disputing", "purpose": "Dispute drafting, review, submission, tracking", "owned_domain": [ "Dispute" ], "application_services": [ "DraftDispute", "ReviewAndSubmitDispute", "TrackDisputeOutcome" ], "infra_adapters": [ "Platform portal submission clients", "LLM drafting client" ], "public_interfaces": [ "DisputeWon/DisputeRejected events" ], "forbidden_deps": [ "Must not depend on reporting-billing internals" ] }, { "name": "reconciliation", "purpose": "Weekly POS-to-payout certification", "owned_domain": [ "ReconciliationRun" ], "application_services": [ "RunWeeklyReconciliation" ], "infra_adapters": [ "Payout statement parsers" ], "public_interfaces": [ "PayoutReconciled event" ], "forbidden_deps": [ "Must not depend on disputing internals" ] }, { "name": "reporting-billing", "purpose": "Report/statement assembly and invoicing", "owned_domain": [ "LeakageReport", "RecoveryLedgerEntry" ], "application_services": [ "DeliverLeakageReport", "InvoiceRecoveredDollars" ], "infra_adapters": [ "Stripe client", "Email delivery" ], "public_interfaces": [ "RecoveredDollarsInvoiced event" ], "forbidden_deps": [] } ], "dependency_rules": [ "Downstream modules (disputing, reconciliation, reporting-billing) may only consume events from upstream modules, never reach into their tables directly", "The rulebook module is a read-only dependency for detection and disputing — no module writes to it except the founder-approved version-bump path" ] }, "security_governance": { "controls": [ { "risk": "Wrong-order dispute reaches a platform", "context": "Disputing", "impact": "high", "control": "Evidence-sufficiency scoring + mandatory analyst confirmation below threshold + 10% sampled re-verification", "audit": "Match rationale + confidence score logged per dispute" }, { "risk": "Cross-client data leak", "context": "Ingestion / Disputing", "impact": "severe", "control": "Row-level auth + per-client retrieval partitioning", "audit": "Access logs reviewed weekly" }, { "risk": "Shared portal credential used instead of a named role", "context": "Intake", "impact": "severe", "control": "Schema-level rejection of any credential-sharing intake path; named-role verification at onboarding", "audit": "Access-grant audit log" } ], "access_control_matrix": [ { "role": "Recovery Analyst", "context": "Disputing / Reconciliation", "capabilities": [ "Review and submit disputes for assigned clients", "Approve reconciliation variances up to $200" ] }, { "role": "Founder / Ops Lead", "context": "Intake / Detection", "capabilities": [ "Approve rulebook version bumps", "Approve new POS-type onboarding" ] } ], "ai_governance": [ "Every AI agent's outputs are logged with confidence score and cited source before any human or downstream action", "Model swaps gated by the eval suite, never silent" ], "audit_log_requirements": [ "Every dispute lifecycle state transition timestamped", "Every reconciliation figure traceable to its source statement/POS lines" ], "prompt_injection_defense": [ "Platform statement and POS content is treated as untrusted data, never as instructions, in every LLM prompt", "Structured extraction schemas constrain model output to typed fields" ], "sensitive_data_handling": [ "Consumer PII minimized at ingestion", "Encryption at rest", "DPA-governed access" ] }, "observability": { "metrics": [ { "metric": "Coverage rate", "type": "gauge", "context": "Client Reporting & Billing", "why": "Tracks % of deduction lines dispositioned weekly", "target": "100%", "alert_threshold": "<100% blocks cycle close" }, { "metric": "Disputes missed inside deadline", "type": "counter", "context": "Disputing", "why": "The zero-tolerance quality target", "target": "0", "alert_threshold": ">0 triggers immediate root-cause review" }, { "metric": "Dispute batch cycle time", "type": "histogram", "context": "Disputing", "why": "SLA is filing >=3 days before window close", "target": "<=25 min per batch of 25 at launch, <=15 min by day 90", "alert_threshold": ">30 min sustained" } ], "dashboards": [ "Analyst exception-queue dashboard", "Win Rate by platform/reason-code dashboard", "Weekly coverage dashboard" ], "ai_evaluation_reports": [ "Weekly gold-standard regression summary", "Monthly red-team result log" ], "audit_reports": [ "Weekly submission audit-trail completeness check" ], "client_outcome_reports": [ "Weekly Leakage Report", "Monthly Recovered-Dollars Statement" ], "quality_review_reports": [ "Weekly win-rate and rejection-reason review", "Monthly red-team report" ] }, "testing_strategy": { "tests": [ { "type": "unit", "validates": "14-day/30-day deadline math and >=3-day filing buffer", "context": "Detection", "example": "An order delivered 12 days ago computes 2 days remaining and triggers priority routing" }, { "type": "component", "validates": "Exception-queue routing on below-threshold evidence", "context": "Disputing", "example": "A 40%-evidence-sufficiency dispute routes to the Exception Queue, never auto-submits" }, { "type": "e2e", "validates": "Full ingestion -> detection -> analyst sign-off -> submission path", "context": "cross-context", "example": "Seeded sample DoorDash statement produces a correctly filed dispute end-to-end" } ], "critical_domain_rules": [ "Deadline-buffer filing policy", "Evidence-integrity policy", "Weekly coverage gate" ], "ai_eval_dataset": [ "Gold-standard order-to-POS match examples per POS system", "Gold-standard dispute drafts with known-correct reason codes per platform" ], "contract_testing_plan": "Canonical schema contract tests run on every ingestion parser change to prevent silent downstream breakage", "manual_qa_checklist": [ "Evidence-sufficiency spot check on 10% of submitted disputes", "Report tie-out verification before every send" ], "regression_plan": "Full gold-standard eval suite re-runs on every prompt, rulebook, or model version change before production cutover" }, "mvp_roadmap": [ { "phase": "MVP — DoorDash Error-Charge Dispute Desk", "goal": "Prove the weekly detect-dispute-submit loop manually-assisted for the first 5 pilot groups", "features": [ "Leakage Scan intake + readout", "Weekly dispute filing", "Weekly Leakage Report" ], "contexts": [ "Intake", "Ingestion", "Detection", "Disputing" ], "ai_needs": [ "Extraction Agent", "Detection Agent", "Dispute Drafting Agent" ], "human_workflows": [ "Founder/analyst reviews every dispute and every outbound communication personally for the first 5 groups" ], "data_needs": [ "DoorDash rulebook v0" ], "integrations": [ "Manual CSV statement pulls, email/PDF delivery" ], "risks": [ "Manual founder bottleneck at volume" ], "exit_criteria": [ "5 pilot groups' first full weekly cycle completed", "Zero missed deadlines across the cohort", "Weekly report tie-out gate passing 100% of the time" ] } ], "scaling_roadmap": [ { "stage": "5 -> 8 pilot groups", "trigger": "5-pilot hardening checkpoint passed (intake spec, evidence checklists, QA sampling standardized)", "architecture_change": "Automate parsing/classification/reporting; POS adapters for Toast/Square/Olo solid", "operational_change": "Exception-queue tiers and reviewer-assignment checklists formalized", "risk": "Per-client snowflake ingestion logic is a stop-the-line signal" }, { "stage": "8 -> 20 clients (Uber Eats + Grubhub added)", "trigger": "Win Rate >=50% and minutes-per-dispute <=30 held for 4 consecutive weeks", "architecture_change": "Second platform rulebook entries codified; Analyst #2 hired", "operational_change": "Pause new onboarding at 20 until COGS/group, rework rate, escalation rate, and cycle time are measured for a full month", "risk": "Multi-platform statement format long tail eats margin if POS/platform scope isn't held firm" } ], "risk_register": [ { "risk": "Platforms move toward fair, fully automated error-charge adjudication, shrinking the dispute pool", "likelihood": "medium", "impact": "high", "signal": "Win rates and charge volumes tracked weekly across the whole book trend down structurally", "mitigation": "Revenue mix shifts to reconciliation retainer + promo/fee audit; expand to adjacent marketplaces (ezCater, grocery delivery)", "owner": "founder", "context": "Detection / Disputing" }, { "risk": "Platform ToS interpreted against third-party portal agents", "likelihood": "low-medium", "impact": "high", "signal": "A platform restricts named-role access for third-party agents", "mitigation": "Operate only through merchant-granted named roles; prefer official APIs; industry precedent (Loop/Voosh/DTiQ operate openly)", "owner": "founder", "context": "Intake" }, { "risk": "Dispute Win Rate materially below 40%", "likelihood": "medium", "impact": "high", "signal": "Pilot cohort win-rate tracking by reason code", "mitigation": "Contingency-only pilots cap downside; per-reason-code tracking finds salvageable segments; pivot toward reconciliation-first if disputing underperforms", "owner": "Recovery Analyst", "context": "Disputing" }, { "risk": "POS/data integration long tail eats margin", "likelihood": "high", "impact": "medium", "signal": "Rising ingestion exception-queue volume for non-standard POS systems", "mitigation": "Restrict pilots to Toast/Square/Olo; implementation fee for exotic stacks", "owner": "founder", "context": "Ingestion" }, { "risk": "Evidence-integrity failure damages platform standing", "likelihood": "low", "impact": "high", "signal": "Red-team seeded item missed by a reviewer", "mitigation": "No-assertion-without-artifact rule; 100% review at launch; immediate withdrawal-and-postmortem protocol", "owner": "Recovery Analyst", "context": "Disputing" } ], "adrs": [ { "id": "ADR-001", "decision": "Launch as a single-region modular monolith, not microservices", "status": "accepted", "context": "8-group pilot cap does not justify microservice operational overhead", "options": [ "Modular monolith", "Microservices", "No-code workflow tool" ], "chosen": "Modular monolith", "business_reason": "Fastest path to the first 5 pilot groups without a platform team", "technical_reason": "Module boundaries mirror bounded contexts, keeping a future split cheap", "tradeoffs": [ "[PLACEHOLDER] owner to complete" ], "risks": [ "[PLACEHOLDER] owner to complete" ], "why": "Matches the actual pilot scale", "consequences": "Single deploy unit, simpler ops at launch", "revisit_when": "Sustained load beyond ~40-60 clients per analyst-throughput target", "reversal": "Would require re-architecting submission around a compliant auto-file API and re-running the evidence-integrity eval suite before cutover", "revisit_trigger": "Sustained load beyond ~40-60 clients per analyst-throughput target" }, { "id": "ADR-002", "decision": "Manual portal submission at launch; no auto-filing until platform APIs support it", "status": "accepted", "context": "Submission is a human chokepoint by design, not a temporary scaling gap", "options": [ "Manual submission via named role", "Auto-file via scraping", "Auto-file via official API once available" ], "chosen": "Manual submission via named role", "business_reason": "Protects platform standing and evidence integrity; matches the licensing-boundary posture in compliance-checklist.md", "technical_reason": "No reliable, ToS-compliant auto-submission API exists across all three platforms at launch", "tradeoffs": "Caps per-analyst throughput until APIs mature", "risks": "None beyond the throughput ceiling, which is priced into the financial model", "why": "Evidence-integrity and accountability are the moat, not automation speed", "consequences": "Human review remains permanent regardless of model capability", "revisit_when": "Official platform APIs supporting compliant auto-filing for low-risk/high-confidence disputes", "reversal": "Would require re-architecting submission around a compliant auto-file API and re-running the evidence-integrity eval suite before cutover", "revisit_trigger": "Official platform APIs supporting compliant auto-filing for low-risk/high-confidence disputes" } ], "self_audit": { "scores": [ { "category": "Domain clarity", "score": 5, "weakness": "None material", "improvement": "Keep the Platform Rulebook citation discipline as Uber Eats/Grubhub coverage is added" }, { "category": "Human-chokepoint discipline", "score": 5, "weakness": "None material", "improvement": "Continue dual review above $75/$200 as volume grows" }, { "category": "Regulatory-boundary clarity", "score": 4, "weakness": "Contingency-fee legality is well-precedented but not independently attorney-reviewed for this business yet", "improvement": "Attorney review before the first signed service agreement (compliance-checklist.md §1-2)" } ], "weakest_parts": [ "Sustained >=55% Win Rate is an Unverified pilot hypothesis, not a fact", "Uber Eats/Grubhub rulebook entries are day-90 scope, not launch scope" ], "biggest_assumptions": [ "Sustained >=55% Win Rate is achievable at scale (Unverified, pilot-tested)", "Scan-to-pilot conversion near 40% among qualified operators" ], "highest_risk_decisions": [ "Manual-first submission at launch caps throughput but protects evidence integrity — ADR-002" ], "needs_domain_expert": [ "[PLACEHOLDER] owner to complete" ], "needs_legal": [ "[PLACEHOLDER] owner to complete" ], "needs_prototype": [ "[PLACEHOLDER] owner to complete" ], "validate_before_prod": [ "Attorney review of the service agreement and DPA templates (compliance-checklist.md)" ] }, "final_recommendations": [ "Launch the DoorDash-only Error-Charge Dispute Desk pilot immediately: codify the DoorDash rulebook, ship the Leakage Scan, and recruit up to 8 founding pilot groups", "Hold Uber Eats and Grubhub coverage as the timed second act once the pilot cohort clears the day-90 checkpoint", "Do not build a client-facing dashboard or software product beyond the internal engine until 20 clients prove margin", "Keep the Recovery Analyst approval gate permanent on every dispute submission and every client-facing report regardless of automation maturity", "Treat the reconciliation retainer as the durability hedge against platform policy shifts shrinking the dispute pool, not a secondary afterthought" ], "extensions": { "service_business_reality_check": { "is_service_business": true, "paid_outcome_clear": true, "workflow_present": true, "ai_native_fit_score": 4.5, "red_flags": [] }, "ai_native_fit": { "score": 4.5, "why": "Mechanical, high-volume, deadline-driven workflow (per-order classification, evidence matching, deadline tracking, dispute drafting) ideally suited to AI with a clean, permanent human chokepoint on every submission.", "disqualifiers": [] }, "domain_evidence_register": [ { "claim": "2.5-3% of operator revenue is caught up in disputes with delivery providers", "evidence_type": "trade press", "source": "Restaurant Business, 2025", "strength": "high", "gaps": "No independent audit of the figure; treated as directional industry-wide" }, { "claim": "DoorDash: 14-day dispute window, 25-100% of item price + tax error charges", "evidence_type": "platform policy, re-verified 2026-07-13", "source": "DoorDash Merchant Help Center", "strength": "high", "gaps": "None — current as of re-check" }, { "claim": "Uber Eats: 30-day dispute window, 96-hour late-report exemption", "evidence_type": "platform policy, re-verified 2026-07-13", "source": "Uber Eats merchant policy / Order Errors page", "strength": "high", "gaps": "None — current as of re-check" }, { "claim": "LA County sued Grubhub (Feb 2024) over refund-charge practices", "evidence_type": "government filing + trade press, re-verified 2026-07-13", "source": "LA County Office of County Counsel; Restaurant Business", "strength": "high", "gaps": "No public settlement or ruling found as of the re-check; case status should be re-verified quarterly" } ], "agent_stress_tests": [ { "agent": "Dispute Drafting Agent", "scenario": "POS record is ambiguous about whether an item was actually packed", "failure_mode": "Drafts an unsupported assertion", "guardrail": "EvidenceSufficiencySpec forces INSUFFICIENT_EVIDENCE output instead", "verdict": "held" }, { "agent": "Extraction Agent", "scenario": "A platform changes its statement export format without notice", "failure_mode": "Silent mis-extraction", "guardrail": "Completeness checklist + confidence scoring routes low-confidence fields to analyst confirmation", "verdict": "held" } ], "aggregate_stress_tests": [ { "aggregate": "DisputeAggregate", "scenario": "Two ingestion runs create duplicate ErrorCharge records for the same order", "invariant_at_risk": "No dispute submitted without analyst sign-off on evidence sufficiency", "verdict": "held — duplicate-dispute blocker in Detection Layer 5 prevents double-filing" } ], "assumption_register": [ { "assumption": "Sustained Win Rate >=55%", "blocking": "Long-run unit economics beyond the contingency-protected pilot", "impact_if_wrong": "high", "how_to_validate": "8-group pilot cohort win-rate tracking by reason code" } ], "boundary_stress_tests": [ { "scenario": "A client wants LeakLedger to also fight a card-network chargeback", "contexts_touched": [ "Disputing" ], "breaks_if": "The scope boundary in compliance-checklist.md is not enforced at intake", "verdict": "held — explicitly out of scope, stated on the landing page and service agreement" } ], "build_buy_integrate": [ { "subdomain": "Outreach & Sales", "decision": "buy", "reason": "HubSpot free + Calendly cover pilot-scale needs; engineering focus stays on the recovery engine" }, { "subdomain": "Detection & Disputing", "decision": "build", "reason": "The core moat; no vendor sells an outcome-priced, mid-market-focused done-for-you version of this" } ], "contradiction_scan": [ { "id": "cs-1", "severity": "none", "message": "No contradiction found between blueprint pricing (financial-model.csv) and microsite pricing copy as of this build.", "refs": [ "financial-model.csv", "site/index.html" ] } ], "core_protection_strategy": [ "[PLACEHOLDER] owner to complete" ], "drift_checks": [ { "stage": "post-launch week 4", "status": "pending", "findings": [ "[PLACEHOLDER] owner to complete" ] } ], "foundry_package": { "version": "1.0", "checksum": "pending", "counts": { "subdomains": 5, "bounded_contexts": 6, "aggregates": 6, "events": 10, "commands": 7, "policies": 4, "invariants": 5, "integrations": 5, "ai_agents": 5, "adrs": 2 }, "subset": { "subdomains": [ "Detection & Disputing", "Reconciliation", "Client Reporting & Billing", "Platform Rulebook", "Outreach & Sales" ], "bounded_contexts": [ "Intake", "Ingestion", "Detection", "Disputing", "Reconciliation", "Client Reporting & Billing" ], "aggregates": [ "ClientAccountAggregate", "DeliveryOrderAggregate", "ErrorChargeAggregate", "DisputeAggregate", "ReconciliationRunAggregate", "RecoveryLedgerEntryAggregate" ], "events": [ "scan.intake_received", "ClientActivated", "OrderIngested", "ErrorChargeDetected", "DisputeDrafted", "DisputeSubmitted", "DisputeWon / DisputeRejected", "PayoutReconciled / VarianceFlagged", "LeakageReportDelivered", "RecoveredDollarsInvoiced" ], "commands": [ "ReceiveScanIntake", "ActivateClientAccount", "DraftDispute", "ReviewAndSubmitDispute", "ReconcilePayout", "DeliverLeakageReport", "InvoiceRecoveredDollars" ], "policies": [ "Deadline-buffer filing policy", "Evidence-integrity policy", "Confidence-band routing policy", "Weekly coverage gate" ], "invariants": [ "A Dispute cannot submit without Recovery Analyst sign-off on evidence sufficiency", "No dollar figure in a filed dispute, reconciliation report, or invoice is ever LLM-computed", "An ErrorCharge's Dispute Window deadline is always deterministic date-math", "A weekly Leakage Report cannot deliver without passing the tie-out gate", "A ClientAccount cannot activate until the six-item completeness checklist passes" ], "integrations": [ "DoorDash Merchant Portal / Developer API", "Uber Eats Manager / reporting API", "Grubhub for Restaurants", "POS (Toast / Square / Olo)", "Stripe (invoicing)" ], "ai_agents": [ "Extraction Agent", "Detection Agent", "Dispute Drafting Agent", "Outcome Tracking Agent", "Anomaly Explanation Agent" ], "adrs": [ "ADR-001", "ADR-002" ] } }, "gates": [ { "id": "domain-modeling", "title": "Domain modeling completeness", "passed": true, "checks": [ { "name": "subdomains >= 3", "ok": true, "evidence": "5 subdomains" }, { "name": "bounded_contexts >= 3", "ok": true, "evidence": "6 bounded contexts" } ] }, { "id": "ai-governance", "title": "AI governance completeness", "passed": true, "checks": [ { "name": "human_roles >= 2", "ok": true, "evidence": "2 human roles" }, { "name": "human_review_checkpoints >= 2", "ok": true, "evidence": "4 checkpoints" } ] } ], "language_conflict_map": [ { "term": "recovery", "context_a": "Disputing", "meaning_a": "A won Dispute's dollar amount", "context_b": "Client Reporting & Billing", "meaning_b": "Any confirmed ledger credit, including reconciliation-sourced amounts", "resolution": "Client-facing copy always says 'recovered dollars' for the ledger total, and 'dispute won' specifically for a filed contest — never used interchangeably" } ], "margin_leakage_map": [ { "leakage": "Analyst review time exceeding the per-batch target", "cause": "Volume spike ahead of a deadline-heavy week", "impact": "COGS/group rises, compressing gross margin", "mitigation": "Risk-tiered sampling once win-rate data accumulates; hire Analyst #2 only at the throughput gate" }, { "leakage": "Exotic POS integration effort", "cause": "A client on a POS system outside Toast/Square/Olo", "impact": "Uncompensated engineering time", "mitigation": "Implementation-fee gate before accepting new POS types" } ], "published_language_contracts": [ { "contract": "Canonical order/deduction/payout schema", "producer": "Ingestion", "consumer": "Detection, Reconciliation", "versioning": "Schema changes require a contract test pass before deploy" } ], "regulated_domain_handling": [ { "regime": "State consumer-privacy law (CCPA-class)", "applies_because": "LeakLedger processes consumer order data as a service provider to the restaurant operator", "controls": [ "DPA with each client", "PII minimization at ingestion", "Encryption at rest" ], "evidence_required": [ "[PLACEHOLDER] owner to complete" ] } ], "rubric": { "categories": [ { "category": "Domain clarity", "score": 5, "min": 3, "passed": true }, { "category": "AI governance", "score": 5, "min": 3, "passed": true }, { "category": "Regulatory boundary clarity", "score": 4, "min": 3, "passed": true } ], "average": 4.7, "pass": true }, "shared_kernel_warnings": [ "The canonical order/deduction/payout schema is a shared kernel between Ingestion, Detection, and Reconciliation — changes require coordination across all three module owners" ], "slop_findings": [ { "pattern": "Generic 'AI-powered' language", "status": "not found", "note": "Copy bar in DESIGN-STANDARD.md §9 enforced across all client-facing artifacts" } ], "unit_economics": { "unit_of_value": "One recovered dollar (dispute win or reconciliation credit)", "price_model": "20-25% success fee + $99/location/month retainer, never hourly", "gross_margin_pct": "37% at pilot pricing -> 64% by day 90 -> 75% by year 1", "cost_drivers": [ "Model inference + hosting", "Recovery Analyst review minutes", "QA/escalation labor", "Support/reporting labor", "Rework allowance" ], "breakeven_note": "Blended monthly gross margin is negative in the first ~8 months as new-pilot COGS outweighs pilot-priced revenue — see financial-model.csv notes; steady-state per-client economics are positive from month 1 of a converted annual client." }, "unresolved_ownership": [ { "concept": "Promo/fee audit depth beyond basic variance detection", "candidates": [ "Reconciliation", "a future dedicated Promo Audit context" ], "recommendation": "Keep inside Reconciliation until promo-audit volume justifies a dedicated bounded context" } ] }, "architecture": { "style": "Modular monolith, single-region, bounded-context-aligned module boundaries", "why": "8-group pilot cap does not justify microservice operational overhead; module boundaries mirror the bounded contexts so a future split stays cheap (ADR-001)", "backend_modules": [ "intake", "ingestion", "detection", "disputing", "reconciliation", "reporting-billing" ], "frontend_modules": [ "marketing landing page (static, self-contained)", "internal dispute-queue view (spreadsheet-grade at launch)" ], "database_strategy": "Postgres, per-client row-level partitioning, canonical order/deduction/payout schema as the shared contract between contexts", "event_bus": "In-process domain events at launch (modular monolith); durable queue only if/when a service split is warranted past the scaling-roadmap trigger", "queue": "Deadline scheduler (cron-based) driving the weekly dispute and reconciliation cycles", "workflow_engine": "None at launch — deterministic rules in code plus the weekly cycle SOP; a workflow engine is deferred until volume justifies it", "ai_orchestration": "Vendor-neutral LLM abstraction layer behind every agent call; gold-standard eval suite gates any model swap (ai-engine-spec.md Layer 10)", "rag_layer": "Platform Rulebook and gold-standard exemplar library, retrieved by Detection and Disputing agents only", "api_boundaries": [ "Ingestion -> Detection (canonical schema)", "Detection -> Disputing (ErrorCharge payload)", "Disputing -> Client Reporting & Billing (confirmed outcomes only)" ], "authn_authz": "Row-level auth; per-client retrieval partitioning; named-role platform access only, never shared credentials", "audit_logging": "Immutable, append-only audit log per dispute and per reconciliation run; doubles as invoice substantiation", "observability": "Structured logs per domain event; weekly win-rate, coverage, and cycle-time dashboards", "file_storage": "Object storage for statement/POS export archives and evidence artifacts, encrypted at rest", "deployment": "Single deployable unit; staged rulebook/eval regression environment before production rulebook version bumps", "client_portal": "None at launch — email/PDF delivery only, matching the 'done-for-you, not software' positioning", "admin_dashboard": "Internal only — dispute queue, exception queue, and win-rate dashboards for the Recovery Analyst and founder", "operator_dashboard": "Same as admin_dashboard at this stage — no separate operator tier until Analyst #2 onboards", "rejected_alternatives": [ { "option": "Microservices from day one", "reason_rejected": "Operational overhead not justified at an 8-group pilot scale (ADR-001)" }, { "option": "Client-facing dashboard at launch", "reason_rejected": "Contradicts the 'done-for-you desk, not software' positioning; deferred until it earns its build cost" }, "[PLACEHOLDER] owner to complete" ] } }, "architecture": { "slug": "restaurant-delivery-dispute-payout-recovery-desk", "archetypes": [ "margin recovery desk", "compliance-adjacent dispute/collections desk" ], "archetype_impact": "Drives a portal-access-in / evidence-linked-report-out shape with a permanent Recovery Analyst approval gate before any platform-facing submission, rather than a self-serve SaaS shape.", "personality": [ "Quiet, evidence-first, never alarmist", "Deadline-literal (dates and dollar amounts stated exactly, never vague)", "Recovery Analyst accountability visible in every dispute and report", "Ledger-grade precision in every citation" ], "forces_ranked": [ { "force": "Deadline determinism", "why": "Every Dispute Window countdown must be deterministic and auditable — a wrong one forfeits real client money" }, { "force": "Human-chokepoint discipline", "why": "The business's entire moat rests on the Recovery Analyst approval gate holding on every submission" }, { "force": "Time-to-first-pilot", "why": "8-group pilot cap must be reachable in 90 days without a platform build" }, { "force": "Multi-platform extensibility", "why": "DoorDash today, Uber Eats/Grubhub next — the Platform Rulebook must generalize across platforms cleanly" } ], "tradeoffs": [ "Single-region modular monolith trades some scalability headroom for speed-to-pilot and lower ops burden", "No client-facing portal at launch trades self-serve visibility for a thinner, faster-to-ship MVP" ], "quality_scenarios": [ { "attribute": "Correctness", "assumption": "A dispute is drafted by the Dispute Drafting Agent", "target": "0 evidence-unsupported disputes submitted in the trailing quarter" }, { "attribute": "Availability", "assumption": "A deadline-heavy week across the full pilot cohort", "target": "100% of eligible Error Charges filed inside their Dispute Window with >=3-day buffer" } ], "options": [ { "style": "Modular monolith", "complexity": "low", "cost": "low", "ops_burden": "low", "team_fit": "high", "scaling_path": "Extract a module to a service if its load profile diverges", "security_impact": "Simpler perimeter, single auth boundary", "fits_here": true, "fits_when": "Pilot-to-early-scale (up to ~40-60 clients per analyst)", "wrong_here": false, "recommended": true }, { "style": "Microservices", "complexity": "high", "cost": "high", "ops_burden": "high", "team_fit": "low at this stage", "scaling_path": "N/A yet", "security_impact": "More surface area, more inter-service auth", "fits_here": false, "fits_when": "Post-100-client multi-analyst scale", "wrong_here": true, "recommended": false }, { "style": "No-code workflow tool", "complexity": "low", "cost": "low", "ops_burden": "low", "team_fit": "medium", "scaling_path": "Would require a rebuild to add deterministic deadline-math and evidence invariants", "security_impact": "Vendor-dependent data handling", "fits_here": false, "fits_when": "Never for this business's evidence-integrity requirements", "wrong_here": true, "recommended": false } ], "chosen_style": "Modular monolith, single production region", "chosen_rationale": "Matches the actual 8-group pilot scale and keeps the deterministic-rules and human-chokepoint invariants enforceable in one codebase.", "rejected": [ { "style": "Microservices", "why_rejected": "Operational overhead unjustified below ~40-60 clients per analyst" }, { "style": "No-code workflow tool", "why_rejected": "Can't cleanly enforce deadline-math determinism and evidence-citation invariants" } ], "target": { "overview": "Single-region modular monolith with six domain modules mirroring the bounded contexts, a Postgres canonical store, and an LLM abstraction layer behind every AI agent call.", "frontend": "Static, self-contained landing page (no framework); internal dispute-queue view is spreadsheet-grade (Airtable/Retool) at launch", "backend": "Python modular monolith; module boundaries mirror bounded contexts (intake, ingestion, detection, disputing, reconciliation, reporting-billing)", "data": "Postgres canonical order/deduction/payout schema, per-client row-level partitioning", "api": "Internal application-service calls at launch; no public API surface until a client-facing portal is justified", "authn_authz": "Row-level auth; named-role platform access only, never shared credentials", "integrations": "DoorDash Merchant Portal/Developer API, Uber Eats Manager/reporting API, Grubhub for Restaurants, Toast/Square/Olo POS exports, Stripe, HubSpot free CRM, e-sign, Calendly", "background_jobs": "Nightly ingestion job; weekly dispute-cycle and reconciliation-cycle cron jobs; deadline scheduler", "object_storage": "Encrypted object storage for statement/POS export archives and evidence artifacts", "notifications": "Email delivery for reports, statements, and exception alerts", "search": "Not applicable at pilot scale", "analytics": "Internal win-rate, coverage, and cycle-time dashboards only", "ai": "Frontier LLM API behind a vendor-neutral abstraction layer; gold-standard eval suite gates any model swap", "observability": "Structured logs per domain event; weekly dashboards; exception-queue alerting", "deployment": "Single deployable unit; staged rulebook/eval regression environment before production rulebook version bumps", "security": "DPA-governed data handling, encryption at rest, per-client retrieval partitioning, immutable audit log", "dr": "Daily Postgres backups with point-in-time recovery; evidence artifacts backed up to redundant object storage" }, "modules": [ { "name": "intake", "purpose": "Client onboarding and completeness checking", "owned_domain": [ "ClientAccount" ], "application_services": [ "ReceiveScanIntake", "ActivateClientAccount" ], "infra_adapters": [ "Email/upload intake handler", "Object storage adapter" ], "public_interfaces": [ "ClientActivated event" ], "forbidden_deps": [ "Must not depend on disputing or billing internals" ], "responsibility": "Turn granted portal access and a POS feed into an activated Client Account", "owned_data": [ "ClientAccount", "PortalGrant" ], "events_produced": [ "scan.intake_received", "ClientActivated" ], "events_consumed": [], "interfaces": [ "-> ingestion" ], "depends_on": [], "entities": [ "ClientAccount", "PortalGrant" ], "failure_risks": [ "Incomplete data blocks activation" ], "scaling": "Stateless; scales with onboarding volume, not a bottleneck at pilot scale", "future_split_trigger": "Never — remains a thin module regardless of scale" }, { "name": "ingestion", "purpose": "Statement/POS normalization", "owned_domain": [ "DeliveryOrder" ], "application_services": [ "IngestPlatformStatements", "IngestPOSExport" ], "infra_adapters": [ "Platform statement parsers", "POS export parsers", "LLM extraction client" ], "public_interfaces": [ "OrderIngested event" ], "forbidden_deps": [ "Must not depend on disputing internals" ], "responsibility": "Normalize every platform statement and POS export into the canonical schema nightly", "owned_data": [ "DeliveryOrder", "PlatformStatementLine" ], "events_produced": [ "OrderIngested" ], "events_consumed": [ "ClientActivated" ], "interfaces": [ "-> detection", "-> reconciliation" ], "depends_on": [ "intake" ], "entities": [ "DeliveryOrder", "PlatformStatementLine" ], "failure_risks": [ "Malformed export mis-extracted", "Portal format drift" ], "scaling": "Parallelizable per client; first bottleneck as client count grows", "future_split_trigger": "Sustained ingestion volume beyond ~40-60 clients per analyst-throughput target" }, { "name": "detection", "purpose": "Deduction classification and deadline scoring", "owned_domain": [ "ErrorCharge" ], "application_services": [ "DetectErrorCharge" ], "infra_adapters": [ "Platform Rulebook retrieval" ], "public_interfaces": [ "ErrorChargeDetected event" ], "forbidden_deps": [ "Must not depend on billing internals" ], "responsibility": "Classify every deduction against the Platform Rulebook and compute deadlines deterministically", "owned_data": [ "ErrorCharge" ], "events_produced": [ "ErrorChargeDetected" ], "events_consumed": [ "OrderIngested" ], "interfaces": [ "-> disputing" ], "depends_on": [ "ingestion" ], "entities": [ "ErrorCharge" ], "failure_risks": [ "Missed eligible charge", "Stale rulebook citation" ], "scaling": "Compute-bound, scales linearly with order volume", "future_split_trigger": "Rulebook complexity beyond three platforms" }, { "name": "disputing", "purpose": "Dispute drafting, review, submission, tracking", "owned_domain": [ "Dispute" ], "application_services": [ "DraftDispute", "ReviewAndSubmitDispute", "TrackDisputeOutcome" ], "infra_adapters": [ "Platform portal submission clients", "LLM drafting client" ], "public_interfaces": [ "DisputeWon/DisputeRejected events" ], "forbidden_deps": [ "Must not depend on reporting-billing internals" ], "responsibility": "Draft, analyst-review, submit, and track every Dispute through to outcome", "owned_data": [ "Dispute" ], "events_produced": [ "DisputeDrafted", "DisputeSubmitted", "DisputeWon", "DisputeRejected" ], "events_consumed": [ "ErrorChargeDetected" ], "interfaces": [ "-> reporting-billing" ], "depends_on": [ "detection" ], "entities": [ "Dispute" ], "failure_risks": [ "Evidence-integrity failure", "Analyst review backlog" ], "scaling": "Human-bound by Recovery Analyst throughput — the real scaling bottleneck", "future_split_trigger": "Multiple analysts requiring independent queue infrastructure" }, { "name": "reconciliation", "purpose": "Weekly POS-to-payout certification", "owned_domain": [ "ReconciliationRun" ], "application_services": [ "RunWeeklyReconciliation" ], "infra_adapters": [ "Payout statement parsers" ], "public_interfaces": [ "PayoutReconciled event" ], "forbidden_deps": [ "Must not depend on disputing internals" ], "responsibility": "Certify every location's weekly payout against POS and flag variances", "owned_data": [ "PayoutVariance" ], "events_produced": [ "PayoutReconciled", "VarianceFlagged" ], "events_consumed": [ "OrderIngested" ], "interfaces": [ "-> reporting-billing" ], "depends_on": [ "ingestion" ], "entities": [ "ReconciliationRun", "PayoutVariance" ], "failure_risks": [ "Missed payout gap", "False-positive variance noise" ], "scaling": "Compute-bound, scales linearly with location count", "future_split_trigger": "Not anticipated at any near-term scale" }, { "name": "reporting-billing", "purpose": "Report/statement assembly and invoicing", "owned_domain": [ "LeakageReport", "RecoveryLedgerEntry" ], "application_services": [ "DeliverLeakageReport", "InvoiceRecoveredDollars" ], "infra_adapters": [ "Stripe client", "Email delivery" ], "public_interfaces": [ "RecoveredDollarsInvoiced event" ], "forbidden_deps": [], "responsibility": "Assemble tie-out-checked reports and compute invoices from confirmed recoveries only", "owned_data": [ "LeakageReport", "RecoveredDollarsStatement", "RecoveryLedgerEntry" ], "events_produced": [ "LeakageReportDelivered", "RecoveredDollarsInvoiced" ], "events_consumed": [ "DisputeWon", "DisputeRejected", "PayoutReconciled" ], "interfaces": [], "depends_on": [ "disputing", "reconciliation" ], "entities": [ "LeakageReport", "RecoveredDollarsStatement", "RecoveryLedgerEntry" ], "failure_risks": [ "Tie-out failure reaching a client", "Invoice dispute" ], "scaling": "Low volume, not a bottleneck", "future_split_trigger": "Not anticipated at any near-term scale" } ], "data_architecture": { "primary_db": "Postgres", "secondary": [ "Object storage for evidence artifacts and export archives" ], "cache": "None required at pilot scale", "search": "Not applicable", "vector": "Not applicable — retrieval is citation-anchored rulebook lookup, not semantic search, at this scale", "object_storage": "Encrypted, per-client-partitioned bucket for statements, POS exports, and evidence", "schema_strategy": "Canonical order/deduction/payout schema as the shared contract; versioned migrations", "migrations": "Standard forward-only migrations with a staging regression pass before production", "backups": "Daily automated backups with point-in-time recovery", "retention": "Life of the client engagement plus applicable audit-retention window", "audit_logs": "Immutable, append-only per dispute and reconciliation lifecycle transition", "soft_delete": "Used for client offboarding; hard delete only after retention window and no legal hold", "privacy": "Consumer PII minimized at ingestion; DPA-governed handling", "encryption": "At rest and in transit", "multi_tenancy": "Row-level, per-client partitioned" }, "api": { "style": "Internal application-service calls; no public API at launch", "public_vs_internal": "Internal only", "versioning": "N/A at launch", "rate_limiting": "Respects each platform's own portal/API rate limits on the ingestion side", "idempotency": "Ingestion and dispute-submission commands are idempotent per order/dispute ID", "pagination": "N/A at launch", "error_format": "Structured internal error codes per bounded context", "webhook_security": "N/A — no inbound webhooks at launch", "retries": "Exponential backoff on platform API calls; failures route to the Exception Queue after max retries", "contract_testing": "Canonical schema contract tests on every ingestion parser change", "backward_compat": "N/A at launch", "contract_testing_plan": "Run on every schema or parser change before deploy" }, "security": { "authn": "Named-role platform access per client; internal team auth via standard SSO", "authz": "Row-level, per-client retrieval partitioning", "tenant_isolation": "Per-client partitioned Postgres rows and object-storage prefixes", "secrets": "Managed secrets store; no credentials in code or logs", "encryption": "At rest and in transit", "session": "Standard session management for internal tooling", "input_validation": "Structured schema validation on every ingestion parse", "api_protection": "N/A — no public API surface", "audit_log": "Immutable, append-only per dispute and reconciliation transition", "admin_access": "Founder/ops-lead only for rulebook version bumps and new-POS-type acceptance", "supply_chain": "Standard dependency scanning in CI", "threat_model": [ "Shared-credential misuse", "Cross-client data leak", "Evidence tampering" ], "abuse_cases": [ "An actor attempts to file a dispute without sufficient evidence", "An actor attempts to access another client's data" ], "zero_trust": "Every internal service call authenticated and scoped to the acting client/role", "asvs_notes": "Standard OWASP ASVS-aligned practices applied at the module boundary level" }, "reliability": { "failure_modes": [ "Ingestion pipeline fails silently", "Platform portal access revoked mid-cycle", "Analyst review backlog delays submission" ], "graceful_degradation": "A single client's ingestion failure never blocks another client's cycle", "retry_policy": "Exponential backoff on platform API calls", "timeouts": "Standard per-integration timeouts with Exception Queue fallback", "circuit_breaker": "Per-platform integration circuit breaker on repeated failures", "queueing": "Cron-driven weekly cycle queue; no real-time queueing required at pilot scale", "idempotency": "Commands are idempotent per order/dispute ID", "dlq": "Failed ingestion items route to the Exception Queue rather than a silent drop", "transactions": "One-aggregate-per-commit transaction boundary throughout", "dr": "Daily backups, point-in-time recovery, redundant object storage", "incident_response": "Founder/ops-lead-owned; missed-deadline incidents trigger immediate root-cause review", "slos": [ { "name": "Dispute filing timeliness", "target": "100% inside window with >=3-day buffer" }, { "name": "Weekly report delivery", "target": "100% on time, tie-out passing" } ] }, "scaling": { "mvp_can_stay_simple": [ "Single-region deployment", "Spreadsheet-grade dispute queue", "No client-facing portal" ], "modular_now": [ "Bounded-context-aligned module boundaries", "Canonical schema as shared contract" ], "deferrable": [ "Client-facing dashboard", "Auto-filing low-risk disputes via API", "Multi-region deployment" ], "breaks_first": "Recovery Analyst review throughput, not the software — the human chokepoint is the real scaling constraint", "db_path": "Postgres scales comfortably well past the pilot's data volume; no near-term migration anticipated", "jobs_path": "Cron-based cycles suffice through the 20-client pause-and-measure checkpoint", "cache_path": "Not needed at this scale", "search_path": "Not applicable", "files_path": "Object storage scales linearly with client count", "api_path": "No public API needed until a client-facing portal is justified", "multi_region": "Not needed at US-only pilot scale", "cost_control": "Inference cost is <10% of COGS per financial-model.csv; the analyst-labor line dominates and scales with automation maturity" }, "ai": { "provider": "Frontier LLM API behind a vendor-neutral abstraction layer", "prompt_mgmt": "Version-pinned with the Platform Rulebook and eval suite", "rag": "Citation-anchored Platform Rulebook and gold-standard exemplar retrieval", "vector": "Not required — rulebook retrieval is structured lookup, not semantic search, at this scale", "embeddings": "Not required at pilot scale", "eval": "Gold-standard order-match and dispute-draft regression suite, re-run on every version change", "hitl": "Permanent Recovery Analyst review before every submission and every client-facing report", "guardrails": "EvidenceSufficiencySpec; no-assertion-without-artifact rule; INSUFFICIENT_EVIDENCE as a valid model output", "prompt_injection": "Statement/POS content treated as untrusted data, never instructions, in every prompt", "leakage": "Per-client memory scope; no cross-client context in any agent call", "fallback": "A failed or low-confidence AI draft routes to the Exception Queue, never a silent skip", "latency_cost": "Inference cost is <10% of COGS; latency is not client-facing (batch nightly/weekly cycles)", "memory": "Per-client, per-batch; no persistent cross-session agent memory", "tool_permissions": "Agents may draft and classify; only the Recovery Analyst's submission action reaches a platform", "auditability": "Every AI output logged with confidence score and cited source before any downstream action", "citation": "Every dispute narrative and variance hypothesis cites a specific POS field or rulebook reason code" }, "devops": { "environments": [ "local/dev", "staging (rulebook + eval regression)", "production" ], "observability": [ "Structured logs per domain event", "Weekly win-rate and coverage dashboards", "Exception-queue alerting" ], "testing_pyramid": [ "Unit (deadline math, reconciliation math)", "Component (classification/exception routing)", "E2E (intake through filed dispute)" ], "accessibility_tests": [ "Automated contrast check against brand.md token values", "Manual keyboard walk before every landing-page deploy" ], "performance_budget": "Landing page <=120KB, zero external requests, LCP <=2.5s mid-tier mobile, INP <=200ms, CLS <=0.1", "cicd": "Git-based CI; eval suite gates any prompt/rulebook/model change before production cutover", "iac": "Standard infrastructure-as-code for the single production environment", "secrets": "Managed secrets store, never committed to source", "preview_envs": "Staging environment doubles as the rulebook/eval regression environment", "migrations": "Forward-only, staged before production", "rollback": "Standard deploy rollback; rulebook version bumps are independently revertible from code deploys", "release_style": "Continuous deploy for code; gated, versioned releases for rulebook changes", "feature_flags": "Used for platform-coverage rollout (e.g., enabling Uber Eats at the day-90 checkpoint)", "monitoring": "Weekly dashboards plus exception-queue real-time alerting", "alerting": "Missed-deadline and tie-out-failure alerts route immediately to the founder/Recovery Analyst", "logs": "Structured, per-domain-event logging", "error_tracking": "Standard error tracking on ingestion parsers and integration clients", "uptime": "Not client-facing real-time; batch cycle reliability is the relevant target", "cost_monitoring": "Inference and hosting cost tracked per client per month against the COGS model" }, "testing": { "unit": "Deadline math (14/30-day countdowns), reconciliation variance math", "integration": "Ingestion parser to canonical schema, per POS/platform format", "contract": "Canonical schema contract tests on every parser change", "e2e": "Full intake -> ingestion -> detection -> disputing -> reporting path against seeded sample data", "security": "Row-level auth and per-client partitioning verified in CI", "a11y": "Automated contrast + manual keyboard walk on the landing page", "load": "Not a near-term priority at pilot scale; revisited at the scaling-roadmap triggers", "chaos": "Not a near-term priority at pilot scale", "migration": "Staged before production with a rollback plan", "backup_restore": "Quarterly restore drill", "ai_eval": "Gold-standard regression suite on every prompt/rulebook/model change", "test_data": "Anonymized seeded sample statements and POS exports per platform/POS system" }, "observability": { "logs": "Structured, per-domain-event", "metrics": "Coverage rate, Win Rate, cycle time, dispute batch throughput", "traces": "Not required at this architecture scale", "audit_events": "Every dispute and reconciliation lifecycle transition", "business_events": "ClientActivated, DisputeWon, DisputeRejected, PayoutReconciled, LeakageReportDelivered, RecoveredDollarsInvoiced", "error_tracking": "Standard error tracking on parsers and integration clients", "security_monitoring": "Access-log review, weekly", "cost_monitoring": "Per-client COGS tracked monthly against the financial model", "dashboards": [ "Win Rate by platform/reason-code", "Exception Queue by severity", "Weekly coverage" ], "alert_thresholds": [ "Coverage <100% at cycle close", "Any dispute inside 3 days of its deadline unsubmitted" ], "triage": "Founder/Recovery Analyst triages exception-queue and alert items within the same business day" }, "cost": { "drivers": [ { "name": "Recovery Analyst review minutes", "note": "The dominant COGS line at launch; automates down per financial-model.csv" }, { "name": "Model inference + hosting", "note": "<10% of COGS per financial-model.csv" } ], "likely_traps": [ "Over-building a client-facing portal before it's justified", "Accepting exotic POS integrations without a fee gate" ], "controls": [ "Implementation-fee gate for non-standard POS systems", "Analyst #2 hiring gate tied to throughput metrics" ] }, "multi_tenancy": { "model": "Single database, row-level per-client partitioning", "isolation": "Row-level auth enforced at the application-service layer", "tenant_aware_authz": "Every query scoped to the acting client", "tenant_config": "Per-client platform/POS connection config", "branding": "Not applicable — internal tooling only, client-facing artifacts are LeakLedger-branded reports", "tenant_export": "Available on request per the DPA's data-portability terms", "tenant_deletion": "Offboarding SOP with retention-window and legal-hold checks", "tenant_audit": "Per-client audit log, reviewable on request", "noisy_neighbor": "Not a near-term concern at pilot scale; batch cycles are per-client isolated jobs", "tenant_rate_limits": "N/A — no public API", "billing": "Stripe, tied to the RecoveryLedgerEntry ledger per client", "why_this_fits": "Row-level partitioning is the simplest model that satisfies per-client data isolation at pilot scale without microservice overhead" }, "privacy_compliance": { "data_classification": "Consumer PII (order-level), client financial data, audit/evidence records", "minimization": "Consumer PII not needed for dispute evidence dropped at ingestion", "consent": "DPA signed before any data ingestion begins", "access_logs": "Reviewed weekly", "audit_trails": "Immutable, append-only", "retention": "Life of engagement plus applicable audit-retention window", "legal_hold": "Retention extended on a documented legal hold", "right_to_delete": "Honored per the offboarding SOP absent a legal hold", "right_to_export": "Available on request per the DPA", "sensitive_handling": "Consumer PII minimized and encrypted; no special-category data processed", "boundaries": "LeakLedger is a service provider to the client under CCPA/state-privacy-law framing", "residency": "US-only data residency at this scale", "vendor_risk": "LLM provider and Stripe are the primary third-party data processors; both under standard DPAs", "breach_response": "Documented breach-response plan; cyber insurance recommended before scaling past the pilot cohort", "admin_controls": "Founder/ops-lead-only access to cross-client rulebook and configuration", "evidence_collection": "Every access and every dispute action is logged for breach-response reconstruction" }, "frontend": { "framework": "None — static, self-contained HTML/CSS/JS for the landing page (DESIGN-STANDARD.md compliant)", "rendering": "Static", "routing": "Single page plus the platform-served /blueprint/ SPA shell", "state": "Minimal inline JS for the intake form only", "server_state": "N/A", "forms": "Delivery Leakage Scan request form, client-side validated, no backend wiring in the microsite itself", "error_handling": "Inline form-status messaging", "components": "Hand-authored semantic HTML sections", "design_system": "Semantic tokens per brand.md and DESIGN-STANDARD.md §5", "auth_ui": "N/A — no client-facing auth surface", "authz_aware_ui": "N/A", "a11y": "WCAG 2.2 AA per DESIGN-STANDARD.md §6", "i18n": "en-US only", "performance": "<=120KB, zero external requests, LCP <=2.5s mid-tier mobile", "bundling": "None — single file", "testing": "Manual accessibility and contrast verification before every deploy", "offline": "Not applicable", "realtime": "Not applicable" }, "backend": { "framework": "Python, modular monolith", "layering": "domain / application / infra per module, mirroring bounded contexts", "domain": "Aggregates and value objects per ai-engine-spec.md and ddd.aggregates", "services": "Application services per bounded context (see architecture.modules)", "repositories": "Per-aggregate, per-client-partitioned repositories", "validation": "Structured schema validation at every ingestion and command boundary", "authorization": "Row-level, per-client", "jobs": "Nightly ingestion; weekly dispute and reconciliation cycles", "events": "In-process domain events at launch", "files": "Object storage for statements, exports, and evidence", "email_sms": "Email only, for reports/statements/exception alerts", "scheduled": "Cron-driven weekly and nightly cycles", "errors": "Structured internal error codes per bounded context", "logging": "Structured, per-domain-event", "config": "Environment-based config; secrets in a managed secrets store", "di": "Standard dependency injection within the modular monolith", "testing": "Unit, component, and E2E per architecture.testing" }, "diagrams": { "context_mermaid": "graph TD; Client-->LeakLedger; LeakLedger-->DoorDash; LeakLedger-->UberEats; LeakLedger-->Grubhub; LeakLedger-->POS", "container_mermaid": "graph TD; Intake-->Ingestion-->Detection-->Disputing-->ReportingBilling; Ingestion-->Reconciliation-->ReportingBilling", "data_flow_mermaid": "graph LR; Statement-->CanonicalOrder-->ErrorCharge-->Dispute-->RecoveryLedgerEntry-->Invoice", "auth_flow_mermaid": "graph TD; Client-->GrantsNamedRole-->LeakLedgerAnalyst-->PortalAccess", "authz_flow_mermaid": "graph TD; Request-->RowLevelCheck-->ClientScopedData", "deployment_mermaid": "graph TD; Staging-->EvalGate-->Production", "background_job_mermaid": "graph TD; NightlyCron-->Ingestion; WeeklyCron-->DisputeCycle; WeeklyCron-->ReconciliationCycle", "event_flow_mermaid": "graph LR; OrderIngested-->ErrorChargeDetected-->DisputeDrafted-->DisputeSubmitted-->DisputeWon", "failure_flow_mermaid": "graph TD; IngestionFailure-->ExceptionQueue-->AnalystDisposition", "multi_tenant_flow_mermaid": "graph TD; Request-->ClientContext-->RowLevelPartition", "ai_flow_mermaid": "graph TD; RawInput-->ExtractionAgent-->DetectionAgent-->DraftingAgent-->AnalystGate-->Submission" }, "adrs": [ { "id": "ADR-001", "decision": "Launch as a single-region modular monolith, not microservices", "status": "accepted", "context": "8-group pilot cap does not justify microservice operational overhead", "options": [ "Modular monolith", "Microservices", "No-code workflow tool" ], "chosen": "Modular monolith", "business_reason": "Fastest path to the first 5 pilot groups without a platform team", "technical_reason": "Module boundaries mirror bounded contexts, keeping a future split cheap", "tradeoffs": "Less independent scalability per module until volume demands it", "risks": [ "[PLACEHOLDER] owner to complete" ], "why": "Matches the actual pilot scale", "consequences": [ "[PLACEHOLDER] owner to complete" ], "revisit_when": "Sustained load beyond ~40-60 clients per analyst-throughput target", "reversal": "Would require re-architecting submission around a compliant auto-file API and re-running the evidence-integrity eval suite before cutover", "revisit_trigger": "Sustained load beyond ~40-60 clients per analyst-throughput target" }, { "id": "ADR-002", "decision": "Manual portal submission at launch; no auto-filing until platform APIs support it", "status": "accepted", "context": "Submission is a human chokepoint by design, not a temporary scaling gap", "options": [ "Manual submission via named role", "Auto-file via scraping", "Auto-file via official API once available" ], "chosen": "Manual submission via named role", "business_reason": "Protects platform standing and evidence integrity; matches the licensing-boundary posture in compliance-checklist.md", "technical_reason": "No reliable, ToS-compliant auto-submission API exists across all three platforms at launch", "tradeoffs": "Caps per-analyst throughput until APIs mature", "risks": "None beyond the throughput ceiling, which is priced into the financial model", "why": "Evidence-integrity and accountability are the moat, not automation speed", "consequences": "Human review remains permanent regardless of model capability", "revisit_when": "Official platform APIs supporting compliant auto-filing for low-risk/high-confidence disputes", "reversal": "Would require re-architecting submission around a compliant auto-file API and re-running the evidence-integrity eval suite before cutover", "revisit_trigger": "Official platform APIs supporting compliant auto-filing for low-risk/high-confidence disputes" } ], "roadmap": [ { "phase": "MVP — DoorDash Dispute Desk", "weeks": "1-4", "outcomes": [ "Ingestion + classification pipeline validated", "First disputes filed" ], "exit_criteria": [ "3-5 Scans delivered", ">=2 pilots signed" ], "kill_criteria": [ "Zero willingness-to-engage signal across the first 8 Scan readouts" ], "build": [ "Intake", "Ingestion", "Detection", "Disputing (manual submission)" ], "defer": [ "Client-facing portal", "Auto-filing" ], "monitor": [ "Win Rate", "minutes-per-dispute" ], "avoid": [ "Microservices", "premature multi-platform scope" ], "acceptable_debt": [ "[PLACEHOLDER] owner to complete" ], "dangerous_debt": [ "[PLACEHOLDER] owner to complete" ], "triggers_to_change": [ "[PLACEHOLDER] owner to complete" ] }, { "phase": "Day-90 — Multi-platform + hardening", "weeks": "5-13", "outcomes": [ "Uber Eats coverage added", "Ingestion automated for top-3 POS" ], "exit_criteria": [ "8-pilot cohort complete", ">=4 converted to annual" ], "kill_criteria": [ "Win Rate below 40% sustained with no salvageable segment" ], "build": [ "Reconciliation automation", "Uber Eats rulebook" ], "defer": [ "Grubhub coverage", "auto-filing via API" ], "monitor": [ "COGS/group", "rework rate", "escalation rate" ], "avoid": [ "Hiring Analyst #2 before the throughput gate clears" ], "acceptable_debt": "Spreadsheet-grade dispute queue", "dangerous_debt": "Per-client custom report formats", "triggers_to_change": "20-client pause-and-measure checkpoint" } ], "anti_overengineering": { "flagged": [ { "item": "Client-facing dashboard", "why": "Contradicts the 'done-for-you desk, not software' positioning at this scale", "simpler": "Email/PDF delivery of the weekly report and monthly statement" }, { "item": "Auto-filing disputes via scraping", "why": "ToS risk and evidence-integrity risk outweigh the throughput gain at pilot scale", "simpler": "Manual submission via named portal role, per ADR-002" } ] }, "risks": [ { "risk": "Recovery Analyst review backlog during a deadline-heavy week", "likelihood": "medium", "impact": "high", "mitigation": "Priority queue ordering by days-remaining; hire Analyst #2 only at the throughput gate", "detection": "Weekly cycle-time dashboard", "owner": "founder", "escalation": "Founder reviews queue depth daily during a backlog", "fallback": "Deprioritize lower-value disputes to protect deadline-critical ones", "category": "operational" }, { "risk": "Platform statement format changes without notice", "likelihood": "high", "impact": "medium", "mitigation": "Weekly rulebook-diff monitoring; parser contract tests", "detection": "Ingestion completeness-check failures", "owner": "founder", "escalation": "Exception Queue + founder review", "fallback": "Manual CSV pull until the parser is patched", "category": "technical" } ], "rules": [ "No dollar figure or deadline is ever LLM-computed", "No dispute submits without Recovery Analyst sign-off", "No client-facing report sends without passing the tie-out gate", "No shared portal credentials — named roles only" ], "audit": { "product_fit": 5, "simplicity": 5, "security": 4, "reliability": 4, "scalability": 4, "maintainability": 5, "performance": 5, "cost": 5, "compliance": 4, "dx": 4, "ops_burden": 5, "extensibility": 4, "team_suitability": 5, "time_to_market": 5, "recommendation": { "verdict": "Build the modular monolith as scoped; do not over-invest in a client-facing portal or microservices before the pilot cohort proves throughput economics.", "stack": "Python modular monolith, Postgres, frontier LLM API behind an abstraction layer", "style": "Modular monolith, single region", "database": "Postgres", "hosting": "Single-region cloud hosting appropriate to an 8-client pilot", "auth": "Row-level, per-client; named-role platform access only", "ai_approach": "Retrieval-first drafting with deterministic rules for all dollar/deadline math", "integrations": "DoorDash, Uber Eats, Grubhub (phased), Toast/Square/Olo POS, Stripe, HubSpot free", "build_first": [ "Intake completeness gate", "Ingestion parsers for DoorDash + Toast/Square/Olo", "Detection deadline math", "Dispute drafting + analyst review queue" ], "revisit_later": [ "Client-facing portal", "Auto-filing via platform APIs", "Multi-region deployment" ], "avoid": [ "Microservices before ~40-60 clients/analyst", "No-code workflow tooling for evidence-critical logic" ], "biggest_risks": [ "Recovery Analyst throughput ceiling", "Platform policy shift shrinking the dispute pool" ], "top_10_rules": [ "No dollar figure or deadline is ever LLM-computed", "No dispute submits without Recovery Analyst sign-off", "No client-facing report sends without passing the tie-out gate", "No shared portal credentials — named roles only", "Every ingestion failure routes to the Exception Queue, never a silent drop", "Every AI output is logged with a confidence score before any downstream action", "Rulebook version bumps require founder review before production drafting", "Analyst #2 hires only at the measured throughput gate", "New POS types require an implementation-fee scoping conversation", "Platform coverage expands (Uber Eats, Grubhub) only after the prior platform's economics are proven" ], "first_10_steps": [ "Stand up the Postgres canonical schema", "Build the DoorDash statement parser", "Build the Toast/Square/Olo POS export parsers", "Implement the deterministic deadline calculator", "Build the Dispute Drafting Agent with the evidence-sufficiency gate", "Stand up the spreadsheet-grade dispute review queue", "Wire Stripe invoicing to the RecoveryLedgerEntry ledger", "Build the weekly Leakage Report template with the tie-out gate", "Run the gold-standard eval suite against seeded sample data", "Onboard the first pilot client end-to-end" ] } } }, "design": { "slug": "restaurant-delivery-dispute-payout-recovery-desk", "archetypes": [ "margin recovery desk", "compliance-adjacent dispute/collections desk" ], "user_mindset": { "goals": "Confirm which delivery dollars are actually recoverable and see the deadline clock on each one", "session_length": "Short, task-focused (a weekly report read, a Scan readout call, a Scan request)", "confidence": "Wants precision (deadlines, dollar amounts, evidence) not reassurance language", "interface_needs": "Scannable status at a glance; no jargon; clear next action" }, "posture": [ "Quiet authority", "Evidence-first", "Restaurant-operator-plain, ledger-precision in analyst-facing detail" ], "density": "Medium — enough white space to read calmly, enough data density to feel like a real ledger, not a marketing page pretending to be a dashboard", "trust_level": { "tier": "medium-high — handles order-level consumer data and client financial recovery figures", "sensitive_domains": [ "Consumer order PII (minimized)", "Client financial recovery data" ], "implications": [ "Every claim must be sourced or marked [PLACEHOLDER]", "No decorative motion or gamified UI patterns" ] }, "differentiation": { "avoid": [ "Insurtech/fintech gradient hero clichés", "Stock delivery-bag/food-photo imagery", "Countdown-timer urgency gimmicks that read as pressure rather than information" ], "strategy": "Ledger-precise, restaurant-operations-specific visual language: deadline windows, dollar-at-risk badges, and dispute-evidence structure rendered as real artifacts, not abstract icons" }, "territories": [ { "name": "Recovery Ledger", "color_mood": "deep forest-charcoal brand, warm paper surface, terracotta accent", "typography": "System sans display, clean sans body", "density": "medium", "component_feel": "Report-card precision — tables, status badges, real dates and dollar figures", "motion": "Minimal, functional only", "fits": "A buyer who wants proof, not persuasion", "risks": "Could read as plain if not paired with sharp, specific copy" }, { "name": "Alarm Fintech", "color_mood": "red/orange urgency, dark dashboard chrome", "typography": "Bold condensed display", "density": "high", "component_feel": "Countdown timers, flashing badges", "motion": "Pulsing alerts", "fits": "A buyer who responds to urgency framing", "risks": "Reads as pressure-selling; banned by DESIGN-STANDARD.md §9" }, { "name": "Generic SaaS Gradient", "color_mood": "purple-blue gradient hero", "typography": "Rounded geometric sans", "density": "low", "component_feel": "Abstract icon grid", "motion": "Scroll-triggered fade-ins", "fits": "A generic B2B SaaS audience", "risks": "Visually confusable with every other SaaS landing page — fails the DESIGN-STANDARD.md §9 distinctness test" } ], "chosen_territory": "Recovery Ledger", "chosen_rationale": "Matches the buyer's actual mindset (evidence-first, deadline-literal) and stays distinct from both the fintech-alarm cliché and generic SaaS gradients, per DESIGN-STANDARD.md §9.", "prioritized_components": [ { "name": "Deadline/Window value-object rendering", "why": "The 14/30-day Dispute Window is the single most important fact on the page — must render identically everywhere per DESIGN-STANDARD.md §3" }, { "name": "Domain-state badges (--state-ok/-risk/-pending/-blocked)", "why": "Operators scan for status, not prose — the badge system carries most of the page's information density" }, { "name": "Pricing table with guarantee beside it", "why": "Trust cue placement at the point of highest risk perception, per DESIGN-STANDARD.md §8" } ], "tokens": { "brand": "147 15% 14%", "brand-fg": "38 44% 96%", "surface": "38 44% 96%", "ink": "60 6% 10%", "muted": "38 11% 34%", "accent": "16 61% 47%" }, "type": { "display": "system-ui, -apple-system, 'Segoe UI', sans-serif", "body": "system-ui, -apple-system, 'Segoe UI', Roboto, Helvetica, Arial, sans-serif", "fonts_url": "none — system font stack only, no external font requests" }, "signature": { "motif": "Dispute Window countdown chip on every dispute-status element", "render": "A small rounded chip showing days-remaining, colored via the domain-state tokens (green when filed with buffer, amber when pending review, red when inside the final 3 days)" }, "patterns": [ { "name": "Evidence citation line", "description": "Every dollar claim on the page cites its source name inline (e.g., 'Source: Restaurant Business, 2025') rather than a footnote users won't read" }, { "name": "Dashed placeholder proof slot", "description": "Proof sections not yet populated by real pilot data use a dashed border and explicit 'pending pilot cohort' label rather than empty space or a fabricated stat" } ], "states": [ "default", "hover", "focus-visible", "disabled", "loading", "error", "empty/placeholder" ], "uniqueness_audit": { "app_specific_decisions": [ "Dispute Window countdown chip is unique to this business's domain, not a generic countdown timer", "Terracotta/forest-charcoal palette distinct from every other launched business's token set" ], "cliches_avoided": [ "No gradient hero", "No stock food-delivery photography", "No fake testimonial carousel" ], "scale_notes": "Palette and motif chosen to remain legible and distinct even if viewed side-by-side with the Ledger Calm (ESA) or other launched businesses' pages — different hue family, different motif." }, "localization": [ "en-US only at launch" ] }, "seo": { "slug": "restaurant-delivery-dispute-payout-recovery-desk", "archetype": "vertical margin-recovery desk / diagnostic-led service site", "archetype_impact": "Ranks primarily on platform-dispute-mechanics questions (DoorDash error charge, Uber Eats order error) rather than generic 'AI service' terms.", "authority_dna": { "site_archetype": "single-vertical service site with a free-diagnostic lead magnet", "monetization_model": "success-fee (% of recovered dollars) + per-location reconciliation retainer", "main_search_intents": [ "informational (platform dispute-policy questions)", "commercial (delivery margin recovery service)" ], "topical_authority_opportunity": "DoorDash/Uber Eats/Grubhub merchant dispute-mechanics content is thin and scattered across vendor blogs and platform help pages — a citation-rich, maintained explainer set can own this niche quickly", "local_seo_opportunity": "Low — buyers search platform/program terms nationally, not 'near me'", "global_national_opportunity": "National within the US third-party-delivery restaurant market", "easiest_ranking_path": "Long-tail platform-mechanics questions with low current competition ('how to dispute a DoorDash error charge as a restaurant')", "hardest_ranking_path": "Broad terms like 'restaurant delivery' or 'DoorDash for merchants' dominated by the platforms themselves", "trust_credibility_requirements": [ "Citations to primary platform policy pages", "Clearly named entity (LeakLedger) so assistants attribute answers", "No fabricated statistics — every figure traces to a Verified source" ], "ymyl": false, "expert_review_needed": true, "site_structure": "Flat: homepage -> a small set of platform-mechanics pillar pages -> FAQ/glossary supporting pages -> /blueprint/ dossier", "seo_moat": "Citation-anchored, continuously updated platform-dispute-mechanics content that AI assistants can quote with a named source" }, "search_market": { "primary_markets": [ "Multi-unit QSR/fast-casual operators on DoorDash", "Franchisee groups (McDonald's/Wendy's/KFC-class)" ], "secondary_markets": [ "Restaurant accounting firms", "Franchisee associations" ], "low_competition_subtopics": [ "DoorDash 14-day dispute window mechanics", "Uber Eats 96-hour late-report exemption", "Payout-to-POS reconciliation for multi-unit restaurants" ], "high_commercial_intent": [ "restaurant delivery dispute recovery service", "free delivery leakage scan", "DoorDash error charge recovery" ], "informational": [ "how to dispute a DoorDash error charge", "what is a DoorDash order error adjustment", "Uber Eats 96 hour rule" ], "local_intent": [], "transactional": [ "delivery margin recovery service", "restaurant payout reconciliation service" ], "comparison": [ "LeakLedger vs Loop AI", "LeakLedger vs Voosh" ], "problem_solution": [ "delivery payout doesn't match POS", "DoorDash charged us for a refund we didn't cause" ], "near_me": [], "long_tail": [ "how many days to dispute a DoorDash error charge", "what evidence does Uber Eats require for a dispute" ], "questions": [ "does DoorDash charge restaurants for refunds", "how much delivery revenue do restaurants lose to disputes" ], "emerging": [ "delivery platform payout reconciliation automation" ], "seasonal": [], "underserved_serps": [ "DoorDash dispute window mechanics for multi-unit operators" ], "weak_serps": [ "Uber Eats 96-hour rule explainer" ], "forum_dominated_serps": [ "reddit threads on DoorDash error charges" ], "winnable_authoritative_serps": [ "DoorDash error charge dispute guide (citation-anchored)" ], "avoid_initially": [ "Broad 'DoorDash for merchants' terms dominated by the platform itself" ], "easy_wins": [ "Long-tail platform-mechanics questions" ], "moderate": [ "Category comparison terms (LeakLedger vs Loop/Voosh)" ], "long_term_plays": [ "Becoming the cited source for delivery-dispute questions in AI assistants" ], "do_not_pursue": [ "Generic 'restaurant technology' terms with no commercial intent" ] }, "keyword_clusters": [ { "primary": "dispute DoorDash error charge", "related": [ "DoorDash order error adjustment", "DoorDash 14 day dispute window" ], "intent": "informational", "user_problem": "Operator doesn't know how or whether they can contest a charge", "funnel": "top", "business_value": "high", "ranking_difficulty": "low", "conversion_potential": "medium", "content_effort": "medium", "serp_weakness": "Thin, non-citation-anchored vendor content", "local_relevance": "none", "global_relevance": "national", "suggested_page_type": "pillar article", "reason": "Directly matches the MVP wedge (DoorDash-only dispute desk)", "priority_score": 95, "priority": "P0", "bucket": "core" }, { "primary": "restaurant delivery payout reconciliation", "related": [ "POS to payout reconciliation", "delivery payout doesn't match POS" ], "intent": "commercial", "user_problem": "Operator's delivery net doesn't match POS-reported sales", "funnel": "middle", "business_value": "high", "ranking_difficulty": "low", "conversion_potential": "high", "content_effort": "medium", "serp_weakness": "No done-for-you desk content exists at this specificity", "local_relevance": "none", "global_relevance": "national", "suggested_page_type": "service page", "reason": "Matches the reconciliation retainer offer", "priority_score": 85, "priority": "P1", "bucket": "core" } ], "topical_authority_map": { "core_topics": [ "DoorDash dispute mechanics", "Uber Eats dispute mechanics", "Delivery payout reconciliation" ], "pillars": [ { "name": "DoorDash Error Charge Dispute Guide", "core_intent": "informational -> commercial", "audience": "Owner/CFO/controller", "conversion_goal": "Delivery Leakage Scan requests", "supporting_pages": [ "14-day window explainer", "evidence requirements explainer" ], "internal_links": [ "/" ], "schema": [ "Article", "FAQPage" ], "evidence_needed": [ "Citation to DoorDash Merchant Help Center" ], "local_variants": [], "national_variants": [ "US" ] } ], "supporting_page_types": [ "pillar article", "FAQ/glossary page", "comparison page" ] }, "site_architecture": { "homepage_strategy": "Single landing page as the front door; the blueprint dossier lives at /blueprint/ per the platform's shell convention", "main_nav": [ "How it works", "Pricing", "FAQ", "Operating blueprint" ], "footer_nav": [ "View the full operating blueprint dossier", "Compliance & scope" ], "hubs": [ { "name": "Platform Dispute Mechanics Hub", "purpose": "Own the informational search intent around DoorDash/Uber Eats dispute mechanics", "url": "/dispute-mechanics" } ], "url_patterns": [ "/", "/blueprint/" ], "avoid_url_patterns": [ "Deep programmatic location pages (no local-SEO justification for this business)" ] }, "global_national": { "national_clusters": [ "US third-party restaurant delivery dispute recovery" ], "linkable_assets": [ "Monthly Delivery Leakage Index (anonymized book-wide data)" ], "original_research_ideas": [ "Annual aggregate win-rate-by-reason-code report once pilot data exists" ], "international_needed": false, "international_notes": "US-only market at this stage; DoorDash/Uber Eats/Grubhub dispute mechanics are US-specific" }, "local_seo": { "justified": false, "reason": "Buyers search platform/program terms nationally, not by city — multi-unit groups operate across many locations", "gbp_categories_primary": [], "gbp_categories_secondary": [], "location_page_rules": [], "citations": [], "review_strategy": "No fabricated reviews; real testimonials only once pilot recoveries exist", "local_schema": [] }, "programmatic": { "recommended": false, "reason": "No location- or franchise-specific programmatic angle justifies thin-content risk at this stage", "rules": [], "per_page_requirements": [], "quality_gates": [] }, "page_templates": [ { "page_type": "pillar article", "purpose": "Own an informational dispute-mechanics query", "target_intent": "informational", "url_pattern": "/dispute-mechanics/[topic]", "title_pattern": "[Platform] [Mechanic] — LeakLedger", "meta_description_pattern": "How [platform]'s [mechanic] works for restaurant merchants, with citations.", "h1_pattern": "[Mechanic] explained", "outline": [ "What the mechanic is", "Deadline/evidence specifics", "Worked example", "How LeakLedger handles it" ], "above_the_fold": [ "[PLACEHOLDER] owner to complete" ], "internal_links": [ "/" ], "schema": [ "Article", "FAQPage" ], "cta_strategy": "Soft CTA to the Delivery Leakage Scan after the direct answer", "conversion_elements": [ "Scan request link" ], "trust_elements": [ "Citation to the primary platform policy page" ], "faq_opportunities": [ "Common operator questions about the mechanic" ], "media": [ "[PLACEHOLDER] owner to complete" ], "quality_requirements": [ "Every factual claim cited", "No fabricated statistics" ], "anti_thin_rules": [ "Minimum a real worked dollar example per page", "No page published without a primary-source citation" ] } ], "on_page_rules": { "title_tag": "Specific mechanic or offer + LeakLedger, under 60 characters", "meta_description": "Direct, factual, under 155 characters, no clickbait", "headings": "One H1 per page; H2s map to the outline", "intro": "Direct answer in the first 2 sentences — no throat-clearing", "snippet_targeting": "Structure the direct answer as a definition or numbered list where natural", "tables_lists": "Used for deadline/evidence comparisons across platforms", "images": "None at launch — zero external requests per DESIGN-STANDARD.md §7", "internal_links": "Every supporting page links back to the homepage Scan CTA", "external_citations": "Every factual claim cites its primary source by name", "author_attribution": "Founder byline on all content at this stage", "freshness": "Rulebook-driven content re-checked on every platform policy diff (ai-engine-spec.md Layer 3)", "cta_placement": "Soft CTA after the direct answer, not before", "mobile": "Single responsive layout, no separate mobile template", "avoid": [ "Keyword stuffing", "Thin AI-generated filler", "Unsourced statistics" ] }, "entity_seo": { "main_entities": [ "LeakLedger", "DoorDash", "Uber Eats", "Grubhub" ], "related_entities": [ "Loop AI", "Voosh", "DTiQ", "Delaget" ], "people": [ "Recovery Analyst (role-title, not an invented named individual)" ], "orgs": [ "DoorDash", "Uber Eats", "Grubhub", "Restaurant Business (trade press)" ], "tools": [ "Toast", "Square", "Olo" ], "regulations": [ "Platform merchant terms of service (DoorDash, Uber Eats, Grubhub) — not government regulation" ], "problems": [ "Unfiled delivery error-charge disputes", "Unreconciled delivery payouts" ], "solutions": [ "Done-for-you dispute filing", "Weekly payout reconciliation" ], "processes": [ "Dispute filing", "Payout reconciliation", "Promo/fee audit" ], "alternatives": [ "Loop AI", "Voosh", "DIY portal work", "Restaurant accounting firm reconciliation" ], "synonyms": [ "order error adjustment", "error charge", "chargeback (platform-side, distinct from card chargebacks)" ] }, "schema_strategy": [ { "type": "FAQPage", "where": "Homepage FAQ section", "required_fields": [ "question", "answer" ], "caution": "Only real, currently-answered FAQ content — no placeholder Q&A" }, { "type": "Article", "where": "Pillar dispute-mechanics pages", "required_fields": [ "headline", "datePublished", "author" ], "caution": "No Organization/LocalBusiness schema for entities that don't yet exist (DESIGN-STANDARD.md §9)" } ], "internal_linking": { "pillar_to_cluster": "Homepage links to each dispute-mechanics pillar once published", "cluster_to_pillar": "Every supporting page links back to the homepage Scan CTA", "cluster_to_cluster": "Related mechanic pages cross-link (e.g., DoorDash <-> Uber Eats window comparison)", "service_to_location": "Not applicable — no location pages", "faq_to_commercial": "FAQ answers link to the pricing section where relevant", "breadcrumbs": "Not needed at this flat site depth", "anchor_text_rules": [ "Descriptive, lexicon-consistent anchor text — never 'click here'" ] }, "technical_seo": { "crawlability": "Single static page at launch; noindex until owner-facing facts are finalized", "indexability": "noindex:true until launch verification passes (per seo_pages)", "sitemaps": "Added once pillar pages ship", "robots": "Standard robots.txt, no crawl blocks beyond noindex during pre-launch", "canonicals": "Self-canonical on the single page", "pagination": "Not applicable", "faceted_nav": "Not applicable", "duplicate_control": "Not applicable at this page count", "redirects": "None required at launch", "core_web_vitals": "LCP <=2.5s, INP <=200ms, CLS <=0.1 per DESIGN-STANDARD.md §7", "mobile": "Responsive single layout", "accessibility": "WCAG 2.2 AA per DESIGN-STANDARD.md §6", "js_seo": "Minimal inline JS only; no framework, nothing render-blocking for crawlers", "rendering": "Static HTML, no client-side rendering dependency", "gsc_setup": "Pending — set up post-launch", "analytics_setup": "data-event attributes wired; analytics platform TBD", "rank_tracking": "Pending — set up post-launch" }, "eeat": { "author_bios": "Founder bio to be added post-launch", "expert_reviewers": "None yet — pilot-stage business", "editorial_policy": "Every factual claim cited or marked [PLACEHOLDER]", "fact_checking": "Manual re-verification against primary platform policy pages before publish", "credentials": [ "Founder background in restaurant operations/finance recovery services [PLACEHOLDER — bio pending]" ], "citations": "Named source cited inline, not just footnoted", "first_hand_proof": [ "Pilot cohort dispute outcomes, once available" ], "update_cadence": "Content re-checked on every rulebook policy diff", "monetization_disclosure": "Pricing and fee structure disclosed plainly, no hidden monetization", "ymyl_notes": "Not classic YMYL (health/finance-advice) but treated with citation rigor given the dollar-recovery claims involved" }, "ai_search": { "principles": [ "Every claim cites a named, dated source", "Plain, quotable factual statements an assistant can extract" ], "tactics": [ "Publish the Delivery Leakage Index as a citable, LeakLedger-attributed statistic", "Structured FAQ content" ], "do_not": [ "Publish unsourced statistics", "Use ambiguous or hedged language that resists extraction" ] }, "conversion": { "primary_cta": "Get my free Delivery Leakage Scan", "secondary_cta": "View the full operating blueprint dossier", "lead_magnets": [ "Delivery Leakage Scan", "Delivery Leakage Calculator" ], "trust_elements": [ "Cited stat strip", "Compliance/scope section", "Honest [PLACEHOLDER] proof slots" ], "per_page_paths": [ { "path": "/", "page_type": "landing page" } ], "tracking": "data-event attributes (ui.*/domain.*) per DESIGN-STANDARD.md §4" }, "link_earning": { "digital_pr_ideas": [ "Aggregate, anonymized delivery-leakage data story pitched to restaurant trade press" ], "original_research": [ "Delivery Leakage Index published monthly from anonymized book data" ], "directories": [ "Franchisee association resource pages" ], "expert_contributions": [ "Guest posts/webinars with franchisee associations" ], "partnerships": [ "Restaurant accounting-firm referral partners" ], "avoid": [ "Paid link schemes", "Guest posts on unrelated domains" ] }, "roadmap_90d": [ { "phase": "Phase 1", "goal": "Publish the homepage and the DoorDash dispute-mechanics pillar", "pages": [ "Homepage", "DoorDash error charge dispute guide" ], "keywords_targeted": [ "dispute DoorDash error charge", "DoorDash 14 day dispute window" ], "required_assets": [ "Delivery Leakage Calculator" ], "internal_links": [], "difficulty": "low", "business_value": "high", "conversion_goal": "Leakage Scan requests", "why_first": "Matches the founding-pilot outreach motion already underway" } ], "roadmap_12m": [ { "phase": "Phase 2", "goal": "Add the Uber Eats and Grubhub dispute-mechanics pillars timed to the day-90 platform-coverage expansion", "pages": [ "Uber Eats order error guide", "Grubhub reconciliation guide" ], "keywords_targeted": [ "Uber Eats order error adjustment", "Grubhub restaurant reconciliation" ], "required_assets": [ "Multi-platform deadline comparison table" ], "internal_links": [ "/" ], "difficulty": "low", "business_value": "high", "conversion_goal": "Leakage Scan requests", "why_first": "Timed to the day-90 platform-coverage checkpoint in launch-plan.md" } ], "priority_pages": [ { "rank": 1, "page_title": "How to dispute a DoorDash error charge (and win)", "slug": "doordash-error-charge-dispute-guide", "page_type": "pillar article", "primary_keyword": "dispute DoorDash error charge", "secondary_keywords": [ "DoorDash order error adjustment" ], "intent": "informational", "funnel": "top", "business_value": "high", "difficulty": "low", "conversion_potential": "medium", "cta": "Delivery Leakage Scan", "schema": [ "Article", "FAQPage" ], "internal_links": [ "/" ], "required_proof": [ "[PLACEHOLDER] owner to complete" ], "why_opportunity": "Thin, scattered existing coverage of the exact mechanic", "production_priority": "P0", "scope": "single article" } ], "competitor_gaps": { "typical_competitor_types": [ "Platform help-center pages", "SaaS vendor marketing pages (Loop, Voosh)", "General restaurant-tech news coverage" ], "common_weaknesses": [ "No worked dollar examples", "No citation-level rigor", "No done-for-you desk positioning" ], "how_to_beat_them": [ "Publish citation-anchored, dated, worked-example content no incumbent produces at this specificity" ] }, "metrics": { "weekly": [ "Leakage Scan requests", "Organic sessions to the pillar page" ], "monthly": [ "Scan-to-pilot conversion", "New keyword rankings" ], "quarterly": [ "Topical authority coverage vs. plan" ], "annual": [ "Content refresh completion against platform policy changes" ] }, "risks": [ { "risk": "Dispute-mechanics content going stale against platform policy changes", "applies": true, "mitigation": "Content re-checked on every rulebook policy diff (ai-engine-spec.md Layer 3)" }, { "risk": "Thin programmatic content penalty", "applies": false, "mitigation": "Programmatic generation explicitly not recommended at this stage" } ], "first_20_pages": [ "Homepage", "DoorDash error charge dispute guide", "Uber Eats order error guide (day-90)", "Delivery Leakage Calculator" ], "first_10_tech_fixes": [ "Confirm noindex removed only after launch verification passes", "Add XML sitemap once pillar pages ship" ], "first_10_authority_actions": [ "Publish the 10-post first-30-days content series", "Open franchisee-association co-marketing conversations", "Publish the Delivery Leakage Calculator lead magnet" ], "final_recommendation": "Launch the homepage and the DoorDash dispute-mechanics pillar together; hold Uber Eats/Grubhub content for the timed day-90 platform-coverage expansion; keep every claim citation-anchored given the dollar-recovery claims involved.", "disclaimers": [ "This SEO plan is operational guidance, not legal or tax advice.", "All cited figures must be re-verified against primary sources before publishing.", "No fabricated reviews, ratings, or case results — proof content ships only as real pilot outcomes exist." ] }, "microsite": { "category": "Delivery-platform margin recovery for multi-unit restaurant groups", "shortTitle": "LeakLedger Recovery Desk", "audience": "Owners, CFOs, and controllers at 5-75-location QSR/fast-casual/pizza/wings/virtual-brand restaurant groups", "problem": "Delivery platforms take back 2.5-3% of revenue through order-error charges and unreconciled payouts inside 14/30-day dispute windows — and most operators have no one whose job it is to watch any of it.", "offer": "A done-for-you delivery-margin recovery desk: every eligible dispute filed inside the deadline, every payout reconciled weekly, a monthly Recovered-Dollars Statement — priced from what we recover, never hourly, starting with a free Delivery Leakage Scan.", "faq": [ { "q": "Won't our GMs catch this stuff already?", "a": "Your free Scan shows your actual filing rate today — for most groups we've talked to, it's close to zero, not because the disputes are unwinnable but because nobody has the recurring time to sit in a merchant portal every week inside a 14-day window." }, { "q": "Will disputing charges make the platforms retaliate against us?", "a": "No. Filing a dispute is a contractual right under your own merchant agreement with each platform, using their own published process. We operate exclusively through platform-supported named user roles — never workarounds that would put your account at risk." }, { "q": "Is it safe to give you portal access?", "a": "You grant a named staff role on each platform (Admin or Store Manager level) — never your login credentials. Access is governed by a signed Data Processing Addendum, every action we take is logged in an audit trail, and you can revoke access at any time." }, { "q": "What happens if you don't recover anything?", "a": "You owe nothing. The success fee is a straight percentage of dollars actually recovered — if that number is $0 in a given period, so is our fee. The reconciliation retainer, when active, covers separately delivered weekly reconciliation work and is disclosed up front before you sign anything." }, { "q": "Do you handle card-network chargebacks too?", "a": "No — that's a different rail, fought platform-side rather than merchant-side. Our scope is specifically platform error-charge and refund adjustments plus payout reconciliation, so we never overpromise on something outside our lane." }, { "q": "Which POS systems do you support?", "a": "Toast, Square, and Olo at launch, with CSV export accepted as a fallback for your first weeks with us. Other POS systems can be scoped with an implementation fee — ask during your Scan review call." }, { "q": "What's the difference between the pilot and the annual agreement?", "a": "The 30-day pilot is DoorDash-only, 25% of recoveries, no retainer, no commitment. If you convert to an annual agreement, your success fee drops to 20% and locks for the life of the agreement, and full three-platform reconciliation coverage with the weekly Leakage Report begins." }, { "q": "How is this priced?", "a": "Recovery success fee: 25% of recovered dollars during the pilot, 20% on an annual agreement. Reconciliation desk retainer: $99/location/month, waived during the pilot. Never hourly." }, { "q": "What's the catch with the free Leakage Scan?", "a": "There isn't one beyond your time: grant read-only portal access under a simple agreement, and within 5 business days you get a quantified forfeited-versus-recoverable report on your own numbers. No pitch, no obligation to continue." } ], "process": [ { "title": "Onboard", "body": "Sign the service agreement and DPA, grant named-role portal access and a POS export, and get your baseline Delivery Leakage Scan within 5 business days." }, { "title": "Stabilize", "body": "We file live disputable items first — error charges still inside their deadline — and stand up your weekly report." }, { "title": "Operate", "body": "Every week: ingest, detect, draft, and file disputes; reconcile POS to payout; deliver your one-page Leakage Report." }, { "title": "Close", "body": "Every month: deliver the Recovered-Dollars Statement (invoice basis) and the store/item error heat map." }, { "title": "Prove", "body": "Every quarter: an ops-improvement review covering Win Rate trend, reconciliation variance trend, and coverage-expansion options." } ], "northStarCta": { "label": "Get your free Delivery Leakage Scan", "href": "#diagnostic", "secondary_label": "View the full operating blueprint dossier", "secondary_href": "/restaurant-delivery-dispute-payout-recovery-desk/blueprint/" }, "trust": { "standards": [ "Named-role portal access only — never shared credentials", "Written service agreement with DPA and authorized-agent clause", "Card-network chargebacks explicitly out of scope" ], "response_time": "Leakage Scan results within 5 business days of complete intake", "data_handling": "Per-client isolation, least-privilege access, encrypted storage, consumer PII minimized at ingestion" }, "hook": "Your delivery platforms have a 14-day expiration date on money that's rightfully yours.", "sub_headline": "Grant portal access and a POS export. Get back a weekly Leakage Report, filed disputes, reconciled payouts, and a monthly Recovered-Dollars Statement — never a tool to operate.", "dream_outcome": "Every legitimately disputable delivery dollar — filed, won, reconciled, and accounted for.", "specific_pains": [ "An order-error charge you never disputed becomes permanent after DoorDash's 14-day window closes", "Uber Eats charges you for a refund even when the customer reported it more than 96 hours late — a rule most operators never check", "LA County sued Grubhub in Feb 2024 over charging restaurants for refunds without verification", "Your delivery net deposit never quite matches what your POS says you sold", "No one on staff has dispute-filing as their actual job" ], "cost_of_inaction": "A 20-location group loses roughly $60,000/year in disputable-but-unfiled charges at the industry-average 2.5-3% of delivery revenue rate — and the McDonald's franchisee cited in trade press contesting $500/location/month shows six-figure losses are not hypothetical.", "mechanism": { "name": "The Detect, Dispute & Reconcile Cycle", "steps": [ { "title": "Detect", "body": "Every order and deduction ingested nightly across connected platforms, matched to your POS record." }, { "title": "Draft", "body": "Every eligible Error Charge drafted into a Dispute with cited evidence, per the platform's required format." }, { "title": "Review & File", "body": "A Recovery Analyst reviews and submits every batch through your named portal role, inside the Dispute Window." }, { "title": "Reconcile", "body": "Every week, POS is certified against payout, and every variance over $200 is investigated." }, { "title": "Report", "body": "A tie-out-checked Leakage Report and, monthly, a Recovered-Dollars Statement — assembled continuously, delivered on schedule." } ] }, "offer_stack": [ { "item": "Weekly Leakage Report", "note": "disputes filed, recovered, and pending, by location, with Win Rate" }, { "item": "Every eligible dispute filed", "note": "inside the deadline, with cited evidence, Recovery Analyst-reviewed" }, { "item": "Weekly Payout Reconciliation", "note": "POS-to-payout certified, variances investigated" }, { "item": "Monthly Recovered-Dollars Statement", "note": "the invoice basis, tie-out checked" }, { "item": "Store/item error heat map", "note": "for your ops team to act on" } ], "guarantee": "No recovery, no fee — every billing period, not just the pilot.", "urgency": "The founding pilot cohort is capped at 8 restaurant groups — not artificial scarcity, an operational limit while we hand-hold the first weekly cycles.", "objections": [ { "q": "Our GMs already handle disputes.", "a": "Ask who's watching the 14-day countdown on every DoorDash charge this week — that gap is what the desk closes." }, { "q": "We can't afford another vendor.", "a": "There's no fee unless we recover money — the free Leakage Scan shows your own number first." }, { "q": "Is this even allowed?", "a": "Filing a dispute is a contractual right under your own merchant agreement; we operate only through platform-supported named roles." }, { "q": "What if we've never filed a single dispute?", "a": "That's the typical starting point for our pilot cohort — the Scan shows exactly what's still recoverable today." } ], "who_this_is_not_for": [ "Single-location independents — the retainer minimum doesn't clear value at that scale yet", "Operators with under 10% delivery mix — the recovery pool is too small to clear pilot qualification", "Anyone wanting a self-serve dashboard to operate themselves — this is a done-for-you desk, not software", "Anyone needing legal advice on a platform dispute, tax advice, or an accounting opinion — those are licensed-professional functions we refer out, never perform" ], "proof_pillars": [ { "title": "Cited, not claimed", "body": "Every stat on this page cites a named, dated source (Restaurant Business, DoorDash/Uber Eats merchant policy) — never an invented statistic." }, { "title": "Analyst-reviewed, always", "body": "No dispute ships to a platform without a named Recovery Analyst's evidence-sufficiency sign-off." }, { "title": "Honest about what's new", "body": "This is a new practice opening its founding pilot cohort — pilot-cohort results will appear here as real cycles complete, not before." } ], "stakes_line": "Every day an error charge sits unfiled is a day closer to its deadline — and most operators simply absorb the loss until someone adds it up.", "deliverable": "A weekly Leakage Report, filed disputes, a reconciled payout, and a monthly Recovered-Dollars Statement.", "unit_of_work": "one Dispute — a single filed, evidenced contest of one platform Error Charge", "lexicon": { "regulator": "Platform merchant support", "regulator_full": "DoorDash, Uber Eats, and Grubhub merchant support/dispute-resolution teams", "statute": "Platform Merchant Policy", "statute_frame": "cited by platform and current policy page, e.g. 'DoorDash Merchant Help Center — Order Error Adjustments'", "persona": "Owner / CFO / Controller", "persona_moment": "an error-charge line grows, or a payout doesn't match POS", "trigger_moment": "an Error Charge crosses day 11 of DoorDash's 14-day Dispute Window with no action taken", "enforcement_stakes": "the charge becomes permanent and the money is forfeited — no appeal, no second chance for that charge", "retention": "renewal driven by the recovered-dollars track record and the reconciliation retainer's stickiness", "cta_verb": "Get your Scan", "intake_checklist": [ "Named-role DoorDash Merchant Portal access", "Named-role Uber Eats/Grubhub access (if available)", "POS export (Toast/Square/Olo/CSV)", "Location roster", "Promo/marketing calendar", "Signed service agreement + DPA" ], "regulator_faqs": [ { "q": "Does LeakLedger ever hold our platform login credentials?", "a": "No — we never collect, store, or request a shared password. We work from named-user staff roles that each platform's merchant portal supports natively." }, { "q": "What happens if a platform disputes our dispute?", "a": "A Recovery Analyst manages the follow-up; if it escalates toward formal legal action, we hand your counsel a complete, cited file and step back from legal advocacy." } ], "trust_standards_specific": [ "[PLACEHOLDER] owner to complete" ] }, "proof_angle": { "id": "leakage-scan-teardown", "headline": "One 20-location group's Leakage Scan will show its real forfeited-vs-recoverable number", "lever": "Anonymized diagnostic teardown", "outcome_verb": "quantified", "outcome_frame": "dollars at risk by cause, Dispute Window exposure map, unreconciled payout list", "proof_promise": "Every number in your own Scan traces to your own statements and POS export — no aggregate industry statistic stands in for your group's actual exposure." }, "indexable": false, "ubiquitousLanguage": { "audience": "Owner / CFO / Controller", "domain": "Restaurant delivery-margin recovery", "deliverable": "Leakage Report", "reviewer": "Recovery Analyst", "record": "Dispute", "unit_of_work": "Dispute", "cta_primary": "Get your free Delivery Leakage Scan", "cta_secondary": "View the full operating blueprint dossier", "regulator": "Platform merchant support", "regulator_full": "DoorDash / Uber Eats / Grubhub merchant support", "statute": "Platform Merchant Policy (DoorDash / Uber Eats / Grubhub)", "trigger_moment": "an Error Charge ages toward its Dispute Window deadline", "event_intake_started": "domain.diagnostic_requested", "event_conversation_requested": "ui.cta_primary" } }, "evidence": [ { "id": "restaurant-delivery-dispute-payout-recovery-desk-ev1", "business_slug": "restaurant-delivery-dispute-payout-recovery-desk", "area": "market", "claim_or_finding": "2.5-3% of operator revenue is caught up in disputes with delivery providers (~20% of delivery profit)", "status": "verified", "evidence": "Restaurant Business — Restaurants say they're bearing the brunt of delivery chargebacks (2025)", "verification_command": "WebFetch restaurantbusinessonline.com delivery chargebacks article", "fix_owner": "content", "remediation": "n/a — verified", "severity": "info" }, { "id": "restaurant-delivery-dispute-payout-recovery-desk-ev2", "business_slug": "restaurant-delivery-dispute-payout-recovery-desk", "area": "pain", "claim_or_finding": "DoorDash merchant dispute window is 14 days from delivery; error charges are 25-100% of item price + tax", "status": "verified, re-checked 2026-07-13", "evidence": "DoorDash Merchant Help Center — What are order error adjustments?", "verification_command": "WebFetch help.doordash.com order-error-adjustments article", "fix_owner": "content", "remediation": "n/a — matches blueprint claim exactly on re-check", "severity": "info" }, { "id": "restaurant-delivery-dispute-payout-recovery-desk-ev3", "business_slug": "restaurant-delivery-dispute-payout-recovery-desk", "area": "pain", "claim_or_finding": "Uber Eats merchant dispute window is 30 days from order date; charges reported by a customer more than 96 hours after the order are not merchant-charged", "status": "verified, re-checked 2026-07-13", "evidence": "Uber Eats — Order Errors (merchant policy)", "verification_command": "WebFetch merchants.ubereats.com/us/en/order-errors", "fix_owner": "content", "remediation": "n/a — matches blueprint claim exactly on re-check", "severity": "info" }, { "id": "restaurant-delivery-dispute-payout-recovery-desk-ev4", "business_slug": "restaurant-delivery-dispute-payout-recovery-desk", "area": "regulatory", "claim_or_finding": "LA County sued Grubhub (Feb 2024) alleging it charged restaurants for customer refunds without verification; case status re-checked", "status": "verified, no public settlement/ruling found on 2026-07-13 re-check", "evidence": "County of Los Angeles Office of County Counsel; Restaurant Business coverage", "verification_command": "WebFetch restaurantbusinessonline.com LA County Grubhub lawsuit article", "fix_owner": "content", "remediation": "Re-check case status quarterly; update if a ruling or settlement is reported", "severity": "low" }, { "id": "restaurant-delivery-dispute-payout-recovery-desk-ev5", "business_slug": "restaurant-delivery-dispute-payout-recovery-desk", "area": "budget", "claim_or_finding": "Loop AI raised a $14M Series A in Feb 2026 (following a $6M seed in 2024), serving 300+ brands — category budget proof", "status": "verified, re-checked 2026-07-13", "evidence": "PYMNTS — Loop AI raises $14 million Series A (Feb 2026); Restaurant Technology News", "verification_command": "WebSearch 'Loop AI restaurant delivery reconciliation Series A 2026'", "fix_owner": "content", "remediation": "n/a — verified current", "severity": "info" }, { "id": "restaurant-delivery-dispute-payout-recovery-desk-ev6", "business_slug": "restaurant-delivery-dispute-payout-recovery-desk", "area": "budget", "claim_or_finding": "Voosh publishes a named case study: $108,561 recovered for an 80-location Wendy's franchisee in 6 months", "status": "verified as vendor-published (not independently audited)", "evidence": "Voosh.ai success-story page", "verification_command": "WebSearch 'Voosh delivery dispute recovery pricing restaurant operators'", "fix_owner": "content", "remediation": "Labeled Inferred in claim table — vendor-published, not independently audited", "severity": "low" }, { "id": "restaurant-delivery-dispute-payout-recovery-desk-ev7", "business_slug": "restaurant-delivery-dispute-payout-recovery-desk", "area": "economics", "claim_or_finding": "~25,000-40,000 US restaurant groups of 5-75 locations; average recoverable leakage $30-60K/group/yr (derived estimate)", "status": "inferred, not independently sourced", "evidence": "Derived from US restaurant location counts (Orbital, 2025) and delivery-mix/dispute-rate industry stats", "verification_command": "Manual derivation check against Orbital and DoorDash market-share figures", "fix_owner": "content", "remediation": "Marked Inferred in business-plan.md and financial-model.csv; not relied on for the go/no-go decision", "severity": "low" }, { "id": "restaurant-delivery-dispute-payout-recovery-desk-ev8", "business_slug": "restaurant-delivery-dispute-payout-recovery-desk", "area": "pilot-hypothesis", "claim_or_finding": "A done-for-you desk can sustain a >=55% dispute Win Rate at scale (floor 40%)", "status": "unverified — pilot hypothesis", "evidence": "Anecdotal ~60% win-rate citation from a systematic disputer in Restaurant Business trade press", "verification_command": "n/a — to be measured in the 8-group pilot cohort per launch-plan.md", "fix_owner": "product", "remediation": "Tracked weekly from pilot 1; pilot pricing is pure contingency so downside is capped even if this assumption fails", "severity": "medium" } ], "seo_pages": { "id": "seo-restaurant-delivery-dispute-payout-recovery-desk", "business_slug": "restaurant-delivery-dispute-payout-recovery-desk", "route": "/restaurant-delivery-dispute-payout-recovery-desk", "title": "LeakLedger — restaurant delivery dispute & payout recovery desk", "description": "LeakLedger for 5-75 location restaurant groups on DoorDash, Uber Eats, and Grubhub. Every eligible error-charge dispute filed inside the deadline, every payout reconciled — priced from what we recover, never hourly, starting with a free Leakage Scan.", "canonical": "/restaurant-delivery-dispute-payout-recovery-desk", "og_title": "LeakLedger — Restaurant Delivery Dispute & Payout Recovery Desk", "og_description": "LeakLedger for 5-75 location restaurant groups on DoorDash, Uber Eats, and Grubhub. Every eligible error-charge dispute filed inside the deadline, every payout reconciled — priced from what we recover, never hourly, starting with a free Leakage Scan.", "schema_type": "FAQPage", "schema_status": "pending-owner-facts", "sitemap_include": false, "noindex": true }, "vertical_style": { "accent": "recovery-terracotta", "signature": "Dispute Window countdown chip with a days-remaining count on every dispute-status element", "layout": "Delivery-margin recovery desk index", "anti": "Fintech alarm-red urgency banners, stock delivery-bag/food-photo imagery, and generic SaaS gradient heroes" }, "canva": { "slug": "restaurant-delivery-dispute-payout-recovery-desk", "territory": "Recovery Ledger", "family": { "id": "recovery-ledger-v1", "name": "Recovery Ledger", "motion": "minimal, functional only" }, "tokens": { "brand": "147 15% 14%", "brand-fg": "38 44% 96%", "surface": "38 44% 96%", "ink": "60 6% 10%", "muted": "38 11% 34%", "accent": "16 61% 47%" }, "type": { "display": "system-ui, -apple-system, 'Segoe UI', sans-serif", "body": "system-ui, -apple-system, 'Segoe UI', Roboto, Helvetica, Arial, sans-serif", "fonts_url": "none — system font stack only, no external font requests" }, "scale": { "h1": "44px/1.18", "h2": "30px/1.2", "h3": "18px/1.3", "body": "16px/1.55", "small": "13.5px/1.5", "tracking_display": "-0.01em", "tracking_body": "0", "weight_display": 800, "weight_body": 400 }, "spacing": { "card_padding": "18-24px", "card_radius": "12px", "card_shadow": "0 8px 24px rgba(31,42,36,.08)", "section_gap": "56px", "hero_gap": "40px" }, "layout": { "hero": "left-aligned copy, right-aligned Delivery Leakage Scan request card", "card": "bordered, low-shadow, ledger-style", "cta": "solid accent button, high contrast text", "archetype": "margin recovery desk", "card_silhouette": "rectangular with a 12px radius, thin border, no heavy shadow", "button_geometry": "rectangular with an 8px radius, no pill shapes" }, "background": { "hero_gradient": "none — flat surface-emphasis wash", "cta_gradient": "none — flat accent surface", "section_wash": "alternating surface / surface-raised bands" }, "motif": "Dispute Window countdown chip motif with a status dot per platform" }, "capabilities": { "marketing": true, "portal": false, "ops": true, "chatbot": false, "payments": false }, "ddd_coverage": { "slug": "restaurant-delivery-dispute-payout-recovery-desk", "total": 16, "passed": 16, "pct": 100, "checks": [ { "key": "subdomains", "label": "Subdomains identified", "count": 5, "min": 3, "ok": true, "gate": "domain-modeling", "unblock": "n/a" }, { "key": "bounded_contexts", "label": "Bounded contexts defined", "count": 6, "min": 3, "ok": true, "gate": "domain-modeling", "unblock": "n/a" }, { "key": "aggregates", "label": "Aggregates named", "count": 6, "min": 3, "ok": true, "gate": "domain-modeling", "unblock": "n/a" }, { "key": "domain_events", "label": "Domain events named", "count": 10, "min": 4, "ok": true, "gate": "domain-modeling", "unblock": "n/a" }, { "key": "commands", "label": "Commands named", "count": 7, "min": 4, "ok": true, "gate": "domain-modeling", "unblock": "n/a" }, { "key": "policies", "label": "Policies defined", "count": 4, "min": 2, "ok": true, "gate": "domain-modeling", "unblock": "n/a" }, { "key": "ai_agents", "label": "AI agents specified", "count": 5, "min": 3, "ok": true, "gate": "ai-governance", "unblock": "n/a" }, { "key": "invariants", "label": "Invariants enforced", "count": 5, "min": 3, "ok": true, "gate": "domain-modeling", "unblock": "n/a" }, { "key": "risk_register", "label": "Risk register entries", "count": 5, "min": 3, "ok": true, "gate": "risk", "unblock": "n/a" }, { "key": "adrs", "label": "ADRs recorded", "count": 2, "min": 1, "ok": true, "gate": "architecture", "unblock": "n/a" }, { "key": "use_cases", "label": "Use cases documented", "count": 2, "min": 2, "ok": true, "gate": "domain-modeling", "unblock": "n/a" }, { "key": "human_roles", "label": "Human roles defined", "count": 2, "min": 2, "ok": true, "gate": "ai-governance", "unblock": "n/a" }, { "key": "human_review_checkpoints", "label": "Human review checkpoints", "count": 4, "min": 2, "ok": true, "gate": "ai-governance", "unblock": "n/a" }, { "key": "data_objects", "label": "Data objects owned", "count": 3, "min": 2, "ok": true, "gate": "data", "unblock": "n/a" }, { "key": "external_integrations", "label": "External integrations mapped", "count": 5, "min": 2, "ok": true, "gate": "architecture", "unblock": "n/a" }, { "key": "security_controls", "label": "Security controls specified", "count": 3, "min": 2, "ok": true, "gate": "security", "unblock": "n/a" } ], "failingGates": [] }, "generated_at": "2026-07-13T12:52:11Z", "checksum": "sha256:1cab693da1534108714f662c9b5fdfb9e5a00b76050c1adc79e416ecbbc481d4" }