Awaab’s Law and Housing Data, Part 3: From Compliance Data to Defensible Evidence

A connected case is not yet a defensible case

In Part 1, I looked at the statutory clocks underneath Awaab’s Law and argued that they depend on clearly defined business events. Before an organisation can calculate a timeframe reliably, it needs to understand what events such as awareness, investigation conclusion, and completion of safety work actually mean.

Part 2 moved from definitions to relationships. An Awaab’s Law response may involve residents, homes, hazards, investigations, findings, actions, work orders, communications, contractors, and several operational systems. The challenge is not simply to capture those records, but to connect them into a coherent case history.

That gives us a useful progression:

Part 1: Definition → Part 2: Connection → Part 3: Assurance

A connected case history is important, but connection alone does not establish that every event within it can be relied upon.

A field may say that an investigation was completed. A work order may show that safety work was finished. A checkbox may indicate that the resident was informed. A reason code may record that access was unavailable.

Those values tell us what the systems say happened.

Part 3 asks a different question:

What allows the organisation to rely on that history?

That introduces an important distinction between a recorded assertion and the information that supports it.

For example:

• investigation_complete = TRUE is an assertion that an investigation concluded
• resident_notified = TRUE is an assertion that communication took place
• works_complete_date = 14/09/2026 is an assertion that particular work was completed on that date
• access_outcome = NO_ACCESS is an assertion about what happened during an attempted visit

Structured values such as these are necessary. They make workflows manageable and allow reporting to function. But they do not, by themselves, explain why the organisation believes the underlying event occurred.

The investigation may have an associated report and findings. The communication may have a letter, email, or contact record. The completed work may have an operative record, photograph, inspection, or other supporting information. The access outcome may sit within a wider chronology of appointments and contact attempts.

The relevant supporting information will vary according to the event. The principle is broader:

A connected record can tell an organisation what its systems say happened. A defensible record needs to show why those assertions can be relied upon.

This does not mean that every field needs a document attached to it, nor that every operational event requires the same form of evidence. The aim is to understand the relationship between an important assertion, the source information behind it, and the compliance outcome eventually reported.

That is the next layer of the information model.

The current Phase 1 landlord guidance is non-statutory and remains in effect until 11:59pm on 29 November 2026. Published Phase 2 guidance applies from 30 November 2026, when the next phase of the requirements comes into force. The Regulations themselves set the legal requirements.

A status is not evidence

Operational systems depend on structured statuses. They allow cases to move through workflows, trigger actions, support reporting, and give teams a manageable view of what is happening.

An Awaab’s Law case might therefore contain values such as:

• investigation_complete = TRUE
• resident_notified = TRUE
• works_complete = TRUE
• access_outcome = NO_ACCESS

Each of those values may be entirely appropriate. The important distinction is that each one is still an assertion about something that happened.

• investigation_complete = TRUE asserts that an investigation reached the point the organisation defines as complete
• resident_notified = TRUE asserts that the required communication took place
• works_complete = TRUE asserts that a particular piece of work was completed
• access_outcome = NO_ACCESS asserts that access was not obtained in the circumstances represented by that record

The status tells us the organisation's recorded position. It does not necessarily tell us what information supports that position.

For an investigation, there may be an inspection record, findings, photographs, notes, or a completed report. For resident communication, there may be a letter, email, contact record, or other correspondence. Work completion may be supported by an operative record, completion note, photograph, inspection, or another appropriate source. A no-access outcome may sit within a wider history of appointments, attempted visits, messages, and responses.

This leads to an important distinction:

A status is an assertion about an event. Evidence is what allows that assertion to be tested.

The point is not that every status needs an attachment, photograph, or separate document. Different events will have different forms of supporting information, and some evidence may itself be structured data held elsewhere in the organisation.

Nor does this mean that operational statuses are somehow unreliable by default. They are necessary for managing the process. The problem arises when the status is treated as though it is also the complete record of the event it represents.

Consider resident_notified = TRUE. That may be sufficient for a dashboard to count the communication as complete. If the organisation later needs to understand what happened, however, several additional questions may matter:

• When was the resident contacted?
• Which resident or household member received the communication?
• Which channel was used?
• What information was provided?
• Which stage of the case did it relate to?
• Where is the underlying communication record?

The Boolean value and the communication record perform different roles. One supports workflow and reporting; the other helps explain why the organisation believes the communication occurred.

