Escrow Analytics: AI Monitoring of RERA and Wafi Waterfalls

Escrow rules and the decision perimeter

Decision Perimeter: Real-Estate Finance

Primary users

The principal operating users are real-estate finance participants. A developer's finance team needs a current view of collections, certified work, invoices, contractual limits, requested releases and blocked items. An account trustee or escrow bank needs a complete instruction pack and an auditable basis for any movement. A project lender needs visibility into progress, cost to complete, liquidity headroom, contractor concentration and compliance with financing conditions. An approved consultant or engineering firm needs an evidence workspace that preserves its independent judgement. A certified public accountant, where required, needs accounting records, supporting invoices, account statements and calculations. Regulators require the statutory reports, notifications and project information specified by the applicable regime.

Decision-rights map

The system must distinguish analysis from authority. A model can classify an invoice, extract a claimed amount, compare a photograph with an approved model and draft an exception note. Those outputs are provisional. They do not certify construction progress, approve a payment order, amend an escrow agreement, waive a covenant or instruct a bank.

Figure 2. escrow decision-rights map

Source: Matchpoint decision-rights framework; statutory role context [1-15].

Jurisdiction, project and contract specificity

Every project must be configured from approved source documents. The legal regime is one layer. The project licence, escrow agreement, sale contracts, construction contracts, consultant appointment, financing documents, approved budget and regulator directions add project-specific conditions. The same apparent milestone label can produce different release outcomes because eligible costs, signatories, retentions, caps, timing conditions and documentary requirements differ.

The system therefore stores a rule pack with an effective date, source hash, jurisdiction, project scope, reviewer, approval status and supersession history. A request is evaluated against the approved rule pack that was effective for that request. Later amendments create new versions; they do not silently rewrite prior decisions.

Dubai Rera Escrow Control Model

Statutory account and evidence perimeter

Dubai Law No. 8 of 2007 establishes a project-specific escrow structure for off-plan real-estate development. The law addresses deposits, separate accounts, statements, depositor records, financing paid into escrow, a five per cent post-completion retention and regulator responses where completion is at risk [1]. The official English text states that the Arabic text prevails if there is a conflict; production legal interpretation must therefore use approved Arabic and English sources where applicable.

Dubai Land Department guidance provides operational context. The official FAQ states that completion percentage is determined through a consultant approved by DLD, that an investor can follow the project through official services, and that the account trustee's engineer visits the site and verifies achievement before payment under the escrow agreement [2]. DLD's mortgage-to-escrow service requires current project and technical-report conditions, while its completed-project payment service defines submission requirements for a completed project [4-5]. These service pages are living operational sources and require scheduled refresh.

Dubai control objects

Dubai waterfall representation

The proposed Dubai waterfall is a project-specific state machine:

Confirm the project, account and request are active and in scope.

Confirm all relevant buyer and financier receipts have been reconciled to the escrow account.

Confirm the payee, cost code and purpose are eligible under the law and escrow agreement.

Confirm the current approved budget and remaining budget for the cost code.

Confirm professional progress certification and required trustee verification.

Confirm invoice identity, amount, tax treatment, prior payments, retention and variation status.

Apply legal, contractual and financing reserves, caps and drawstops.

Route the resulting entitlement and exceptions to the required signatories.

Release through the trustee's controlled banking process.

Reconcile the bank debit and close or escalate differences.

The engine produces a calculated maximum eligible release and a complete exception list. It does not produce an unconditional instruction to pay.

Figure 3. Dubai and Saudi escrow waterfall crosswalk

Source: Matchpoint crosswalk based on official sources [1-15].

Saudi Wafi Escrow Control Model

Active statutory structure

Saudi Arabia's active Law of Selling and Leasing Off-Plan Real Estate Projects requires a separate escrow account for each project [11]. The account is for the licensed project, funds are protected from attachment for developer creditors, and project-financing funds must be deposited into the account [11]. Article 11 requires a payment order signed by the developer, consulting firm and certified public accountant, subject to the law's exceptional mechanism. Articles 12 to 14 address non-construction expenditure, excess funds and retention [11].

