How to Manage Study Library Shifts

What a shift contains

A reliable shift record may need a stable identity, branch, display name, start and end semantics, operating days, effective dates, operational status, capacity eligibility, exceptions and audit metadata. The actual Libix fields and statuses must follow the repository and approved product documentation.

Shift, plan, allocation and attendance

Define time boundaries deliberately

Adjacent intervals can use a consistent half-open model such as [start, end), where the start is included and the end is the next boundary. The exact canonical rule should follow the Libix date/time standard. Do not create arbitrary one-minute gaps merely to hide overlap. Overlap depends on time, branch, eligible capacity and plan/zone rules—not on names alone.

Handle overnight shifts explicitly

A window such as 22:00 → 02:00 next day crosses a calendar boundary. Store and display that relationship deliberately, define the business date and apply the same convention to allocations, attendance and reports. An end time earlier than a start time is not enough by itself to describe an overnight shift.

Branch schedules, days and exceptions

Different branches may have different schedules, and days of operation may vary. Weekly closures, holidays and special hours should be represented as controlled exceptions or effective schedules where supported, rather than destructive edits to a recurring shift definition. If the current architecture lacks exceptions, document that limitation instead of implying a feature.

Change shifts without rewriting history

Use effective dates for consequential timing, day, eligibility or capacity changes. Before applying a new schedule, show affected plans, memberships, allocations, future attendance windows and capacity. A label-only rename may be different from a business change; retirement should preserve historical references, while temporary closure should affect availability without deleting the shift.

Connect shifts to eligible capacity

Shift capacity is derived from operationally eligible seats, branch, zone, maintenance, status and configured rules. One physical seat may serve multiple non-overlapping shifts; the sum of shift opportunities is not the physical seat count. Fixed, flexible and hybrid seating require their own allocation logic.

Connect plans, allocations and attendance

Plan eligibility and shift availability must agree before a member receives access. Allocation must not create incompatible time or seat overlap. Attendance records presence according to its own model; an entitlement is not attendance, and a check-in should not create a permanent allocation. Any early-entry or late-exit tolerance must be configurable and separately documented, not treated as a shift extension.

Handle closures and maintenance

Maintenance or zone closure can reduce eligible capacity for a relevant shift without redefining the shift itself. Availability should invalidate or recalculate after shift, seat status, allocation or closure changes. Temporary closure is not retirement, and a closure should not delete historical attendance or allocation context.

Reports and multi-branch control

Shift reports should state branch, date, schedule version, capacity basis and exception scope. Compare branches only when their definitions are comparable. Preserve historical schedules so owners can answer which rules applied on a past date. Do not use this page to claim an ideal number of shifts, universal duration or occupancy target.

Shift-management SOP

Frequently asked questions