The model reads. The rules rank.

Buyer matching is the kind of problem that looks like it was built for a language model. Messy inputs, fuzzy criteria, a judgment call at the end. The obvious move is to hand the model a deal and a list of buyers and ask it who fits.

We tried the obvious move. What we ship now puts the model in the middle of the pipeline and nowhere near the final order, and I’d defend that split to anyone building something similar.

I’m co-founder and CTO at Rehouzd. Wholesale operators bring us off-market single-family deals, and the system’s job is to answer one question: of the investors we know about, who should see this deal first? Get it wrong and an operator wastes a day calling people who were never going to buy.

The pipeline looks like this, and the order matters more than any single component.

candidates = hard_filter(deal)     # market, price, asset type
                                   # deterministic. no model.

for buyer in candidates:           # the model reads the mess
    buyer.features = extract(
        buyer.transaction_history,
        buyer.notes,
        buyer.past_acquisitions,
    )

ranked = score(candidates, deal)   # deterministic + explainable

Hard constraints eliminate candidates first, deterministically. A buyer who doesn’t operate in the market or doesn’t touch this asset type isn’t a weak match, they’re not a match. There’s no reason to spend model tokens or model judgment on a question that a comparison answers.

Then the model does the part it’s genuinely good at, which I’ll come back to.

Then a scoring function ranks what survives. No model. Weights, inputs, an order.

This is the part people argue with, so here’s the actual case. Note what isn’t on the list: cost and latency. Those are real, but they’re not why. If model-driven ranking were better, it would be worth paying for.

An operator won’t act on an order they can’t interrogate. The first question anyone asks about a ranked list is “why is this buyer at the top?” A deterministic score answers that every time, in terms the operator recognizes — this buyer scores high because of these three things. A model can produce an explanation, but it’s a story generated after the fact, and it isn’t necessarily the reason for the ordering. Operators figure that out fast, and once they do they stop trusting the list. An explanation you can’t verify is worse than no explanation, because it spends trust you’ll need later.

Rankings have to be stable. The same deal should produce the same order today and next week. Model-driven ranking drifts — a prompt edit, a version bump, an unusual input, and suddenly the buyer who was third is seventh. Nothing broke, no test failed, and the operator who noticed now believes the system is arbitrary. Determinism isn’t a purity thing here. It’s what lets someone build a mental model of the system and keep it.

When it’s wrong, you need to know what to change. An operator says the ranking is off. With a scoring function you look at the weights, change one, and know exactly what moved and what didn’t. With a model-ranker you’re rewriting a prompt and hoping, with no bounded blast radius and no way to confirm you didn’t break the cases that were fine. The debugging story matters more than the day-one accuracy, because you will be debugging this for as long as it’s in production.

Three pilot operators used v1, and they caught two things fast.

The first was activity bias.

We ranked buyers by recent transaction activity, because transaction activity is what the data gives you cleanly. Operators looked at the top of the list and told us those weren’t the people who close. Some high-activity buyers make a lot of offers and follow through on few. Some quieter buyers close nearly everything they engage on. The data said “active.” The operator knew “flaky.” Our ranking had confidently optimized a proxy.

The second was buy-box nuance. The model matched on the attributes that were sitting in structured fields — price, beds, market — and missed everything operators actually hold in their heads: how much condition a buyer will tolerate, how they finance, which streets they won’t touch regardless of the numbers. Technically-valid matches that any experienced operator would immediately discard.

Both failures have the same root. The system was reasoning over the data that was convenient rather than the data that was true.

The buy-box problem is what convinced me the model belongs in the pipeline — just not at the end.

The naive fix is to ask operators to fill out a buy box per buyer. It works for about a week. Nobody maintains it, it goes stale, and now you have a form that lies.

So the model reads instead. It goes through a buyer’s transaction history, acquisition patterns, and the unstructured notes people actually write, and it infers the buy box: this buyer consistently takes heavier rehab, this one never goes above a certain age of construction, this one has only ever bought in three sub-markets despite being “active” across the metro. That’s a real constraint set, derived from behavior rather than from what someone typed into a field eighteen months ago.

This is the whole argument for the split in one sentence: put the model where the mess is, and keep it out of the decision. Reading unstructured history into structured features is a job that has no deterministic solution — it’s exactly what language models are for. Ordering a list of candidates by known features is a job that has a perfectly good deterministic solution, and using a model there trades away explainability and stability for nothing.

Buy-box extraction fixed the second problem. Activity bias, I have not fixed.

I know that ranking on activity is measuring the wrong thing. I don’t yet have a signal that reliably captures who actually closes. The obvious candidates all have problems. Close rate needs enough engagements per buyer to mean anything, and the tail is thin. Operator judgment is the most accurate signal available and the hardest to collect consistently, because it requires busy people to record something at the exact moment they’d rather move on. Inferring reliability from outcomes takes a volume of completed cycles we’re still accumulating.

So today the ranking still leans on activity more than I’d like, softened by the buy-box work but not solved. If you’re building a matcher, this is the trap I’d flag hardest: the signal that’s easy to collect will quietly become the thing you optimize, and it takes a user telling you to notice.

Anyone who tells you their ranking captures reliability should be asked how they measured it.

I don’t have a clean number, and I’d rather say that than dress up a metric.

What I have is behavioral. Operators stopped overriding the list. Before, they’d scan the ranking, ignore it, and work from their own memory of who to call — which is the real signal that a matcher has failed, because the system is generating work instead of removing it. Now they start at the top and work down.

The lists also got shorter. v1 returned long sets of technically-valid buyers, which is functionally the same as returning nothing: a list of forty is a list you have to re-rank yourself. Hard filters plus a real buy box cut that to a handful an operator can act on in one sitting. Fewer, more defensible candidates beat comprehensive every time, because the operator’s scarce resource is attention, not options.