Attendance rules that still explain last month

Here is a failure mode almost every attendance system shares. You tighten the late-arrival grace period from fifteen minutes to ten. Someone reruns March's report. March now shows lateness that nobody was ever told about, and the numbers no longer match the conversations managers had at the time.

Mutable rules rewrite history

The problem begins when a policy is stored as one editable row. Changing the number from fifteen to ten does not only affect tomorrow; every report that reads the current row now applies the new rule to old attendance. The database still has the punches, but it has lost the policy context that gave those punches meaning.

Freezing rules forever is not the answer. Operations change grace periods, overtime thresholds, break expectations, holidays, rounding methods, and role-specific conditions. The correct model is an effective-dated rule: each revision has a start date, an optional end date, a reason, and a permanent identity. A change appends a version instead of overwriting the previous one.

Stamp every evaluation with its source

When the system evaluates a shift, it should record which rule version produced the result. That link matters when a manager asks why someone was flagged late, when payroll investigates a changed total, or when an administrator tests a future policy before activating it.

Versioning creates three practical guarantees:

• Historical reports remain reproducible because March continues to use March's rules.
• Every exception can be traced to the exact configuration and inputs that caused it.
• Administrators can change policy without a code release while preserving the old operating record.

Corrections need the same discipline. An approved attendance correction should preserve the submitted time, the corrected time, who approved it, when it changed, and why. Replacing the original value may make the screen cleaner, but it removes the evidence required to explain the final payroll input.

Test the boundary dates

The most common defects sit at the edge of validity windows: overnight shifts crossing midnight, a policy activated halfway through a pay period, daylight-saving changes, regional holidays, and employees moving between roles or sites. Test these scenarios with real operating examples before rollout.

A useful acceptance check is to select one past pay period and prove that the same inputs still produce the same outcome after a new rule is published. Then run a future-dated scenario and confirm that only eligible shifts use the new version.

Crewtide applies this versioned approach to attendance rules, approved corrections, role assignments, and payroll-related rule sets. The principle is broader than compliance: operational data earns trust when the system can explain what happened using the rules that were actually in force at the time.