Build log

Can AI help screen tenants without breaking fair-housing rules?

Aug 14, 2026

Screening applicants is the highest-liability step a small landlord can automate. My AI never scores anyone; it keeps the ledger that proves every household was treated the same.

Key findings

The reusable screening playbook stores no thresholds and no applicant criteria; a pointer file forces the decision owner to approve fresh written criteria every turnover against current law.
Every status in the decisions log must cite a numbered criterion, applied in the same order to every household; a qualified household not selected is logged as exactly that, never as a failure.
The AI's best contribution was a refusal: it spotted a consumer-report edge case and gated it [verify with counsel] instead of answering.

Yes — if the AI is the clerk and never the judge. It keeps a ledger where every decision cites a numbered criterion, applied in the same order to every household.

Most AI leasing tools are built backwards: they automate the ranking of applicants, which is exactly the step that creates fair-housing exposure, and they leave the record-keeping to the human. This build log comes from a real unit turnover at a small rental property, the one behind 918TS, the management portal I had AI build, and it runs the other way. The AI works the paperwork. It never works the choice.

Every applicant household follows the same path: freshly approved criteria, one ledger row citing a numbered criterion in the same order, neutral non-selection notices, and a closeout that promotes only de-identified lessons. Diagram source: this page; maps 1:1 to the screening-criteria compatibility pointer and steps 7 and 9 of the unit-turnover playbook.

Why does the reusable playbook store zero criteria?

Open the tenant-screening playbook in my system and you find almost nothing. screening-criteria.md is eight lines long, and it is deliberately a compatibility pointer: a file that exists so old links keep resolving, holding nothing you could reuse. Its whole message is that no threshold, applicant fact, deposit, fee, occupancy number, or legal conclusion is current there. The decision owner must approve fresh written criteria inside the active turnover project, after checking current federal, California, and local requirements.

That emptiness is the design. A saved threshold is a stale legal conclusion waiting to be reused. Screening rules move at all three levels of government, and a cutoff that was lawful to apply last turnover may not be lawful this one. The unit-turnover playbook (last validated 2026-07-27) says it outright: dates and legal duties are never copied from the playbook; you recompute both for the current event.

The template economy defaults to the opposite. Downloadable screening kits ship prefilled cutoffs and scoring rules that fossilize inside the file, and every reuse quietly asserts the law hasn't changed. I think that default is a trap, and the empty pointer is the fix.

What is the AI actually allowed to touch?

The paperwork, structured as a ledger: a log where every entry must justify itself. The per-turnover decisions log carries one row per applicant household, and every status in that row must cite a numbered criterion from the freshly approved list. The criteria also get applied in the same order to every household. Order sounds like a nicety. It isn't. If one household gets its income verified first and another gets its rental history read first, you are running a different process per household even with identical criteria on paper.

Inside that structure, the AI is a clerk. It drafts rows, checks that no status is missing its criterion number, and keeps notice wording identical across households. A status is a citation of a numbered criterion, not a score, so there is nowhere for the machine to put an opinion. Applicant data itself stays in an access-controlled project record that the reusable layer never holds. Missing evidence gets written NOT CAPTURED, never guessed.

The row I care most about belongs to a fully qualified household that didn't get the unit. The discipline requires the log to say so plainly: "unit leased to another qualified applicant — NOT a criterion failure." Nobody gets a deficiency invented for them so the paperwork looks tidy, and every non-selected household receives the same neutral notice.

Where did the AI earn its place?

Not by deciding anything. Its best moment in the whole turnover was a refusal. Credit and background checks (what the law calls consumer reports) had been pulled during screening. The AI flagged that adverse-action notice rules (the consumer-report laws that can require a written notice when a report factors into an outcome against an applicant) might still apply even to a neutral non-selection. Then it did the valuable thing: it gated the question as "[verify with counsel]" instead of answering it.

An AI that answers legal questions confidently is a liability generator. The useful behavior is issue-spotting: surface the edge case, name the uncertainty, and route it to a human with the license to resolve it. That refusal habit is the same spine that runs through everything else I let AI operate: the system is built so uncertainty gets flagged, not smoothed over.

What survives after the unit is leased?

Closeout is step 9 of the playbook: compare estimate to actual, then promote only de-identified lessons, meaning lessons stripped of anything that points back at a person. The turnover-lessons pointer is blunt about what does not carry forward: dates, criteria, prices, products, vendors, resident and applicant facts, and legal conclusions. Names, scores, and prices never flow back into the reusable playbook. The next turnover starts from the empty pointer again, on purpose.

Two honest notes. Details here are generalized to protect the people involved, and nothing from the restricted applicant record appears on this page. And none of this is legal advice; the playbook index itself says the files are methods, not legal authority. What I can show is a record-keeping discipline built so that consistency is provable instead of asserted.

So here is the question I'd put to your setup. If your AI helps you choose between people (tenants, hires, vendors), could you show, row by row, that everyone was measured against the same numbered list in the same order? Or does the answer live somewhere in a chat history?

Method & data

Method: the 918TS tenant-screening discipline as its governing files record it — the screening-criteria compatibility pointer, the nine-step unit-turnover playbook (last validated 2026-07-27), the turnover-lessons pointer, the playbooks index, and the domain operating practices
Data: patterns and methods only; no names, dollar figures, addresses, case identifiers, or confidential content · Last checked: 2026-08-14

How this was made

AI-drafted, adversarially checked, human-directed. My AI assistant wrote this from the system's own records — the screening-criteria compatibility pointer, the unit-turnover playbook, the playbooks index, and the 918TS operating-practices file. A separate AI session then tried to break every claim against those records, and automated privacy and readability gates ran before publish. I direct this pipeline, own every boundary in it, and audit published pages on a rolling basis — if you find an error, tell me and it goes in the corrections log, dated, never silent.

I'm Ali — I run real life-and-work admin on AI agents, then check their work in the open. More at /about.

Published under my standards. Found an error? Tell me — corrections go in the corrections log, dated, never silent.

Cite this

@online{ali2026fairhousing,
  author = {Ali},
  title  = {Can AI help screen tenants without breaking fair-housing rules?},
  date   = {2026-08-14},
  url    = {https://alidoes.ai/fair-housing-ai-tenant-screening/}
}

Caught something I got wrong? Send it directly. Confirmed corrections go in the corrections log.