Screening Is Watched. The Model That Decides Who Stays Is Not.

Four Systems, One Legal Question

Post-move-in automation arrives piecemeal, which is why it is rarely governed as one thing. In a typical mid-sized portfolio you will find some combination of:

• Renewal risk scoring — a model ranking which residents to renew, at what increase, and which to let lapse.
• Automated violation detection — noise sensors, smart-camera analytics, package and access logs, parking recognition, or text classifiers running over maintenance tickets and resident messages.
• Delinquency and filing workflows — rules that escalate an account through notice, late fee and filing on a schedule with no human decision point.
• Communication triage — an assistant deciding which resident messages are urgent, which get a template, and which are closed.

Each looks like operations. Together they determine who keeps their housing, which is the question the Fair Housing Act asks about. And unlike screening, there is no applicant-facing vendor in the middle — the decision, and the notice with your name on it, is yours.

Why Neutral Features Do Not Protect You

The standard reassurance is that the model never sees race, familial status, national origin or disability. Disparate impact analysis does not care. It asks whether a facially neutral practice produces a discriminatory effect, whether the practice serves a substantial, legitimate, non-discriminatory interest, and whether a less discriminatory alternative would serve that interest.

Run that against the features these models actually use. Late-payment counts track income volatility and payday timing. Maintenance ticket volume tracks unit age and household size. Noise and guest-activity signals track family composition, multi- generational households and caregiving. Complaint counts track the prejudices of neighbours. None of these are protected characteristics; all of them are correlated with some, and the model's job is precisely to find and exploit correlation.

The third step of the analysis is the one operators most often lose. Even where the interest is legitimate, a cheaper and less discriminatory alternative that serves it undermines the defence — and in this domain there usually is one, because a rule keyed to a single concrete fact almost always outperforms a composite score on defensibility.

The Accommodation Collision

This is the failure mode that turns an ordinary compliance question into a case with a named plaintiff. Reasonable accommodation duties mean certain conduct that looks like a lease violation is protected: an assistance animal in a no-pet building, a caregiver whose visits exceed the guest policy, mobility equipment stored where policy forbids, behaviour associated with a psychiatric disability.

An automated pipeline does not know any of that unless someone built the gate. What it does is detect, flag, escalate and generate a notice — to a resident whose accommodation request is already in your system. The document produced is dated, specific and discoverable, and it is very hard to characterise as an isolated staff error when it was generated by a rule you configured.

Accommodation status has to function as a hard interlock: no automated notice, no automated escalation, no automated non-renewal on a resident with a pending or granted accommodation, until a person who knows the file has reviewed it.

Just Cause and the Pretext Trap

A growing number of jurisdictions require a stated, permitted ground for eviction or non-renewal. That requirement interacts badly with score-driven decisions in a specific way: if the real reason is the score, and the notice states a permitted ground selected afterward to fit, you have created a pretext record.

Pretext claims are easier to prove than disparate impact and they play worse in front of a factfinder. The internal artefacts — a queue ordered by risk score, a note reading "flagged for non-renewal", a template selected by the system — are exactly what discovery is aimed at. The operational rule that follows is simple: the ground stated in the notice must be the ground that actually drove the decision, and it must be documented independently of any model output.

What a Defensible Process Looks Like

1. Inventory every system that touches a resident outcome. Including the ones bought as building operations rather than as decisioning — sensors, access control, ticket triage. You cannot test what is not on a list.
2. Measure outcome rates, by property. Non- renewal, filing and fee rates by protected class where you can lawfully estimate it, and by proxy geography where you cannot. Portfolio averages hide the property where the problem lives.
3. Require a concrete predicate for any adverse action. A specific missed payment, a specific documented violation with a date. A score may prioritise attention; it must not be the reason.
4. Gate on accommodation status and on language access. Both as hard blocks on automation, not as review steps someone is supposed to remember.
5. Keep the human review real. A reviewer who approves ninety-nine percent of queued actions is documenting rubber-stamping. Measure override rates and treat a near-zero rate as a finding.
6. Test the less discriminatory alternative explicitly. Compare your model against a simple, transparent rule on both business outcome and disparity. If the simple rule is close, the model is hard to justify and easy to attack.
7. Retain the decision record. Inputs, version, score, reviewer, stated ground, outcome. The claim will be filed long after your log rotation would otherwise have discarded all of it.

Common Questions