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.

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 interface. The saved request body was identical each time; only the response cut-off changed.

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 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.

This test starts with the raw response behind yesterday's verified week-ending 24 September pulse. 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.

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.

Source: the official DLD 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 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.

Source: DLD 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.

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.

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.

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

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

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.

Source: row-level diff of three saved official DLD transaction responses extracted 25 and 26 September 2026. The resolving DLD 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

Why can the same Dubai transaction query show a different total?+

This controlled test proves that the same saved DLD 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.

How do I check Dubai real estate transactions?+

Use the official DLD 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.

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.

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.

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.