Awaab’s Law and Housing Data, Part 1: Can Your Data Prove an Awaab’s Law Response?

Awaab’s Law is also an information problem

Awaab’s Law is often presented as a repairs-timescale problem. But a deadline can only be measured if an organisation agrees when the clock starts, what each stage of the process means, what evidence demonstrates that an action occurred, and who is responsible for maintaining those definitions and records. It is therefore also an information-definition, evidence, and data-governance problem.

This article builds on a theme from my recent five-part series on the practical implementation of HACT's UK Housing Data Standards (UKHDS): before an organisation can confidently standardise, report, or govern its data, it first needs a shared understanding of what that data represents. That series provides a useful starting point for the data-dictionary, definition, ownership, and quality concepts used here.

A compliance clock is only as reliable as the events behind it

At the most visible level, Awaab’s Law is clearly a timescale problem.

Under the current Phase 1 requirements, social landlords must investigate potential significant damp and mould hazards within 10 working days of becoming aware of them. Where an investigation identifies a significant hazard, relevant safety work must be completed within 5 working days of the investigation concluding, and a written summary must normally be provided within 3 working days. Potential emergency hazards must be investigated within 24 hours, with relevant safety work also completed within the applicable 24-hour period. Requirements also apply to supplementary preventative work, suitable alternative accommodation where required, and keeping the tenant informed.

It is therefore understandable that much of the immediate organisational response focuses on reporting.

Dashboards can show open cases, approaching deadlines, breaches, average investigation times, and the proportion of cases completed within target. Operational teams need that visibility, and senior leaders need to understand whether the organisation is responding within the required timeframes.

But those measures are only the visible layer.

A dashboard might report: Investigation completed in 7 working days

The calculation appears straightforward. The more important question is:

Seven working days between which two events?

The starting point might be when:

• When the resident first raised the issue
• When a contact-centre adviser recorded it
• When a repair was created
• When a contractor or member of staff notified another team
• When a specialist case was opened
• When the issue was assessed as potentially falling within the scope of Awaab’s Law

Those events may occur at different times. The same problem exists at the other end of the calculation. What exactly does investigation completed mean?

• Does it mean that somebody attended the property?
• That an inspection was completed?
• That an inspection report was submitted?
• That the findings were reviewed?
• That the organisation reached the conclusion required by the Awaab’s Law process?

Again, those events may not happen at the same time. A calculation can therefore be mathematically correct while still measuring the wrong events.

The landlord guidance describes Day Zero as the point at which a potential hazard is reported or the landlord otherwise becomes aware of it. The relevant investigation timeframe runs from that awareness, not necessarily from the creation of a repair or specialist case.

So the first data challenge is not calculating the number of working days between two fields. It is establishing what real-world events those fields are supposed to represent.

Before an organisation can confidently report that an investigation took seven working days, it needs to understand what event started the period, what event ended it, and how those events are represented within its data.

That is where a timescale problem becomes an information-definition problem. And it leads to the next question:

What are the business events that start, change, and complete each statutory clock?

Statutory clocks are built on business events

Awaab’s Law does not create a single timer running from the first report of a problem through to final completion. Instead, it creates a series of related obligations triggered by different events. At a simplified level, the process might look like:

Awareness → Triage → Investigation → Finding → Safety work → Preventative work → Communication → Resolution

But the process is not always linear. An investigation may identify an emergency hazard and trigger a different response. A renewed investigation may begin a new investigation period. A material change can create a new trigger. Further investigation may also be required while other obligations, such as completing identified safety work, continue. Phase 2 Guidance

The result is a set of related clocks that can:

• Start from different events
• Run concurrently
• Change route following a finding
• Restart following a new trigger
• Continue while another part of the case remains unresolved

For example, the conclusion of an investigation may trigger separate timeframes for providing the written summary, completing relevant safety work, and beginning, or taking steps to begin, supplementary preventative work.

The organisation is therefore not simply asking:

When did the case start, and when did it finish?

It needs to understand which event starts each obligation and which event demonstrates that it has been satisfied.

The clock is defined by events, not fields

This creates an important distinction between business events and the fields available in operational systems. A system might contain:

• reported_date
• inspection_date
• repair_complete_date
• case_closed_date

