A Schedule Is a Versioned Commitment

1. Feasibility and commitment are different problems

A schedule allocates people to work, but also communicates what those people and their managers may rely on. A draft can change freely while it is being explored. A published schedule creates expectations about attendance, coverage, travel, and personal time. Treating both as the same mutable calendar makes it difficult to explain which version was agreed.

For LunchLineup, the central design question is how to preserve that commitment while still allowing necessary changes. The proposed answer is a versioned schedule with explicit transitions from draft to published, and from a published revision to an amended revision. The feasibility checks apply to the whole affected assignment set, not merely to the row an editor changed.

This paper develops that model from scheduling requirements. It does not assert that LunchLineup already implements the proposed optimizer, approval process, or acknowledgment behavior.

2. Define hard constraints before preferences

A hard constraint defines whether an assignment is allowed. Examples include overlapping shifts for the same person, missing required skills, and assignments outside declared availability. A soft objective expresses a preference among feasible alternatives, such as reducing split shifts or distributing undesirable hours more evenly.

The distinction belongs in the data and explanation. If a weighted objective can trade away a required skill to reduce a preference penalty, the system has modeled the requirement incorrectly. A hard constraint can be relaxed only through an explicit policy decision that changes what counts as feasible.

A useful planning order is to establish time and role requirements, identify eligible people, check whether coverage is possible, and then improve preferences. When no feasible assignment exists, the product should report the specific unresolved requirement. Returning an apparently complete schedule with hidden violations moves the planning failure into operations.

3. Worked example: two swaps remove one qualification

Consider a synthetic shift that requires two people, at least one of whom holds a designated qualification. The published schedule assigns Alex, who holds the qualification, and Blair, who does not. Alex requests a swap with Casey, who also lacks it. A second editor is considering a different adjustment to Blair's assignment.

If the application evaluates Alex's replacement only as an available person, it may accept the swap and leave the shift without the required qualification. If two editors both reason from the earlier schedule, each may assume the other assignment still provides coverage. The invariant belongs to the resulting shift, not to either swap request in isolation.

The third row is not automatically an approved schedule. Availability, overlap, assignment authority, and other applicable constraints still need evaluation. A focused reason such as “required qualification missing” helps the scheduler repair the proposal without implying that fixing one condition proves every other condition.

4. Publish an immutable revision

A publication transition should identify the full schedule revision being released. Later edits create an amendment rather than silently modifying the previous commitment. A request to accept a swap includes the base revision it was evaluated against; if the relevant assignments changed, the application reevaluates the request.

1. 1. DraftExplore assignments and constraints.
2. 2. ValidateCheck the resulting schedule.
3. 3. PublishRelease an identified revision.
4. 4. AmendExplain and communicate the change.

Publication, notification delivery, and worker acknowledgment are separate states. Sending a message does not establish that it was read, and reading it does not necessarily mean accepting a proposed change. The product must define which transitions require acknowledgment and how unresolved changes are handled.

Notifications should identify the change and applicable revision. A delayed message about an older amendment must not replace a newer schedule on the recipient's device. The authoritative view should make the current published revision discoverable even when message delivery is incomplete.

5. Time must survive the calendar boundary

A schedule needs both local civil-time meaning and an unambiguous interval for conflict calculations. Repeating “Monday at nine” in a named time zone is not the same as repeating a fixed number of seconds after the previous occurrence. Daylight-saving transitions can create missing or repeated local times.

The iCalendar specification defines date-time forms, time-zone identifiers, and recurrence representations. Those definitions are relevant to exporting schedule events, but they do not determine an application's policy for ambiguous shifts. [1] The proposed design records the intended zone and resolves each occurrence explicitly before publication.

A worker viewing the schedule from another zone should be able to identify which local time governs attendance. Changing a profile's display zone should not silently move the underlying shift. Tests must include overnight work, cross-zone viewing, and both directions of daylight-saving transitions where applicable.

6. Repair strategy and evaluation

Manual editing gives schedulers direct control and can work well for small teams. Its cost is repeated reasoning about interactions that are easy to overlook. Full optimization can explore many alternatives, but may create widespread changes when only one assignment needs repair.

Bounded repair searches within an explicit affected region, such as the changed shift and eligible replacements, while preserving other published commitments where possible. It trades global optimality for stability. A repair that cannot satisfy the hard constraints should return the remaining conflict rather than expanding the scope silently.

Evaluate feasibility separately from preference quality. For each test schedule, record which constraints apply and verify the final assignment set. Then compare preference outcomes against a declared baseline. Counting filled shifts alone would reward a schedule that fills positions with ineligible people.

Useful cases include overlapping edits, repeated swap submissions, a qualification expiring before a future shift, unavailable notification delivery, and a draft based on stale availability. An amendment should preserve history and expose who still needs to be informed. None of these tests, on their own, establishes that a scheduling policy is fair or legally appropriate.

7. Conclusion and limits

A dependable schedule is both feasible and identifiable. Separating draft exploration from published commitment makes it possible to reason about concurrent swaps, communicate changes accurately, and preserve the context of earlier decisions.

This design leaves important policy choices open: which constraints are mandatory, how preferences are weighted, who may authorize exceptions, and when a worker's agreement is required. Those choices need organizational input and appropriate review. The technical contribution is a structure in which such decisions can be represented and tested, rather than being hidden inside calendar edits.

References

1. IETF. RFC 5545: Internet Calendaring and Scheduling Core Object Specification, 2009. Time-zone and recurrence representations discussed in Section 5.