The implementing regulations add operational detail. They address independent accounts and reports for project scopes, public project information, project-reporting frequency, project and unit identifiers, secure withdrawal requests, exceptional withdrawals, delayed-project controls and notification of violations [12]. The official Wafi platform describes the national off-plan licensing service and provides the current operating context [13].

Wafi control objects

Wafi waterfall representation

The proposed Wafi waterfall validates the project licence and account status, assigns the request to the correct project scope, matches the payee and cost category, reconciles the invoice and account ledger, tests statutory and approved-budget limits, verifies engineering and accounting evidence, gathers the required signatures, applies retentions and exceptional approvals, submits through the approved channel and reconciles the resulting cash movement.

The Saudi model creates a particularly clear segregation-of-duties requirement. The developer, consulting firm and certified public accountant are separate approval principals for ordinary disbursement. An AI service may prepare a common evidence pack for their review; it must preserve separate identities, review histories and signatures.

From canonical data to progress evidence

Canonical Escrow Data Model

Design principle

The proposed architecture treats each consequential statement as an evidence-backed object. A dashboard percentage without lineage is insufficient. The system must retain the source file, exact location, extraction method, transformation, reviewer, approval status, effective period and link to the decision in which the value was used.

The canonical model has six ledgers:

a project ledger for licence, parties, contracts, budgets, units and work packages;

an escrow ledger for receipts, releases, reserves, returns, fees and bank balances;

a progress ledger for planned, measured, certified and accepted progress;

an evidence ledger for documents, images, video, scans, certificates and observations;

a decision ledger for requests, tests, exceptions, approvals, overrides and releases;

a model ledger for prompts, model versions, tools, inputs, outputs, evaluations and reviewer corrections.

Core identifiers

Atomic evidence object

An evidence object records a single proposition or asset with custody and scope. Its fields include evidence ID, project ID, asset hash, source type, source owner, capture time, receipt time, location, period, work package, claim, unit, value, confidence, permission, reviewer, review status, supersession, retention class and source pointer.

Confidence is not approval. A high model score does not turn an image into a professional certificate. The model score supports routing and review prioritisation. The approved professional status is stored separately.

Temporal and version controls

Construction, certification, bank and contract data arrive at different times. The architecture stores both event time and processing time. This permits a reviewer to see what was known when a release was evaluated and what arrived later. A schedule revision, budget variation or replacement certificate creates a new version with an explicit effective date. Prior packs remain reproducible.

Figure 4. Canonical escrow evidence model

Source: Matchpoint evidence architecture; provenance and risk context [19-27,42-50].

Escrow Data-Flow Architecture

Layers

The proposed architecture has eight layers:

Permissioned connectors receive bank files, regulator data, project-controls data, approved documents and captured media.

Evidence vault preserves originals, hashes, signatures, metadata, permissions and retention controls.

Canonicalisation services map account, project, WBS, cost code, payee, invoice and unit identifiers.

Deterministic reconciliation services balance cash, duplicate invoices, cumulative releases, budget availability, caps, retention and entitlement.

AI analysis services classify, extract, compare, explain and draft with source pointers.

Policy and rule engine evaluates the approved jurisdiction and project rule pack.

Workflow service routes exceptions, reviews, signatures, consent and bank instructions.

Decision surfaces present developer, trustee, accountant, engineer, lender and regulator views appropriate to their authority.

Trust boundaries

Event-driven processing

Each change emits a signed event, such as bank statement received, progress capture received, certificate approved, invoice superseded, request submitted, exception opened, approval recorded, release posted or reconciliation failed. Idempotency keys prevent duplicate processing. The system writes append-only events and builds current views from them. Corrections are additional events linked to the original entry.

Data freshness service levels

Figure 5. Permissioned escrow data-flow architecture Source: Matchpoint architecture; official escrow, AI and security context [1-25,42-50].

Construction-Progress Evidence

Evidence hierarchy

Computer vision is one component of a broader evidence hierarchy. The proposed hierarchy moves from approved design and schedule, through contemporaneous capture and quantitative measurement, to professional certification and trustee or regulator review.

Capture protocol

