Compliance Deadlines: Write the Rules as Data, Not Code Paths

Every compliance product eventually meets the same wall. The first ten deadline rules are easy. The next fifty each have an exception, the exceptions have jurisdictions, and the rule that was a one-line calculation in month one is now a function with eleven parameters that nobody wants to touch.

The failure is rarely the date arithmetic. It is that the rules were written as code paths instead of as data.

Why is deadline calculation harder than it looks?

Because "thirty days" almost never means thirty days.

A deadline in a legal or regulatory workflow is usually a chain: an anchor event, an interval, a calendar convention, and a set of adjustments. Each link varies independently.

• The anchor may be a filing date, a service date, or a date of knowledge — and which one applies depends on the matter type.
• The interval may count calendar days, business days, or court days, which are three different things.
• The calendar brings weekends, public holidays, and jurisdiction-specific court closures.
• The adjustment decides what happens when the computed date lands on a non-working day — roll forward, roll back, or leave it.

Hard-code any one of those and you have built a rule that works for exactly one case type. Hard-code all four and every new customer requires a code change.

What does it mean to treat rules as data?

It means the calculation is composed from named parts at runtime rather than branched through in a function.

On Atlex, a legal deadline-tracking and compliance platform built solo from concept to production, we shaped the product around reusable logic templates: deadline and due-date rules composed once, then applied across different case types. The point of that structure was to keep the system flexible as requirements evolved — because in this domain, requirements always evolve, and they evolve per customer.

The practical difference:

That second row is the actual goal. The people who know what the deadline rules should be are lawyers, not developers, and a system that requires a deploy to encode their knowledge will always lag behind it.

What has to be true before you trust a computed deadline?

A calculation the user cannot verify is a calculation they will keep a spreadsheet alongside. Which means you have built a second system, not a replacement for the first.

Three properties matter more than the arithmetic:

It has to be explainable. The user needs to see which rule fired and which anchor it used, not just the resulting date. "14 March" is an answer. "14 March, 30 court days from service on 28 January, rolled forward past the holiday" is a number they will act on.

It has to leave a trail. When a date changes because an upstream date changed, that has to be visible after the fact. Atlex carried activity feeds for this reason — in a compliance context, the history of a deadline is part of the record.

It has to leave the product. A deadline that only exists in your dashboard competes with the calendar the user actually lives in, and loses. Atlex generated ICS calendar entries so obligations landed where the work already happens.

What does this mean for scoping a compliance build?

Budget the domain modelling, not the CRUD.

The screens in a compliance product are unremarkable — lists, detail views, forms. The value is entirely in whether the rule engine survives contact with the real variety of cases, and that is discovered by working through actual matters with someone who knows the domain, not by designing screens.

Atlex went concept to production in six months as a solo build, with authentication and two-factor, subscription billing on Stripe, transactional email, calendar generation, activity feeds and super-admin tooling. The infrastructure was the fast part. Getting the rule composition right was the work that made the rest worth building.

---

A working note on compliance and scheduling logic. Project detail is in the Atlex case study.