← Back to Blog
How It Works

How Dubai Offer Verdict Works: Data Source Transparency from DLD to Analysis

DLD official data source transparency over Dubai register motif

Summary

Every number in Dubai Offer Verdict traces back to Dubai Land Department registered data. Here is exactly how DLD transaction and Ejari rental data flows from government source to BigQuery to Claude Sonnet analysis — no black box.

Public data depth by source (illustrative)

DLD / Dubai Pulse95%

Building-level sales, Oqood, Ejari exports

Portal medians35%

Asking prices — useful for discovery, not closes

Broker PDFs20%

Marketing — verify every number against register

Content reviewed: May 23, 2026.

Speed without verified sourcing is noise. We built Dubai Offer Verdict so every broker-offer verdict traces to DLD registered transactions and Ejari where applicable — with optional paid evidence reports on Gumroad. This article documents exactly how that output is produced: from the official government registry, through every technical step, to the model that structures the final verdict. Every number in the system has a traceable origin. This is what that chain looks like.


The Source: Dubai Land Department

Every property transaction figure and rental contract metric in Dubai Offer Verdict traces back to one place: the Dubai Land Department, or DLD. The DLD is the government body responsible for registering real estate transactions, tenancy contracts, and all related property data in Dubai. Its records are the official legal basis for sale prices, rent levels, and transaction volumes — what professionals, regulators, and courts rely on.

The system does not use portal asking prices, broker-reported figures, or third-party listing data. The entire pipeline is built on DLD-sourced datasets: registered transaction records and Ejari registered rent contracts. That keeps every number in the analysis aligned with what the regulator publishes rather than what any market participant chooses to advertise.

This distinction matters because portal asking prices in Dubai typically run 8–13% above DLD registered closing prices, and advertised rents typically run 8–12% above Ejari registered contract rents. Analysis built on portal data produces yield and price figures that are systematically optimistic. Analysis built on DLD data produces figures that reflect what buyers actually paid and what tenants actually registered.


From DLD to Cloud Storage

DLD data enters the infrastructure as structured files — typically CSV exports covering transaction records and rent contract records. These files are stored in a dedicated bucket in Google Cloud Storage.

The two primary datasets are:

Transactions — sale and purchase records including prices, dates, project identifiers, area designations, unit types, and related fields.

Rent contracts — Ejari-registered tenancy data including rent amounts, contract dates, property references, and contract type (new versus renewal).

The same files stored in Cloud Storage are the exact files that feed BigQuery. There are no hidden intermediate sources and no manual edits to the numbers between the DLD export and the database. The upload and refresh frequency tracks DLD export availability.


From Cloud Storage to BigQuery

The CSV files in Cloud Storage are loaded into Google BigQuery using Python scripts. Each script reads a specific dataset — transactions or rent contracts — and loads it into a dedicated BigQuery table using a truncate-and-replace approach. Each run replaces the table with the contents of the latest file. Schemas are applied consistently so that price fields, date fields, and area identifiers are typed correctly and ready for structured querying.

The result is a single source of truth inside BigQuery that maps directly to DLD-sourced data. No numbers are changed or reinterpreted during the load step. It is a direct transfer from government export file to queryable table.


How the product queries the data

When you run /#broker-offer-checker on this website, the system executes structured SQL queries against the BigQuery tables for the matched project and comparable resale window. These queries are defined in the codebase and return specific outputs for that verdict.

The queries return transaction counts, price per sqft (median and trend) for matched resales, completion context where relevant, and — where sufficient Ejari data exists — rental contract counts and rent levels for the building or neighbourhood slice used in the verdict. The query results are assembled into a structured data payload: a clean, typed summary of what BigQuery returned for that specific offer check. That payload is what gets sent to the AI model. The model does not receive raw CSV files, unstructured text, or any data source other than the specific BigQuery output from the DLD-sourced tables.


How Claude Sonnet Turns Data Into Analysis

Claude Sonnet, accessed via the Anthropic API, receives the structured BigQuery payload and produces the analysis sections visible on the website and in paid website reports (after you redeem the USD 50 Gumroad pack).

The model receives two inputs: the structured data payload from the query, and a fixed system prompt. The system prompt describes relevant Dubai market context — regulatory frameworks, supply dynamics, typical yield ranges by community type, known risk factors — and sets explicit rules for how the model must behave when writing analysis.