Every capture campaign should have an approved plan: project and zone, date window, responsible operator, device, route, viewpoints, lighting tolerance, privacy exclusions, safety controls, file format, resolution, capture manifest and upload deadline. The protocol must preserve negative evidence; missing areas are recorded rather than silently omitted.

For fixed cameras, the system records calibration, field of view, obstruction and uptime. For mobile capture, the operator follows a defined route and confirms checkpoints. For laser scanning or photogrammetry, the technical team records coordinate reference, registration error, coverage and processing parameters. For drone capture, aviation and security approvals are preconditions; Section 17 addresses the jurisdiction-specific constraint.

BIM and schedule alignment

IFC is an open, vendor-neutral schema for built-asset information and is published as ISO 16739 [26]. The architecture maps an approved IFC or equivalent model to work packages, cost codes and schedule activities. Model elements receive stable identifiers. A change-control service records additions, deletions, geometry revisions and classification changes. A progress algorithm must compare against the approved revision applicable to the observation date.

Research on computer-vision-based progress monitoring commonly separates data acquisition and reconstruction, as-built modelling and progress assessment [32-41]. Methods include photographic reconstruction, object detection, semantic segmentation, scan-to-BIM comparison and schedule-linked visual evaluation. The literature also reports limitations involving occlusion, viewpoint, changing site conditions, labelled data, element granularity and generalisation [32-41]. These limitations support a review-first design.

Progress state taxonomy

Computer-Vision Progress Verification

Bounded role for vision models

Vision models can identify and localise visible construction elements, compare repeated viewpoints, read supported labels, highlight discrepancies and prepare a reviewer queue. Claude can analyse images and visual PDF content under current platform capabilities, subject to documented limits [21-25]. These functions support evidence preparation. They do not establish hidden work, structural quality, material compliance, test performance, title, contractual acceptance or legal entitlement.

Model pipeline

The proposed pipeline is:

Validate capture identity, hash, time, location, permissions and project binding.

Run quality checks for blur, exposure, occlusion, field of view and duplicate frames.

Register the image or point cloud to the approved project coordinate system.

Retrieve the applicable model elements, work packages and schedule activities.

Run approved detection, segmentation or scan-comparison models.

Create element-level observations with source crops, model version and confidence.

Aggregate only under an approved measurement rule.

Route low-confidence, conflicting or material observations for professional review.

Store reviewer corrections and final status without overwriting the model output.

Quality gates

Evaluation metrics

Object-detection precision, recall and mean average precision describe model performance; they do not measure release-decision safety. A production evaluation also measures element-status accuracy, quantity error, coverage, false-completion rate, conflict detection, source-pointer validity, reviewer correction rate and downstream release impact.

Published studies provide context rather than a transferable production benchmark. For example, Park and Kang report a case-specific visual schedule-progress method and disclose its evaluation metrics [37]. Bhattacharjee and colleagues report a single-project integrated UAV, photogrammetry and BIM study [39]. Reja, Varghese and Ha's systematic framework emphasises the stages and levels of computer-vision progress monitoring [32]. A Matchpoint or client claim requires testing on the intended project's elements, capture conditions, languages, schedule and evidence rules.

Figure 6. Computer-vision progress-verification workflow

Source: Matchpoint workflow; construction-progress research [32-41].

Reconciliation, entitlement and exceptions

Milestone-Reconciliation Agent Design

Agent contract

The milestone-reconciliation agent receives a release request ID and an approved rule-pack version. It may retrieve only permitted project objects. It produces a structured reconciliation pack, never a free-form payment instruction.

The output schema contains:

request and rule-pack identifiers;

project, account, payee and invoice identity;

milestone and work-package mapping;

planned, measured, model-observed, certified and accepted progress;

budget, commitment, prior release, retention and reserve values;

source pointers for every material input;

deterministic entitlement calculation result;

conflicts, omissions and stale evidence;

proposed routing and required approvers;

model version, prompt, tools and execution record.

Task decomposition

Source-grounded extraction

Claude's citation feature can return document-linked citation blocks for supported document content [23]. The production design stores its own immutable source pointers as well: file hash, page or cell, bounding box where available, exact extracted text, parser version and reviewer status. Visual citations require separate crops and coordinates because current citation support may be text-focused under particular platform paths [21-23].

