Clear definitions are only the starting poin
In Part 1, I looked at the statutory clocks underneath Awaab’s Law and argued that they cannot be measured reliably until an organisation has defined the business events that start, change, and complete them.
Fields such as reported_date, investigation_date, or works_complete_date may appear straightforward, but their names do not establish which real-world events they represent. Before building the KPI, the organisation first needs to understand those events.
That establishes one part of the information model. The next challenge is that the events do not necessarily belong to a single repair.
An Awaab’s Law response can involve the resident and their household, the home, the location and nature of the hazard, investigations and findings, safety measures, multiple work orders, preventative work, communications, access attempts, alternative accommodation, and changes in circumstances. Relevant information may also be spread across several systems and organisations.
The question therefore moves from:
What does this field mean?
to:
How do these different records connect to describe one coherent case?
That is where an Awaab’s Law case becomes something much larger than a repair order.
As with Part 1, this article focuses on the information and data implications of the process rather than providing a legal interpretation of Awaab’s Law. The government guidance is non-statutory. Phase 1 guidance remains in effect through 29 November 2026, with the published Phase 2 guidance applying from 30 November 2026.
A repair order answers only part of the question
Housing organisations already have established repairs processes. At their simplest, they might look something like:
Problem reported → Job raised → Attendance → Work completed → Order closed
That sequence produces useful operational data. A repairs system may record when the job was created, its priority, who it was assigned to, appointment and attendance information, the work undertaken, and when the order was closed.
All of that may be relevant to Awaab’s Law, but it does not necessarily describe the wider response.
Suppose a resident reports mould in a bedroom. The repairs record shows that a mould treatment was raised on Monday and completed on Wednesday.
That tells us something important about the work, but it may not tell us when the landlord first became aware of the potential hazard, who in the household is affected, whether relevant circumstances were reported, what caused the mould, what an investigation concluded, or what the resident was subsequently told.
It may not even tell us what role that particular work played in the wider response. The mould treatment could represent an immediate safety measure, part of supplementary preventative work, or one task among several required to deal with the underlying problem.
The repair order therefore answers an important question:
What work was raised?
The wider case needs to answer something broader:
Why was action required, who was affected, what was found, what decisions were made, what actions followed, what was communicated, and what happened afterwards?
These questions are related, but they are not interchangeable.
A repairs system may be doing exactly what it was designed to do. The problem arises when a record designed primarily to manage an individual piece of work is expected to represent an entire regulatory journey.
The case connects the person, the home, and the hazard
A repair is normally associated with a property. An Awaab’s Law response may need considerably more context.
The Phase 2 guidance describes Awaab’s Law as taking a person-centred approach, with the assessment considering the circumstances of the actual resident rather than a hypothetical occupier. Relevant information about the resident and household can therefore form part of understanding the risk presented by a hazard.
A simple relationship such as:
Property → Repair
does not capture all of that context.
At a conceptual level, the organisation may instead need to connect:
Resident and household → Home → Hazard → Case
Each element represents something different. The resident and household describe who may be exposed and which relevant circumstances are known. The home provides the property context. The hazard describes the potential risk being considered, while the case connects those elements to the organisation's response.
The location of the hazard may need to be more precise still.
Damp and mould might affect a bedroom, bathroom, external wall, window reveal, or several rooms. A structural problem might originate in a roof or another shared part of a building while affecting several individual homes. A hazard in a communal area creates a different relationship again.
This connects to an issue explored in the UK Housing Data Standards series (UKHDS): an asset can be represented at several levels. Building, block, dwelling, room, and component describe different parts of the physical environment and should not automatically be treated as interchangeable.
For an Awaab’s Law case, the useful relationship might therefore extend towards:
Site → Building → Block or section → Dwelling → Space or room → Component
That does not mean every landlord needs a perfect hierarchical asset model before it can manage a case. The level of detail needs to be appropriate to the problem.
If a roof defect causes damp across several homes, recording the issue only against each individual dwelling may hide the shared cause. Conversely, recording the problem only against the building may obscure which homes and residents are actually affected.
The information model therefore needs to preserve two related questions:
Where is the underlying problem? Who and what is affected by it?
Those questions may have different answers.
The purpose of connecting this information is not to automate professional judgement. It is to make the relevant facts available when that judgement is required. Good information does not replace the decision-maker. It provides a clearer basis for the decision.
An investigation is not a finding
An investigation should be treated as a record in its own right rather than reduced to a single date. The landlord guidance recognises different investigation routes, including standard, renewed, emergency, and further investigations. A remote investigation may be followed by a renewed in-person investigation in qualifying circumstances, while further investigation may be needed where the extent or underlying cause of a hazard cannot yet be established.
This creates an immediate problem with a field such as investigation_date. It could refer to the first remote assessment, an in-person inspection, a renewed investigation, a structural survey, or an emergency investigation triggered later in the case. A single case may therefore need to retain several investigation records, each with its own timing, type, method, investigator, conclusion, and resulting actions.
Conceptually, the relationship is closer to:
Case → Investigation(s)
rather than simply:
Case → Investigation date
This matters because the path through a case can change. An initial investigation may reach one conclusion before a renewed or further investigation reaches another. If the latest result simply replaces the earlier one, the organisation retains the current position but loses the chronology of how it arrived there.
A further distinction is needed between the investigation itself and what it finds. An investigation describes the activity undertaken, while a finding describes its outcome. A field such as investigation_status = significant potentially combines two different questions: whether the investigation has concluded and what that investigation concluded.
Keeping those concepts separate allows the investigation to describe when and how the assessment took place, while the findings describe the hazards identified, their location, and the resulting categorisation. It also accommodates situations where a single investigation identifies several issues. An inspection prompted by damp and mould, for example, might also identify an electrical hazard. The information model therefore needs to support relationships in which a case can contain several investigations, an investigation can produce several findings, and those findings can relate to more than one hazard:
Case → Investigation(s) → Finding(s) → Hazard(s)
This is more realistic than assuming that one case corresponds to one repair or one hazard.
None of this means that every operational system needs to expose a highly normalised relational model to its users. The important point is that the underlying concepts remain distinct. If they are not, different meanings can gradually accumulate within the same fields and statuses. A single case_status, for example, may eventually be expected to describe investigation progress, works, communication, access, and final resolution.
The system may continue to operate perfectly well from a technical perspective while the meaning of its data becomes progressively harder to interpret consistently. That is exactly the kind of issue a good data dictionary or standards-led review should expose: not simply whether a field exists, but whether it has been asked to represent several different business concepts.
One hazard may require several actions
This becomes clearer once the process reaches repairs. Consider a damp and mould case where an investigation identifies mould growth associated with a roof defect and inadequate ventilation. The immediate response may involve treating the mould or taking another temporary measure to make the home safer, while separate roofing work, ventilation improvements, scaffolding, and later checks may still be required.
One hazard can therefore generate several actions and several operational records. Those actions may also serve different purposes. The landlord guidance distinguishes between relevant safety work used to make the property safe and supplementary preventative work intended to prevent the hazard from recurring. It also recognises that supplementary preventative work may not always physically begin within five working days, provided the required steps are taken within that period and the later commencement requirements are met.
That distinction matters for the data model because a field such as works_complete_date tells us very little unless we know which work has been completed. Closing the first work order does not necessarily mean the hazard has been fully resolved, while closing the final work order does not tell us when the property was first made safe.
A more useful relationship is therefore:
Case → Hazard → Required action(s) → Work order(s)
The required actions might include making the property safe, investigating further, preventing recurrence, arranging alternative accommodation, or communicating with the resident. Each may then generate one or more operational records with its own purpose, status, and timeframe.
This also means that operational concepts such as Open, In progress, and Complete can be too coarse when applied to the case as a whole. A property may already have been made safe while further work remains outstanding. Temporary measures may be in place, access to part of the home may have been restricted, or alternative accommodation may have been arranged while the underlying defect is still unresolved.
The organisation may therefore need to distinguish between several different points in the case, including when the immediate risk was controlled, when the underlying problem was resolved, when preventative work was completed, and when the case was formally closed.
Those dates do not need to agree. A safety-work completion date may legitimately occur before the final repair completion date because they represent different business events.
This is an important data-quality point as well as a modelling one. A reconciliation process should not automatically treat different completion dates as contradictory. The model needs enough semantic clarity to explain what each date represents and why they differ.
The reporting question then becomes more precise. Instead of asking whether “the repair” is complete, the organisation can ask whether the required safety action has been completed, whether supplementary preventative work has begun, and whether the underlying problem has ultimately been resolved.
Communication belongs in the case history
Communication is not separate from the Awaab’s Law response. The current landlord guidance requires written summaries in specified circumstances and requires landlords to take reasonable steps to keep tenants informed about the timing and progress of required work. The Phase 2 guidance also provides a written-summary template covering findings, required actions, target timescales, further investigation, preventative work, and alternative accommodation where relevant.
From a data perspective, the challenge is that these communications may sit in different places:
- A work order may be held in the repairs system
- A written summary may sit in CRM or a document store
- Emails and phone calls may be recorded elsewhere
- A contractor may communicate information during a visit
If those records are not connected back to the case, it becomes difficult to understand what the resident was told, when they were told it, and which stage of the response the communication related to.
A field such as:
resident_notified = TRUE
may be useful for workflow control, but it does not represent the communication history. A more useful conceptual relationship is:
Case → Communication(s)
Relevant communications might record when the contact occurred, who it was with, the channel used, its purpose, and any associated document or correspondence. This does not mean every phone call requires a complicated data structure. It means that communications relevant to the regulatory process should remain connected to the wider case.
The written summary provides a useful practical test. The Phase 2 guidance expects the summary to bring together information about the investigation, findings, actions, and relevant timescales.
Could the organisation populate that summary reliably from the information connected to the case?
If doing so requires someone to open the repairs system, locate a survey PDF, search CRM notes, check a spreadsheet, contact the contractor, and then rely on personal knowledge to assemble the position, that reveals something important about the information model.
The individual systems may each be functioning as intended. The problem is that the information needed to understand and communicate the case has not yet been connected into a coherent view.
Current state is not case history
An Awaab’s Law case is not necessarily static. The condition of the property may worsen, new information may become available, or the resident's circumstances may change.
The landlord guidance recognises this explicitly. Where there has been a material change relating to a potential hazard, a new standard investigation may be required and the relevant Awaab’s Law timeframe can begin again. Examples include a worsening hazard or new or worsening symptoms that may be associated with it.
This means the information model cannot always assume:
One case → One assessment → One outcome
Consider a resident who initially reports damp in a bathroom. An investigation takes place and a finding is recorded. Several days later, the resident reports that mould has spread into a child's bedroom and that their circumstances have changed.
That later report is not simply an update to the existing value. It is another event in the history of the case.
If the system simply replaces:
hazard_severity = X
with:
hazard_severity = Y
the organisation retains the current position but may lose how that position developed.
A stronger case history might preserve:
- Original report
- Initial investigation and finding
- Material change
- Revised assessment
- New investigation
- Revised finding
This does not require every operational system to become an event-sourcing platform. It does mean that somewhere in the information landscape there needs to be enough history to understand what was known, and what decisions followed, at relevant points in time.
That creates an important distinction:
Current-state data tells us what the organisation believes now. Case history tells us what the organisation knew then.
Both are useful, but they answer different questions.
The same principle appeared in the UKHDS work through effective dates, retired values, version control, and change history. Important information changes over time, and preserving only its latest state can remove context that later becomes necessary.
One case may span several systems
By this point, the information model is considerably broader than the repairs system.
A single case might involve Customer Services receiving the first report, a housing management system holding resident and tenancy information, an asset system describing the home, a repairs platform managing work orders, a surveying or compliance system recording investigations, contractor systems holding attendance information, CRM storing correspondence, and a reporting platform bringing the information together.
None of that is unusual. Specialist systems exist because they perform different functions, and the objective should not necessarily be to force every part of the case into one application.
The more important requirement is that the organisation can connect the information reliably.
Conceptually, a case might connect:
- Resident and household
- Tenancy
- Home
- Hazard or hazards
- Awareness events
- Investigations
- Findings
- Required actions
- Work orders
- Communications
- Access attempts
- Alternative accommodation
- Material changes
- Closure
The challenge is knowing that those records belong to the same regulatory journey.
That becomes difficult when systems identify the same things differently. A contractor may return the landlord's repair reference, a CRM record may contain only the resident and property, an inspection report may use an address, and a locally maintained spreadsheet may introduce a separate case number.
Each record may be perfectly valid in isolation. The integration problem is establishing their relationships. This is why interoperability involves more than moving data from one system to another. The receiving system also needs enough shared identifiers and meaning to understand what the information relates to.
It raises a more fundamental question:
Does the organisation have an identifiable Awaab’s Law case?
That does not require a new application or a database table called awaabs_law_case. The case is first a conceptual requirement: some reliable mechanism needs to establish that a group of events and records form part of the same journey.
Without that, reporting may need to reconstruct the case retrospectively by finding repairs for a property, looking for inspections around similar dates, searching CRM contacts and contractor records, and then inferring which records belong together. That may be possible for one-off analysis, but it is a fragile basis for routine operational control.
The connecting mechanism could take several forms:
- A case record within an existing system
- A shared case identifier carried across platforms
- An integration or data platform that maintains the relationships
The technical implementation is secondary to the underlying requirement. The organisation needs a dependable way of saying:
These records belong to the same case.
This does not imply that the resulting case view becomes a new “single source of truth”. Different systems may legitimately remain authoritative for different facts. The housing management system might remain authoritative for the tenancy, CRM for the original resident contact, the repairs system for a work order, and a surveying system for investigation findings.
The consolidated case view can still bring those facts together without pretending to be their original source.
That distinction is important. The problem is not that several systems exist. The problem arises when the organisation cannot identify which system is authoritative for a particular business fact, or cannot reliably connect that fact to the wider case.
This is also where the UK Housing Data Standards work remains relevant. Interoperability depends on more than matching similarly named fields. It depends on shared understanding of entities, relationships, identifiers, definitions, and the processes through which information moves.
For Awaab’s Law, the same principle applies internally:
The organisation does not simply need the individual records. It needs the relationships that make those records one coherent case.
Can you reconstruct one case from the records?
There is a practical way to test whether the information model is working: take one completed or representative case and try to reconstruct it from the information the organisation actually holds.
The written summary provides one useful test. The published Phase 2 guidance includes a template covering the issue reported, investigation findings, whether a significant or emergency hazard was identified, required actions, target timescales, further investigations, preventative work, and alternative accommodation where relevant.
The question is not simply whether somebody could manually write the letter. They probably could. The more useful question is whether the organisation can identify where each part of the information comes from.
For example:
- Original issue and report date → Resident contact or awareness record
- Resident and household → Housing management
- Investigation undertaken → Investigation record
- Hazard identified → Investigation finding
- Immediate safety measures → Required action or work record
- Further investigation → Investigation record or plan
- Safety work → Required action and work order
- Preventative work → Required action and work order
- Target dates → Case or action plan
- Alternative accommodation → Accommodation record
- Resident contact details and preferences → CRM or housing management
Once those sources have been identified, the harder questions begin. Are they connected to the same case? Are important facts held as structured data or buried in notes and documents? Are conflicting versions available? Can the organisation identify the appropriate source for each fact? Can it reconstruct what was known at the point the communication was issued?
That final question matters because the current state of a case may be very different from its position several months earlier. A written summary issued on 12 May should reflect what was known and planned on 12 May, rather than the eventual outcome visible when somebody reviews the case later.
The same exercise can then be expanded beyond the written summary. Rather than beginning with systems and tables, start with what happened:
- Resident reports a problem
- Landlord becomes aware
- Relevant resident and household information is considered
- Potential hazard is identified
- Investigation takes place
- Findings are recorded
- Required actions are identified
- Safety work is undertaken
- Resident is informed
- Preventative work is arranged
- Further information or material change occurs
- Additional investigation or action follows
- Underlying issue is resolved
- Case is closed
For each stage, ask four questions:
- What business event occurred?
- What information was created?
- Which system or organisation holds it?
- What connects it to the wider case?
This kind of exercise can expose problems that are difficult to see through a system-by-system review. A critical event may exist only in free text, several work orders may have no explicit link to the same hazard, an investigation may exist only as a PDF, contractor records may lack the landlord's case identifier, or the operational system may retain only the latest status.
Those findings do not automatically mean that a new platform is required. They show where the information model is incomplete and where relationships, identifiers, processes, or data structures may need to improve.
This is the main shift from Part 1 to Part 2.
Part 1 focused on questions such as:
What is awareness? What does investigation concluded mean? What represents completion of safety work?
Those definitions remain essential, but individually defined fields still provide only fragments if their relationships are unclear.
The information model therefore needs to move beyond:
Field → Definition
towards something closer to:
Entity → Event → Relationship → Definition
For an Awaab’s Law case, that might mean connecting:
People → Homes → Hazards → Cases → Investigations → Findings → Actions → Work → Communications
The exact structure will vary between organisations. The objective is not to design the perfect enterprise data model before taking action. It is to ensure that the information model reflects the case that actually occurred, rather than forcing that case into whichever systems and records already happen to exist.
The relationships are what make the records a case
A repair order is an important operational record. It can show that work was raised, assigned, attended, and completed. But an Awaab’s Law response may require a much broader understanding of what happened around that work.
The organisation may need to know who was affected, where the hazard existed, when it became aware, what information was available at each stage, which investigations took place, what they found, which actions followed, what was communicated, how circumstances changed, and when the underlying issue was ultimately resolved.
Those facts may not belong to one record, and they may not belong to one system. The information challenge is therefore not simply to capture more fields, but to establish the relationships that allow separate records to form a coherent case history.
Part 1 asked:
What do the events mean?
Part 2 asks:
How do those events connect?
That leaves one further question:
Even if the definitions are clear and the records are connected, how do we know that the resulting case history can actually be relied upon?
A field may say that an investigation was completed. A work order may show that a job was closed. A checkbox may indicate that the resident was informed. A reason code may record that access was unavailable.
But what supports those assertions?
That is where the discussion moves from connected compliance data to defensible evidence.
And that is the subject of Part 3.