alidoes.ai

All writing

Post-mortem

Why did my AI file the record under the wrong property?

A document that merely mentioned another property pulled a tenant transition into the wrong home record. The fix wasn't a smarter model — it was a better routing key.

Key findings

  • A tenant transition and shared-building work were filed under the wrong property record because the system followed an address mention.
  • An address is the loudest string in a property document; the loudest string is usually the wrong routing key.
  • Routing by role and outcome (who the person is to you, and where the work actually landed) restored the real story.

My AI filed a tenant transition and shared-building work under the wrong property because it routed by a mentioned address. Routing by role and outcome fixed it.

An address is the loudest token (the most attention-grabbing string) in any property document, and here's the claim I'll defend: the loudest token is usually the wrong routing key. My system proved it by misfiling two real records.

What did the AI actually get wrong?

I keep one home record per property: a canonical file (canonical: the single agreed-on version) that holds that property's whole history. My AI assistant read incoming documents and filed each one to a record. The routing step is where this broke.

Two items landed wrong the same way. A tenant transition got filed under a property that wasn't the tenant's. Work on shared building infrastructure got filed the same wrong way. In both cases, the document mentioned another property's address, and the assistant followed the mention instead of the people and the work.

One honesty note before the mechanism. I'm writing this from the incident's ledger row (the one-line record of what went wrong and what fixed it). Everything here is generalized to protect the people involved: no addresses, no cities, no tenant details. "One property" and "another property" is all you get. The pattern is exact; the texture is thin on purpose.

Why does address matching fail?

Because documents about one property mention other properties constantly, and a mention is not aboutness. A mailing address that isn't the work site. A building shared between records. An old address carried forward in a template. If your router grabs the most prominent address string, every one of those ordinary mentions is a live misfile waiting to happen.

Address matching felt rigorous when I set things up. It wasn't. It's keyword search wearing a filing clerk's badge: a heuristic (a quick rule of thumb) that holds only until a document mentions two places, and property paperwork does that constantly. I shipped it anyway. That call was mine, not the model's.

The failure is also silent, which is the worst property a failure can have. A misfiled record doesn't look wrong. It looks filed.

Same document, two routing rules: address match files it wrong; role plus outcome files it right One document, two routing rules One document a tenant transition or shared-building work; mentions two properties → → Address-match routing follows the loudest string: the address it sees mentioned → Wrong record filed under the property that was merely mentioned Role + outcome routing asks: whose tenant is this? which building did the work change? → Right record filed under the property where the work happened
The same document routed two ways: address matching follows a mere mention to the wrong home record; role + outcome routing follows the person and the work to the right one. Diagram source: this page; maps 1:1 to the role-based routing fix this post describes.

What is role-based routing?

The fix was to stop asking what address the document contains and start asking two different questions. Who is this person to me — the tenant of which property, an owner, a contractor? And where did the work's outcome land — which property is different after this document than before it?

Both answers are stable in a way an address string is not. The tenant's role tied the transition to exactly one property, whatever addresses the paperwork carried. The infrastructure work physically changed one building, and that building belongs to one record. Route on those two facts and, in the ledger's own words, role-based routing "restored the real story."

Notice what the fix is not. Not a smarter model, not a longer prompt, not a plea to read more carefully. It's a different routing key — a context-engineering change (changing what the system is asked and told, not the model itself).

What does this generalize to?

Every filing, retrieval, and lookup step in an AI system has a routing key, and somebody chose it, usually implicitly, usually the loudest surface string. Names collide. Subject lines lie. Addresses get mentioned for a dozen reasons that have nothing to do with where a record belongs. Roles and outcomes are the boring, durable facts underneath, and they are what a careful human clerk actually uses.

This is the same discipline as the rest of my verification setup: don't argue with the model's judgment; change the structure so the judgment isn't load-bearing. The router that failed wasn't dumb. It answered exactly the question I gave it. I had given it the wrong question.

So: what's the loudest token in your documents? If your system routes by it, how would a misfile ever surface — would anything tell you, or would the record just sit there, quietly wrong, looking filed?

Method & data

Method: one misrouted-records incident from live property-records admin — a tenant transition and shared-building infrastructure work filed under the wrong home record, and the role-based routing rule that refiled them
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 — here, the incident's ledger row, the one-line record of the misfile and the fix; the surrounding texture is deliberately generalized. 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{ali2026wrongproperty,
  author = {Ali},
  title  = {Why did my AI file the record under the wrong property?},
  date   = {2026-08-14},
  url    = {https://alidoes.ai/ai-wrong-property-routing/}
}

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