A requirement, a preference, or a habit?

A practical way to separate what cannot move from what merely needs a conversation.

Start with the consequence

“We never play on Wednesdays” can mean three very different things: the venue is closed; the team would prefer another day; or someone remembers that last season used Tuesdays. Treating all three as absolute restrictions can make an otherwise workable season appear impossible.

For every request, record its owner, the affected dates and teams, the reason, and the consequence of breaking it. A closed venue is unavailable. A player-welfare or governing-body rule needs to be represented accurately. A preference needs an agreed priority and a clear way to report exceptions.

Give every constraint a test

“Reasonable rest” is not testable. “At least 48 hours between the end of one game and the start of the next” is. This number is an illustration, not a recommended recovery standard. Use the actual policy appropriate to your competition and participants.

Be equally precise about time zones, overtime buffers, shared facilities, and whether a restriction applies to a team, a division, or an individual. Most importantly, ask who can authorize an exception. Software cannot supply authority that the organization has not assigned.

Keep a small decision register

Use four fields: rule, scope, priority, and approver. Attach the source, such as a venue agreement or league policy. Review contradictions before generating games. If two requirements conflict, return a concrete example to the owners rather than silently relaxing one.

After publication, retain the agreed rule set alongside the schedule version. That makes later changes explainable and gives next season a better starting point. The goal is not to formalize every conversation; it is to stop important decisions from disappearing into someone’s memory.