The same applies to a completion date. works_complete_date = 14/09/2026 can be a perfectly valid reporting value, but its usefulness depends on what was completed, how that completion was recorded, and whether the source information supports the business event the date is being used to represent.

Part 2 focused on connecting records into a coherent case. Part 3 adds another requirement: the important assertions within that case need to remain connected to the information that supports them.

Without that connection, the organisation may know what its systems currently say happened without being able to explain why that position should be relied upon.

A defensible case needs an evidence chain

Part 2 moved the information model beyond individual fields and towards the relationships between people, homes, hazards, investigations, findings, actions, work, and communications.

Conceptually, that moved us towards something like:

Entity → Event → Relationship → Definition

That helps establish which records belong to the same case and what those records are intended to mean.

For assurance, however, another layer is needed. The organisation also needs to understand how an important business event becomes a recorded value and how that value ultimately contributes to a reported outcome.

A useful way of representing that relationship is:

Business event → Recorded assertion → Supporting evidence → Reported outcome

Consider resident communication:

Resident informed → resident_notified = TRUE → correspondence or contact record → reported communication outcome

Or completion of safety work:

Safety work completed → completion status and date → work record and appropriate supporting information → reported compliance outcome

The exact chain will vary depending on the event, the organisation, and the systems involved. The important point is that the reported outcome is not the beginning of the information chain. It is the end of one.

Take an investigation as another example. The relevant business event might be that the investigation has concluded. An operational system records that through a status and conclusion date. Supporting information may include the investigation record and findings. Those values may then pass through an integration layer or reporting model before contributing to the calculation shown on a dashboard.

Conceptually:

Investigation concludes → status/date recorded → investigation record and findings → transformed reporting data → compliance measure

This distinction is useful because each part of the chain answers a different question:

• Business event: What happened in the real world?
• Recorded assertion: What does the system say happened?
• Supporting evidence: What information supports that assertion?
• Reported outcome: How has the assertion been used in reporting or decision-making?

The chain does not need to exist in one application. In practice, the event may be recorded in one system, the supporting information held in another, and the final calculation produced in a data warehouse or reporting platform.

That is not inherently a problem. The issue is whether the organisation can follow the relationship between them.

A case model therefore answers:

Which records belong together?

The evidence chain answers:

Why can the important assertions within those records be relied upon?

Those are complementary questions.

A case may be perfectly connected from a technical perspective while still containing weakly supported assertions. Equally, individual source records may contain strong supporting information but remain difficult to use if they cannot be linked reliably to the wider case.

For assurance purposes, both are needed.

The case history connects what happened. The evidence chain connects those events to the information that supports them.

Once that distinction is established, the next question becomes more specific: what counts as suitable supporting evidence for different kinds of assertion?

The evidence depends on the assertion

Once the distinction between an assertion and its supporting information is clear, the next question is what evidence is appropriate for each event.

There is no universal evidence field that can be added to the case and treated as sufficient for everything. The evidence needed depends on the business event being represented and the assertion the organisation is making about it.

This connects directly to the data-dictionary principles discussed in the UK Housing Data Standards series (UKHDS). A good definition does more than explain what a field means. It also helps determine how that value should be created, what information should support it, and which data-quality checks are appropriate.

For example:

• Landlord awareness might be supported by the original resident contact, an inspection record, a staff report, or a contractor notification.
• Investigation conclusion might be supported by the investigation record and its associated findings.
• Resident communication might be supported by correspondence, a contact record, or another record of the communication.
• Completion of work might be supported by the operational completion record, together with any verification required by the process.

Material change might be supported by the new report, observation, or information that caused the case to be reconsidered.

The point is not that every event needs a separate PDF, photograph, or document. Supporting information may be structured data, operational records, correspondence, documents, images, or a combination of several sources.

What matters is the relationship between the assertion and the information supporting it.

There is no universal “evidence field”. The evidence depends on the assertion being made.

This also affects data quality.

A rule for awareness_datetime might test whether a date is present and falls within a sensible range, but those checks only establish technical validity. If the definition says the field represents the earliest established point of landlord awareness, the quality question also becomes whether the value can be traced to an appropriate awareness event.

Likewise, a populated works_complete_date does not necessarily establish that the relevant safety work was completed. The organisation first needs to know which action the date relates to and what information supports that completion status.

The definition, quality rule, and supporting information are therefore connected:

Definition → Assertion → Supporting information → Quality test

This is why evidence should be considered as part of the information model rather than treated solely as a records-management problem. The question is not simply where documents are stored. It is whether the organisation can connect an important recorded assertion to the information that supports it.