Those rules are direct: base all quantitative claims only on the data in the payload, do not invent figures, read trend direction from actual data fields rather than inference, and flag data gaps explicitly rather than substituting generic market commentary. If the transaction volume for a project is insufficient to support a yield conclusion, the output must say so.

Claude Sonnet is an interpreter of the data the system queries — not an independent source of market information. It has no internet access during a request, no direct access to DLD or any external database, and no ability to introduce outside data. It works only with the structured payload it receives. That constraint is what makes the analysis auditable: the model cannot produce a number that does not originate in the DLD-sourced BigQuery tables.

The Google Search enrichment in paid website reports operates separately — surfacing developer news, project announcements, and operational cost context — and is clearly marked as supplementary to the core DLD analysis rather than part of the transaction data chain.


What This Means for the Analysis You See

The practical consequence of this architecture is that the figures in any verdict output have a specific, traceable origin.

When a paid website report states a median transaction price of AED 1,340/sqft for a specific project, that figure comes from DLD registered closing prices for that project in BigQuery — not from a portal listing, a broker brochure, or a developer marketing sheet. When it shows a gross yield calculation, the rent figure comes from Ejari registered contracts for that building and the price figure comes from DLD registered transactions for that building.

The DLD data is not perfect. Like any government registry, it has lags between transaction and registration, gaps in project coverage for very new launches with no registered completions, and occasional data quality issues in historical records. Where data is insufficient for a reliable conclusion, the analysis output flags that gap rather than filling it with assumption. A project with fewer than 10 registered transactions in the past 12 months will show a confidence qualifier on its yield and price figures.

The chain is: DLD → Google Cloud Storage → BigQuery → structured query output → Claude Sonnet → verdict. Every link is documented. Every number has a path back to a government-registered source.


Running your own check

The transparency described here is the foundation for every /#broker-offer-checker verdict on this website. To benchmark a concrete broker or resale ask against registered closes:

  1. Open /#broker-offer-checker, pick the project from the DLD-backed index, and enter what you were quoted (size, type, total price).
  2. Read the free first-pass verdict and the plain-English “why” bullets — they are all traceable to the pipeline above.
  3. If you need the full negotiation evidence (exact comps table, broker-question script, counter-offer wording, deeper flags, exports where enabled), buy the paid pack: 5 analyses for USD 50 on Gumroad and redeem your key on the site.

For raw exploration outside the checker, use Dubai Pulse, Dubai REST, and Ejari directly — the same government registers this pipeline ingests.


Before you wire


FAQ

Where does Dubai Offer Verdict get its data? All transaction price and rental yield data traces back to Dubai Land Department registered records. DLD transaction data and Ejari registered rent contract data are loaded from government-sourced CSV exports into Google BigQuery. The offer-check pipeline queries BigQuery directly. No portal asking prices, broker figures, or third-party listing data are used in the core metrics.

What is the difference between DLD data and portal data? Portal platforms publish asking prices and asking rents — what sellers and landlords request, not what buyers pay and tenants register. DLD registered transaction prices are the actual closing prices recorded at government registration. Ejari registered rents are the actual contract amounts registered with the government. Portal asking prices typically run 8–13% above DLD closing prices. Ejari rents typically run 8–12% below portal asking rents. Yield calculations built on portal data are systematically overstated relative to DLD and Ejari-based calculations.

Does Claude Sonnet invent or estimate any figures in the analysis? No. Claude Sonnet receives only the structured data payload returned by the BigQuery queries — which contains only DLD-sourced figures — plus a fixed system prompt. The model's instructions explicitly prohibit inventing figures, inferring numbers not present in the data, or substituting generic market commentary for data gaps. Where data is insufficient for a reliable conclusion, the output is required to flag that gap. The model has no internet access during a request and cannot introduce outside data.

How current is the data? The data is as current as the most recent DLD export loaded into BigQuery. Refresh frequency tracks DLD export availability. There is typically a lag between a transaction occurring and its registration appearing in DLD records — standard for any government registry. Very recent transactions and newly launched projects with no registered completions will not appear in the dataset or will appear with insufficient volume for reliable analysis, which the output will indicate.

Can I see the analysis for a specific project before paying? Yes. /#broker-offer-checker on this website gives a free first-pass verdict for broker resale asks against DLD-registered comps when the project is in the index. If you need the full report layout (negotiation pack, richer comps, service-charge context, alternatives, PDFs where enabled), use the paid pack: 5 analyses for USD 50 on Gumroad (card checkout, license key by email).


Not investment advice. All analysis based on DLD registered transaction data and Ejari registered rental contracts.