Those fields may all be useful. But the regulatory process is concerned with concepts such as landlord awareness, conclusion of an investigation, identification of a significant or emergency hazard, completion of relevant safety work, beginning of supplementary preventative work, issue of the written summary, and material change.

Those are business events. The system fields become useful for compliance reporting only when the organisation can establish which of those events they actually represent.

A useful way of thinking about the relationship is:

Legal requirement → Business event → Data representation → Compliance calculation

The legal requirement establishes what needs to happen. The business event defines the real-world point that starts, changes, or satisfies that requirement. The data representation records that event within the organisation’s systems. Only then can the compliance calculation measure the relevant period.

For example:

• Requirement: complete the investigation within the applicable period following awareness
• Start event: landlord becomes aware of the potential hazard
• Data representation: awareness_datetime
• End event: investigation concludes
• Data representation: investigation_conclusion_datetime

That is fundamentally different from simply calculating:

job_complete_date - repair_created_date

The second calculation may be easier because those fields already exist. It may even be useful for measuring repairs performance. But availability does not establish suitability.

Define the clock before defining the KPI

For each relevant timeframe, the organisation should first establish:

1. What is the obligation? The action or outcome required
2. What starts the clock? The qualifying business event
3. What ends the clock? The event demonstrating completion
4. What is the time basis? Hours, working days, or another basis
5. Can the clock restart? If so, which event triggers a new period?
6. Can clocks run concurrently? If so, how are the obligations related?
7. Can the route change? If so, which event changes the applicable response?

This is the information model underneath the eventual dashboard, the order matters. If an organisation begins with the fields already available, there is a risk that the regulatory process becomes interpreted through the structure of its existing systems:

• repair_created_date exists, so that becomes the start
• inspection_date exists, so that becomes the end

A stronger approach begins with the business process:

• What event actually starts this obligation?
• What event actually satisfies it?

Only then should the organisation ask how those events are represented technically. The dashboard should therefore be viewed as the end of the information chain rather than the beginning of the work.

Before defining the KPI, define the clock.

And before defining the clock in data, the organisation needs to understand what its fields actually mean.

A field name is not a definition

One of the central arguments in my earlier UKHDS series was that familiar field names can conceal very different business concepts.

A field called Property Type, Ownership, Occupied, or Building may appear self-explanatory, while carrying different meanings depending on the system, process, team, or report using it.

The same principle applies to Awaab’s Law. Consider:

reported_date

At first glance, the meaning seems obvious. But it could represent:

• The date the resident first contacted the landlord
• The date a contact-centre record was created
• The date a repair was raised
• The date a contractor or member of staff notified another team
• The date a specialist case was created

Each date may be valid but they are not necessarily the same business event. The same problem can appear later in the process. Imagine a field called:

works_complete_date

This might represent the date an operative closed a work order, the date relevant safety work was completed, the date supplementary preventative work was completed, or the date somebody subsequently verified the work.

Again, each could be useful but they answer different questions. The same ambiguity can apply to fields such as investigation_date or case_closed_date. This is why a field name is not a definition.

The UKHDS series made a related distinction between a useful data dictionary and a simple schema extract. A database can tell us that a field contains a date, whether it allows null values, and perhaps which system or table it belongs to.

It cannot necessarily tell us what that date represents in the real world, which process creates it, or which business purpose it is suitable for. For Awaab’s Law, those distinctions can directly affect how the statutory clocks are measured. A useful definition might therefore capture something more like:

• Field: awareness_datetime
• Business definition: Earliest established point at which the landlord became aware of the potential hazard
• Business event: Landlord awareness
• Potential sources: CRM, repairs, inspection, contractor notification
• Business owner: Agreed accountable owner
• Regulatory use: Starting the applicable Awaab’s Law timeframe

The precise definition would depend on the organisation's interpretation, processes, systems, and legal advice. The point is not that every landlord should create a field called awareness_datetime.

The point is that the organisation should be able to explain what the value used in the calculation actually represents. This also connects to another theme from the UKHDS series:

Technical validity is not the same as accuracy or fitness for purpose

A date can be populated, correctly formatted, and technically valid while still representing a different event from the one assumed by the report. An Awaab’s Law dataset could therefore contain no missing dates, no invalid values, and perfectly functioning calculations while still producing an unreliable measure.

The arithmetic may be correct but the definition may not be. This is where a data dictionary stops being documentation for its own sake. It becomes part of the control around how important regulatory information is interpreted and used.