Each numeric field has a unit and sign convention. Amounts retain source currency. Percentages distinguish percentage points from proportions. Dates use ISO format plus source timezone. The model may not calculate final entitlement. It emits parsed inputs; a deterministic service performs calculation and returns a signed result.

Missing evidence and abstention

The agent must produce unsupported, conflicted, stale or not applicable where evidence is insufficient. It may not infer a certificate date from an upload date, a payee from a filename, a progress percentage from a narrative adjective, or legal eligibility from a prior similar request.

Prompt-injection resistance

Construction packs can contain arbitrary text. All document content is treated as untrusted data. Model instructions are separated from source content. Tools use allowlisted schemas and read-only access during analysis. The agent cannot send email, alter a bank file, modify a certificate, approve a request or execute a payment. Any source text that asks the model to ignore controls is captured as a security event.

Escrow And Cash Reconciliation

Double-entry project sub-ledger

The platform maintains a project sub-ledger reconciled to the trustee bank statement. Receipts are classified as buyer collections, financier deposits, developer injections, refunds, interest or other approved categories. Debits are classified by payee, invoice, cost code, release request and bank reference. Unmatched items remain in suspense with an owner and ageing status.

Control totals

For each cut-off date, the system tests:

Opening bank balance + cleared receipts - cleared debits = closing bank balance.

Opening project ledger + posted ledger entries = closing project ledger.

Bank closing balance - project ledger closing balance = unreconciled difference.

The final release workflow is blocked when the unreconciled difference exceeds an approved tolerance or includes a material unexplained item. Tolerance does not permit concealment; it governs routing and timing.

Release-base calculations

Duplicate and anomaly controls

The platform detects exact and near-duplicate invoice numbers, reused certificate periods, repeated bank references, round-dollar splits, payee-account changes, invoice-date anomalies, duplicate image captures, abrupt progress reversals and requests just below an approval threshold. An anomaly is a review signal. It is not proof of fraud.

Three-way and four-way matching

Ordinary construction requests should match contract or purchase order, certified work, invoice and bank instruction. Where delivery evidence is material, a delivery note, test certificate or inspection record becomes a fifth component. Each mismatch has a defined owner and status.

Figure 7. Milestone-reconciliation agent from source evidence to controlled pack

Source: Matchpoint framework; Claude capability and governance context [19-25].

Release-Entitlement Engine

Rule representation

The release-entitlement engine applies approved machine-readable rules to accepted inputs. Each rule has a unique ID, legal or contractual source, exact source pointer, jurisdiction, project scope, cost category, effective date, expression, required evidence, approvers, exception route, test cases and approval history.

A rule is not placed in production because a model extracted it. Legal, escrow, finance and project-control reviewers approve the rule and its test cases. The system preserves the legal text next to the executable expression so reviewers can identify any gap between them.

Waterfall sequence

The proposed sequence is strict:

Validate project, account, request and rule-pack identity.

Validate source completeness, authenticity and freshness.

Validate payee, cost purpose and account eligibility.

Validate professional certifications and required signatures.

Calculate gross certified entitlement.

Deduct prior releases, retention, liquidated or other approved deductions.

Apply budget availability and cumulative category limits.

Apply legal and contractual reserves.

Apply lender drawstops, consent conditions and cash controls.

Calculate a provisional maximum and required approvals.

Route all exceptions; do not net unrelated exceptions into one score.

After approval, generate a controlled instruction record for the trustee process.

Release states

Reserve stack

The engine calculates reserves independently and then applies the approved priority. Typical categories include statutory completion retention, contractual retention, defect reserve, tax reserve, unresolved-variation reserve, lender interest or debt-service reserve, cost-to-complete buffer and disputed-payment hold. The presence and priority of each reserve are project-specific.

Rule conflict

If two approved rules produce inconsistent results, the engine stops. It records the conflicting rule IDs, sources and affected amount. An authorised legal or contractual reviewer resolves the conflict through a new rule-pack version. The system does not choose the more permissive rule.

Alert Taxonomy And Exception Workflow

Alert design

