The Built Future
An investment firm that owns its infrastructure makes more decisions, with more context behind each one, at a quality the firm sets for itself. This writing describes that infrastructure: what it is made of, why it has to be shaped the way it is, and what a firm can do once it exists.
I started investing in commercial real estate at eighteen. What I learned first was that everything worth knowing about a deal sits locked inside its documents. What I learned next was that once you get it out, almost nobody keeps it. Every firm watches thousands of deals, prices, and outcomes cross its desk, then lets them vanish the moment they’re read.
This is a description of a firm built the other way. Not a firm with better AI tools, but one whose infrastructure is designed to keep what it learns: unified, queryable, auditable, and specific to how that firm creates value. It is written as six principles because the architecture only works as a whole. It is not a product pitch.
I wrote it because I believe the next decade of this industry belongs to the firms that own their own knowledge, and I believe that ownership should sit with the firm itself, not with a vendor, and not with a model. That is the standard I hold Rets to, and this is the thinking behind it.
The Fragmentation Tax
Every commercial real estate investment firm runs on fragmented infrastructure. Deal data lives in one system. Lease abstracts in another. Communications in Slack and email. Financial models in Excel files across shared drives. Asset management in Yardi or MRI. Investor reporting in a fourth platform.
Each system was adopted to solve one problem. None were designed to work together. The result is a firm where information exists but cannot be reached, where knowledge is created but not kept, and where the same questions get answered again and again because the answers disappear into silos.
The cost is real. Analysts spend hours hunting for data that already exists somewhere in the firm. Decisions get made without context that would have changed them. Mistakes repeat because the lessons were never captured. Institutional knowledge walks out the door when people leave. Every new hire spends months learning where things are, who to ask, and which version of which file is current.
Consider a new deal. The acquisitions team receives an offering memorandum. They create a folder on the shared drive. They start a model in Excel. They pull comps from CoStar. They email the broker with questions. They discuss the deal in Slack. They request a site visit. They receive environmental reports. They pull rent rolls and leases. They draft an IC memo in Word.
Every one of those actions creates information in a different system. None of it connects. The model does not know about the broker’s email. The IC memo does not link to the Slack thread where someone raised a concern about a tenant’s credit. The environmental report sits in a subfolder no one will find again unless they already know it is there. Two years later, when the same property comes back to market, the firm starts from scratch because no one can reconstruct what was learned the first time.
Each individual tool works. The problem is architectural. The firm’s information infrastructure was never designed. It accreted over years, one tool at a time, and the firm ends up knowing far less than the sum of what its people know.
The firms that dominate the next decade will rebuild their operating infrastructure around a different architecture: unified, queryable, auditable, specific to how they create value, bounded where human judgment begins, and built to improve as the underlying models improve. Before the principles, three pieces of ground truth explain why the architecture has to take that shape.
What Should Not Be Automated
A CRE investment firm can automate its financial modeling today. The analytical frameworks are static and the outputs are deterministic. Underwriting a property means taking data from a set of documents and transforming it into a model. When I founded my company this was the first thing we offered. Take the due diligence package, hand it to a system that converts the documents into machine-readable form, let the system establish which document governs which fact, review the exceptions, and map the values into the assumption cells of the firm’s Excel model.
The reading and the transformation should be automated. The judgment should not. Those are two different kinds of work and the line between them is the most important line in this writing.
A steward of investor capital earns that role through the relationship formed with a prospective acquisition during a sound underwriting. The understanding of the physical asset, the tenants, the submarket and the risks is the fiduciary duty itself. A firm that lets the system carry the judgment as well as the reading has handed its duty to a vendor. People round to the path of least resistance, and without governance inside the firm, that is exactly what will happen. Poor decisions will follow and duties will be violated.
So the design goal is precise: remove every hour spent turning documents into data, and return every one of those hours to the judgment that the data is for.
How the Error Compounds
A system that is 99% accurate sounds reliable. When its output feeds the next step, the 1% does not stay where it was made. It travels through every decision that depends on it.
An underwriting is a chain of dependent facts. The rent roll feeds NOI. NOI feeds value. Value feeds debt sizing. Debt sizing feeds equity. Equity feeds the return. Each link is a transformation of the one before it, so an error at the source is carried, and often multiplied, all the way to the number the investment committee votes on.
When every step in a chain has to be right for the result to be right, the reliability of the whole is the product of the reliability of each step. This is the law of series reliability, and it governs any system that passes one output into the next.
When every step is equally reliable:
Reliability falls faster than intuition expects as the chain gets longer.
| Accuracy per step | 10 steps | 30 steps | 50 steps | 100 steps |
|---|---|---|---|---|
| 97% | 74% | 40% | 22% | 5% |
| 99% | 90% | 74% | 61% | 37% |
| 99.9% | 99% | 97% | 95% | 90% |
A single lease abstract has about 30 material fields. At 99% per field, one abstract in four contains at least one error. At 97%, more than half do. At 99.9%, 97 in 100 are clean. Each added nine is the difference between an abstract a firm can rely on and one it has to re-check by hand.
The count of errors grows with the volume of facts.
A 200-lease portfolio at 30 fields per lease is 6,000 facts. At 99% accuracy that is 60 wrong facts in the data room. At 99.9% it is 6. The firm does not know which ones are wrong, so at 99% it re-checks all 6,000 by hand.
That is how often errors occur. The magnitude matters more. Value is NOI over the cap rate, so a proportional error in NOI is a proportional error in value, and a cap rate error adds to it.
A 3% miss in NOI on a $100M asset is a $3M miss in value. Add a 25 basis point cap rate error at a 6% cap and the miss is about 7%, or $7M. Then leverage amplifies it. The value error lands entirely on the equity.
At 65% LTV a 3% value miss is an 8.6% equity miss. At 75% LTV it is 12%. This is the mathematics behind a fact every principal already feels: commercial real estate makes fewer decisions than most businesses, and each one is heavier. A small deviation in the input becomes a large deviation in the outcome because the assets are large and the capital is levered.
Two things make this worse than the arithmetic suggests. First, the errors are correlated. When every number came out of the same flawed rent roll, the errors do not cancel. They add. Second, the 1% is not random. Extraction errors concentrate in the hard cases: handwritten amendments, co-tenancy clauses, termination options, CPI escalators with caps. Those are disproportionately the material facts. The unreliable slice of the output is biased toward the consequential slice of the lease.
The architectural consequence is direct. The only place an error is cheap is at the source, before the chain begins. Every extraction has to carry its provenance, its confidence, and the name of the person who checked it. That converts unknown error into measured error and puts the human check at the one point where it does the most work. The decision ledger described later exists first for this reason, and only second for accountability.
What a Language Model Is
Most of the debate about AI in this industry runs on a wrong picture of what the tool is. A large language model is a transformer: a network trained to predict the next token of text given everything before it. Its core mechanism is attention, in which every token in the model’s context is weighed against every other token, so the model reasons over relationships that are present in front of it. Its weights are fixed once training ends. Each of those facts forces a piece of the architecture.
| Property of the model | What it means | What it forces on the firm |
|---|---|---|
| Next-token prediction | Output is a sample from a probability distribution. The model is a reader and a writer. It is not a calculator | The model reads the documents. The spreadsheet does the arithmetic. Financial models stay deterministic and the model never becomes the source of a number |
| Attention | The model reasons over the relationships in its context, and only those | The firm needs a data model that decides which relationships enter the context. That is the ontology |
| Frozen weights | After training the model learns nothing. It has no memory of the firm, its deals, or the last question it answered | The firm’s memory has to live outside the model, in a structure the model is handed at query time. That is the ledger |
| Finite context | Everything cannot go in at once. Attention cost grows with the square of what is in context. Something has to choose | Retrieval over a structured ontology, rather than search over files, decides what the model sees |
| Weights are rented | Every firm can use the same model. No firm can rent another firm’s context | Differentiation lives in the layer above the model. That layer is the asset, and it is what survives when the model is swapped |
| Sampling without grounding | An ungrounded model produces plausible text, which is not the same as true text | Every answer cites its source. Grounding is the mechanism that makes an output admissible in an investment decision |
The firm rents the model and owns the context. Everything the firm is worth in this architecture lives in the context.
The Frontier
A firm is at its efficient frontier when it cannot gain speed without giving up depth, or gain depth without giving up speed. Most firms believe they are there. They are not. Fragmentation forces the trade: a deal reviewed faster is a deal reviewed with less context, because assembling the context is what takes the time.
A firm sitting inside the frontier can gain on both axes at once. Removing the hours spent locating and reformatting data makes the review faster and, because the freed hours go to judgment, deeper. That is a Pareto improvement, and it is the reason the claims later in this writing about speed and depth are not in tension.
The frontier itself also moves. Each generation of models extends what a firm can do at a given cost, so a firm built to absorb new models moves outward with the frontier while a firm hardcoded to a model stays where it was built.
One OntologyPrinciple 01
The foundation is a single, coherent data model that spans every function of the firm.
Today a “tenant” means something different in the lease abstraction system, the rent roll, the asset management platform and the investor report. The same entity exists in several systems with different identifiers and no link between them. When someone asks what the firm’s exposure to a tenant is across the portfolio, someone has to open Yardi, pull a tenant list, cross-reference it against abstracts in another system, check the rent rolls and compile the answer by hand. It takes hours, it is error-prone, and it has to be repeated every time the question is asked because no system remembers the last time.
A unified ontology removes this. Every entity, whether tenant, property, lease, investor, deal or decision, exists once and connects to everything relevant to it.
| Entity | Connected to |
|---|---|
| Property | Leases, tenants, financials, documents, communications, decisions, transactions, inspections, environmental reports, zoning records |
| Tenant | Leases across properties, credit data, payment history, communications, renewal discussions, industry data, related tenants |
| Lease | Property, tenant, amendments, estoppels, escalations, options, restrictions, guarantors, commencement certificates |
| Deal | Documents, models, communications, decisions, timeline events, participants, comparable transactions, market data |
| Investor | Commitments, distributions, communications, reporting, meetings, co-investment history, preferences |
| Decision | Context, participants, rationale, outcomes, related decisions, the assumptions that drove it |
This is a living system rather than a warehouse for reporting. When a lease is amended, the tenant record reflects it. When a deal timeline shifts, the change links to the message that caused it. When an assumption changes in a model, the rationale is captured. When a property manager emails about a maintenance issue, the email connects to the property, the tenant and the lease.
The practical effect is that the model can be handed everything relevant. A question about a tenant returns lease terms at every property where they sit, payment history, renewal conversations from Slack, notes from property manager calls, credit alerts, the IC memo from the original underwriting, and a broker’s comment about the tenant’s expansion plans from an email three months ago. All connected, all in context, all cited.
An asset manager takes a call from a tenant asking for a rent reduction. Before the call ends, they can ask: what are this tenant’s terms across our portfolio, what is their payment history, what did our credit analysis show at underwriting, and have they asked for this at other properties? Today that answer takes three systems, a call to accounting and a search through old email. Here it arrives in seconds with provenance.
A deal team evaluates an acquisition whose anchor tenant the firm already holds at two other assets. Today the team may not learn of the exposure until someone on the IC happens to remember. Here the connection is automatic. The existing relationship, the payment history at both properties, the renewal discussions underway and the credit trend surface before anyone asks.
The ontology also captures relational context that fragmented systems lose entirely. The broker who brought a deal in 2019 is the same broker who just sent a new one. An LP in Fund III sits on the board of a company that is a tenant in the portfolio. The law firm that handled a Denver closing also handled a dispute at another property. These relationships inform decisions. In a unified ontology they are entities the system understands and can reason over.
Answers on DemandPrinciple 02
Every piece of information the firm possesses should be reachable in plain language.
Today, getting an answer requires knowing where to look: which system, which folder, which file, which tab. The person asking must already know how the information is organized. That creates bottlenecks around the few people who know where things are and shuts everyone else out of the firm’s accumulated knowledge. A ten-person shop keeps this in one person’s head. A fifty-person firm cannot, and each team develops its own way of organizing information with no common interface across them.
| Question | Sources traversed | Answer |
|---|---|---|
| What are the lease terms for Tenant X at Property Y? | Lease, amendments, rent roll, estoppels | Complete current terms with citations |
| What did we discuss with the broker about pricing? | Email, Slack, call notes, meeting summaries | Timeline of the pricing conversation |
| Why did we pass on this deal last time it traded? | IC memos, pipeline notes, communications | The decision and its rationale |
| Which properties have tenants with termination options in the next 24 months? | All lease abstracts across the portfolio | List with terms and exposure quantified |
| What rent growth did we assume in similar deals, and what happened? | Historical models, IC memos, outcome tracking | Assumptions against actual outcomes |
| What is our total exposure to coworking tenants and how have they performed? | Leases, rent rolls, payment history, credit data | Portfolio-wide analysis with trend |
| Summarize every conversation with this LP in the last six months. | Email, call notes, meeting summaries, reporting | Chronological synthesis with themes |
The interface is conversational. You ask the way you would ask a knowledgeable colleague. The system reads the ontology, synthesizes, and answers with sources. You can follow up, drill down or pivot. If the answer references an amendment, you can open it. If it cites a Slack thread, you can read it.
Search returns documents that might contain the answer. This returns the answer. Search says here are 47 documents that mention Tenant X. This says Tenant X occupies 12,000 SF at Property Y under a lease expiring March 2027 with one five-year renewal option at 95% of market, current on all payments except a 15-day late payment in June 2024 that their CFO attributed to a billing migration in an email on June 22nd.
A principal preparing for IC can ask for the three biggest risks in a deal and how the firm handled similar risks before, and receive a synthesis that would have taken a senior analyst half a day. An asset manager noticing a payment delay can ask what the firm knows about the tenant’s financial health and get the full picture across accounting, credit monitoring, news and correspondence. A deal team entering a new market can ask what the firm learned from every deal it closed or passed on in that MSA over five years, including which assumptions held and which brokers proved reliable.
No one waits for someone else to pull data. No one decides with partial context. A first-year analyst queries the same knowledge as a twenty-year partner. Senior judgment is not reduced. Everyone gets the context that informs it.
The Decision LedgerPrinciple 03
Every decision, every change and every piece of analysis should be traceable to its origin, its rationale and its author. I call this the decision ledger, to keep it distinct from the accounting ledger every firm already runs.
Today the reasoning behind decisions evaporates almost immediately. An analyst changes a rent growth assumption in Excel. A VP overrides a cap rate. A partner passes on a deal after a call with a local broker. In each case the decision and its reasoning exist only in memory, and memory degrades. Two years later, evaluating a similar deal or reviewing performance, the reasoning is gone. The firm cannot learn from its own experience because it has no record of its own thinking.
The ledger is an immutable record of every significant action the firm takes.
| Event | What gets recorded |
|---|---|
| Data extraction | Source document, extracted values, confidence, reviewer |
| Assumption change | Previous value, new value, rationale, author, timestamp |
| Timeline change | Original date, new date, reason, requester, approver |
| Variance resolution | Conflicting values, chosen value, reasoning, evidence |
| Decision | Options considered, option chosen, rationale, participants, dissents |
| Communication insight | Source message, interpretation, effect on the analysis |
| Model override | Original output, override, justification, approver |
| Risk flag | Risk identified, severity, mitigation, owner |
During underwriting, the model shows 3% rent growth. The analyst changes it to 2% after a broker mentions new supply. In most firms that change happens in Excel with no record. In the ledger it is recorded: previous value 3%, new value 2%, rationale (“broker indicated 2M SF of new supply delivering in 2025 that will suppress rent growth for 18 to 24 months”), source (the broker’s Slack message and its date), author, timestamp. Two years later, when the deal is reviewed against actual performance, the firm sees exactly what was assumed and why. If rents grew at 1.8%, the firm knows this broker’s supply intelligence was reliable. If rents grew at 4%, the firm knows to weight that source differently.
A deal goes through IC at a projected 15% IRR. Two years later the trajectory is 10%. The usual post-mortem says the market softened or leasing was slower than expected. Both statements are true and neither helps the next decision. With the ledger the post-mortem is precise. Rent growth was assumed at 3% on a trailing five-year average; actual was 1.5% because of supply the broker flagged and the analyst underweighted. Leasing velocity was assumed at 10,000 SF a quarter on the leasing agent’s projection; actual was 6,000, and that agent has now overestimated demand on three of the last four deals. Exit cap was assumed at 5.0% on comparable sales; the trajectory suggests 5.5% because the comp set skewed toward higher-quality assets. Each of those is specific, traceable and actionable.
A firm that closes five deals a year cannot learn from deals alone. The unit of learning is the assumption, and deals passed on count as much as deals closed, because every one of them recorded a view that can be checked against what happened.
Five closed and forty passed, at twenty-five assumptions each, is 1,125 checkable data points a year. Five closed deals reviewed as whole deals is five. The ledger multiplies the firm’s sample size by two orders of magnitude without changing how many deals it does.
The value compounds. In the first year, decisions are recorded and rationale is captured, which alone forces clarity at the moment of decision. By the second year, patterns appear: a particular analyst is conservative on rent growth and historically right, and aggressive on leasing velocity and historically wrong. By the third year, outcomes connect to assumptions at scale and systematic biases in the firm’s underwriting become visible. By the fifth year, the firm can say what happened the last N times it assumed X in context Y.
The ledger also produces accountability of a healthy kind. When every decision is recorded with its reasoning, people reason better. Writing “I am changing this assumption because” forces a clarity that mental shortcuts do not. People who are required to justify their judgments make more calibrated judgments. Few firms require it.
Over time the ledger becomes the firm’s most valuable asset after its people: a complete, queryable record of everything the firm has learned from its own experience. No other firm has it. No generic platform can replicate it.
Built to the FirmPrinciple 04
Every investment firm operates in its own way. Its own models, its own deal stages, its own IC process, its own terminology, its own risk tolerances, its own relationships. This is the source of its differentiation. It should not be standardized away.
A firm’s alpha comes from its particular approach to finding, evaluating and managing investments, and that approach is encoded in tribal knowledge: the unwritten rules, the pattern recognition, the heuristics partners carry in their heads. A multifamily firm in the Sun Belt evaluates deals differently from an office REIT in gateway markets. A value-add operator sees risk differently from a core fund. A firm that has invested in one market for thirty years knows which submarkets are turning, which brokers control deal flow, which tenants pay and which property managers perform. No data provider captures that.
A generic platform cannot hold it either. The platform imposes its own ontology, its own workflows, its own definition of a deal stage, its own IC memo structure. It standardizes exactly the things that should differ. The firm ends up operating like every other firm on the same platform and the tribal knowledge stays in people’s heads.
A firm-specific system learns how the firm works. When IC requires a format, the system produces that format. When the models use particular line items, the system maps to them. When partners ask questions a certain way, the system understands the intent. The firm’s definitions of core, value-add and opportunistic are encoded. Its risk tolerances are parameters. Its market and asset-type assumptions, developed over decades, become queryable institutional knowledge rather than one partner’s memory.
Two firms evaluate the same deal. If both use the same generic platform with the same algorithms, they reach similar conclusions and bid similarly, and whatever edge either had from differentiated judgment is gone. If each runs a system built on its own ontology, the outputs diverge, because each system applies its own firm’s assumptions, tolerances and history. The AI amplifies the difference instead of erasing it.
This is what owning infrastructure means. The firm does not own the model. Nobody does. The firm owns the layer above the model: the ontology, the workflows, the ledger, the encoded judgment. That layer is built to the firm, it belongs to the firm, and it is the thing that cannot be bought off a shelf because no shelf has it. The model beneath it is a commodity that gets replaced. The layer above it is the asset that compounds.
Rising With the WaterPrinciple 06
The models available today will be obsolete within years. A firm that builds infrastructure around today’s specific capabilities is trapped when better capabilities arrive.
The pace is unlike anything software has seen. Context windows have gone from thousands of tokens to millions. Reasoning has gone from pattern matching to multi-step analysis. Accuracy on hard tasks improves with every generation. The architectural principle is model agnosticism: systems that improve as the underlying models improve, without reconstruction.
Think of it as building a boat. Every year the water rises. A firm built on the shore, hardcoded to current capabilities, gets flooded. A firm built as a boat rises with it.
| Layer | What it does | Upgrade path |
|---|---|---|
| Features | Extraction, analysis, querying, generation, reporting | Unchanged |
| Abstraction | Translates the firm’s logic into model-agnostic requests | Actively maintained and evaluated |
| Foundation models | Core capabilities: reading, reasoning, language | Swapped as better models release |
When a better model releases, it goes into the foundation layer. The abstraction layer handles the translation, and that is active work rather than plug-and-play: prompt behavior shifts between models, edge cases surface, evaluation benchmarks get recalibrated. The abstraction layer is a living interface. But the features keep working, now on better capabilities, without being rebuilt.
Today a system might extract 90% of lease terms correctly from a difficult document. When the next generation arrives, accuracy passes 99% and the system handles the handwritten amendments, poor scans and unusual clause structures that previously needed a person. The firm does not rebuild its pipeline. The abstraction layer adapts, the evaluation suite confirms, and the capability improves. The same happens to synthesis of broker communications, analysis of market trends, pattern matching across historical deals, and generation of IC memos and investor reports.
Over five years the gap between the two approaches becomes enormous. One firm compounds. The other rebuilds with every generation.
One System
These six principles are not features to adopt piecemeal. Each depends on the others.
The ontology gives natural-language queries something to traverse. Queries generate the interactions the ledger records. The ledger produces the history that makes the firm-specific system intelligent. Firm-specific design ensures the ontology reflects how the firm actually works rather than a template. The human premium sets the boundary: everything in the world of bits belongs to the system, everything in the world of atoms belongs to people, and the system exists to maximize the time and context available for human judgment. Model agnosticism ensures the whole structure improves over time instead of degrading.
Remove one and the rest weaken. An ontology without a ledger is connected data with no memory. A ledger without firm-specific design is an audit trail of generic assumptions. Answers on demand without an ontology is a search engine.
| Principle | What it enables | What it requires |
|---|---|---|
| One ontology | AI that sees everything and answers in full context | Coherent data modeling across every function |
| Answers on demand | Anyone reaches anything instantly | An ontology to traverse and a natural-language interface |
| Decision ledger | Systematic learning, traceable decisions, contained error | Consistent capture of decisions, rationale and provenance |
| Built to the firm | Differentiation preserved, tribal knowledge encoded | Deep understanding of the firm’s own process |
| Human premium | Time returned to irreplaceable human work | A clear boundary between the system’s territory and people’s |
| Rising with the water | Capabilities improve with every model generation | An abstraction layer between features and models |
The Firm This Produces
A firm built on these principles operates differently from any CRE investment firm before it.
Decisions are made with complete information. Evaluating a deal, the team has instant access to everything the firm has ever learned about that market, that asset type, that tenant and that broker. The IC discussion moves from “does anyone have the data on” to “given everything we know, what is our conviction.”
Knowledge accumulates. Every deal adds to institutional memory. Every decision and its outcome becomes a data point. When people leave, what they knew stays. When people join, they inherit everything the firm has learned.
Speed rises without cutting depth. The firm moves faster because information is instant, processing is automated and people spend their time on judgment. The speed comes from removing waste: hours hunting for data, reformatting spreadsheets, compiling reports by hand, answering the same questions repeatedly. The analysis is deeper because the people doing it have more time and more context.
Judgment improves. The ledger connects decisions to outcomes, patterns emerge, and the firm gets better at knowing which assumptions hold and which risks materialize. A partner’s thirty years become queryable rather than anecdotal.
Differentiation compounds. The system learns the firm’s way of seeing. Competitors on generic platforms converge. This firm diverges, and the longer it operates the wider the gap.
People do human work. Relationships, negotiation, strategy and judgment become the job. The firm attracts better people because the work is better.
The gap widens every year. The AI-native firm compounds: better data, better learning, better capabilities, better people doing better work. The traditional firm runs faster on a treadmill.
Why I Wrote This
The AI-native CRE investment firm is the one with the best operating infrastructure: unified, queryable, auditable, built to the firm, bounded by the human premium, and built to rise.
The technology exists. The architecture is achievable. Nothing here is speculative. It is the convergence of capabilities available today with an industry that has been underserved by technology for decades. The question is which firms rebuild their infrastructure around these principles and which bolt AI onto broken systems.
The firms that get it right will operate at a level the industry has never seen. The firms that do not will keep their fragmented systems, lost knowledge, repeated mistakes, eroded differentiation, and people buried in processing work that machines should do.
I wrote this because the people in this industry are worth more than the infrastructure they have been given. The judgment, the relationships and the institutional knowledge that great firms are built on deserve technology that amplifies them. This is what that technology looks like.