A reason code summarises a history

Some assertions are particularly difficult to understand when they are reduced to a single status or reason code.

Access provides a useful example.

An operational system might contain:

access_outcome = NO_ACCESS

or:

exception_reason = ACCESS

Those values can be useful for workflow and reporting. They allow cases to be categorised and help teams identify where planned activity could not proceed.

But NO_ACCESS may summarise a much longer sequence of events.

The underlying case might include:

• An appointment being offered
• Confirmation or attempted confirmation with the resident
• An operative attending the property
• No access being obtained
• Further phone calls, messages, or letters
• A rearranged appointment
• A request for an alternative time
• Another attempted visit
• Eventual access at a later date

Collapsing that history into a single value may be appropriate for a particular report. It should not mean that the underlying chronology disappears.

A reason code summarises a history. It should not replace it.

This is the same distinction between current state and case history discussed in Part 2.

A current record might legitimately say:

access_outcome = NO_ACCESS

while the wider case history explains when access was attempted, what happened, what communication followed, and how the position subsequently changed.

That matters because a summary code cannot answer every question about the underlying sequence. It may tell us the organisation's current classification, but not necessarily:

• Which appointment the code refers to
• When the attempted access occurred
• What contact preceded or followed it
• Whether further attempts were made
• Whether alternative arrangements were offered or agreed
• Whether access was subsequently obtained

The same issue can occur elsewhere in the case. CANCELLED, NO_ACTION, TENANT_REFUSED, DUPLICATE, or other operational reason codes may each represent the end result of a more complicated sequence.

The answer is not to remove those codes. Structured classifications remain useful for workflow, analysis, and reporting. The information model simply needs to preserve the distinction between the summary classification and the events from which that classification was derived.

Conceptually:

Case events → Chronology → Reason code → Reported outcome

This keeps the data model useful at both levels. Operational teams can work with concise statuses and reason codes, while the organisation retains enough history to understand how those values arose.

That becomes particularly important where a reported position depends on a sequence of actions rather than a single event. In those situations, retaining only the final code can preserve the conclusion while losing the information needed to explain it.

Outsourced work cannot mean outsourced information

Part 2 established that an Awaab’s Law case may span several systems. In practice, some of those systems may sit outside the landlord altogether.

Contractors may carry out inspections, attend properties, complete work, take photographs, record observations, or speak directly with residents. In doing so, they generate information that can become part of the case history.

The problem arises when the operational activity is outsourced but the information generated by that activity is not brought back into the landlord's governed record.

For example:

• A contractor portal may contain detailed completion notes while the landlord receives only COMPLETE
• An operative may identify another hazard that never reaches the case record
• Photographs may remain in the contractor's system without a reliable case reference
• An attendance timestamp may exist without being linked to the investigation or action it relates to

Important observations may be retained only in contractor free text

None of those situations necessarily mean the contractor process is failing. The issue is whether the information needed to understand the case remains accessible and connected.

Outsourcing an activity does not remove the need for the resulting information to re-enter the landlord's governed case history.

This is particularly important where the landlord's own reporting relies on a contractor status.

Imagine the landlord receives:

work_status = COMPLETE

That may be enough to close an operational task, but if the completion status contributes to a regulatory measure, the organisation may also need to understand what was completed, when it was completed, which action it related to, and what supporting information exists.

The landlord does not necessarily need to copy every contractor record into its own systems. It does need a reliable relationship between the contractor activity and the wider case.

That might mean preserving:

• The landlord's case or work reference
• The contractor's corresponding reference
• Attendance and completion information
• Relevant findings or observations
• Supporting photographs or documents where appropriate
• Any new issue identified during the visit

The exact mechanism will vary. It might involve system integration, structured data exchange, document transfer, shared identifiers, or a combination of approaches.

The principle is the same:

If contractor information supports an important assertion in the case, the organisation needs to be able to trace that assertion back to the relevant contractor record.

Otherwise, part of the evidence chain sits outside the information model used to manage and report the case.

The dashboard is the end of the information chain

Even where the operational case is well structured and supported, the final compliance measure may still be several steps removed from the original events.

A dashboard rarely reads directly from an investigation record, work order, or resident contact. The data may pass through integrations, transformations, reporting models, calculated fields, and business rules before it reaches the user.

Conceptually, the route may look something like:

Business event → Operational record → Integrated case data → Transformation logic → Reporting model → Dashboard

Each stage can be legitimate. The important question is whether the organisation understands how one became the next.

