# Dubai transaction query revisions: cut-offs and reproducibility, 26 September 2026

> A controlled DLD re-query shows one removed row, a stable same-day repeat, exact cut-offs, hashes, field definitions and a reproducible method.

Source: https://withlida.com/insights/dubai-transaction-query-revisions-26-september-2026

---

:::intro
The same official Dubai Land Department residential-sales query for 18 to 24 September 2026 returned **2,348 records at 10:25:30 GST on 25 September and 2,347 at 06:19:47 GST on 26 September**. The AED total was lower by exactly **AED 2,423,000.00** in the later snapshot, while a second extraction 150 seconds later returned the same normalized row set.
:::

:::summary
- One actual revision was observed: the normalized DLD row population changed from 2,348 records to 2,347 between the 25 and 26 September extraction cut-offs.
- The returned value changed from AED 5,561,538,842.07 to AED 5,559,115,842.07, a difference of AED 2,423,000.00; the median remained AED 1,320,000.00.
- Two fresh runs on 26 September, 150 seconds apart, both returned 2,347 records and the same normalized-row hash.
- A full raw-file hash changes when the response timestamp changes. A normalized-row hash tests whether the returned data population changed.
- A reproducible DLD result needs the query bytes, raw response, response timestamp, hashes, calculation code and publication cut-off kept together.
:::

## The saved result changed by one row

