Dubai REST Parity Plan — RRS Concierge Intelligence Layer
Goal: give the RRS 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 `rrs-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 RRS 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 RRS 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 `rrs` │ │ 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 `rrs-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 |
| `rrs_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 RRS 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
RRS's live unit ledger, the buyer's payment milestones, and the SPA status —
Dubai REST's "wallet" concept, but for RRS'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 RRS brand (it
positions RRS 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).