This describes work that is in design. Everything below is what we are building, not something you can switch on today.
"Is parking included?"
It is the most ordinary question in leasing and you answer it fourteen times a week. Now picture the building it is being asked about: two units have a tandem spot behind the building, one has the garage, and the rest are on street permits that the city renews in March.
There is exactly one wrong way to answer that question, and it is to answer it plausibly.
Because most units in most buildings do come with parking, and a plausible answer is "yes, parking is included." That answer is right most of the time, which is precisely what makes it dangerous. An applicant who is told parking is included, and who arrives to find a street permit and a waiting list, has not been given a mistake. They have been given a representation about their housing, on the landlord's behalf, in writing, by the landlord.
The question every operator asks second
The first question anyone asks about software answering applicants is whether it can. The second one, about ninety seconds later, is the real one:
How would I know it isn't making things up?
It is the right question and most answers to it are unsatisfying, because most answers are some version of "we've instructed it carefully" or "our accuracy is very high." Both of those are promises about behaviour. Neither is a mechanism, and an operator whose name is on the message is entitled to a mechanism.
The design: not "be truthful", but "you may not speak without a source"
Here is the idea the whole thing rests on, and it is deliberately unclever.
The model is not being asked to be truthful. It is being denied the ability to speak without a source.
Those sound similar and they are not remotely the same engineering problem. Asking for truthfulness is asking a system to have a property. Denying it the ability to speak without a source is a constraint you can build, test and demonstrate.
In practice that means two rules, and everything else follows from them.
Every fact asserted about a unit has to resolve to a field on that unit's record. Parking, laundry, utilities, pet rules, the date it is available, what the screening asks for. If the record says the unit has a tandem spot, that is what can be said. If the record is empty on parking, then nothing about parking can be said — not a hedge, not a general statement about the building, nothing.
Every answer about policy has to resolve to a line in the firm's own pack — the document described in your leasing rules exist. Same rule: a line, or no answer.
No record and no line means it stops and hands the question to a person. Not "answers cautiously". Stops.
That third rule is doing the real work, and it is the reason this approach is cheaper than trying to make a model careful. A careful model still composes when it is uncertain, and its carefulness shows up as hedged language rather than as silence. A model that cannot reach a record cannot produce the sentence at all.
Why the plumbing gets built before the interesting part
Which brings us to the least glamorous thing on this roadmap.
A unit fact store is a boring piece of software. It is a structured place where what is true about each unit is written down, field by field, so that it can be looked up rather than inferred. Nobody demos it. It does not appear in a headline.
It also has to exist before any of the interesting work is safe, because the entire design above is a lookup. Without somewhere to look, the two rules degrade to "the model does its best", and doing its best on a question about somebody's housing is the failure mode this whole piece is about.
So it goes first. That ordering — plumbing before capability — is the same reason the desk-side drafting layer is being built ahead of the parts that talk to strangers. It is not caution. It is the sequence in which these things can be made to work.
What "show me" would actually look like
Internally, an answer will carry the record it came from. A firm asking "why did it tell them that" gets pointed at a field on a unit, or a line in their own pack, with a date on it.
Two things worth being straight about. First, this is a description of how the design works, not a claim about accuracy — we are not going to quote you an error rate, because a number like that means nothing without saying what was counted, and any vendor quoting one to you should be asked exactly that. Second, provenance is an internal mechanism. It exists so a firm can be shown where an answer came from when it matters, not as a feature an applicant sees.
The trade-off: it will escalate a lot at first
Now the part that costs you something, because it does.
Grounded-or-escalate means the quality of the answers is bounded by the completeness of your records. Early in an account, when the unit records are thin, a lot of ordinary questions will have no field to resolve against — and every one of those becomes a handover to a person instead of an answer.
That is the system working correctly and it will not feel like it. It looks like software that does not know very much, because at that point it does not.
Filling in unit facts is real work. Somebody has to go through the buildings and record what is actually true, unit by unit — which parking, which laundry, which utilities, what the pet situation genuinely is on the second floor. It is a few hours per building, it is tedious, and we are not going to pretend the setup is free.
What you get for it is the difference between software that answers fourteen questions a week correctly and software that answers thirteen correctly and one confidently. The second kind is worse than nothing, because it costs you the credibility of the other thirteen.
There is also a smaller benefit that firms tend to notice first: the exercise of writing down what is true about every unit surfaces the fact that nobody currently knows. The parking situation on the second floor is exactly the sort of thing that lives in one person's memory, and this is the process that gets it out.
What this piece is not about
One boundary, stated deliberately.
Everything here concerns facts about buildings. Parking, laundry, dates, what your screening asks for. Nothing in this design extends to inferring, characterising or asserting anything about a person. Grounding is a mechanism for saying only what your records say about your property — and applicants are not a field on a record.
Releaser is available to property management firms in the United States and Canada: one shareable link per property, your screening completed before anyone reaches your calendar, and self-serve booking for the people who meet the criteria you set.
Grounded unit answers, and the unit fact store underneath them, are in design. This is what we are building them to be.