Dubai REST Parity Plan — The brokerage client Concierge Intelligence Layer
Goal: give the the brokerage client platform's AI concierge the full knowledge and computational
capability of Dubai REST (DLD's official platform), grounded in the same
government data, with zero pretense of government authority.
---
0. Ground rules (the no-assumptions foundation)
1. **Knowledge and computation are replicable; authority is not.** Dubai REST
issues title deeds, executes Ejari registrations, files disputes. Those are
sovereign acts. Our concierge computes, explains, verifies against open
data, prepares, and deep-links to the official service — it never claims to
issue, register, or certify.
2. **Every number traces to a source.** Indexes come from DLD's own published
transaction data (Dubai Pulse), not model guesses. Every computed answer
carries its data vintage ("based on DLD transactions through <date>").
3. **Dubai data is Dubai-only.** RAK (NH Collection RAK) has no Dubai
Pulse equivalent. RAK answers come from the verified `brokerage-knowledge-base`
layer + RERA-RAK/Law 12/2023 rules already researched for the SPA engine.
The bot always knows which jurisdiction it's answering for.
4. **The bot never does math in prose.** All computation goes through
deterministic tools (fee calculator, yield calculator, index query). LLM
arithmetic is a known failure mode; tool calls are auditable.
1. Dubai REST capability inventory → parity classification
| # | Dubai REST capability | Class | Our implementation |
|---|---|---|---|
| 1 | Sale index / price trends by area & period | **A — full parity** | Materialized views over ingested DLD transactions (1.5M+ rows, 46 cols) |
| 2 | Rental index by area & period | **A** | Ejari rent-contracts dataset (4M+ contracts) → median/percentile views |
| 3 | Rental return (gross yield) on a property | **A** | yield tool: rent index ÷ sale index for matched area/type |
| 4 | Service charge index | **A-** | DLD publishes per-project service charges; ingest where available, else explain + link |
| 5 | Broker verification + performance | **A** | Broker open dataset → lookup tool ("is BRN X licensed?") |
| 6 | Certified developer / project directory | **A** | Developer + project datasets → lookup tool |
| 7 | Valuation estimate | **A- (estimate, not certificate)** | Comparable-transactions model (same area/type/size window); clearly labeled estimate; official valuation = deep-link |
| 8 | Transaction fee math (4% transfer, Oqood 4%, trustee fees, mortgage 0.25%, knowledge/innovation fees) | **A** | Deterministic fee calculator tool, jurisdiction-aware (RAK fees differ — e.g. AED 3,000 off-plan transfer service) |
| 9 | Off-plan project tracker (completion %, escrow no., payments due) | **A for the brokerage client inventory / B for others** | Our own projects: live from CRM (unit ledger, milestones, escrow refs — already built). Other developers' projects: open project-status data + link |
| 10 | Real-estate wallet (my properties, my payments) | **A for the brokerage client buyers** | Buyer portal view over `deal`, `payment_milestone`, `pdc` — our schema already holds this |
| 11 | Ejari register/renew/cancel | **B — guided workflow** | Step-by-step guidance + document checklist + deep-link to official service |
| 12 | TWIMC letter, map issuance, mortgage bid requests | **B** | Explain + checklist + deep-link |
| 13 | Rental dispute filing | **B** | Explain rights (Law 26/2007, 33/2008, RDC) + link; never legal advice |
| 14 | Title deed issuance / official certificates | **C — never** | Explicit: "issued only by DLD; here's exactly how" |
| 15 | Noqodi payment execution | **C** (their rail) | Our payments run through our escrow flow; DLD fees paid on their portal |
Class A = full computational parity from open data. B = concierge workflow +
official deep-link. C = out of bounds by design, redirected gracefully.
2. Architecture (three layers on the existing stack)
```
┌──────────────────────────────────────────┐
│ CONCIERGE (Claude, tool-use, multilingual)│
│ system prompt: jurisdiction router, │
│ authority guardrails, citation policy │
└────────┬──────────────────┬───────────────┘
│ RAG retrieve │ tool calls
┌────────────▼───────┐ ┌───────▼─────────────────┐
│ KNOWLEDGE LAYER │ │ COMPUTATION LAYER │
│ pgvector in `brokerage` │ │ Postgres functions + │
│ • DLD service docs │ │ API routes: │
│ • laws & guides │ │ • fee_calc(jur, price,…) │
│ • RAK KB (verified)│ │ • yield(area, type) │
│ • FAQ corpus │ │ • price_index(area, t) │
└────────────────────┘ │ • rent_index(area, t) │
│ • broker_verify(brn) │
┌────────────────────┐ │ • valuation_estimate(…) │
│ DATA LAYER │◄─┤ • project_lookup(name) │
│ `market` tables: │ └──────────────────────────┘
│ transactions, rents,│
│ brokers, developers,│ nightly ingest ◄── Dubai Pulse
│ valuations, projects│ (CSV bulk + OAuth API delta)
└────────────────────┘
```
2.1 Data layer — `market` schema (new isolated schema, your pattern)
Dubai Pulse offers both bulk CSV and an OAuth client-credentials API
(`api.dubaipulse.gov.ae`, Bearer token, filterable). Ingestion plan:
- **Initial load:** bulk CSVs (transactions, rent contracts, brokers,
developers, valuations, projects/buildings/units) → staging → typed tables.
Practical scoping decision: load transactions from 2015→present (~1M rows;
Supabase-comfortable) rather than full 2004 history; keep full history in
cold storage if ever needed.
- **Refresh:** nightly Vercel cron → Dubai Pulse API delta by date filter →
upsert. Broker/developer directories refreshed weekly.
- **Derived views (the "indexes"):** materialized views refreshed post-ingest:
`sale_index(area, property_type, period)` — median & p25/p75 price and
price/sqm, volume; `rent_index(...)` — median annual rent, renewal vs new;
`yield_matrix(area, type)` — rent median ÷ price median.
- Provenance columns on every row: `source_dataset`, `ingested_at`.
2.2 Knowledge layer — extends the existing RAG + pgvector
Corpus, chunked and embedded into the pattern already live on the platform:
1. DLD service catalog + user guides (what each service is, requirements,
fees, steps, links) — scraped from dubailand.gov.ae public pages, refreshed
monthly, each chunk carrying its source URL.
2. Legal layer: Dubai (Law 7/2006, 13/2008, 8/2007, Ejari laws) and RAK
(Emiri Decree 22/2008, Law 12/2023) — summaries with citations, from the
SPA-engine research.
3. The existing verified `brokerage-knowledge-base.md` (founders, NH Collection,
RAK market data) — already built.
4. FAQ corpus: fees, Golden Visa property thresholds, off-plan buyer rights,
escrow protections, freehold zones — each answer pre-cited.
Chunk metadata: `jurisdiction` (dubai | rak | federal), `topic`, `source_url`,
`last_verified`. The retriever filters by jurisdiction first — this is what
prevents the classic failure of quoting Dubai's 4% fee for a RAK deal.
2.3 Computation layer — deterministic tools
Implemented as Postgres functions + thin API routes; the concierge calls them
via tool use and formats results. Core set:
| Tool | Input | Output |
|---|---|---|
| `fee_calc` | jurisdiction, price, mortgage?, off-plan? | itemized: transfer/Oqood %, trustee, knowledge/innovation, mortgage reg, total |
| `price_index` | area, type, period | median, p25/p75, AED/sqm, volume, YoY |
| `rent_index` | area, type, period | median rent, distribution, YoY |
| `yield_calc` | area, type (or specific unit price + rent) | gross yield %, vs city median |
| `valuation_estimate` | area, type, size, age | comparable-window estimate + confidence band + "not an official valuation" |
| `broker_verify` | BRN or name | licensed?, office, status (from DLD dataset) |
| `project_lookup` | project/developer name | registration status, developer, escrow presence |
| `brokerage_unit_status` | unit code | live from our CRM (auth-scoped) |
| `roi_model` | already built on the landing page | reuse, now fed by real indexes |
Every tool response includes `data_as_of` so the concierge can (must) state
data vintage.
2.4 Concierge orchestration
- **Jurisdiction router** first: RAK question → RAK KB + RAK fee rules; Dubai
question → market data + Dubai rules; ambiguous → ask one clarifying
question.
- **Authority guardrails** in the system prompt: never claim to issue/register/
certify; Class-C intents get the "here's how, on the official portal"
pattern with the exact DLD deep-link; no legal advice — explain the law,
recommend counsel for decisions.
- **Multilingual** rides the existing Option-A layer (language detection via
system prompt). Legal terms keep the English/Arabic official term in
parentheses on first use.
- **Citations:** RAG answers cite source URL + last-verified; computed answers
cite dataset + vintage.
3. What this gives the brokerage client that even Dubai REST doesn't have
- Dubai REST is a lookup platform; ours is **conversational** across all of it
("what's my total cost buying a 2BR in JVC at 1.8M with a 60% mortgage?" →
one answer, itemized, computed).
- **Cross-jurisdiction:** Dubai market intelligence *and* RAK expertise in one
concierge — nobody selling NH Collection RAK against Dubai comps can do this
today.
- **Fused with the CRM:** the same brain that quotes the JVC sale index knows
the brokerage client's live unit ledger, the buyer's payment milestones, and the SPA status —
Dubai REST's "wallet" concept, but for the brokerage client's own buyers, already backed by
migrations 001–005.
4. Phased roadmap
**Phase 1 — Computation core (fastest visible win)**
`market` schema + transactions/rent ingest (bulk CSV) + the three index views
+ `fee_calc`, `yield_calc`, `price_index`, `rent_index` tools + concierge tool
wiring. Exit test: "average price per sqm for a 1BR in Dubai Marina this year,
and total buying costs at 1.5M?" answered with cited, dated numbers.
**Phase 2 — Knowledge parity**
DLD service-catalog corpus + legal layer + FAQ into pgvector; jurisdiction
router; guardrail prompt hardening. Exit test: 50-question eval sheet spanning
Class A/B/C intents, graded for accuracy, citation, and correct authority
behavior (C-intents must redirect, never pretend).
**Phase 3 — Directories & valuation**
Broker/developer/project datasets + `broker_verify`, `project_lookup`,
`valuation_estimate` with confidence bands. Nightly cron refresh live.
**Phase 4 — Buyer wallet**
Auth-scoped buyer portal: my unit, my milestones, my PDCs, my SPA status,
completion updates — the Dubai REST wallet concept on our own rails (RLS
already enforces the boundaries).
5. Risks & mitigations (stated, not assumed away)
- **Dataset licensing:** Dubai Pulse open datasets are free, but commercial-use
terms per dataset must be read before launch; some DLD datasets are "open,"
others commercial. Mitigation: verify terms per dataset in Phase 1, keep the
ingest list to confirmed-open ones.
- **Data volume:** full transactions history is large; scope to 2015+ and
aggregate older years into the index views only.
- **Staleness:** cron failure = stale indexes. Mitigation: `data_as_of`
surfaced in every answer + freshness alert on the command deck.
- **RAK asymmetry:** no open RAK transaction feed exists; RAK market claims
stay pinned to the verified-sources-only KB rule already in force.
- **The bot being wrong about money:** all computation in tools, all tools
unit-tested against hand-worked examples before the concierge may call them.
6. Decisions needed before Phase 1 build
1. Confirm Dubai market intelligence is in-scope for the the brokerage client brand (it
positions the brokerage client as a UAE-wide authority, not just a RAK developer) — or scope
indexes to buyer-education only.
2. Transactions history depth: 2015+ (recommended) vs full 2004+.
3. Where the concierge surfaces: existing landing-page concierge only, or also
inside the CRM for agents (agent-facing answers can include CRM data;
public-facing must not).