Collective agreements encoded, not interpreted

Collective agreements: a dense and variable framework

In regulated industries, workforce scheduling is not governed by labour law alone. Collective bargaining agreements (CBAs) layer sector-specific and company-specific rules on top of the legal baseline. Healthcare, security, transport, aviation, logistics: each sector has its own agreement, often negotiated at the national or regional level, sometimes supplemented by internal company accords.

These agreements define rules that go well beyond what generic labour law requires. They specify additional rest periods between shifts, stricter limits on weekly or monthly working hours, premium pay triggers for night work or weekends, and specific entitlements such as guaranteed consecutive days off or restrictions on how many weekends an employee can work per month.

The challenge for scheduling is that these rules vary significantly from one agreement to another. A security company and a hospital may both operate 24/7, but the CBA rules governing shift transitions, night work, and weekend entitlements will differ in detail. Even within the same sector, two companies may operate under different agreements depending on their size, region, or historical negotiations.

For the person building the monthly roster, this means carrying a dense rulebook in their head and applying it correctly to every employee, every day, for the entire planning period. The margin for error is not a question of competence. It is a question of volume.

What the CBA imposes on the roster

Collective agreements translate into concrete scheduling constraints that affect every assignment decision. Understanding what they require in practice is essential before discussing how to automate them.

The most common CBA-driven constraints include:

• Minimum rest between consecutive shifts, sometimes 12 hours rather than the statutory 11, with further extensions after night shifts
• Maximum number of weekends worked per month, typically one or two, with guaranteed full weekends off for the remainder
• Monthly hour caps that vary by contract type, with part-time and student contracts carrying lower ceilings than permanent staff
• Entitlement to consecutive rest days, where the agreement may require at least two consecutive days off per scheduling period rather than allowing isolated single days
• Night shift restrictions for certain employee categories, such as workers over a certain age, pregnant employees, or staff returning from extended leave
• Limits on consecutive working days, often stricter than the legal maximum, particularly in safety-sensitive roles

Each of these rules interacts with the others. A planner cannot evaluate rest periods in isolation from weekend entitlements, or monthly hour caps independently from night shift restrictions. The rules form an interconnected web, and satisfying all of them simultaneously for 50, 100, or 200 employees over a full month is where manual processes consistently struggle.

Encoding rules without touching the code

A constraint programming solver provides a natural framework for encoding CBA rules. The distinction between hard constraints and soft objectives maps directly onto the structure of most collective agreements.

Hard constraints represent rules that cannot be violated under any circumstances. Rest periods, qualification requirements, hour caps, and absence protections fall into this category. If a CBA mandates 12 hours of rest between shifts, the solver treats this as an absolute boundary. No solution that violates it will be produced.

Soft objectives represent preferences that the solver pursues as far as possible while respecting all hard constraints. Fairness in shift distribution, weekend balance across employees, and avoidance of isolated rest days are typically modelled as weighted penalties. The solver minimises the total penalty score, finding the best achievable balance.

The critical design principle is that the operations manager or planner configures these rules, not a developer. The constraints are defined in a configuration layer: rest period durations, hour limits by contract type, weekend entitlements, and penalty weights for each objective. When the CBA changes, the configuration changes. The solver code itself does not need modification.

This separation between rules and engine is what makes the system maintainable over time. A new CBA clause about rest after night shifts becomes a configuration update, not a software development project.

Contract types and differentiated rules

Collective agreements rarely apply uniformly to all employees. Permanent staff, temporary workers, part-time employees, and student contracts each carry different rights and restrictions. The CBA typically specifies distinct rules for each category.

In practice, this means the solver applies different constraint sets depending on contract type:

• Permanent employees may have a monthly hour target of 160 to 180 hours, with guaranteed weekends off and full night shift eligibility
• Part-time staff have proportionally reduced hour caps, and the agreement may restrict them from certain shift types or time slots
• Student contracts typically carry the lowest monthly hour ceilings, often with additional restrictions on night work and weekend assignments
• Temporary workers may have different weekend entitlements and may be excluded from certain equity calculations, depending on the agreement