Suppose a dashboard reports:

investigation_within_target = TRUE

That value may not exist in any operational system. It may have been derived by selecting an awareness date, selecting an investigation conclusion date, applying a working-day calculation, and comparing the result with the relevant threshold.

That does not make the value weaker.

Derived data is not inherently less reliable than directly recorded data.

What matters is whether the derivation is understood, controlled, and reproducible. For an important reported outcome, the organisation should be able to answer questions such as:

• Which case records contributed to the result?
• Which source supplied each important value?
• Was the value recorded directly or derived?
• Which rule selected between competing dates?
• Which transformation produced the reported status?
• Can the result be reproduced from the underlying records?
• Which source information supports the original assertion?

This is where data lineage becomes part of regulatory assurance.

The UK Housing Data Standards work made a similar point: a value shown in a report may have passed through several systems and transformations before reaching the user. Understanding the final field therefore requires more than knowing its name and data type. The route from source to report also matters.

For Awaab’s Law, that route might be:

Resident contact → awareness event → governed awareness date → working-day calculation → compliance status → dashboard

or:

Work completion record → relevant safety action → governed completion date → timeframe calculation → reported outcome

The dashboard is therefore the end of the chain rather than the evidence itself.

This does not mean that every manager viewing a dashboard needs to understand the SQL, integration logic, or reporting model underneath it. It means that the organisation should be able to trace an important result backwards when required.

A useful assurance question is:

Can we move from the reported outcome back through the calculation, the case record, and the supporting information without relying on assumptions or personal knowledge?

If the answer is yes, the organisation has more than a number on a dashboard. It has a traceable route from the reported result back to the events and records from which that result was produced.

Different records do not always mean bad data

A connected case history may still contain conflicting information.

Part 1 dealt with disagreements in meaning. Different teams might use the same field name to represent different business events. Part 2 added the complication of information being spread across several systems. Part 3 introduces another problem: those systems may record different versions of what happened.

For example:

• CRM records the resident's first contact on Monday
• The repairs system records the issue on Tuesday
• A contractor marks work as complete on Wednesday
• An inspection on Thursday suggests further work remained outstanding
• resident_notified = TRUE, but no associated communication can be located

None of those records should automatically be assumed to be wrong. They may represent different events, different stages of the process, or genuinely conflicting accounts.

The first task is therefore to understand whether there is actually a conflict.

A Monday CRM contact and a Tuesday repair creation date may both be correct because they describe different events. A contractor completion date and a later inspection record may also both be valid if the contractor completed one work order while the wider action remained incomplete.

This is why disagreement between values should not be resolved simply by choosing whichever timestamp looks most convenient.

Different values do not necessarily mean bad data. They may mean different events have been recorded.

Where the records do genuinely conflict, the organisation needs a governed way of handling that uncertainty.

That might involve establishing:

• Which source is authoritative for the business event
• Whether one value is derived from another
• Whether the records refer to the same event
• Whether later information changes the interpretation
• Whether the conflict can be resolved from supporting information
• Whether the case needs review

The wrong approach is to allow the reporting layer to resolve the issue silently.

For example, a calculation such as:

MIN(contact_date, repair_created_date, case_created_date)

might produce a convenient awareness date. It does not establish that the earliest value actually represents landlord awareness.

Similarly, selecting the latest available completion date may remove a conflict from the dataset while obscuring whether that date refers to safety work, preventative work, final repair completion, or case closure.

The uncertainty needs to remain visible until it can be understood.

A useful assurance mindset might therefore distinguish between values that are:

• Confirmed: supported by an appropriate source
• Derived: produced through an understood rule or transformation
• Conflicting: credible sources disagree
• Missing: the expected information cannot be located
• Unclear: information exists, but its meaning or relevance cannot yet be established

These do not need to become universal system statuses. They are a useful way of thinking about the strength of the information supporting an important assertion.

The objective is not to eliminate every uncertainty from the dataset. It is to avoid turning uncertainty into certainty simply because the reporting model requires a value.

A defensible information model should preserve uncertainty where the evidence remains uncertain.

That provides a much stronger basis for review than a dashboard that appears complete because every case has been forced into a definitive category.

Can you reconstruct the evidence?

Part 2 suggested taking a completed case and reconstructing the information journey:

Can we reconstruct the case?

Part 3 adds another question:

Can we support the important assertions within it?

This can be tested without beginning with a large-scale assurance programme. Take a manageable sample of completed cases, perhaps 10 to 20, and work through the important events from beginning to end.

