1
Variable Rules
Break requirements may depend on shift length, consecutive work, employee scope, or employer policy.
How a simple break generation and placement feature evolved into a configurable scheduling rules engine capable of generating and validating employee breaks while respecting dynamic legal windows.
Break requirements can depend on shift duration, uninterrupted work time, employee attributes, employer policies, and whether one type of break can satisfy another requirement.
For Week at Work, the break scheduling system was designed around a core separation: what the rules require should remain independent from how the schedule chooses to satisfy those requirements.
The resulting architecture can determine required breaks, calculate ideal placement, validate manually adjusted schedules, and prepare valid schedules for optimization across an entire day's workforce.
Separate the legal or policy obligation from the scheduling decision used to satisfy it.
A reliable break system has to understand both the breaks themselves and the periods of uninterrupted work created between them.
Break requirements may depend on shift length, consecutive work, employee scope, or employer policy.
Longer shifts may require multiple meals or recurring rest-break obligations.
A meal may satisfy a rest requirement in some circumstances without universally eliminating the rest.
Managers may move scheduled breaks after generation, potentially invalidating the original schedule.
Legal placement windows can shift after qualifying breaks interrupt consecutive periods of work.
Individually valid break schedules can still create poor staffing coverage if too many employees break simultaneously.
The algorithm first determines the obligations generated by the rules, then progressively converts those obligations into scheduled breaks.
Each stage answers a different question, reducing the complexity that would result from trying to generate persisted ShiftBreak records directly from raw rules.
The engine supports different trigger models so labor requirements can evolve independently of the scheduling algorithm.
Requirements based on the total duration of an employee's scheduled shift.
Requirements based on the amount of uninterrupted work performed since a qualifying break.
Consecutive-work rules behave fundamentally differently because the work timeline changes whenever a qualifying break occurs.
Intermediate models allow each stage of the scheduling algorithm to represent exactly the information it needs.
A required break can carry details such as break type, duration, paid status, trigger offsets, legal-window constraints, substitution behavior, and whether the underlying rule operates as a rolling window.
Scheduling-only concepts remain in the scheduling domain instead of becoming unnecessary persistent database state.
Rather than committing immediately to a start time, the system first calculates a legal range and an ideal target inside that range.
If the preferred time is unavailable, the placement algorithm can search nearby candidates—such as five minutes earlier or later—while remaining inside the allowable window.
A meal overlapping a rest window does not automatically mean the rest can safely disappear.
A naive implementation might remove a rest whenever a meal occurs inside the same window. That can create another excessively long period of uninterrupted work later in the shift.
The more useful abstraction is to treat rest rules as obligations requiring a work period to be interrupted by a qualifying break.
Suppression is not fundamentally about deleting a break. It is about determining whether another break satisfies the obligation created by the rule.
The validator reconstructs the shift as alternating periods of work and qualifying breaks, then evaluates each resulting work segment.
An employee can have the correct number of meals and rest breaks while still violating a consecutive-work rule.
Static windows anchored only to shift start become insufficient once qualifying breaks can reset the consecutive-work clock.
Dynamic windows provide one shared concept that can support scheduling, validation, optimization, and UI explanations.
Managers need the ability to move breaks for operational reasons without the scheduling engine silently destroying intentional changes.
Breaks initially created by the rules engine.
Previously scheduled breaks that participate in future validation and recalculation.
Manager-selected break positions that should be preserved whenever possible.
Historical schedule state that cannot simply be regenerated away.
Human scheduling decisions and automated compliance validation should complement each other rather than compete for ownership of the schedule.
Determines which breaks an employee requires and where those breaks should initially be placed.
Determines whether the resulting schedule continues to satisfy all applicable rules.
The scheduling algorithms live in application services instead of being embedded directly inside commands and query handlers.
This makes the scheduler and validator independently testable while allowing the same services to participate in schedule creation, shift editing, previews, and automated optimization workflows.
Represent triggers, scope, duration, recurrence, and substitution behavior as data instead of hard-coded scheduling logic.
A generated schedule may be valid initially but must still be independently validated after later changes.
Compliance depends on when breaks occur, not merely how many breaks appear on the schedule.
RequiredBreak, IdealBreak, LegalWindow, and WorkSegment each represent a distinct scheduling concern.
Existing and manually adjusted breaks should participate in future validation rather than simply being regenerated.
The final architecture separates legal requirements, scheduling decisions, validation, and operational optimization so each concern can evolve independently.
The most important architectural decision was separating what is required, where it should be scheduled, and whether it remains valid.
See additional system design, software architecture, and product development projects.