The solver handles this by associating each employee with a contract type and applying the corresponding constraint profile automatically. The planner does not need to remember which rules apply to which category. The configuration encodes it once, and the solver enforces it for every run.

When a new contract type is introduced, or when the CBA redefines the rules for an existing type, the adjustment is made in the configuration. The next solver run applies the updated rules across all affected employees without requiring the planner to manually verify each assignment.

Rest periods, night work and premium tracking

Rest period enforcement is one of the areas where collective agreements most frequently exceed statutory requirements. The legal minimum between shifts may be 11 hours, but the CBA might require 12 hours as standard and 14 hours after a night shift. These reinforced rest constraints are critical for compliance and for employee wellbeing in demanding operational environments.

The solver models rest periods by analysing shift-pair transitions. For each pair of consecutive shifts that an employee might work, the system calculates whether the gap between the end of one shift and the start of the next meets the required minimum. Shift pairs that violate the rest requirement are identified and blocked. This approach handles complex cases such as late-evening shifts followed by early-morning assignments, which are the most common source of rest period violations in manual schedules.

Night work restrictions add another layer. The CBA may limit the number of consecutive night shifts, require extended rest after a night block, or exclude certain employee categories from night assignments entirely. These rules are modelled as hard constraints, ensuring that the solver never produces a schedule that violates them.

Beyond constraint enforcement, the solver output provides the data needed for premium calculations. Night hours, Sunday hours, and public holiday assignments are tracked per employee. While the solver does not calculate payroll directly, it produces structured assignment data that payroll systems or export tools can use to determine premium entitlements accurately. This eliminates the manual step of reviewing the schedule to identify which hours qualify for which premium rate.

Traceability and proof of compliance

A schedule generated by a constraint solver is not just a roster. It is documented proof that CBA rules were respected for every employee on every day of the planning period.

Every assignment can be traced back to the constraints that governed it. If an employee was assigned a specific shift, it means all hard constraints were satisfied for that assignment: rest periods, qualifications, hour caps, and any employee-specific restrictions. If an employee was not assigned to a shift they are qualified for, the reason is identifiable: a rest conflict, an hour limit, a blocked day, or a fairness rebalancing.

This traceability has practical value in several contexts:

• Labour inspections can be answered with a precise account of how the schedule was produced, which rules were applied, and how conflicts were resolved
• Internal audits can verify that CBA compliance is structural rather than dependent on individual planner judgment
• Employee disputes about fairness or assignment patterns can be addressed with objective data rather than subjective justification
• In the event of an incident in a safety-sensitive environment, the schedule demonstrates that rest periods and workload limits were respected

The solver run report documents the optimisation score, the trade-offs that were made between competing objectives, and any coverage gaps that could not be filled within the constraint framework. This creates an auditable record that manual scheduling processes cannot provide.

When the agreement changes

Collective bargaining agreements are renegotiated periodically. New clauses are added, thresholds are adjusted, and entitlements evolve. For operations that rely on manual scheduling, each change introduces a transition period during which the planner must remember and apply the new rules while potentially phasing out the old ones. This is a common source of compliance gaps.

With a solver-based approach, adapting to a new agreement is a configuration update. If the minimum rest period increases from 11 to 12 hours, the value is changed in the constraint configuration. If a new contract type is created with specific weekend entitlements, its constraint profile is defined and associated with the relevant employees. If night shift rules are tightened for a specific category, the corresponding parameter is updated.

The next solver run applies the new rules across the entire workforce, for every day of the planning period, without risk of partial application or oversight. There is no transition period during which some employees are scheduled under old rules and others under new ones. The change is atomic: once the configuration is updated, every subsequent schedule is fully compliant with the new agreement.

This responsiveness is particularly valuable in industries where agreements are renegotiated frequently or where interim amendments are common. The operational team does not need to overhaul their scheduling process. They update the rules, run the solver, and review the output. The structural compliance guarantee holds regardless of how often the rules change.