For example:

Awareness → Investigation → Finding → Required action → Safety work → Preventative work → Communication → Material change → Resolution

For each important event, ask:

1. What is the assertion? What does the organisation say happened?
2. Where is it recorded? Which system, field, status, document, or operational record contains it?
3. What supports it? Which underlying information provides the basis for that assertion?
4. Can that source be located? Is the supporting information accessible and connected to the case?
5. Does anything conflict with it? Do other records contain a different date, status, or account?
6. Can the reported outcome be traced back to it? Can the organisation explain how the source information became the value shown in the compliance report?

The result should not simply be a pass or fail.

One case may contain a strongly supported awareness event, a derived investigation date, a work-completion status supported only by contractor free text, and a resident-notification flag for which no underlying communication can be found.

Another case may be almost entirely reconstructable but contain two conflicting timestamps for the same critical event.

Those distinctions are useful. A simple review might classify important assertions as:

• Confirmed
• Derived
• Conflicting
• Missing
• Unclear

That immediately provides more information than checking whether the relevant fields are populated. A field can be complete without being well supported. A case can pass basic completeness checks while still requiring substantial manual interpretation to understand what happened.

This exercise can also expose recurring weaknesses across the sample. Several cases may rely on the same contractor free-text field. Resident communications may repeatedly be difficult to locate. Awareness may be consistently derived from the repair creation date because earlier contact information is not linked to the case.

Those patterns point towards improvements in the information chain rather than isolated data corrections.

The purpose of the exercise is therefore not simply to audit individual cases. It is to identify where the organisation's information model consistently loses context, evidence, relationships, or lineage.

Part 2 tested whether the records could be assembled into a coherent history.

Part 3 tests whether that history can withstand a second question:

If somebody asks why we believe this happened, can we show them?

Measure the strength of the information, not only the deadline

Once the evidence chain is understood, the organisation can begin to measure the health of that chain as well as the headline compliance outcome.

The statutory measure may tell the organisation whether an investigation, communication, or piece of work was completed within the required timeframe. That remains important. But it does not necessarily tell the organisation how strong the information underneath that result is.

Internal assurance measures could therefore look at questions such as:

• What proportion of cases have a traceable awareness event?
• How many investigations have identifiable findings?
• Are key completion dates linked to suitable source records?
• Can required resident communications be located?
• How many cases contain conflicting critical timestamps?
• How many cases require significant manual reconstruction?
• How often is the authoritative source for a key event unclear?

These are not statutory metrics. They are management and data-assurance measures.Their purpose is to show whether the information supporting the compliance position is complete, traceable, and understandable.

That distinction matters. A dashboard might show that 95% of cases met a particular timeframe. An assurance review might then show that a material proportion of those cases depend on manually derived awareness dates, missing communication records, or contractor statuses that cannot easily be traced back to the underlying activity.

The first measure describes the reported outcome. The second describes the strength of the information chain behind it. Both are useful, but they answer different questions.

Compliance reporting tells the organisation what the result is. Data assurance helps show how much confidence it can place in the information used to produce that result.

That creates a more complete view of performance. It also helps identify where improvement is needed, whether in definitions, case relationships, source systems, integrations, contractor data, or reporting logic.

Defensible data can explain how the organisation reached its position

A compliance dashboard is important, but every figure on it sits at the end of a longer information chain.

Part 1 considered whether the events being measured had been defined clearly enough for the statutory clocks to mean what the organisation thought they meant.

Part 2 considered whether those events could be connected across residents, homes, hazards, investigations, actions, work, communications, and systems to form a coherent case history.

Part 3 has added a final layer: whether the important assertions within that history can be supported, traced, and explained.

That brings the trilogy together:

Part 1: Definition → Part 2: Connection → Part 3: Assurance

A defensible record therefore requires more than populated fields, complete statuses, and calculated KPIs.

The organisation needs to understand:

• What the data means
• Which business events the records represent
• How those records connect into a case
• Which information supports the important assertions
• Where conflicts or uncertainty remain
• How source records become reported outcomes

None of this removes the need for operational judgement, legal interpretation, or professional decision-making. It gives those decisions a stronger information foundation.

The same principle runs through all three articles: the dashboard is the visible end of the process, not the beginning.

A reported percentage may be precise. A status may be complete. A case may be fully connected.

The deeper question is whether the organisation can explain how it reached that position.

The objective is not simply data that produces a compliance figure. It is data from which the organisation can reconstruct and explain what happened.