Data Model Inferred

So what: WeCourts's domain model is bigger and more padel-specific than OpenRally's v0.5 schema, and centers around a canonical WPPR Player identity that links a person to every match in their history regardless of which organizer ran it. The model is similar to OpenRally's at the Tournament/Match/Team layer but adds Organizer tier, Club facilities catalogue, Community, Rating cycle + projection, Magic link, Incident log, and WPPR submission queue as first-class entities.

This is inferred from the rendered public surface, Featurebase changelog notes, network observations, and event-page URL patterns — not from a database dump. Each table notes its evidence source.

Core entities

Player

Inferred from: 02-wppr.text.txt (Players Hub), 13/29-event-*.text.txt (event cards), 43-may-grand-clash.text.txt (LFP cards), 34-featurebase-changelog.text.txt Mar 13 entry.

Open questions: Are there merge / canonical-pointer rows for duplicate profiles? Featurebase complaints suggest no clean merge — duplicates exist as separate rows and users can't resolve.

Tournament

Inferred from: 13-sample-event.text.txt (/e/ZE7A), 29-event-5GLP.text.txt (Groups + KO), 45-americano-event.text.txt (/t/33F8), 43-may-grand-clash.text.txt (drawer).

Team (Registration)

Inferred from: event detail pages with team rows, "Looking-for-Partner" cards, 34-featurebase-changelog.text.txt Apr 30.

Match

Inferred from: bracket pages and "Recent Results" cards.

Club / Venue

Inferred from: 20-club-detail.text.txt (ISD Padel), 47-padel-art-club.text.txt.

Schema observation: Same UUID-keyed Club entity serves both clubs AND federations AND academies — Jordan Tennis Federation has a club page at /clubs/2b0e3630-1d4b-.... There is likely a club_type enum: padel_court / academy / federation / event_organizer_only_no_courts.

Organizer

Inferred from: 04-organizers.text.txt, footers on event pages ("BY Padel Sphere — Bati Varfi"), Featurebase changelog ("Trusted organizers skip approval...").

OrganizerMember (RBAC for Collaboration Accounts)

Inferred from: Featurebase "Collaboration Accounts" (Completed).

Community (WhatsApp-curated)

Inferred from: 09-communities.text.txt.

LFP_Listing (Looking-for-Partner)

Inferred from: 43-may-grand-clash.text.txt LFP block.

WPPRSubmission (drop-in / linked-tournament)

Inferred from: 07-drop-in.text.txt, 34-featurebase-changelog.text.txt Apr 30 ("Resubmit Results", waiver mechanism).

RatingCycle / RatingProjection

Inferred from: 34-featurebase-changelog.text.txt May 13 entry "Rating Progression — your WPPR journey, fully visible".

MagicLink

Inferred from: 34-featurebase-changelog.text.txt May 4 Operator Console "magic links" tab.

Incident

Inferred from: Operator Console "incidents" tab + SOS Console actions.

TournamentTVScreen (pairing)

Inferred from: 10-tv.text.txt, "OPEN PAIRING SCREEN" button.

Entity relationships

User (auth) ───── 1:N ──── OrganizerMember ──── N:1 ──── Organizer
                                                          │
                                                          1:N
                                                          ▼
                                                       Tournament ───── N:1 ──── Club
                                                          │                       │
                                                          │                      1:N
                                                          │                       ▼
                                                          │                    Court (inferred, not directly observed)
                                                          │
                                                          1:N
                                                          ▼
                                                       Team
                                                          │
                                                          1:N
                                                          ▼
                                                       Match
                                                          │
                                                          1:N (via team)
                                                          ▼
                                                 RatingImpactPerMatchPerPlayer
                                                          │
                                                          N:1
                                                          ▼
                                                       Player
                                                          │
                                                          1:N
                                                          ▼
                                                       RatingCycle

Tournament ───── 1:N ──── LFP_Listing ──── N:1 ──── Player
Tournament ───── 1:N ──── MagicLink
Tournament ───── 1:N ──── Incident
Tournament ───── 1:N ──── TournamentTVScreen
Tournament ───── 1:1 ──── WPPRSubmission (when scored)

Community ───── N:1 ──── Organizer (parent)
Community ───── M:N ──── Player (via membership)

Key schema decisions inferred (lessons for OpenRally)

