When a game-day schedule breaks

Operating reality

A free field is not a safe answer.

Imagine a Saturday fixture at 09:00. The field closes shortly before play, while the published schedule is already in families’ calendars. The scheduler finds another open field. That is only the beginning of the decision.

A team might already have a second fixture. The assigned official may be unavailable. A venue rule may exclude the age group. Another operator may be editing the same schedule. A notification could be sent before the approved change is stored.

Find a permissible change, show who it affects, obtain the right approval, commit it against current state, and reconcile delivery to the people who need to know.

This scenario focuses on that transaction. It does not attempt to redesign registration, payments, standings, or every youth-sports workflow at once.

Authority before infrastructure

Which record is allowed to change?

Before choosing AWS services, identify the owner of each fact. The competition may own the published fixture, while a venue system owns field availability and an officials system owns assignment status. A synced calendar is not automatically authoritative.

If those owners disagree, the platform needs a conflict rule and an escalation owner. It cannot safely select the newest timestamp and hope it is correct. The full scheduling paper covers downstream standings, calendars, and notification projections; this worked example stays with one rescheduling decision.

Compare the approaches

Automate validity, not authority.

The base recommendation is a rules engine that rejects invalid options and gives an authorized operator the final choice. Keep manual repair available when data or automation is unavailable. Add AI explanation only if real users struggle to compare several valid options. None of these approaches makes a model the source of eligibility.

These are the boundaries we would agree with the organization before implementation. They are not universal league rules.

Authoritative state

The current schedule revision, venue status, team and official availability, and the policy version used for the decision.

Hard rules

No prohibited venue, double booking, ineligible assignment, or unapproved safeguarding exception. The organization must define its actual rules.

Preferences

Among valid options, compare disruption, travel, notice time, and organizer effort. These are ranked only after rule checks pass.

Authority

An authorized operator reviews the impact and approves or rejects a change. The model has no write permission.

A slot on the closed field is rejected immediately. Two other slots may remain candidates, but neither becomes publishable until team, official, venue, notice, and approval checks pass. The system checks the schedule revision again before committing the choice.

AI’s limited role: summarize the impact of the valid options or draft a message for review. It should not establish eligibility, invent another slot, approve an exception, or issue the write. When one simple valid option is already clear, a model call may add cost and latency without adding value.

Implementation pattern

Commit the decision once. Deliver the message reliably.

A schedule API reads a versioned snapshot. A deterministic rules service produces eligible choices. An optional explanation service sees only candidate IDs and permitted policy context. The approved command checks authorization and schedule revision before writing.

The schedule change and an outbox record commit in the same database transaction. A relay publishes the committed intent to a queue, and a worker sends notifications with retry and delivery status.

A transactional outbox avoids announcing a rolled-back change, but adds relay, retry, idempotency, and reconciliation work. Direct synchronous sending is simpler to code, yet makes provider availability part of the schedule transaction and complicates partial failure.

On a phone, follow the transaction

1. Read a versioned schedule and capture the disruption.
2. Reject conflicts and calculate feasible option IDs.
3. Optionally explain those IDs with scoped policy content.
4. Approve with a human and check the revision again.
5. Commit schedule and notification intent together, then deliver asynchronously.

Open the full system map to inspect the services and control boundaries.

Capacity and cost

The same decision does not require the same deployment everywhere.

The following are design directions, not throughput or price promises. Actual sizing needs peak-event data, notification volume, recovery targets, tenant policy, and a measured workload.

One programme

Keep a small number of services and a single transactional store. Prefer clear operational ownership over splitting every domain into its own service. Skip the model on routine changes.

Several organizations

Make organization identity explicit in authorization, records, jobs, and observability. Separate noisy notification work from the schedule write and test cross-organization access.

A large network

Plan for simultaneous disruptions, independently paced message delivery, workload isolation, and organization-aware support. Decide whether shared infrastructure still meets each tenant’s contractual and privacy needs before introducing more isolation.

The first cost lever is avoiding unnecessary work: do not call a model for deterministic checks, generate explanations only for uncertain decisions, and observe queue age and per-organization usage before adding infrastructure.

Production evidence

A clean diagram is not a passing test.

A reviewable implementation should show what the system does on the paths that make the happy-path diagram misleading.

No valid replacement

Return no publishable option and the failed constraints.

Evidence to request: An invalid candidate never appears as an approvable choice.

Model unavailable

Show rule-checked options without generated explanation.

Evidence to request: A model outage does not create a slot or block a manual decision.

Schedule changes during review

Reject the stale approval and recompute against the latest revision.

Evidence to request: Concurrent operators cannot overwrite a newer decision.

Message provider fails

Keep the committed change, retry delivery, and surface unresolved recipients.

Evidence to request: Retries neither lose nor silently duplicate notification work.

Before building, the organization must also set its actual eligibility and safeguarding rules, data-sharing limits for any model, notification timeliness target, override policy, and the person responsible for reconciliation.

Continue the review

What would you challenge next?

This is an educational reference design, not a verified client deployment. The application view adapts supplied reference material; the decision and AWS views are proposed. Implementation principles are informed by AWS transactional outbox guidance and the AWS Agentic AI Lens. Those sources do not validate this exact design.

What breaks when your workflow changes?

Bring the rules, system boundaries, and failure history. We can help turn them into a design your team can review and test.