×
![Modal Image]()
Our engineering contribution inside Cadastral’s AI platform for commercial real estate, from OCR to billing.
A single commercial real estate document can carry more complexity than its page count suggests. A lease may include amendments, dense tables, scanned pages, legal language, and information that only makes sense in context. Some documents are easy to process. Others expose the limits of a system very quickly: OCR has to interpret the page correctly, extraction has to identify the right fields, and whatever the model returns still needs to be traceable back to the source.
That is a fair summary of the engineering challenge behind this kind of product. Commercial real estate runs on documents: leases, loan agreements, insurance certificates, due diligence files, property records, emails, spreadsheets, and years of folder history. The information is often fragmented, buried in long documents, and spread across systems that do not talk to each other. Vertical AI can do a lot here, not as a chatbot over PDFs, but as a product system built around ingestion, OCR, structured extraction, retrieval, source-grounded answers, permissions, integrations, usage metering, billing, and an experience legal and asset-management teams can trust.
That is the environment Amplified joined as an engineering partner, working alongside a client-led technical team with its own product direction and domain expertise. Our role was not to define the business or own the platform. We contributed to selected product and infrastructure areas, including document intelligence, AI workflows, cloud integrations, permissions, product experience, usage metering, billing, and operational reliability. What made the work interesting was not only the model. It was the system around it.
Commercial real estate teams work with documents that vary widely in structure and quality: scanned PDFs, negotiated and amended leases, loan documents, certificates of insurance, and email attachments. The challenge is not simply accessing that information, but turning it into something the system can reliably interpret and users can work with.
AI in this setting cannot stop at answering one question at a time. The deeper opportunity is turning unstructured documents into structured, reviewable, searchable, reusable information: fields a person can compare, filter, verify, and act on across a portfolio. That takes architecture for the whole document lifecycle, from text extraction and page processing through OCR, field identification, party detection, structured abstractions, partial-result storage, human review, and source references, out to search, tables, chat, and workflow surfaces. None of it reduces to calling a model.
For the user, the flow should feel simple: upload or connect documents, let the system process them, then search, ask, or review. Behind that, the platform had to handle large files, scanned documents, unusual layouts, inconsistent page structures, multi-document imports, and portfolio-level jobs that run for a long time.
Our engineers contributed to processing reliability in the document intelligence layer: durable processing patterns, retry-safe workflows, staged extraction, partial-result handling, and safeguards around expensive operations such as OCR, page processing, chunking, and model calls. Processing had to behave like a resilient workflow rather than a single request and response. It had to resume after an interruption, avoid duplicate outputs, persist intermediate results, recover from partial failure, and stop 1 enormous file from starving everything else. In enterprise AI, reliability is a feature the customer can see.
Users don’t only want to ask what a lease says. They need the fields that matter across a portfolio, dates, parties, clauses, obligations, rents, options, critical rights, and compliance requirements, in a form they can compare and review.
That requires a balance between automation and human judgment. The model can identify and extract, and people still need to inspect sources, edit fields, rerun extractions, and keep a revision history. We contributed to the product and data experiences that made extraction operational: structured abstractions, reviewable fields, reusable document views, and surfaces where AI output became editable, sortable, filterable, source-linked, and reusable. This is where AI engineering turns into product engineering. The model produces a first pass. The system has to make it durable and useful.
Trust in a document-heavy workflow comes from traceability. Nobody working with legal or financial information can accept an answer because it sounds plausible. They need to open the document and confirm the answer came from the right place. So citations and source references are trust architecture rather than a UI nicety, and we contributed to source-grounded answer flows, document references, and viewing experiences that take a person from an answer back to the evidence. A citation has to open the right source, stay attached to the answer, work predictably in a streamed response, and survive the user changing context or coming back later. A missed clause or a misread date can affect a negotiation, a compliance review, or an asset decision, which makes the path back to the page as important as the answer.
As the platform matured, lease abstraction stopped being the only workflow. Credit agreements, certificates of insurance, vendor contracts, loan documents, due diligence packets, deal files, and custom collections all needed support without rebuilding the experience for each. We contributed to more flexible document and collection models: generalized document views, structured abstractions, reusable file-listing patterns, update workflows, and collection-based experiences, so that a PDF viewer, a breadcrumb, a file table, a review surface, and an abstraction flow could serve several document families at once. That’s the difference between a feature and a system.
Enterprise customers won’t rebuild their document libraries by hand. Real estate teams keep files in Google Drive, SharePoint, Box, Dropbox, OneDrive, and similar systems, so a useful platform has to connect to them. We contributed to cloud storage integrations and synchronization: connecting external systems, mirroring document structures, selective sync, change detection, and keeping the in-product view aligned with files that kept changing at the source.
From the user’s side the task is simple: connect the account, choose what to sync, see those documents in the platform. From the engineering side, sync is far more than copying. Folder changes, renames, moves, deletions, permission updates, large hierarchies, interrupted syncs, rate limits, timeouts, differences between providers, and selective visibility all happen while the source keeps changing underneath.
So the layer had to reason about change rather than mirror files: compare external folder structures with the internal document model, tell a deleted file from a moved, renamed, or recreated one, propagate nested permission changes, and recover from partial failure. In public-safe terms, we contributed through snapshot comparison, change detection, selective synchronization, permission-aware syncing, and recovery from interrupted operations. If the system can’t reach the right documents in the right structure with the right permissions, the intelligence layer has nothing to work with.
Trust in enterprise AI is also about who can see what. Because these documents carry sensitive legal, financial, operational, and compliance information, a platform that searches and summarizes them has to respect access. The principle we worked to was that collaboration should never weaken security.
If someone shares an AI conversation that references sensitive documents, access to the thread isn’t enough. The system has to check whether the recipients can see the underlying material, especially when an answer draws on several documents, folders, records, organizations, workspace roles, or external cloud permissions. We contributed to permission-aware workflows, role-based access, and collaboration patterns around AI output: sharing conversations, guarding actions by access, improving member management, and making permissions clearer in the interface.
As the platform moved into larger organizations, access control had to support structured roles such as administrators, content managers, billing users, team members, and viewers. Restricted actions should be hidden, disabled, or explained. Permission loading states should never flash the wrong thing. Invite and role-management failures should return a message a person can act on. For an enterprise customer, permissions are part of the product, whatever the org chart calls them.
AI may be the headline, and the surrounding experience decides whether people come back. As the platform grew across document management, the assistant, collections, notifications, settings, billing, permissions, and data tables, we contributed to interface work that moved it toward a unified design system: design tokens, reusable components, page redesigns, responsive edge cases, and the removal of legacy patterns once the new experience was stable.
Before anyone can ask a good question, they have to find, browse, preview, move, upload, and select the right documents while the system handles duplicates, long names, and unusual file types. We contributed to recursive folder search, file previews, drag-and-drop file movement, attachment modals, upload flows, and shared state-management patterns that cut down on inconsistent counts and stale selections. The same discipline carried into structured data: editable columns, column-level filtering, pinned columns, saved table configurations, and per-user view persistence.
The assistant was part of this too. Behind a simple flow, select documents, ask, read the answer, open the source, there is a process that prepares context from a lease, a building, a folder, or a portfolio, manages long-running model calls, streams partial responses, tracks usage, and stores references. We contributed to parts of the chat and attachment experience, including file selection, previewing, attachment state, history, and source navigation. People shouldn’t need to understand retrieval, embeddings, or streaming to get value. They need to know what the system used, what it found, and where the answer came from.
Then there’s money. As AI-native products mature, commercial operations become an engineering problem: usage tracked, AI actions metered, and billing that supports subscriptions, credits, invoices, overages, and usage-based pricing. We contributed to metering AI actions such as chat, deep research, and document abstraction, to billing and credit workflows, and to the reliability of data synchronization between the product and the billing system. The pattern that mattered most was idempotency. Billing has to handle duplicate, delayed, and out-of-order events without double charges, missing records, or inconsistent balances, and if the same event arrives twice the result has to stay safe. None of it shows in the interface, and all of it decides whether a customer is billed correctly for the AI they used.
Email intake followed the same logic, since deal context often arrives as attachments and threads, and we contributed to authentication and ingestion flows for external communication sources. And because speed alone isn’t enough when the product handles legal-grade documents, we contributed to infrastructure reliability and observability: dedicated processing capacity for different workload types, monitoring and tracing of expensive operations, safer release plumbing, and testing environments. Document processing, OCR, model calls, cloud sync, permission checks, and billing all have different performance profiles, and if they aren’t isolated and monitored, a spike in 1 hurts the rest.
We didn’t work in isolation. Our client had its own engineers, product direction, domain expertise, and architectural context, and our people contributed inside that: taking ownership of selected areas, implementing features, hardening workflows, and strengthening parts of the system.
That took more than code. Requirements moved quickly, customer needs shifted, model capabilities changed, and edge cases arrived from production. Being useful meant communicating clearly, working autonomously, and translating complex product goals into systems a team could understand and maintain. Our value was focused execution: improving the parts of the product we touched, within the client’s direction, without overstating what we owned.
If you’re building a vertical AI product, here’s the question we’d ask you: which layer around your model is the one you haven’t built yet?
The collaboration took place during a period of public momentum for Cadastral. In February 2026, the company announced a $9.5 million fundraise to support its work building a vertical AI platform for commercial real estate. Later, Legora announced its acquisition of Cadastral, positioning the product’s capabilities within a broader AI-native legal intelligence platform for commercial real estate.
For Amplified the point isn’t a claim on that outcome. No engineering partner gets to make 1. The point is what a product engineering team can do inside an ambitious, client-led AI effort: strengthen selected parts of the platform alongside the client’s own people, across document intelligence, AI workflows, integrations, access control, product experience, metering, billing, and reliability.
That’s usually where the real work of enterprise AI happens: in the systems around the model that make it useful and trustworthy where people make decisions that matter. Let's build together.