For Awaab’s Law, that relationship can be thought of as:

Regulatory concept → agreed business meaning → operational process → system field → reporting rule

If those connections have not been established, a technically sophisticated report can still depend on assumptions that were never explicitly agreed.

Day Zero may exist before the case does

The concept of awareness makes the distinction between a business event and a system event particularly important.

A potential hazard does not have to enter the organisation through one controlled route. A resident might contact Customer Services, mention an issue to a housing officer during a visit, or raise another concern with a maintenance operative already attending the home. Relevant information might also arise through an inspection, another internal team, or a contractor and subsequently need to be reported into the landlord's process.

The landlord guidance reflects this. It places responsibility on landlords to have appropriate internal procedures for reporting and escalation, rather than assuming that awareness begins only when a particular repair or specialist case is created.

Consider a simple hypothetical sequence:

• 09:10: A resident tells a maintenance officer about significant damp and mould
• 11:30: The maintenance officer passes the concern to the repairs team
• 14:05: A repair is created
• 09:20 the following morning: A specialist damp and mould case is opened

From a systems perspective, every one of those events could generate a perfectly valid timestamp. The question is which timestamp represents the event that starts the relevant regulatory clock.

That decision should not be made by the reporting team simply selecting whichever field is easiest to query. Nor should it emerge accidentally from the structure of a Power BI model, SQL query, or case-management system. It requires an agreed understanding of the business event, documented and then implemented consistently in the data.

The Phase 1 guidance provides a closely related scenario. A tenant tells a maintenance officer employed by the landlord about damp and mould, and the officer later passes the concern to the housing management team. The guidance treats the landlord as becoming aware when the tenant first reports the issue to the maintenance officer, not when the information subsequently reaches the housing team.

That creates an important data principle:

Day Zero is a business event. It is not necessarily the date on which the organisation's preferred system creates a case.

This connects directly to the process and lineage themes explored in the UKHDS series. Understanding a data item requires more than locating the field in which it eventually appears. The organisation also needs to understand what event created it, where that event occurred, and how the information reached the system or report in which it is later used.

For Awaab’s Law, that distinction can be significant. case_created_datetime may accurately record when a specialist case was created, while repair_created_datetime may accurately record when a repair was raised. Neither necessarily represents the earlier point at which the landlord became aware of the potential hazard.

The fields are not wrong. They represent different events.

This is why starting with the dashboard and tracing only as far back as its immediate source data can be misleading. The system used to manage the Awaab’s Law case may not be the system in which the triggering event first occurred.

The practical question is therefore not simply:

When was the case created?

It is:

When did the qualifying business event occur, and can the organisation represent that event reliably in its data?

If those two dates are different, the information model needs to preserve that distinction. Otherwise, the statutory clock may already have started before the system used to monitor it has created the case.

The same definition must survive across teams and systems

Documenting a definition is only useful if the organisation can apply it consistently. Imagine different teams using the same term:

• Repairs: awareness means the date the repair was raised
• Customer Services: awareness means the date the resident made contact
• Compliance: awareness means the date the issue was assessed as potentially in scope
• Reporting: awareness is derived using MIN(case_created_date)

Each interpretation may have developed for a reasonable operational purpose. The problem is that they are being treated as different representations of the same business concept.

This reflects a governance issue explored in my UKHDS series. When a data dictionary exposes several competing definitions, it has not created the disagreement. Those differences were already influencing processes, reports, integrations, and decisions. Documenting them simply makes them visible.

Governance becomes practical when the organisation has to answer questions such as:

• What does awareness mean for this process?
• Who is accountable for that definition?
• Which source should be treated as authoritative?
• What happens when two sources disagree?
• Can later information establish that awareness occurred earlier?
• Who approves a change to the definition?
• Which reports and processes are affected if it changes?

These are not primarily technical decisions. An analyst might propose a well-researched definition of awareness_datetime, but that does not automatically make it the organisation's approved interpretation.

The same distinction applies to ownership. Someone may administer the repairs platform, manage the supplier, configure workflows, and control access without being accountable for defining what regulatory awareness means. As discussed in the UKHDS series, system ownership and data ownership are not necessarily the same thing.

For a critical Awaab’s Law data item, governance therefore needs to establish the agreed definition, the accountable business owner, the authoritative source or source hierarchy, and how conflicts or changes will be handled.

