Fall 2026 Concept Season
Game Changes
One request captures both teams, the existing match, proposed details, reason, acknowledgements, and approval.
One request captures both teams, the existing match, proposed details, reason, acknowledgements, and approval.
One approved answer
Affected parties receive the final decision and Root keeps the audit trail before the official record is updated.
What improves over the current request
The public MYSL instructions require a team to find the match, click Change Game, enter a team registration code, complete the change details, and wait for MYSL to approve or request clarification. Root keeps that necessary league control but removes the disconnected identity and duplicate-data steps.
The request begins with a known match and an authenticated actor. Original details, proposed details, responses, revisions, cut-off warnings, clash results, and the final league decision remain on one auditable record.
What each role can validate in this demo
The team-manager view demonstrates submission, opponent review, revision, and cancellation. The league-administrator view demonstrates the approval queue, required decision notes, and the final applied result. Other roles can see only the information their responsibilities require.
GotSport-aware by design
For an initial MYSL pilot, GotSport can remain the sanctioned system of record. RootSoccer supplies the clearer request, approval, notification, and audit workspace; the exact export or integration handoff is mapped with MYSL before any claim of automated synchronization.
The RootSoccer game-change request, step by step
MYSL currently sends teams from schedules and standings into a registration-code form. This concept shows the stronger RootSoccer workflow without pretending GotSport disappears on day one.
1. Start from the game
An authorized team manager or league administrator opens the actual match. Teams, season, opponent, kickoff, and venue are already attached—there is no second search or re-keying step.
2. Identity replaces shared codes
Role-based sign-in proves who is acting and which team or league they represent. Root records the actor instead of relying on a reusable team registration code.
3. Propose one complete change
The request captures the proposed kickoff, location, required reason, commentary, and extenuating circumstances while warning about league cutoffs and competition clashes.
4. Opponent responds in context
The opposing team reviews the original and proposed details, then accepts or rejects. The requester can revise or cancel without starting an untraceable email chain.
5. League makes the decision
Only the correct league role can approve or reject. Rejections require an explanation so the requester has a clear path to revise.
6. One decision reaches everyone
Approval atomically updates the game, preserves the request history, records activity, and notifies affected participants and families.