When Every Deadline Is Derived From One Effective Date

The examples below are deliberately generalized and may use simplified or hypothetical scenarios. They are not descriptions of any identifiable organisation's current systems, architecture or control state.

Some changes cannot go live whenever they are ready. They have to take effect on a specific published date that the outside world already knows, because other people have planned around it. Aviation charts change on a fixed international cycle. Tariffs change on a date announced in advance. Statutory returns are due on dates the law sets. Examination timetables, payroll cut-offs and rate changes work the same way.

Once a date is fixed and public, every step before it stops being a choice. The team does not decide when to close intake; the effective date decides, and the team either meets it or misses the cycle entirely. Software that models the effective date but leaves the upstream steps to a calendar reminder has modelled the least important part.

Generate the calendar, do not type it

The set of permitted effective dates usually follows a rule. A cycle might run every 28 days from a published anchor date, or fall on the first working day of each quarter, or follow a schedule an external body publishes years ahead. Whichever it is, the rule can generate the calendar, and a generated calendar can be extended without anyone retyping it.

This matters more than it sounds. A hand-maintained list of dates is correct until the year it is not extended, and the failure is silent: the system simply has no cycle to attach work to, and the work goes somewhere else. Generating the calendar from its rule means a date three years out exists today, so planning against it is possible and so is testing against it.

Derive the ladder by subtraction

Each cycle carries a ladder of milestones computed backwards from its effective date. Intake closes some number of days before. Verification with the originating department finishes some days after that. Approval is due next, then distribution, then the date itself. Each rung is the effective date minus an interval that the organisation has agreed and written down.

Store those computed milestones on the cycle when it is created. Computing them on demand seems tidier and creates a problem: if somebody changes the interval policy in June, every cycle in the system silently acquires new deadlines, including the ones already in progress and the ones already closed. Persisting the ladder at creation time means a policy change applies to future cycles and leaves history alone, which is the same reasoning behind versioned business rules covered in effective-dated business rules.

Lateness is a computed state

The common implementation is a scheduled job that emails somebody a few days before each milestone. It is easy to build and it fails in a specific way: a notification is a single event in time. It fires, it is read on a phone during a meeting, it is dismissed, and after that the system carries no memory that the deadline is close.

Derive the state instead. Every item in progress has a distance to its next milestone, computed from today's date, and that distance produces a status the item wears until the underlying fact changes. An item that is eleven days from an approval deadline shows as approaching. An item past its distribution deadline shows as late and keeps showing as late. Nobody can dismiss it, because there is nothing to dismiss.

• Compute the status from the milestone and the current date, and store neither the status nor a flag.
• Give each status a threshold the organisation agreed, so approaching means the same thing to everyone.
• Let a queue sort by distance to deadline, since that is the order the work should be done in.
• Send notifications from the derived state, so the message and the screen can never disagree.
• Keep the notification history separate from the state, because who was told is a different question from what is due.

Blocking and warning are different mechanisms

A warning tells a person that time is short. A block prevents a transition until a precondition is met. Conflating them produces one of two bad systems: one that warns about everything and blocks nothing, so the warnings are ignored, or one that blocks on a soft target, so people work around it.

Decide per milestone which it is. Missing an internal review target usually warrants a warning, because the work can still be completed late. Publishing an item that has not been approved usually warrants a block, because approval is the control that makes publication legitimate. Write that decision down against the milestone, so a future maintainer does not have to infer it from the code.

A cycle with nothing in it still needs an output

The case that gets missed is the quiet one. When a cycle arrives and there is nothing to publish, the temptation is to do nothing, because there is nothing to do. Outside the organisation, that is indistinguishable from a cycle that was forgotten.

Where the recipients have planned around the date, an empty cycle needs its own artefact: a notification stating that this cycle contains no changes. Model it as a required output of the cycle. A cycle whose content set is empty at its distribution milestone should raise an item to produce that notification, and the cycle should not close as complete without it.

Some changes create additional obligations

In several regulated domains, a change of a certain type triggers a second, separate notice: a short advance notification that a change is coming, published on a different schedule to the change itself. The trigger is a property of the change, and the resulting obligation has its own deadline, its own approval and its own record.

Model the trigger as a rule evaluated when the item is classified, and create the obligation as a linked item with its own place on the ladder. Two failure modes follow from getting this wrong. Generating the obligation too late leaves no time to satisfy it. Generating it as a checklist tick, with no real item behind it, means nobody can tell whether it was actually issued.

What to test

• The instant before a milestone, the milestone instant itself, and the instant after, for each rung.
• An item submitted one day before intake closes and one day after, asserting which cycle each lands in.
• A cycle whose content set is empty at distribution, asserting the empty-cycle output is raised.
• A policy change to an interval, asserting that cycles created earlier keep their original ladder.
• A calendar generated across a year boundary and a leap year, asserting no cycle is duplicated or skipped.
• A change classified as triggering an additional obligation, asserting the linked item exists with its own deadline.
• An item that misses every milestone, asserting it can still be completed and is still reported as late.

Use dates unless you can defend the need for timestamps

Published cycles usually speak in whole dates. Storing them as timestamps invites a time-zone question nobody asked, and the answer tends to be discovered at a boundary, when an item submitted late on the last permitted day is judged by a server clock in a different zone. If the business speaks in dates, store dates. If a genuine cut-off time exists, store it explicitly with the zone it is defined in, and name the zone in the interface so the person submitting can see which clock applies.

Why this shape is worth the effort

A team working this way can answer questions that a reminder-based system cannot. Which items are at risk for the cycle after next. Whether a submission arriving today can still make the current cycle. What the deadlines were for a cycle that closed eighteen months ago, under the policy that applied then. Whether the quiet cycle last quarter produced its notification.

None of those answers requires anyone to remember anything, which is the point. The organisation's obligations are in the system as data, the system computes what follows from them, and the people using it spend their attention on the work rather than on tracking the work.