An alert must identify the affected object, evidence, rule, amount, materiality, owner, clock and permitted resolution. Generic red warnings create noise. The proposed taxonomy distinguishes eligibility, evidence, progress, finance, cash, counterparty, authority, security and data-quality alerts.

Severity

Severity is calculated from consequence, exposure, reversibility, legal significance, evidence reliability and time sensitivity. A low model confidence is not automatically a critical business alert. A missing legally required signature is critical even if all amounts reconcile.

Exception lifecycle

Each exception moves through open, assigned, under review, information requested, resolved, accepted risk, rejected or expired. Resolution requires evidence and an authorised person. Accepted risk requires an explicit authority and expiry. Reopening preserves the prior history.

Alert fatigue controls

The system groups alerts only when they share a root cause and authority. It suppresses exact duplicates, preserves the highest materiality, and displays the number of affected requests and amount. It measures alert precision, override rate, ageing and repeated root causes. A control owner reviews thresholds; the model does not tune materiality autonomously.

Human review, monitoring and release control

Lender Dashboard Mock-Up

Purpose

The lender view is a decision surface for exposure, completion, liquidity, cost to complete, covenant and exception status. It must state its as-of time and data coverage. It should display planned, observed, certified and accepted progress separately.

Dashboard hierarchy

The top panel contains project identity, licence status, escrow account status, current data cut-off, total lender exposure, cleared escrow cash, remaining approved project cost, latest certified progress and open critical exceptions. A second panel shows progress against schedule, certified value against release, and forecast cost to complete. A third panel shows releases by cost category and payee concentration. A fourth panel presents covenants, consents and reserves. A final panel lists decision-ready exceptions with source links.

Text wireframe

The values in this wireframe are placeholders. They are not observed project data.

Explainability

Clicking any KPI opens its calculation, source objects, rule version, evidence status and reviewer. The dashboard does not present a single opaque project-health score. A lender can see whether a warning arises from cash, physical progress, a missing approval, a contract issue or stale data.

Figure 8. Lender dashboard hierarchy for exposure, completion and decision

Source: Matchpoint lender-control framework; risk-data context [49].

Human Review, Signature And Override

Separate workspaces

The developer, consultant, certified public accountant, trustee and lender receive separate workspaces and credentials. The system may show a common evidence pack, but each party records its own review, comments, approval scope and signature. One party cannot use the model to impersonate another.

Professional review checklist

Electronic signatures

An approval record contains signer identity, role, organisation, authority, appointment version, approved amount, conditions, timestamp, signature mechanism, document hash and revocation status. The signature is bound to the exact pack version. Any change after signature creates a new version requiring the applicable approvals again.

Override policy

Overrides are exceptional and transparent. An override record contains the failed rule, affected amount, reason, approving authority, supporting source, compensating control, expiry and required notification. Rules classify which failures are non-overridable. The dashboard reports override volume, ageing and concentration by approver or counterparty.

No autonomous release

The system does not hold bank credentials and cannot submit a final payment instruction without the bank's approved human and technical controls. Where an authorised integration is later implemented, transaction limits, dual control, payee validation, step-up authentication and independent reconciliation remain mandatory.

Worked Escrow Scenarios

Scenario status

The examples in this section are Illustrative examples. Names, projects, balances, progress percentages, invoices, thresholds, outcomes and timelines are invented to demonstrate the framework. They are not client facts, regulator decisions or observed performance.

Dubai request

Illustrative example A Dubai off-plan project submits an AED 12.0 million contractor request. The current approved consultant certificate supports AED 11.4 million of gross work for the period. Contractual retention and a prior payment reduce the net invoice-supported amount to AED 9.7 million. Cost-code availability is AED 10.2 million. Cleared escrow cash after protected reserves is AED 10.0 million. The deterministic provisional maximum is therefore AED 9.7 million, before final trustee review.

The vision service finds that several facade zones visible in the capture appear less complete than the schedule mapping assumed. The model does not reduce the certified amount. It opens a material evidence conflict, links the affected images and BIM zones, and routes the exception to the approved consultant and trustee engineer. The release remains held until they resolve the discrepancy or provide additional evidence.

Saudi request

