If you read the last post on real estate knowledge graphs, you probably ended it with a question. How does the graph actually know what a “lease” is? What separates a tenant from a subsidiary from a guarantor? What tells the system that your firm treats medical office and industrial as different asset classes with different logic behind each?
That’s the ontology question, and it’s the part of AI in real estate that almost nobody talks about because it sounds like a data team problem. It isn’t. It’s the reason most AI tools produce output that looks right but doesn’t quite hold up when you check it. Ontology is the layer underneath everything else, and it’s where the difference between impressive-looking demos and actually useful software gets decided.
What data ontology actually is
An ontology is the rulebook. It defines what things are, how they relate to each other, and what properties they carry.
Think about your own firm for a second. When someone on your team says “the lease,” they know from context whether they mean the master lease, an amendment, a specific tenant’s lease, or the ground lease underneath the whole property. When they say “the tenant,” they know whether they mean the operating entity, the parent, or the personal guarantor. That shared understanding is your firm’s implicit ontology, and it lives inside your team’s heads.
For AI to work on your data, that understanding needs to become explicit. The system needs to know that a lease is a type of document with specific fields and obligations, that it belongs to a specific tenant, that it’s attached to a specific property, and that certain types of leases such as medical office, ground, and industrial triple-net carry their own fields and obligations that don’t apply to the others.
Without that rulebook, the AI is guessing, and when it guesses on your rent roll, your lease abstraction, or your budget variance report, you’re the one who has to catch the mistake.
Why operators should care about ontology
Ontology sounds like something for the data team, but the consequences show up in operator work.
When AI extracts a CAM clause from a lease and treats every clause the same way, you get inconsistent abstractions where the important details get lost in the noise. When AI summarizes a rent roll without knowing that “Acme Corp” and “Acme Corporation LLC” are the same tenant, you get inflated tenant counts and missed concentration risk. When AI processes a ground lease using the same logic it applies to a standard commercial lease, you get missing fields and quiet errors that surface during diligence six months later. Ontology is what stops that from happening. It’s the difference between AI that produces an artifact and AI that produces something you can actually act on.
The two-level problem in real estate
Here’s the piece most AI tools miss. Real estate doesn’t have a flat document taxonomy, it has a parent-and-subtype structure that shows up everywhere.
A document might be a lease, but what kind of lease? A medical office lease, a ground lease, an industrial triple-net lease, and a multifamily residential lease share some fields and diverge on others. The extraction logic is different for each, the fields that matter are different, and the validations that matter are different. A generic ontology that stops at “lease” will process all of them the same way and quietly miss what makes each one different.
The same is true for other document types. A loan document might be a mortgage, a mezzanine loan, a construction loan, or a bridge loan. An OM for an industrial asset carries different information than an OM for a multifamily property. Even something as apparently simple as “property” has meaningful subtypes underneath it in most firms.
Because real estate documents behave this way, we built Outcome‘s ontology with two levels of classification. The first level identifies the parent type, and the second identifies the subtype, so the system knows not just what kind of document it’s looking at but what kind of thing within that category. That’s how the extraction logic can match the actual complexity of your documents instead of collapsing everything into a lowest common denominator.
Generic ontology versus your ontology
Most AI tools come with a generic real estate ontology baked in. That’s better than nothing, but it doesn’t reflect how your firm actually operates.
Your asset classes might be cut differently than the textbook version, your fund structure might require relationships the generic model doesn’t track, and your reporting conventions might roll a property up into a different portfolio hierarchy than a competitor with an identical building down the street. When your ontology is generic, your AI can only reason about a generic version of real estate, and the specifics that make your firm your firm get lost.
Outcome’s ontology starts from a baseline real estate model and then adapts to how each firm operates. The graph reflects the way your portfolio is actually organized, the workflows your team actually runs, and the relationships your business actually tracks. That isn’t customization for its own sake, it’s the only way AI can reason about your business instead of a generic idea of real estate.
Why this used to be a six-month project
The traditional way to build an ontology looked something like this. Hire a consulting firm, spend three months modeling your data with a team of people who don’t run your business, hand the schema to a data engineering team, spend another three months building it, validate with stakeholders, deploy, and then discover that the business changed while you were building. It was expensive, slow, and usually already outdated by launch. That’s why most firms never did it. The math didn’t work.
AI changes the math. Instead of a data architecture project that has to finish before anyone gets value, the ontology now takes shape through a scoping conversation about how your business actually works, and then refines itself as documents flow through the system. When the AI encounters a document type outside the baseline or spots a new relationship pattern in your data, the system adapts, so your ontology grows with your business instead of getting stuck at whatever schema was defined at day one.
Where auditability comes in
There’s one more thing worth naming, because it comes up every time an enterprise team kicks the tires. A good ontology has to be able to defend itself.
When your AI extracts a number from a lease, you need to be able to trace that number back to the exact place in the exact document it came from. Not “somewhere in the lease” but the page, the section, and the paragraph. Not “we’re pretty sure that’s the right tenant” but the resolved entity, the reason the variants were merged, and the record of that decision. When something gets flagged for review, the system needs to know where in the workflow it happened and what to do next.
Because auditability isn’t a compliance add-on, we built Outcome’s ontology to carry provenance by default, so every entity knows its source, every relationship knows the document that established it, and every extraction carries a precise citation back to the exact location in the original document. Audit-ready isn’t a separate workstream. It’s just how the system works.
Why this compounds
Here’s the part nobody says out loud, which is that every document you process makes your ontology smarter about your specific business. The system learns your tenant naming conventions, your fund hierarchy, and the edge cases that show up in your leases but not in someone else’s. After a year on the platform, that accumulated knowledge is worth more than the platform itself, because it can’t be replicated by starting over somewhere else.
That’s the real switching cost, and it’s the reason ontology matters as a business asset and not just a technical one. Your ontology, shaped by your data, becomes a proprietary asset that gets more valuable the longer it runs.
The point
Ontology used to be a data team problem. In an AI-active firm, it’s an operating asset. The firms that get this right will have AI that reasons accurately about their business, and the firms that don’t will have AI that produces fast, confident, plausible-sounding output that they have to keep checking.
You already have an ontology, it just lives in your team’s heads. The question is whether you encode it somewhere your AI can use it, or leave it locked up in tribal knowledge that walks out the door when someone leaves.