1. Player is a globally canonical entity (wppr_id) — exists independent of any single tournament or organizer. This is the identity-graph moat. Players exist in the schema BEFORE they sign up — they're inserted by organizers submitting results.
2. Tournament has two route types (/e/ scored, /t/ listed) — implies a route_type field controlling whether bracket UI renders. OpenRally should consider an early "listed-only" mode to onboard organizers who don't want full scoring (smooth migration path off spreadsheets).
3. Multi-currency at the Tournament level (AED + JOD observed) — entry_fee_currency is a real column, not assumption. OpenRally's "Thailand-first" should still ship multi-currency from v0.5+.
4. Levels are an array on Tournament — ["B-", "C+", "C", "C-"] — a tournament can accept multiple WPPR categories. OpenRally's current category model is unclear (DECISIONS.md doesn't specify per-tournament level array).
5. Team Level Sum field gates entry by combined skill — "Team Level 7.7" means the two partners' WPPR scores sum ≤ 7.7. This is an anti-sandbagging mechanism baked into registration. OpenRally should design for this when v3 rating lands.
6. MGG and Direct Advance are first-class booleans tied to team counts — they're not just config in description, they're enforced at draw-time. OpenRally will need this when Groups+KO lands.
7. Disqualification has 3 outcome modes — forfeit_wins / zero_unplayed / void_all — stored on the Team or Incident, drives recompute of standings. OpenRally's current single-elim model doesn't need this yet but Groups+KO does.
8. Magic links carry granular granted_permissions JSON — auth-less shareable URLs with limited scope. OpenRally could implement this with Supabase Edge Functions + JWT signed by a per-tournament secret.
9. Rating Cycle is separate from Player — projected ratings live in a transient cycle table, published ratings live on Player. Updating-every-20-matches is the cycle close trigger.
10. The Identity graph is leaky — duplicates are a current pain. The fact that WPPR ratings can be applied to players who never signed up means duplicates compound when organizers spell names differently. OpenRally's wedge is to require canonical player identity at registration time (mobile OTP confirm) before granting ratings — keeps the graph clean from day 1.

Post-onboarding-walk additions (2026-05-22)

The Phase 3 partial walk (signup → /onboarding → /onboarding/pending-review) confirmed some inferences and added new entities. Sections below upgrade specific entities from inferred → observed.

Organizer entity — upgraded fields

The Organizer table inferred earlier now has observed columns from the onboarding /onboarding flow (screenshots/64-create-company-form.png):

NEW entity: ClubProfile (distinct from Organizer)

The onboarding split (Padel Club vs Organizer Company) confirms two separate entity types branching from the same approval queue. The Padel Club path creates a Club row directly (linking to Organizer.default_club_id), while the Organizer Company path creates a standalone Organizer record.

Confirmed from screenshots/60-onboarding-create-club.png:

Notable absence: No Logo upload in this MVP variant. Club logos come from the wider Clubs directory or the auto-tagged photos field on Club detail page (20-club-detail.text.txt shows "6 images" gallery).

NEW entity: OnboardingState

A state machine that didn't exist in my earlier data-model spec.

NEW entity: RatingCycle — upgraded with Initial Rating ("IR") status

Earlier inferred RatingCycle.is_published boolean. Confirmed from raw-html/67-rating-wppr.text.txt: - The featured player "Gonzalo Rubio" has WPPR INITIAL RATING 7.587 IR A+ Provisional with 10 matches and 90% win rate, 2 tournaments - "Provisional" is a distinct rating status before the full 20-match cycle closes - "IR" prefix on the badge ("IR A+") differentiates Initial from Published

Updated enum on Player.wppr_status: - unrated — no matches yet - ir_provisional — at least 1 match but cycle not closed (< 20 matches) - wppr — at least one full 20-match cycle published - wppr_verified — verified player (had matches verified by organizers)

NEW: BookingSystemIntegration (inferred from marketing)

Per raw-html/67-rating-wppr.text.txt: "Booking Systems — Full APIs ready. Live with booking systems like PadelOS, Epic Padel, and more."

NEW: ExternalRatingSource (inferred from "WPPR Watch")

Per raw-html/67-rating-wppr.text.txt: "WPPR Watch — Aggregating global data from FIP, Premier Padel, RankedIn, Winner App, and Tournify."

NEW: SmartCourtAICameraSource (inferred)

Per raw-html/67-rating-wppr.text.txt: "AI Camera Feeds — Tracking match results and analytics seamlessly from smart courts powered by AI-powered smart courts."

Stack confirmations (post-walk)

Updated lesson set

11. Two-persona organizer model — Club (venue-anchored) vs Organizer Company (entity-anchored, multi-venue) is a meaningful schema choice. OpenRally's current single Organizer model may need a type discriminator early.
12. Onboarding state machine deserves explicit modeling — wecourts has email_unverified → email_verified → path_chosen → entity_created → pending_review → approved/rejected as discrete states with associated UIs. OpenRally's v0.3 admin organizer-applications has Approve/Reject but the player-facing intermediate states aren't fully spec'd in DECISIONS.md.
13. Identity-graph pre-fill is a UX feature wecourts already ships — if you sign up with an email that already has a WPPR player record, your phone, name, country are pre-filled. OpenRally could mirror this once OpenRally's player graph exists (probably v3+).
14. Dedupe-search-before-create on entity creation — wecourts gets this right on Org/Club paths, gets it wrong on Player path. OpenRally should apply this pattern uniformly from day 1.
15. Two route types per tournament: /e/{code} for scored/WPPR-eligible, /t/{code} for listed-only — confirmed by walking the Americano test event (raw-html/45-americano-event.text.txt). Schema column route_type is real.
16. Approval / trust ladder is a distinct lifecycle from feature gates — wecourts pings organizers via WhatsApp on state change. OpenRally's email-only notification needs a multi-channel rewrite if we want to match this DX in SEA (where LINE / WhatsApp dominate).