When a firm buys an AI document tool, it usually grades the summary: the paragraph the model writes about the lease, the memo it drafts about the deal. That is the wrong thing to grade. Structured data extraction is the real product. The valuable output is not the prose a human reads once and closes. It is the set of normalized fields that flows into a model, a database, and a portfolio, and keeps paying out every time someone queries it. The summary is consumed and discarded. The structured record compounds. A firm that optimizes for the readable narrative is buying the disposable half of the tool and leaving the durable half on the table.
Key Takeaways
The summary is read once and thrown away. The structured record is queried for the life of the asset. Only one of them is an asset in the accounting sense.
IDC projects that 80% of the global datasphere will be unstructured by 2025. Extraction is the step that moves a document across that line, and a summary never crosses it.
Gartner puts the average cost of poor data quality at $12.9 million per year per organization. A summary cannot carry a validation rule, a data type, or a source citation. A structured field can.
A summary answers one question. A structured dataset answers questions nobody has asked yet, including the portfolio-level query that spans a thousand documents.
The test of an extraction tool is not how well it writes. It is whether its output is typed, normalized, validated, and traceable to the page it came from.
What Is the Difference Between a Summary and Structured Data Extraction?
A summary is prose a person reads: a paragraph describing a lease or a deal. Structured data extraction produces typed, labeled fields: base rent as a number, commencement as a date, renewal options as a repeatable record. The summary is built for one human reading once. The structured output is built for every system and query that comes after.
Consider a single clause: "Tenant shall pay base rent of $32.00 per rentable square foot per annum, escalating three percent (3%) annually, commencing on the Rent Commencement Date." A summary restates it in a sentence. A structured extraction returns something a machine can act on.
Field | Value | Type |
|---|---|---|
base_rent_psf | 32.00 | number (USD/SF/year) |
escalation_type | fixed | enum |
escalation_rate | 0.03 | number (percent) |
escalation_frequency | annual | enum |
rent_start | Rent Commencement Date | date reference |
The sentence and the table carry the same facts. Only the table can be summed across a portfolio, checked against a validation rule, sorted by escalation rate, or fed into a discounted cash flow model without a human retyping it. The summary is a dead end. The table is an input.
Why Does Structured Data Compound While a Summary Depreciates?
Structured data compounds because it is reusable across questions and systems, while a summary is written for a single reading and loses value the moment that reading ends. A normalized field enters a database and answers a new query every quarter. Prose answers the one question it was written for and then sits inert in a folder.
The economics are the difference between a consumable and an asset. A summary is a consumable: produced, read, discarded, reproduced when the question comes up again. Structured data is an asset: extracted once, then queried, joined, and modeled indefinitely.
Take a firm screening 400 offering memorandums a quarter. Assume each OM yields roughly 40 fields worth capturing, and that an analyst retypes those fields into a model at a fully loaded cost of $60 an hour, spending 45 minutes per document on data entry alone. That is 400 times 0.75 hours, or 300 hours a quarter, about $18,000, spent moving numbers that already existed from one format to another. If the output of that labor is only a set of models, the structured data is thrown away at the end of each deal, because it was never stored as data in the first place. Next quarter the same fields on comparable properties get retyped from scratch. The work does not compound because the product was treated as prose.
Now store the same 400 extractions as structured records. The 300 hours still happen once, but the output persists. Rent comps, expense ratios, and tenant rosters accumulate into a proprietary dataset the firm can query the next time a deal in the same submarket lands. The labor was identical. The decision to keep the structured output rather than the summary is what converts a recurring cost into a compounding asset.
Why Can't a Summary Carry Data Quality?
A summary cannot carry data quality because prose has no schema to validate against. There is no data type to enforce, no range to check, no required field to flag as missing, and no cell to attach a source citation to. Quality controls operate on structured fields. On a paragraph, they have nothing to grab.
This is not a stylistic preference. Gartner estimates that poor data quality costs the average organization $12.9 million per year, a figure drawn from a survey of 154 reference customers of data quality vendors. The controls that prevent those losses, type enforcement, range validation, completeness checks, and provenance, are all operations on structured data.
Data quality control | Works on a structured field? | Works on a summary? |
|---|---|---|
Type enforcement (is base rent a number?) | Yes | No |
Range validation (is the cap rate between 3% and 12%?) | Yes | No |
Completeness (is the expiration date missing?) | Yes | No |
Source citation (which page did this come from?) | Yes | Rarely, and never per field |
Cross-document reconciliation | Yes | No |
A summary that says a lease "has strong renewal terms" cannot be validated, reconciled, or cited at the field level. A structured record that says renewal_option_count equals 2, each with a defined notice window and a page reference, can be checked by a rule and traced to its source. The audit trail that makes an extraction defensible to an investment committee lives in the structured layer, not the prose. This is the same reason source citations matter more than raw accuracy in an extraction tool: a citation attaches to a field, not to a paragraph.
What Should Firms Actually Evaluate in an Extraction Tool?
Firms should evaluate the structured output, not the writing. Test whether every field is typed, whether formats are normalized across source documents, whether values are validated against rules, whether each field cites its source page, and whether the output loads into a model or database without a human retyping it. The summary is a byproduct.
The reason this matters is that unstructured content is where most information already lives, and extraction is the only bridge to a usable format. IDC projects that 80% of the global datasphere will be unstructured by 2025, and CRE runs on exactly that: leases, offering memorandums, rent rolls, and operating statements in PDF. A tool that turns those into more prose has not solved the problem. It has reformatted it. A tool that turns them into normalized, validated, traceable fields has moved the information across the line that separates a document from a dataset.
Two hard cases separate real structured extraction from a summary dressed up as data. The first is table extraction, where most CRE document AI still fails: a rent roll's grid of tenants and terms has to survive as rows and columns, not collapse into a paragraph. The second is normalizing ten different rent roll formats into one clean schema, because a field is only compoundable if it means the same thing across every document that feeds it. A tool that writes a fluent summary but fails both of these is optimizing the disposable output.
Frequently Asked Questions
What is structured data extraction?
Structured data extraction is the process of pulling specific facts out of a document and returning them as typed, labeled fields rather than prose. In commercial real estate, it means turning a lease or offering memorandum into normalized values, rent as a number, dates as dates, options as repeatable records, that a model or database can use directly.
Is the AI summary useless then?
No. A summary is a fast way for a human to orient before diligence, and it has real value at the moment of reading. The argument is about durability, not utility. The summary is consumed once, while the structured data is queried for the life of the asset, so the structured output is what a firm should evaluate and keep.
Why does structured data matter more for a portfolio than a single deal?
Because portfolio questions span many documents at once, and only structured data can be aggregated. A summary answers a question about one lease. A structured dataset answers a question about every lease, which tenant concentration is riskiest, which submarket has the widest loss to lease, a question no single summary can reach.
How do you know if a tool produces real structured data?
Check whether the output is typed, normalized across formats, validated against rules, and traceable to the source page, and whether it loads into your model without retyping. If the primary deliverable is a paragraph a person reads, the tool is selling the summary and treating the structured data as an afterthought.
Conclusion
The summary is the part of an AI extraction tool that demos well, because it is legible to a human in the first ten seconds. That is exactly why it is the wrong thing to grade. Legibility to one reader at one moment is not the same as value to a firm over the life of an asset. The structured record is harder to appreciate in a demo and worth far more in production, because it is the only output that survives past the first reading.
Operators who understand this stop asking whether the model writes a good paragraph and start asking whether its structured output is typed, normalized, validated, and cited. A firm that keeps the summary and discards the structured record has kept the receipt and thrown away the purchase.
Related
Document AI
Sources
IDC, "Worldwide Global DataSphere Forecast," cited for the projection that 80% of the global datasphere will be unstructured by 2025.
Gartner, "How to Improve Your Data Quality," reporting an average cost of poor data quality of $12.9 million per year per organization, based on a survey of 154 reference customers.