The row population changed once across the three saved snapshots, then remained stable during the same-day control. The filter selections match the fields on the [DLD Real Estate Data](https://dubailand.gov.ae/en/open-data/real-estate-data/) interface. The saved request body was identical each time; only the response cut-off changed.

| Official DLD snapshot | Records | Returned value | Median row value | Normalized row set |
|---|---:|---:|---:|---|
| 25 Sep 2026, 10:25:30 GST | 2,348 | AED 5,561,538,842.07 | AED 1,320,000.00 | `82986ae87e2a...` |
| 26 Sep 2026, 06:19:47 GST | 2,347 | AED 5,559,115,842.07 | AED 1,320,000.00 | `7597cc066370...` |
| 26 Sep 2026, 06:22:17 GST | 2,347 | AED 5,559,115,842.07 | AED 1,320,000.00 | `7597cc066370...` |

Source: three saved official DLD transaction responses for the 18 to 24 September 2026 filter, extracted at the timestamps shown. The [DLD Real Estate Data](https://dubailand.gov.ae/en/open-data/real-estate-data/) page provides the current interface and filter context, not these historical row snapshots. Sums and medians were recomputed from the saved rows with Decimal arithmetic.

The neutral read: the first fresh result had one fewer row and AED 2,423,000.00 less returned value than the saved 25 September result, both differences equal to -0.04%. The median difference was AED 0.00. The identical normalized hashes in the two fresh runs mean no further row-content change was observed during their 2-minute, 30-second interval.

::figure{src="images/blog/dubai-transaction-query-revisions-26-september-2026/inline-1.png" alt="Three DLD snapshots show 2,348 records followed by two stable results of 2,347" caption="The same query changed by one row between 25 and 26 September, then held the same normalized population across the two fresh runs."}

This test starts with the raw response behind [yesterday's verified week-ending 24 September pulse](/insights/dubai-residential-transactions-week-ending-24-september-2026). It does not repeat that article's weekly breakdown. It asks a different question: what happens when its exact query is run again?

## Transaction date, extraction time and publication date are different clocks

The transaction date belongs to each returned row; the extraction time belongs to the response; the publication date belongs to this report. Treating them as one date makes a live query look more final than the evidence supports.

| Date or time | What it identifies | Value in this test | Source |
|---|---|---|---|
| Filter window | The From and To inputs sent to DLD | 18 to 24 Sep 2026 | Saved request; current filter context at [DLD Real Estate Data](https://dubailand.gov.ae/en/open-data/real-estate-data/) |
| Transaction Date | DLD's public label for the date attached to a sales row | Returned range was 17 Sep 2026 at 15:15:27 to 24 Sep 2026 at 15:13:30 | [DLD Real Estate Data](https://dubailand.gov.ae/en/open-data/real-estate-data/) and saved rows |
| Extraction cut-off | The response `timeStamp` when that snapshot was produced | 25 Sep at 10:25:30 GST; 26 Sep at 06:19:47 and 06:22:17 GST | Saved official responses |
| Publication date | The editorial date attached to this report | 26 Sep 2026 | This publication record |
| Registration Type | A category, Ready or Off Plan, not a date | Both types were left open in the query | DLD interface and saved request |

The returned minimum `INSTANCE_DATE` falls on 17 September even though the From input was 18 September. This report preserves the official response boundary. It does not silently remove that row or convert the filter into a midnight-to-midnight definition that the response itself does not show.

The public sales response does not supply a separate per-row registration-date field. It supplies Transaction Date and Registration Type. The extraction cut-off is therefore the response timestamp, not a presumed registration date.

## The query must be frozen before the total

The reproducible population is Residential Sales for the exact DLD filter window, with every other listed dimension left open. A total without these inputs is not the same analytical object.

| Query field | Exact value sent | Population effect | Official evidence |
|---|---|---|---|
| From and To | `09/18/2026` to `09/24/2026` | Applies DLD's date-filter boundary | [DLD Real Estate Data](https://dubailand.gov.ae/en/open-data/real-estate-data/) |
| Transaction Type | Sales, `P_GROUP_ID=1` | Excludes Mortgages and Gifts | Same official interface and saved response labels |
| Usage | Residential, `P_USAGE_ID=1` | Excludes Commercial and Other usage | Same official interface and saved response labels |
| Registration Type | Blank | Includes Ready and Off Plan rows | Saved request |
| Freehold, Area, Property Type | Blank | Applies no further filter on those fields | Saved request |
| Page request | Take 5,000; skip 0 | Requests the first 5,000 rows | Saved request |
| Sort | `INSTANCE_DATE_DESC` | Orders rows by the returned transaction-date field | Saved request |

Source: the official [DLD Real Estate Data](https://dubailand.gov.ae/en/open-data/real-estate-data/) interface, checked 26 September 2026, plus the exact saved request and three saved official responses extracted at the stated cut-offs. The interface page supplies current filter context; it does not expose those historical rows.

Each response repeated a `TOTAL` equal to the number of saved rows. The largest result had 2,348 rows, below the 5,000-row request. That makes the response internally complete for this request; it does not turn the snapshot into a permanent historical version.

The broader [DLD data-source map](/insights/dubai-dld-real-estate-data-sources-2026) explains which official surface fits transactions, rents, projects and other questions. This method stays inside one transaction population.

## The field dictionary prevents category drift

The calculation uses DLD's returned labels as they stand. It does not translate Unit into apartment, Ready into completed construction evidence, or a response row into a unique legal file.

| Returned field | Meaning used here | Treatment in the calculation | Source |
|---|---|---|---|
| `TRANSACTION_NUMBER` | DLD's returned transaction identifier | Counted for a distinct-identifier check | Saved DLD rows |
| `INSTANCE_DATE` | The row's Transaction Date field | Used only for returned range and sorting | DLD public output label and saved rows |
| `GROUP_EN` | Transaction family | Required to equal Sales | Saved DLD rows |
| `USAGE_EN` | Usage category | Required to equal Residential | Saved DLD rows |
| `IS_OFFPLAN`, `IS_OFFPLAN_EN` | Registration Type flag and label | Preserved as Ready or Off Plan | DLD public output label and saved rows |
| `IS_FREE_HOLD_EN` | Freehold label | Preserved, not filtered | DLD public output label and saved rows |
| `AREA_EN` | DLD area label | Preserved exactly | Saved DLD rows |
| `PROP_TYPE_EN` | DLD Property Type | Preserved as Unit, Building or Land | DLD public output label and saved rows |
| `TRANS_VALUE` | Returned Amount | Converted from its saved value to Decimal before sums and medians | DLD public output label and saved rows |
| `RN`, `TOTAL` | Page row number and repeated response total | Audited, then excluded from the normalized content hash | Saved DLD rows and calculation method |

Source: [DLD Real Estate Data](https://dubailand.gov.ae/en/open-data/real-estate-data/), checked 26 September 2026, plus the three official saved responses.

The first snapshot had 2,348 distinct transaction numbers across 2,348 rows. Each fresh snapshot had 2,347 distinct numbers across 2,347 rows. That equality is a control for this population, not a rule that every DLD query always has one row per identifier.

## Two hashes answer different audit questions

The full-file hash proves which exact response file was used; the normalized-row hash tests whether the substantive returned row population matches. Both are needed because a fresh response carries a fresh timestamp even when its rows are unchanged.

| Artefact | SHA-256 | What the comparison showed | Source period |
|---|---|---|---|
| Exact query JSON | `8dad1fecf248b1c67558aadf27793821aff00d1a7acd90c758a85ec2a9dc1f91` | One request body controlled all runs | Saved 18 to 24 Sep 2026 query |
| 25 Sep raw response | `b7241c47e7b0bcf7a9be59939894e9b14827e65ae671ce1d08600fc4c8153a3d` | Exact file behind the earlier cut-off | Extracted 25 Sep 2026 |
| 26 Sep run A raw response | `5d56d7ac667cede27df0b45245f6ee79771fd8c05de7588d77054e5cacd4577d` | Different file and different row population | Extracted 26 Sep 2026 |
| 26 Sep run B raw response | `25f16c2ec995c2e52caa2584f93b5d0611e0700176398212b5d9ac53e4f2cc78` | Different file, same normalized rows as run A | Extracted 26 Sep 2026 |
| 26 Sep normalized rows | `7597cc06637036db6bad603792d777d13c9d8b3a51b4b894fc6f6bde06e61ec3` | Identical in run A and run B | Extracted 26 Sep 2026 |

Source: SHA-256 hashes calculated from the saved official DLD responses and the exact query file on 26 September 2026.

The normalization sorts every row and excludes only `RN` and the repeated `TOTAL` before hashing. Row membership and every other returned field remain in the fingerprint. That is why the 25 September normalized hash differs from 26 September, while both 26 September normalized hashes match.

:::aside{title="Method aside: when to use the word revision"}
A new raw-file hash alone is not evidence of a revised population because the response timestamp also changes. This report calls the 25-to-26 September difference a revision only because the normalized row set changed. It calls the 150-second control stable only because the normalized row sets were identical. Neither label predicts whether a later extraction will match.
:::

## Reproduce a dated result in six saved steps

A reproducible result freezes the question, input, output, calculation and editorial cut-off as one evidence bundle. Re-running the live query later answers a new as-of question.

| Saved artefact | Minimum content | Audit question it answers | Evidence in this test |
|---|---|---|---|
| Query file | Every filter, page limit, offset and sort | Was the population definition identical? | One JSON file, one query hash |
| Raw response | Complete unedited server output | Which exact rows existed at that cut-off? | Three complete JSON responses |
| Response time | Timestamp and timezone from the server | When did this snapshot exist? | Three `timeStamp` values in GST |
| Calculation program | Decimal parsing, counts, sums, median and assertions | Can every displayed metric be regenerated? | One saved program and JSON output |
| File and row hashes | Raw-file and normalized-row SHA-256 | Did bytes change, and did row content change? | Four artefact hashes plus two normalized populations |
| Publication record | Date and named source cut-off | Which snapshot did the article report? | 26 Sep 2026 publication, 06:22:17 GST final data cut-off |

Source: the saved 25 and 26 September 2026 official DLD responses, exact query, `recompute.py` and its machine-readable output.

::::steps
:::step{title="Name the population"}
Write the date window, transaction type, usage and every open dimension before running the query. “Dubai transactions” alone is not a reproducible scope.
:::
:::step{title="Save the exact request"}
Keep the JSON bytes that were sent, then hash that file. A later analyst can distinguish a data revision from a filter change.
:::
:::step{title="Keep the raw response untouched"}
Store the complete response before opening it in a spreadsheet or transforming a field. Record the endpoint, response timestamp and timezone beside it.
:::
:::step{title="Calculate from saved rows"}
Parse each `TRANS_VALUE` as Decimal. Recompute the count, sum and median from the rows, and assert that the repeated DLD `TOTAL` equals the saved row count.
:::
:::step{title="Compare content, not only bytes"}
Hash the raw file for exact identity. Separately sort and hash normalized rows so a new response timestamp does not masquerade as a population revision.
:::
:::step{title="Publish the cut-off"}
Put the query period and final extraction time beside the number. If a later run differs, publish it as a new snapshot or a documented revision, not as an invisible replacement.
:::
::::

::figure{src="images/blog/dubai-transaction-query-revisions-26-september-2026/inline-2.png" alt="Five-stage reproducibility path from query to raw JSON, hash, Decimal calculation and publication" caption="The audit trail keeps the request, response, hash, calculation and publication cut-off together."}

## The observed revision proves a difference, not its cause

The saved responses establish that one row left this query population between the two cut-offs. They do not establish why it left or what happened in any private transaction file.

| Established by the saved evidence | Not established by the saved evidence | Required additional evidence |
|---|---|---|
| One Ready, Residential, Free Hold, Land row dated 24 Sep 2026 at 13:33:51 was present first and absent later | Whether it was corrected, cancelled, reclassified or temporarily omitted | An official revision note or a transaction-specific record explicitly proving the cause |
| Its returned value was AED 2,423,000.00 | The parties' contractual position, payment history or completion status | The relevant official record and supplied transaction documents |
| The total and count were each -0.04% at run A versus the earlier snapshot | A citywide price movement or a forecast | A dataset and method designed for that separate question |
| Run A and run B matched for 150 seconds | That the population will never change again | A later dated extraction using the same query |

Source: row-level diff of three saved official DLD transaction responses extracted 25 and 26 September 2026. The resolving [DLD Real Estate Data](https://dubailand.gov.ae/en/open-data/real-estate-data/) page is linked for current interface context, not as a host for the saved historical rows.

No SPA, valuation, offer, receipt, bank statement, completion statement or other transaction-specific document was supplied for this report. The method therefore stops at the public row-set evidence.

## FAQ, checked 26 September 2026

::::faq
:::faq-item{q="Why can the same Dubai transaction query show a different total?"}
This controlled test proves that the same saved [DLD Real Estate Data](https://dubailand.gov.ae/en/open-data/real-estate-data/) inputs returned one fewer row on 26 September than at the 25 September cut-off. The public response does not identify the cause, so this report does not assign one.
:::

:::faq-item{q="How do I check Dubai real estate transactions?"}
Use the official [DLD Real Estate Data](https://dubailand.gov.ae/en/open-data/real-estate-data/) interface for current data. Record the From and To dates, Transaction Type, Registration Type, Freehold, Area, Usage and Property Type selections, then save the output and extraction time together.
:::

:::faq-item{q="Is transaction date the same as extraction date?"}
No. DLD labels the row field Transaction Date, while the response `timeStamp` records when that query snapshot was produced. This report was published on 26 September 2026 using a final data cut-off of 06:22:17 GST that day.
:::

:::faq-item{q="Which DLD transaction total is correct when two snapshots differ?"}
Each total is a dated result for its named query and extraction cut-off. For the 18 to 24 September 2026 population, 2,348 records is the 25 September snapshot and 2,347 records is the later 26 September snapshot.
:::

:::faq-item{q="Does a matching raw-file hash prove the rows are unchanged?"}
A matching full-file hash proves identical bytes. In this test the fresh raw-file hashes differed because their response timestamps differed, while the normalized-row hash matched and established that the row content was stable across the 150-second control.
:::
::::

:::callout{variant="info" title="Subscribe for the next report"}
Subscribe to the withlida market-data briefing for the next transaction report and its dated source notes.
:::