The governance structure does not need to be complicated. It does need to be explicit.

A compliance definition should not change depending on which team, system, or dashboard is answering the question.

That does not mean every related timestamp should be collapsed into one field. An organisation may legitimately retain:

• resident_report_datetime
• repair_created_datetime
• specialist_case_created_datetime
• regulatory_awareness_datetime

Those fields can all be valid because they represent different events. The problem begins when they are treated as interchangeable simply because each looks like a plausible version of the same date.

This was another theme from the UKHDS work. Sometimes the correct response is not to force several meanings into a single definition, but to recognise that several distinct concepts exist and name them clearly.

Awaab’s Law data needs the same discipline:

Separate the events, define them clearly, and agree which one is used for each regulatory purpose.

Start with the clocks, not the dashboard

None of this means that a landlord needs to create a comprehensive enterprise data dictionary before it can improve its Awaab’s Law reporting.

One of the practical lessons from my UKHDS series was to begin with a defined business problem, identify the critical data needed to support it, and expand from there. Awaab’s Law provides exactly that kind of bounded use case.

For each relevant timeframe, establish:

• What starts the clock? The qualifying business event
• What ends the clock? The event demonstrating completion
• Can the clock restart? The trigger and rule
• Can another clock begin at the same time? The relationship between obligations
• Can the route change? The event that changes the applicable response
• Where are those events recorded? The relevant systems, datasets, and fields
• Who owns the definition? The accountable business owner
• What happens if sources disagree? The agreed rule for resolving the conflict

This creates a manageable scope around the critical information needed for the regulatory process, rather than attempting to document every field across every system.

Take awareness as one example

Rather than beginning by searching databases for fields containing terms such as reported, created, or received, start with the business question:

1. What real-world event constitutes landlord awareness for this process?
2. Where can that event occur across the organisation?
3. How is each route represented within the data?
4. Which definition and rule will be used to represent awareness consistently?
5. Does that rule behave as expected when tested against real cases?

Only then should the resulting value be relied upon within the KPI.

This mirrors the approach explored through the UKHDS series: begin with the business purpose and process, identify the critical information, connect the business meaning to its technical implementation, and then test whether the data actually represents what the organisation believes it does.

The order matters. Starting with the fields already available risks making the regulatory process fit the existing system:

repair_created_date exists, so that becomes awareness.

Starting with the business event asks a different question:

What information do we need to represent awareness correctly, and can our existing data provide it?

The answer may vary. An event may already be captured clearly, require a transformation between existing fields, appear in several systems, exist only in narrative information, or not currently be recorded in a suitable form.

Uncertainty is also a valid finding. If the organisation cannot yet establish which timestamp reliably represents awareness across every route, it is better to make that gap visible and resolve it than to select the most convenient field and begin reporting a percentage against it.

The practical starting point is therefore not:

Which fields do we have?

It is:

Which business events do we need to represent, and can our data represent them reliably?

Only once that question has been answered should the dashboard become the focus.

Before measuring the clock, define the events

Awaab’s Law creates explicit statutory timeframes, but those timeframes depend on the information used to measure them.

Before an organisation can confidently report investigation times, written-summary deadlines, completion of safety work, or other compliance measures, it needs to understand the business events behind them. What constitutes awareness? When has an investigation concluded? Which event represents completion of relevant safety work? Where are those events recorded, and who is accountable for their definitions?

These are not simply reporting questions. They are questions of business meaning, process, ownership, and governance.

That is why the principles explored through the UKHDS are relevant beyond standards implementation. A useful data dictionary connects business concepts to the systems, processes, rules, ownership, and quality expectations that sit underneath them. The underlying principle is the same: an organisation cannot reliably measure data that it cannot clearly describe.

A dashboard can calculate the difference between two timestamps with complete mathematical precision. That does not establish that those timestamps represent the events the organisation thinks they do.

Precision is not the same as meaning. Before measuring the clock, define the events.

That establishes the foundation.

The next challenge is that those events may be spread across residents, homes, hazards, investigations, repairs, communications, contractors, and multiple systems. Understanding their individual meaning is only the first step. The organisation also needs to understand how they connect into one coherent case history.

At that point, an Awaab’s Law case becomes something much larger than a repair order.

That is the subject of Part 2.