The Compliance Calendar Build Standard
How to build a compliance calendar that survives a rule change, an owner who says no, and the property manager who set it up leaving. Written so you can build it yourself.
Does the work of
- Compliance Officer
- Property Manager
- Operations Manager
Most compliance calendars are a spreadsheet of due dates. They work until a rule changes, and then every date in the column is wrong and nobody can tell which ones. The difference between a calendar and a list of dates is that a calendar stores the rule and derives the date. That single decision is most of this specification.
In short
- What this is
- An open build standard for a compliance calendar across a rent roll or an asset register. Implement it in whatever you like.
- The core rule
- Store the rule with an effective date. Derive the due date. Never store a due date as a fact.
- What it does not do
- It does not decide. It surfaces what is due, drafts the action, and escalates what is at risk. A person still says yes.
- The hard part
- Not the dates. The owner who declines the work, and the obligation that stays live anyway.
Want the whole thing by email?
This paper, plus the rest of the library. One click to stop them.
1. What this standard covers
Any set of recurring obligations attached to properties, assets or people, where missing one has a consequence set by somebody else. In a rent roll that is smoke alarms, electrical and gas safety checks, pool barriers, routine inspections, lease expiries, rent increases and insurance currency. The same shape covers licence renewals in a trade business and certification in a fleet.
It does not cover doing the work. It covers knowing the work is due, proving it was done, and noticing when it was not.
2. Dated rules, derived dates
This is the whole standard in one section. A due date is not a fact about a property. It is the output of a rule applied to an anchor date, and both sides move.
Rules carry an effective date, and old rules are kept. When a jurisdiction changes an interval, you do not edit the rule — you add a new version with a new effective date. Everything recomputes, and an audit two years later can still show which rule governed a date that has already passed. A calendar that edits its rules in place cannot answer the only question an audit asks.
Rules are also per jurisdiction. Intervals, notice periods and entry rules differ by state and territory, and a rent roll that crosses a border needs the rule to know which side it is on.
3. The obligation record
One row per obligation per property. It needs enough on it that somebody who has never seen the property can act:
- What is required — and the rule version that says so
- The anchor — the date the interval counts from, and where that date came from
- The derived due date — computed, shown, never typed in
- Evidence of last completion — the certificate or report, attached, not just a tick
- Who is responsible — the agency, the owner, or the tenant, because it is not always you
- State — one of the four below
The evidence field is the one people leave out and the one a tribunal asks for. A tick confirming an alarm was tested is worth very little without the report that proves it.
4. The four states
State 1
Scheduled
The obligation has a derived due date and nothing is required yet
Recomputed whenever the rule or the anchor date changes
State 2
Due, action drafted
Inside the lead time. The notice, booking or request is written
Drafted, never sent. A person releases it
State 3
Waiting on someone
Tenant access, an owner approval, a contractor booking
Carries who, since when, and the next chase date
State 4
Breached or at risk
The date passed, or it cannot now be met within the lead time
Escalates to a named person. Never clears itself
The fourth state must never clear itself. A missed obligation that quietly disappears when the work is eventually done destroys the only record that it was ever missed, which is exactly what you need when someone asks why.
5. Six rules that keep it trustworthy
Derive, never store.
A due date is computed from a dated rule and an anchor. If it is stored as a value, a rule change silently leaves every row wrong and nothing tells you.
Keep superseded rules.
Add a version with an effective date rather than editing in place, so a date that has already passed can still be explained.
Propose, never commit.
Draft the entry notice, the contractor booking, the owner request. A person sends it. Notices in particular are legal instruments and their timing is not something to automate away.
Silence is a finding.
Nothing arriving is the signal. A booking never confirmed and a certificate never returned both look identical to an empty inbox, and both need to surface.
Escalate, never resolve, an at-risk item.
The system's job is to make sure a person knows in time. It is not to decide the obligation was not that important.
Record refusal as a state, not an absence.
When an owner declines the work, that is an outcome to store with its date and its author. The obligation stays live and the refusal is the evidence.
6. The parts that are harder than they look
The dates are the easy half. These are what the rest of the time goes on:
The anchor date is often unknown
You inherit a rent roll and nobody knows when the alarm was last checked. A calendar that requires a real anchor cannot start; one that assumes today is safe is quietly wrong for a year. Model an explicit unknown state that surfaces for verification rather than defaulting.
The rule differs by jurisdiction and changes
Intervals, notice periods and who may enter are set per state and territory, and they move. This is why rules are dated and versioned, and it is ongoing work rather than a one-off configuration.
The obligation is not always yours
Some duties sit with the owner and some with the tenant. A calendar that treats every row as the agency's job produces a queue nobody can action, and one that ignores the others misses the ones you are still liable to chase.
The owner says no
This is the genuinely hard one. The work is due, the owner declines to pay, and the obligation does not go away. The system has to hold a live obligation, a recorded refusal and the evidence of having asked, all at once, without pretending the matter is closed.
Access, and the reschedule that undoes the plan
Entry requires notice, notice requires a date, and a tenant who is not home resets it. The second attempt is the normal case, not the exception, so build for it rather than treating it as an error.
Evidence arrives as an attachment from someone else
A contractor emails a PDF certificate. Matching it to the right property and obligation is the same cross-boundary problem as invoice matching, and it fails the same ways.
7. What breaks after it works
A spreadsheet calendar works while the person who built it is reading it every week. The failures come later:
- A rule changes and nothing recomputes. Every date in the column is now wrong and there is no way to tell which. This is the failure the whole standard is designed around.
- It leaves when they do. The knowledge of which properties are exceptions, which owners always decline, and which contractor actually turns up is not in the spreadsheet.
- Completion is recorded without evidence. Ticks accumulate, certificates do not, and the file is worth nothing at a tribunal.
- The breach list gets cleared. Someone tidies up the overdue rows, and with them the record that anything was ever missed.
8. Conformance checklist
A build conforms if all of the following are true. Use it on your own implementation, or on one an AI built for you.
- Due dates are derived from a dated rule and an anchor, never stored as values.
- Superseded rule versions are retained with their effective dates.
- Rules are held per jurisdiction where the obligation differs by one.
- An unknown anchor date is an explicit state that surfaces, not a default.
- Every obligation carries evidence of last completion, not just a completion flag.
- An owner or tenant refusal is stored as a dated outcome, and the obligation stays live.
- Nothing sends a legal notice without a person releasing it.
- A breached obligation never clears itself when the work is finally done.
- Someone other than the builder can explain what it does, and it runs on an account the business owns.
Build it yourself, or have it built
This standard is free to implement and we would rather it was followed than owned. If you build it, the conformance checklist is the thing to hold your build to, and you are welcome to it whether we ever speak.
- Before you start— working out which obligations in your rent roll are actually yours, and what the anchor dates are.
- When it is stuck— usually unknown anchors, cross-border rules, or matching returned certificates to the right property.
- When the person who built it has gone— taking over a calendar that already runs and documenting it against this standard.