Illustrative example A Saudi off-plan project prepares a SAR 7.5 million release. The project record confirms the licensed scope and escrow account. The consulting firm approves the engineering evidence and the certified public accountant confirms the financial calculation. A payee-bank change was entered after the invoice review. The system blocks instruction generation, requires independent payee verification and preserves the three approval records. Once the payee change is verified under the bank's approved process, the signatories review the final pack version.

Cross-scenario lesson

The main control value is the separation of evidence, arithmetic and authority. A vision discrepancy creates a review item. A bank-detail change creates a security and counterparty control. A calculated maximum constrains the amount. None of those outputs substitutes for the required professional and banking decisions.

Model Evaluation And Production Monitoring

Golden set

Before production, the project team creates a permissioned, representative golden set of past requests. It includes ordinary, incomplete, disputed, amended, multilingual, low-quality, duplicate and adversarial cases. Specialists label fields, source pointers, eligibility, progress states, exceptions and final human outcomes. The evaluation set remains separate from prompt and workflow development.

Component evaluations

End-to-end evaluation

The end-to-end unit is a release pack. Reviewers compare the AI-supported pack with the approved human baseline on amount, unsupported release risk, missed exception risk, time, specialist effort, reviewer disagreement and reproducibility. Cases are stratified by jurisdiction, project phase, value, cost category, evidence quality and language.

Severity-weighted error

A false positive visual alert creates review cost. A missed duplicate invoice or unsupported payee change can create a larger exposure. The evaluation therefore weights errors by approved severity and affected amount. Weighting is governance policy, not a model-selected parameter.

Production monitoring

Production monitoring covers input drift, capture quality, extraction accuracy, correction rate, source-pointer failure, rule-pack version, tool errors, latency, security events, exception ageing and override patterns. Any material model, prompt, parser or rule change triggers regression testing.

Incident response

An incident playbook defines detection, containment, evidence preservation, impacted requests, access revocation, bank and regulator escalation, human fallback, root-cause review and controlled restart. The platform retains model inputs and outputs subject to privacy and legal retention rules.

Security, capture constraints and implementation

Privacy, Security And Media Provenance

Data-protection perimeter

Site imagery may contain workers, visitors, vehicle plates, neighbouring properties and location data. Payment packs contain identities, account details and signatures. UAE Federal Decree-Law No. 45 of 2021 defines and regulates personal-data processing [16]. Saudi Arabia's Personal Data Protection Law and its implementing guidance establish rights and controller obligations [17-18]. A project must obtain jurisdiction-specific legal advice, define purpose and lawful basis, minimise capture, restrict access, set retention and manage cross-border processing.

Privacy-by-design controls

Evidence integrity

Every original asset receives a cryptographic hash on ingestion. The system stores device, operator, capture time, upload time, geospatial metadata where permitted, transformations and derivative hashes. C2PA defines an opt-in technical standard for content provenance and authenticity manifests [27]. Where supported by capture devices and software, C2PA-compatible credentials can supplement the custody record. They do not prove the semantic truth of the scene; they help verify declared provenance and tamper evidence.

Access control

Access is granted by project, organisation, role, object class and purpose. Retrieval filters are enforced before a source reaches the model. Privileged actions require step-up authentication. Service accounts receive narrowly scoped permissions. The system records read, export, correction, approval and administrative events.

Cybersecurity baseline

The control programme maps the service to NIST AI RMF governance, mapping, measurement and management functions [19-20], the organisation's information-security management system, secure software practices and incident processes [42-46]. Generative-AI risk controls include pre-deployment testing, provenance, incident disclosure, model and supplier governance, and documented human roles [20].

Drone And Remote-Capture Constraints

UAE

The UAE GCAA treats commercial photography, aerial survey and related work as regulated professional drone operations and describes registration, operator authorisation, security clearance and operational permission requirements [28]. Current airspace publications and safety decisions can change quickly. A GCAA decision dated 28 February 2026 temporarily suspended drone operations [29]. A later GCAA alert dated 2 May 2026 addressed the resumption of normal air navigation operations [30]. I cannot verify from the cited publications that the drone-specific suspension was explicitly cancelled for every proposed construction-capture operation. A project must obtain current written confirmation and all required approvals before any flight.

