How Compliance Checks Work: On-Demand vs. Automatic

Note (v0.1.171): As of this release, compliance checks are on-demand only. Automatic triggering on tenancy lifecycle events is a tracked improvement, not yet implemented. This page documents current behaviour and the planned future state.

---

Current Behaviour

What triggers a compliance check?

A compliance check is only run when a user explicitly requests it. There are two ways to trigger a check:

1. Re-check button — On the compliance dashboard, clicking Re-check for a specific tenancy calls the compliance.checkTenancy mutation, which runs evaluateAndPersist for that tenancy.
2. Bulk check — Selecting multiple tenancies and running a bulk check calls the same mutation for each selected tenancy.

In both cases, evaluateAndPersist is the function that:

• Evaluates all compliance rules against the tenancy
• Writes the results to the compliance records table
• Powers work-queue alerts and dashboard indicators

What does NOT trigger a compliance check?

• Creating a new tenancy
• Adding or changing a deposit
• Changing a deposit protection scheme
• Setting or updating a tenancy end date
• Loading the compliance dashboard

Portfolio Summary: In-Memory Only

The portfolioSummary query evaluates compliance rules every time the compliance dashboard loads. However, this evaluation is in-memory only — it does not write records to the database, does not update the compliance table, and does not trigger work-queue alerts. It is used solely for display purposes on the dashboard.

---

Implications

New tenancies have no compliance records by default

A tenancy created today will have no compliance check records until a user manually triggers a check. This means:

• The tenancy will not appear in compliance-related work queues
• No compliance alerts will fire for the tenancy
• The compliance dashboard will not reflect the true compliance state of new tenancies

Stale compliance data

If a tenancy's details change after a check has been run (e.g. a new deposit scheme is set), the compliance records will not automatically update to reflect the change. The next manual check will bring them up to date.

---

Planned Improvements

The following changes are tracked for implementation:

1. Event-Driven Compliance Checks

An Inngest event hook will be added for the following tenancy lifecycle events:

• tenancy.created — fires when a new tenancy is created
• tenancy.updated — fires when a tenancy is modified (deposit added, scheme changed, end date set, etc.)

When these events fire, evaluateAndPersist will be called automatically for the affected tenancy, ensuring compliance records are always current.

2. Nightly Compliance Sweep

The existing daily Inngest function (deadline-reminders.ts), which already runs at 07:00 every day, will be extended to call evaluateAndPersist for every active tenancy. This provides a safety net that catches any tenancies whose compliance state may have drifted since the last event-driven check.

---

Reference

Function	Purpose	Persists Records?	Powers Alerts?
portfolioSummary	In-memory rule evaluation for dashboard display	No	No
compliance.checkTenancy	On-demand compliance check for a single tenancy	Yes	Yes
evaluateAndPersist	Core evaluation + write function, called by checkTenancy	Yes	Yes
deadline-reminders.ts	Daily Inngest job (07:00) — currently deadline reminders only	N/A	N/A

---

Related

• Changelog — v0.1.171
• Compliance Dashboard: src/app/dashboard/compliance/compliance-dashboard.tsx
• Daily Inngest function: src/inngest/deadline-reminders.ts