The retrofit fund's dashboard looked reassuring from the council office. It showed a queue of applications, a colored map, and a score beside every address. When Noor checked her own application, however, the interface became much less reassuring. Her building had persistent damp, high winter bills, and a plan to replace failed insulation. She had uploaded energy statements, household income evidence, and the contractor's assessment. The system returned 51 points and placed the application below the funding line. Its only explanation was: “Estimated impact does not meet current priority threshold.”
Noor could not tell whether the estimate was based on her actual bills, a model of similar homes, an old property record, or an input that had failed to upload. She could not know whether the score reflected the expected carbon reduction, the household's financial position, the readiness of the work, or all of those at once. She could not correct anything because the portal did not identify anything to correct. For a public scheme that decides whose home becomes warmer and cheaper to run, this is not merely a poor user experience. It is an accountability failure.
An automated ranking can help staff handle a large number of applications, but it cannot make the choices within that ranking disappear. Somebody chooses the objectives, the available evidence, the thresholds, and the effect of a missing value. Digital rights require those choices to remain understandable and challengeable when they affect a person. The useful standard is not full technical disclosure for its own sake. It is actionable clarity: enough information for someone to see what happened, identify what may be wrong, and obtain a review that can change the result.
Start with the public purpose, not with the score#
Before a council asks residents to accept an automated assessment, it should state what the assessment is trying to achieve. A retrofit programme may seek to reduce energy use, reach households facing fuel poverty, support unsafe or poorly insulated buildings, or distribute investment across an area. Each aim is legitimate, but they can point in different directions. A system designed to maximize projected emissions savings per pound may favour projects that are easy to deliver. A system designed to reduce hardship may give greater weight to households whose applications require more support. Calling either outcome “the data-driven answer” hides a policy choice that should be open to public scrutiny.
Before a council asks residents to accept an automated assessment, it should state what the assessment is trying to achieve.
The published criteria should therefore explain the trade-offs in plain language. Residents need to know whether the score considers actual energy spending, income, housing condition, estimated savings, permissions, and project cost. They also need to know what it deliberately does not use. That negative list matters. It prevents a convenient but inappropriate proxy from entering the process simply because it is available in a database. It also gives civil society groups and frontline advisers a concrete basis for asking whether the scheme is meeting the purpose it promised.
This does not mean publishing a recipe that lets applicants game every threshold. A description can be specific without becoming an instruction manual. For example, it can say that the scheme gives additional weight to independently evidenced high heating costs, that property data older than a stated period is treated as provisional, and that applications will not be downgraded merely because a resident does not have a digital meter. Such statements allow people to prepare evidence and spot mistakes while preserving the programme's ability to assess applications fairly.
The score itself should never be the first and last word. It is a summary of distinct components: submitted facts, information retrieved from official sources, estimates generated from those facts, and an administrative decision applying the programme rules. These components have different consequences. Noor may correct a factual record, question an estimate, or appeal a rule's application. When the interface compresses them into one number, it makes all three forms of participation harder. A good public explanation pulls them apart rather than making the system sound more certain than it is.
Build an evidence trail a resident can actually use#
After an assessment, the portal should provide a case-specific explanation rather than a generic paragraph about artificial intelligence. Noor should be able to see a concise evidence card: the heating-cost evidence recorded, the income band used, the property characteristics retrieved, the age of the energy certificate, the projected improvement, and the application-status checks. Every item needs a clear label. Was it supplied by the household? Was it obtained from a public register? Was it inferred by the model? Was it missing or rejected? Those labels turn an opaque output into a set of inspectable claims.
Source and timing are essential. An official property record can be wrong after a renovation. A recent loss of income may not appear in a previous tax year. A consumption estimate for a building type may be a useful starting point but a bad account of one particular household. The system should show when it queried each source, which version it used, and how long the data is considered current. If a data source is uncertain, the interface should say so plainly and offer an appropriate route to submit stronger evidence. Treating an estimate as a fact is one of the fastest ways to make automation look objective while reproducing an old mistake.
The evidence trail must record failures as well as inputs. If an uploaded scan could not be read, if the address failed to match a register, or if the system ignored a document format, the resident should not discover that only through a low score. The portal should flag the issue, explain the practical effect, and provide a way to repair it. This is particularly important in programmes that are supposed to help people who may have limited time, limited digital access, or complex housing arrangements. A technical mismatch should trigger support or a request for clarification, not silently become a measure of need.
Councils should test these pathways with real patterns of evidence before using them at scale. Test cases should include a shared meter, a tenant whose bills are in a landlord's name, a household with fluctuating income, and an older resident using paper documents with help from a local advice centre. The purpose is not to treat these people as edge cases that delay a streamlined system. It is to discover whether the streamlined system is excluding normal life. Advisers, housing officers, and community groups should help design the tests because they see the points where an apparently simple online process breaks down.
A challenge route must have the power to matter#
Explanation becomes performative if it ends with a contact address and no consequence. A resident should be able to challenge a specific factor directly from the assessment screen: “this energy use estimate is inaccurate,” “this income record is out of date,” or “this document was not considered.” The process should say what evidence may help, but it must not demand a perfect technical argument. Its purpose is to surface a credible discrepancy, not to make a resident prove that they understand the model better than its owner.
The same route must be available through assisted channels. A telephone worker, a housing adviser, and an in-person desk should be able to record the challenge in the same case system, with the same status and deadlines as an online form. Otherwise, the people least able to use a portal will receive a weaker version of the right to contest it. Accessibility is not satisfied by placing a PDF at the bottom of a web page. It means that the correction process works for people who use different languages, devices, schedules, and levels of digital confidence.
Human review must be meaningful. The reviewer needs access to the inputs and audit trail, authority to replace a bad data point, and the ability to recalculate or override a result where the rules allow it. A reviewer who can only repeat the automated outcome provides a conversation, not a remedy. When a correction is accepted, the programme should restore the position Noor would reasonably have held without the error. It should not tell her to wait for the next funding round after a mistaken estimate consumed this one.
Timing matters as much as procedure. If funding is allocated quickly, a challenged application may need a provisional hold, a reserved place, or an expedited review. A decision corrected after the money has gone cannot fully repair a winter spent in a cold home. The scheme should state which discrepancies trigger that protection and publish the target times for each stage. Clear deadlines make it possible to see whether review is functioning; they also prevent an organization from treating delay as a neutral administrative fact.
Individual challenges reveal system-wide problems. If many applicants correct the same property attribute, the issue may be an outdated database rather than hundreds of isolated mistakes. If a particular document type is repeatedly rejected, the upload design may be defective. The programme should review these patterns regularly and publish what it has changed, without exposing personal cases. That feedback loop turns contestability into a source of better administration instead of framing every correction as an inconvenience.
Procurement cannot outsource public responsibility#
When a vendor supplies the scoring tool, its contract should not become a shield behind which the council hides. The public body remains responsible for the purpose of the scheme, the data it permits, the outcomes it accepts, and the remedies available to residents. It needs contractual rights to inspect documentation, obtain logs, test changes, and suspend a rule when evidence shows harm. A vendor may protect genuine security information or intellectual property, but those interests do not erase the authority required to explain a consequential public decision.
There should be a named accountable team, not a loose chain of referrals between IT, procurement, benefits staff, and the contractor. That team needs the budget and authority to maintain an assisted route, correct source data, commission independent testing, and stop the use of a flawed component. Accountability without decision-making power is simply a way to assign blame after the fact. The resident's question—“why did this score place me below the line?”—must lead to someone able to investigate and act.
Monitoring should include outcomes people can recognize. Alongside processing time, the council should track correction rates, review times, common sources of disagreement, and differences in low-priority results across neighbourhoods, housing types, and access routes. Those patterns do not automatically demonstrate unlawful discrimination, but they indicate where an investigation is necessary. The point is not to promise that a model will never make an error. It is to detect whether the system makes certain errors predictable for the same people.
Noor does not need a guarantee that her application will receive funding. She needs an honest account of how it was assessed and a fair chance to correct a decision built on bad information. A public score becomes legitimate not because it is produced by sophisticated software, but because the people affected can inspect its grounds, contest its mistakes, and receive a remedy while the remedy still matters. In a retrofit programme, that is the difference between a digital tool that helps distribute resources and one that quietly turns an unexplained number into another barrier to a warm home.
