Surveyors visit the homes most at risk of damp and mould before anyone has to report it. Every tenant report still starts the Awaab's Law clock, and a person makes every decision about a hazard.
At a glance
An illustrative scenario. The numbers are typical examples, not a client case study. The cloud services and UK rules were checked on 9 November 2026.
Most social landlords find damp and mould the same way: a tenant phones, fills in a web form or tells a housing officer. By then the mould is visible, and it may have been affecting the household's health for months. Some households never report it at all, because they've been told before that it's condensation, because they're worried about their tenancy, or because nobody asked.
The warning signs are usually already in the landlord's data, but scattered. The stock condition survey knows which archetypes have solid walls, poor ventilation or a history of roof leaks. The repairs system knows about the extractor fan that was reported broken twice, and the leak from the flat above. The contact centre knows about the call that mentioned a child's asthma. Sensors in some homes show humidity staying high for weeks. Nobody sees all of it together, so surveyors are sent where reports come in, not where the risk is.
Since 27 October 2025, Awaab's Law has set fixed timescales once a landlord is aware of a potential damp and mould hazard. More hazards follow from 30 November 2026. The Regulator of Social Housing expects landlords to understand the condition of every home, and the Housing Ombudsman has spent years asking landlords to move from reactive to proactive handling and to stop blaming tenants' lifestyles. Finding risk earlier is the obvious next step, as long as it never slows down the reports that already exist.
Agree these, and measure the baseline, before anything is built. Example targets are typical, not promises.
Share of damp and mould cases first identified by a proactive visit rather than a tenant report.
ExampleRising each quarter, from a measured baseline
Share of proactive visits that find damp, mould or a cause that needs work. Too low wastes surveyor time; very high can mean the list is too cautious.
ExampleAbove the rate for randomly chosen homes, and reviewed monthly
Investigations, written summaries and safety work completed on time, for every case, however it was found.
ExampleEvery case, with no change for reported cases
Homes with a new damp and mould case within 12 months of the last one being closed.
ExampleDown by a third
Homes with a current stock condition record and the fields the model needs, such as ventilation and heating type.
ExampleAbove 90% of the stock
Proactive visits and outcomes split by area, building type and household group, including households with recorded vulnerabilities.
ExampleNo group worse off
Cross-sector rules are on the UK regulation map.
Once the landlord is aware of a potential significant damp and mould hazard, it must investigate within 10 working days, give the tenant a written summary within 3 working days of the investigation ending, and complete safety work within 5 working days. Emergency hazards must be investigated and made safe within 24 hours. A tenant report starts the clock whatever the model says, so reports never pass through the model. Proactive visits sit on top of this process. When a visit finds a potential hazard, that starts the clock too, and the system records the date.
The guidance says a sensor's risk notification doesn't necessarily mean the landlord is aware of a hazard, but consistent readings that show potential issues should prompt timely investigation. So sustained readings create a task with an owner and a deadline, not a silent score. Landlords should take vulnerabilities at face value, and the same hazard may need a faster response for one household than another. That judgement is made by a person, using the vulnerability records, not by the model.
Landlords must have an accurate, up-to-date understanding of the condition of every home, and use it to keep homes safe and decent. The risk model is a way of using that data, not a substitute for stock condition surveys. Its outputs feed the stock condition plan and investment decisions, and they would stand up in an RSH inspection. The Transparency, Influence and Accountability Standard means tenants are told how their data is used, and the tenant panel helps shape the design.
The Ombudsman's 2021 spotlight asked landlords to take a zero-tolerance approach, move from reactive to proactive handling, and stop blaming lifestyle. Its later reports tie good outcomes to accurate records of repairs, inspections and household vulnerabilities. Nothing the system produces, including the model's reasons, letters and surveyor packs, suggests the tenant caused the damp. Complaints still follow the Code's timescales: acknowledge within 5 working days and respond at stage 1 within 10 working days of acknowledging.
Readings from sensors inside a home are personal data, because they can reveal when people are in, cooking, bathing or heating. That means a DPIA before the pilot, a lawful basis agreed with the DPO, sensors installed only where the household agrees, readings used only for keeping the home safe, and a short retention period. Occupancy patterns are never used for tenancy enforcement or anything else. Health and vulnerability data is special category data and is used by people to set urgency, not as a model input.
The model doesn't take decisions about tenants: it adds homes to a list that a person approves, and every hazard decision is a surveyor's. Even so, the design keeps the safeguards the new rules expect: tenants can be told why a visit was offered, can ask for one themselves, and can challenge a finding with a person.
A model trained on past reports learns who reported, not only where damp was. Households less likely to report, for example because of language, disability or fear about their tenancy, can be under-ranked. The fairness measures check reach and outcomes by group, and the visit list keeps a share for homes with little data.
Showing AWSAzuresovereign / on-prem services. Switch with the toggle; every diagram and table on this page follows it.
01Channels
02Intake
03Intelligence
04Orchestration
05Systems of record
06People
| Layer | AWS | Azure | Sovereign / on-prem |
|---|---|---|---|
| Sensor readingsMost landlords buy sensors as a service, so take readings from the provider's API. Don't build on Azure IoT Central, which retires on 20 September 2029, or AWS IoT Events, which has ended. | API Gateway receiving readings from the sensor provider's platform; AWS IoT Core if gateways connect directly | API Management receiving readings from the sensor provider's platform; Azure IoT Hub if gateways connect directly | Kong, or an MQTT broker (e.g. Eclipse Mosquitto) feeding Apache Kafka |
| Time-series historyKeep hourly summaries, not every raw reading, and delete them on a set schedule. Timestream for LiveAnalytics is closed to new customers. | Timestream for InfluxDB | Fabric Real-Time Intelligence (Eventhouse) | TimescaleDB or InfluxDB |
| Housing data pipelineNightly extracts of stock condition, repairs, complaints and contact data, keyed on the property reference. Fixing that key is often half the work. | AWS Glue, Amazon S3 | Data Factory and OneLake in Microsoft Fabric | Apache Airflow, with PostgreSQL or Apache Iceberg on Ceph |
| Risk modelGradient-boosted trees on home-level features usually beat anything fancier here, and are easier to explain to surveyors and tenants. | SageMaker AI | Azure Machine Learning | MLflow and Kubeflow on Kubernetes |
| Reasons and fairness checksSageMaker Clarify and Model Monitor closed to new customers on 30 July 2026, so new AWS builds run these checks in their own pipeline. | Open-source libraries (e.g. SHAP, Fairlearn) in SageMaker AI Pipelines | Azure Machine Learning Responsible AI dashboard and model monitoring | Open-source libraries (e.g. SHAP, Fairlearn) in MLflow and Kubeflow pipelines |
| Summaries and pre-visit packsBoth clouds offer a choice of models, including Claude. The pack summarises the home's history; it never gives a view on the cause. | Amazon Bedrock | Microsoft Foundry | Open-weight models served with vLLM on your own GPUs, or IONOS AI Model Hub |
| Agent runtimeThe original Bedrock Agents closed to new customers on 30 July 2026; new builds use AgentCore. | Amazon Bedrock AgentCore | Foundry Agent Service | An open-source agent framework (e.g. LangGraph) on Kubernetes |
| Workflow and events | AWS Step Functions, EventBridge, SQS | Logic Apps or Durable Functions, Event Grid, Service Bus | Temporal, Apache Kafka or RabbitMQ |
| Link to the housing management systemAgree in discovery what your housing system supplier's API allows: creating an inspection request, or only reading. | API Gateway, plus your existing integration platform if you have one | API Management, plus your existing integration platform if you have one | Kong or your existing API gateway, plus your existing integration platform if you have one |
| Human reviewThe list and the reasons appear where the team already works, next to the open Awaab's Law cases. | In the damp and mould team's existing case tool | In the damp and mould team's existing case tool | In the damp and mould team's existing case tool |
| GuardrailsBlocks wording that blames the household, such as lifestyle or drying clothes, in packs and drafts. | Bedrock Guardrails | Foundry guardrails (Azure AI Content Safety) | Open-source guardrails (e.g. NeMo Guardrails, Llama Guard) |
| Identity, permissions, keysSensor data is visible only to the damp and mould team and surveyors, not to tenancy enforcement. | IAM Identity Center, Amazon Verified Permissions, KMS | Entra ID, Azure RBAC, Key Vault, Purview | Keycloak or your existing Active Directory; OpenBao or HashiCorp Vault; an HSM |
| Monitoring and auditLog every score, every list, every approval and every visit outcome, with the model version. | CloudWatch, CloudTrail | Azure Monitor, Log Analytics | Prometheus, Grafana, OpenTelemetry |
| UK data residencyIONOS AI Model Hub runs in German data centres: EU, not UK, residency. Check where the sensor provider stores readings, too. | eu-west-2 (London) | UK South / UK West | Your own UK data centre, or a UK or EU provider |
On a phone, the table shows the platform you pick. Sovereign / on-prem means open, portable components you can run in your own data centre or with a UK or European provider; IONOS is shown as one example, and others exist. What sovereign cloud means →
Many organisations keep core systems and sensitive data on their own servers. This is how the same design works across both.
Stays on-prem
The housing management system, the asset and stock condition system, and the contact and vulnerability records stay where they are. Many councils and housing associations still run these on their own servers or with a hosted supplier, and nothing here needs them to move.
Uses cloud AI
The home-level data store, the risk model, the sensor rules and the visit planning agent can run in AWS or Azure, or on your own servers with open-weight models. Only the fields the model needs leave the housing systems: property reference, building attributes, repair codes and dates, and sensor summaries. Names and health details stay behind.
How they connect
Nightly extracts and change events over a private link (AWS Direct Connect or Azure ExpressRoute) and the API layer. Approved visits come back as inspection requests through the housing system's API, so they appear in the normal repairs workflow.
If the link drops
Nothing about tenant reports changes, because they never depended on the model. The damp and mould team works its existing cases as before, sensor readings queue at the provider, and the next visit list is drafted when the link returns.
What each agent may do through its tools, what it may not, and where a person signs off. The limits are enforced by the platform, not the prompt.
Visit planning agent
Where a person signs offThe damp and mould team approves every proactive visit, and a surveyor decides every hazard. Reports from tenants never pass through the agent. Its permissions are enforced by the platform's identity and policy controls, not by instructions in a prompt.
The housing management system stays the record for every report, inspection and Awaab's Law case. The AI reads from it through an API layer and nightly extracts, and writes back only draft inspection requests that a person approves. If you already run an integration platform, the AI uses it like any other system.
Tenant reports follow their own path, untouched. A report reaches the damp and mould team through the existing process and starts the clock the moment the landlord is aware of it. The risk model runs alongside, never in front, so a model outage, a bad score or a slow pipeline can't delay a report.
Events keep the parts decoupled. Each sustained sensor alert, approved visit and visit outcome becomes a message on a queue, with an ID so a retry never creates a duplicate inspection. Visit outcomes flow back into the training data, so the model learns from what surveyors actually found.
The model can be switched off without affecting anyone's safety. If it's paused, proactive visits stop and everything else carries on exactly as it did before.
Map the data across the housing, asset and contact systems, fix the property key, measure the baseline, agree the sensor data terms, and meet the tenant panel.
Gate · must be true to passBaseline agreed, data access confirmed, DPIA started, lawful basis for sensor data agreed with the DPO.
One area or archetype, in shadow mode first: the model ranks homes, surveyors visit a sample from the top of the list and a random sample, and the hit rates are compared.
Gate · must be true to passHit rate clearly above the random sample, no group worse off, no effect on reported cases, and sign-off from the head of property services.
Weekly visit lists go live for the pilot area, with sensor review tasks, monitoring, support and a rollback plan.
Gate · must be true to passMonitoring, support model, rollback plan and staff training in place.
Extend across the stock, then reuse the same data foundation for the hazards Awaab's Law adds from 30 November 2026, such as excess cold.
Gate · must be true to passEach new area or hazard passes the same pilot gate.
| Activity | Director of property | Product owner | Solutions architectI can fill this | Technical PMI can fill this | EngineersI can fill this | Damp and mould lead | DPO | SecurityI can fill this |
|---|---|---|---|---|---|---|---|---|
| Business case and benefits | Accountable | Responsible | Consulted | Consulted | Informed | Consulted | Informed | Informed |
| Target architecture and data integration | Informed | Consulted | Accountable and Responsible | Consulted | Consulted | Consulted | Consulted | Consulted |
| DPIA and sensor data terms | Accountable | Consulted | Consulted | Informed | Informed | Consulted | Responsible | Consulted |
| Model build and fairness testing | Informed | Consulted | Accountable | Consulted | Responsible | Consulted | Consulted | Informed |
| Pilot visits and hit-rate comparison | Informed | Accountable | Consulted | Responsible | Consulted | Responsible | Informed | Informed |
| Go-live decision | Accountable | Responsible | Consulted | Responsible | Informed | Consulted | Consulted | Consulted |
| Run, monitor and improve | Informed | Accountable | Consulted | Consulted | Responsible | Responsible | Consulted | Consulted |
R ResponsibleA AccountableC ConsultedI Informed· not involved
Option A
If there's no architect on the programme, I'd own the design end to end: the home-level data foundation, the model and its checks, the integration with your housing management system, and the gates. I'd make sure tenant reports stay on their own path, and I'd report to your programme board.
Option B
If your partner or your own team already has an architect, I'd take on the data pipeline, the model and the agent under their lead, and give them a second senior opinion on integration, data protection and the Awaab's Law process.
Goes wrong
Reports start going through the model, and a low score becomes a reason to wait.
How the design avoids it
Reports never touch the model. The clock starts on awareness, and the agent has no permission to change a case.
Goes wrong
The model learns who reports, not where damp is, and keeps missing quieter households.
How the design avoids it
Train on surveyor findings, measure reach by group, and keep part of each list for homes with little data.
Goes wrong
Sensor readings sit on a dashboard nobody owns.
How the design avoids it
Sustained readings become tasks with an owner and a deadline, and the decision is recorded.
Goes wrong
The model's reasons drift into blaming the household.
How the design avoids it
Features describe the building and its repairs, not behaviour. Guardrails block lifestyle wording, and the tenant panel reviews the letters.
Goes wrong
Stock condition data is years old, so the model is confidently wrong.
How the design avoids it
Measure data coverage as a KPI, and treat every proactive visit as a chance to update the stock condition record.
Changes already announced or under way that affect this design. More in the UK horizon scan.
The same home-level data and sensor temperatures help with excess cold. Make sure the reporting and triage process covers the new hazards before 30 November, whatever the model does.
Store survey findings against the updated HHSRS hazard list, so the data foundation serves every hazard, not only damp.
Retrofit can cause damp if ventilation isn't right. Use the model and sensors to check homes before and after works.
Record damp and mould findings in a form you can report against the new criterion, so you can see progress well before 2035.
Keep the model's reasons, the approvals and the visit outcomes in a form you could show the ICO and your tenants.
Good answers are specific. Vague answers to any of these are worth following up.
Whether you need someone to lead the design or to support the architect you already have, let's talk it through.