Saudi Arabia

Saudi GACA material requires applicable government approvals, registration and operational authorisation for small UAS; aerial survey or photography can require additional approvals [31]. Current GACA rules and the intended project's location and operation must be verified before capture.

Capture fallback

The operating model must function without drones. Approved fixed cameras, ground-based mobile routes, 360-degree capture, handheld imagery and terrestrial laser scanning can supply evidence where legally, safely and technically permitted. Capture method is recorded as part of evidence quality; the system does not merge methods without an approved comparison protocol.

Economics, Capacity And Ninety-Day Roadmap

Evidence boundary

No supplied Matchpoint or client dataset establishes time saved, cash cost reduction, loss reduction, financing improvement, release acceleration or additional revenue from this architecture. No Matchpoint or client financial outcome is claimed.

Measurement model

The baseline and pilot use the same request definition and quality gate. Measures include active human hours, elapsed calendar time, specialist hours, exception detection, rework, unsupported-field rate, release-pack quality, incidents and technology cost.

Ninety-day roadmap

Days 0 to 15: authority and source map. Confirm jurisdictions, projects, professional roles, current laws, regulator services, account agreements, finance documents, capture permissions, data-protection requirements and system boundaries. Freeze the initial source register.

Days 16 to 30: canonical data and evidence vault. Configure identifiers, bank reconciliation, WBS and cost-code maps, evidence objects, access, retention, hashes and event records. Load a limited historical set.

Days 31 to 45: deterministic waterfall. Encode and approve one narrow request category, calculate budget, cash, retention and release constraints, and test against approved examples.

Days 46 to 60: AI shadow workflow. Add controlled document extraction, source pointers, progress-image analysis and exception drafting. Run in shadow mode with no production decision effect.

Days 61 to 75: professional and lender review. Approved professionals compare outputs with their current process. The team measures correction, missed exceptions, false alerts, time and usability.

Days 76 to 90: governance decision. Review security, privacy, evaluation, incidents, supplier terms, operational support and observed economics. Authorised management decides whether to stop, extend shadow mode or permit a tightly scoped production pilot.

Figure 9. Ninety-day implementation roadmap

Source: Matchpoint implementation framework; governance context [19-25,42-50].

Minimum production gates

Limitations And Conclusion

Limitations

This paper is a research and operating-design document. It does not provide legal, regulatory, engineering, audit, accounting, banking, privacy, cybersecurity, aviation, valuation or investment advice. Official translations may not prevail over Arabic source texts. Laws, implementing regulations, service requirements, regulator directions, bank processes and platform capabilities can change. Every project requires current professional review.

The computer-vision literature includes diverse datasets, project types, capture methods, element classes and metrics [32-41]. Reported case performance is not evidence of equivalent performance on a Dubai or Saudi project. Visual evidence cannot reliably establish hidden work, material quality, test compliance or contractual acceptance without additional evidence. BIM and schedule data can themselves be incomplete or stale. Model outputs may be wrong, unsupported or manipulated.

The proposed rule engine requires accurate approved legal and contractual interpretation. The dashboard depends on bank, project-controls, certification and evidence freshness. A well-designed platform cannot repair a defective appointment, fraudulent source, unauthorised capture, missing professional independence or compromised banking process by itself.

Conclusion

Milestone-linked escrow releases are a data, evidence and authority problem. Dubai and Saudi Arabia provide distinct legal structures with a common need for project-specific accounts, professional evidence, controlled disbursement and records. A defensible digital architecture joins those structures to a canonical ledger, immutable evidence, deterministic entitlement, exception-led workflow and segregated approval.

Claude and construction computer vision can support document analysis, imagery review, comparison, source-linked drafting and exception preparation. Their useful role is bounded by custody, evaluation, abstention, deterministic calculation and human authority. The authorised consultant, accountant, developer, trustee, lender and regulator remain responsible for the decisions allocated to them.

The recommended first implementation is one jurisdiction, one project, one request category and one shadow-mode pilot. Expansion should follow approved evidence on quality, security, reviewer effort and operating economics. No Matchpoint or client financial outcome is claimed.