How the AI review works — and what it will never do

Tenancy screening is one of the places where "let AI handle it" is genuinely dangerous. Get it wrong and you're on the wrong side of GDPR Article 22 (automated decisions) or the Equal Status Acts. So the AI review in Real Enquiries is deliberately narrow, and a lot of what looks like AI isn't.

Here's the whole design.

What's computed without a model

The affordability panel never touches an LLM. It's arithmetic:

• Assessable income = each occupant's stated monthly income in full, plus 50% of any guarantor's combined income.
• Rent ÷ assessable income, compared with the client's own affordability threshold.
• A maximum affordable rent, and ±€100/±€200 scenario rows.
• A guarantor calculation: the shortfall if the rent is still over the guideline after existing guarantors, and a suggested guarantor income.

Because it's deterministic, it renders the moment you open the file — even while the AI pass is still running, or if it later fails. The document date recency check ("this statement is over three months old") is deterministic too. The model never produces these numbers; it only sees the computed ratio so it can reason about a sensible next step.

What the model does

One call per application. It gets the household's stated details and their documents — payslips and financial records first, up to a hard byte budget — and returns:

• A plain-language summary of the household.
• checks — a cross-check of stated income, employment and references against the actual documents. The prompt forces read-and-quote-first: the stated income is treated as a claim being checked, not the answer, and the model is told never to restate the applicant's figure as if it were printed on the page. (An earlier version of a smaller model liked to "verify" a payslip by echoing the stated number back. That's now a test that fails the build.)
• document_notes — a status and a one-line verdict per file, plus the detected document type (so a work contract uploaded under "Payslip" is flagged) and the language, with a short translated verdict for anything non-English.
• recommended_action — one of: request documents, request references, request a guarantor, follow up, or ready to review. A next step, sanitised to that set.

Document bytes are never stored. Only the findings are, and they're purged on your company's retention schedule.

The lines it won't cross

The system prompt bars the model from mentioning or inferring from any protected ground — nationality, age, family status, HAP or housing assistance, disability, religion, civil status, race, Traveller-community membership — including anything of that nature inside an uploaded document. And the request never carries nationality, date of birth, number of children, HAP status, or PPS number in the first place.

It does not:

• score, rank, or grade an applicant;
• recommend an approve or a decline;
• feed any automation — no rule can change an application's status from an AI value;
• draft a decline that cites a protected ground.

Why bother being this careful

Because the useful version of AI screening isn't "the computer says no". It's "here's the household, here's whether the rent adds up, here's where the payslip and the application disagree — now you decide". That's a tool a letting agent can actually stand behind in front of a landlord, and in front of the RTB.

See it on a real file in the screening walkthrough, or read the Screening Automation page.