Civil Law and UAE: Protocolisation of Legal Obligations in Software Systems

1. Meaning of Protocolisation of Legal Obligations

Protocolisation of legal obligations means converting legal, contractual, regulatory, or compliance requirements into structured software rules, protocols, workflows, permissions, automated checks, and machine-executable instructions.

In simple language:

Protocolisation means making software enforce a legal or contractual obligation through programmed rules.

For example, a software system may be programmed to:

reject a transaction exceeding an authorised limit;

require two signatures before payment;

automatically suspend an account after a contractual default;

verify digital identity;

record consent;

prevent transfer of restricted digital assets;

calculate contractual charges;

automatically release escrow funds when conditions are satisfied;

preserve an electronic audit trail; or

automatically execute a transaction when predetermined conditions occur.

It is therefore the meeting point between:

Civil Law + Contract + Software + Automation + Evidence + Compliance.

2. Protocolisation Is Not the Same as Electronic Contracting

These concepts should be distinguished.

Electronic contracting

A human enters into a contract through electronic means.

Example:

A customer clicks “I agree” to online terms.

Automated electronic transaction

The system itself performs a transaction according to pre-programmed instructions.

Protocolisation

A broader concept in which legal obligations themselves are translated into operational software rules.

Example:

“Payment requires approval by two authorised directors.”

The legal/contractual rule is translated into:

Payment request        ↓ Check amount        ↓ Check authorised person        ↓ Require second approval        ↓ Record approvals        ↓ Execute payment

Thus:

Electronic contracting records legal agreement; protocolisation operationalises the legal obligation.

3. UAE Legal Foundation

The UAE is particularly relevant to this subject because its electronic-transactions legislation expressly recognises automated electronic transactions.

The important current legislation includes:

1. Federal Decree-Law No. 46 of 2021

Electronic Transactions and Trust Services Law

This is central to protocolised transactions.

It recognises:

electronic documents;

electronic signatures;

electronic transactions;

automated electronic transactions;

electronic attribution;

trust services;

digital authentication.

2. Federal Decree-Law No. 25 of 2025

Civil Transactions Law

This is the current UAE Civil Transactions Law, effective from 1 June 2026.

It provides the general civil-law framework within which software-mediated contractual obligations must operate.

3. Federal Decree-Law No. 45 of 2021

Personal Data Protection Law

Relevant where protocolised systems process:

identity information;

customer data;

employee information;

behavioural data;

automated decision information.

4. Consumer Protection legislation

Relevant where automated software rules affect:

pricing;

refunds;

subscriptions;

warranties;

cancellation;

consumer rights.

5. DIFC legal framework

The DIFC provides an especially developed environment for:

digital assets;

blockchain;

smart contracts;

artificial intelligence;

automated dispute resolution;

software;

digital signatures;

digital identity;

fintech.

Its Digital Economy Court is particularly relevant to technology-based civil disputes.

4. Automated Electronic Transactions Under UAE Law

One of the most important provisions is Article 11 of Federal Decree-Law No. 46 of 2021.

It recognises contracts made between automated electronic media, including systems programmed in advance.

The legal effect is significant:

A contract does not become legally ineffective merely because the system, rather than a human, performed the relevant electronic act.

This creates an important foundation for protocolisation.

For example:

Company A's system

→ receives order

→ verifies price

→ checks inventory

→ checks payment

→ automatically accepts order

→ generates confirmation.

The absence of a person manually clicking “accept” does not necessarily invalidate the transaction.

5. Attribution Is the Central Issue

Protocolisation creates a major legal question:

Who is legally responsible for what the software did?

Software itself is generally not treated as an independent legal person merely because it can make an automated decision.

The analysis therefore normally goes toward:

who programmed the system;

who authorised it;

who deployed it;

who controlled it;

whose business it operated for;

what authority was given to it;

whether it operated within its programmed parameters;

whether the system was manipulated;

whether the other party knew or should have known about the automation.

This produces the following formula:

Software action → Attribution → Legal person → Obligation → Liability

6. Protocolisation and Contract Formation

Software can operationalise the formation of a contract.

Consider an online marketplace.

The protocol might contain:

Offer

→ product listed

Acceptance

→ customer completes specified transaction process

Authentication

→ identity/payment verification

Contract record

→ electronic document generated

Performance

→ seller receives order

Evidence

→ system preserves timestamp, IP/device information, payment record and acceptance log.

The legal question is not simply:

“Did software execute the transaction?”

It is:

Did the software act according to a legally attributable process that satisfies the requirements for formation and performance of the contract?

7. Protocolisation and Smart Contracts

Smart contracts are an important example.

A smart contract can contain code such as:

IF payment received THEN transfer digital asset

or:

IF delivery confirmed THEN release escrow

The code can automatically perform the contractual mechanism.

But an important legal distinction exists:

Code execution does not automatically determine the complete legal meaning of the parties' agreement.

A smart contract may execute automatically, but disputes can still arise about:

mistake;

fraud;

authority;

interpretation;

invalidity;

illegality;

consumer rights;

force majeure;

cybersecurity;

restitution;

ownership;

unjust enrichment.

Therefore:

Code execution ≠ complete legal adjudication.

8. Case Law

Because “protocolisation of legal obligations” is an emerging concept, there is not yet a large body of UAE reported cases using that exact terminology.

The following cases are therefore best understood as closely related authorities dealing with automated transactions, software, digital platforms, digital assets, electronic contracting and technology-based obligations.

Case 1: Naima v Nadine [2024] DIFC SCT 112

This is one of the most useful authorities for digital contractual protocolisation.

The dispute involved an online professional-network membership.

The customer registered through an online process and accepted contractual terms providing for:

an annual commitment;

monthly instalments;

automatic renewal;

contractual payment obligations.

The defendant argued, in substance, that she had not continued using the service.

The DIFC Small Claims Tribunal nevertheless treated the digital acceptance and contractual terms as legally significant and awarded the claimant approximately AED 2,220 plus the applicable court fee.

Principle

A digitally structured contracting process can create binding contractual obligations.

The software interface does not make the underlying contract legally irrelevant.

Protocolisation significance

The platform converted legal rules into a sequence:

Registration → acceptance → subscription → payment schedule → renewal → continuing obligation

This demonstrates how contractual obligations can be embedded into software architecture.

9. Case 2: Linux v Lizeth [2022] DIFC SCT 237

This dispute concerned a Software Development Agreement relating to an e-commerce and restaurant-management platform.

The case illustrates that software development itself can be the subject of conventional contractual obligations.

The Tribunal examined the contractual relationship and ultimately dismissed the claim.

Principle

Software does not replace the contract governing:

development;

performance;

payment;

functionality;

delivery;

contractual responsibility.

Protocolisation significance

A software system can implement an obligation, but the underlying legal obligation remains capable of ordinary contractual interpretation.

Thus:

The protocol is an implementation mechanism, not necessarily the entire legal relationship.

10. Case 3: Latha v Lavni [2022] DIFC SCT 022

This case involved a tripartite arrangement concerning:

software licensing;

use of software;

development of modules.

The dispute demonstrates how different legal obligations can be distributed among parties involved in software architecture.

Principle

The existence of software does not eliminate the need to determine:

who had contractual rights;

who had development obligations;

who owned or could use the relevant software;

what each party promised;

whether performance occurred.

Protocolisation significance

A software ecosystem can contain several legally distinct relationships.

For example:

Developer → Platform owner

Platform owner → Customer

Customer → End user

Each relationship can contain separate obligations even though the same software system performs them.

11. Case 4: Nisan v Neysa [2024] DIFC SCT 174

This case concerned a company that registered as a third-party seller on an online marketplace.

The onboarding process required agreement to marketplace terms and a business services agreement.

The claimant attempted to rely upon the digital relationship in proceedings before the DIFC Courts.

The Court ultimately found that it did not have jurisdiction.

Principle

Digital participation in a platform does not automatically establish jurisdiction.

Protocolisation significance

This illustrates an important limitation:

Software architecture cannot automatically create jurisdiction that applicable law does not recognise.

A platform may contain:

governing-law clause;

jurisdiction clause;

arbitration clause;

automated dispute mechanism.

But the legal validity and effect of those provisions must still be determined according to applicable law.

12. Case 5: Miran v Motab [2023] DIFC SCT 213

This dispute involved digital content/music distribution.

Copyright infringement had already been established through Saudi proceedings, and the DIFC Court considered the financial consequences and attributable profits.

The Court relied upon evidence concerning digital distribution and calculated the relevant profits attributable to the infringement.

Principle

Digital records can provide the factual foundation for civil remedies.

Protocolisation significance

Software systems may automatically generate:

transaction records;

download statistics;

usage records;

payment data;

distribution information;

revenue records.

Such information can become important evidence when determining civil liability and damages.

Therefore:

Protocolisation creates not only automated performance but also an evidentiary architecture.

13. Case 6: Gate Mena DMCC & Huobi Mena FZE v Tabarak Investment Capital Ltd [2024] DIFC DEC 002

This dispute involved cryptocurrency transactions, digital wallets, intermediary relationships, communications and payment arrangements.

The DIFC Digital Economy Court dealt with the dispute through conventional principles concerning:

contractual obligations;

authority;

evidence;

payment;

representations;

digital transactions.

Principle

Digital-asset transactions remain subject to ordinary legal analysis even when technologically sophisticated.

Protocolisation significance

A crypto transaction may involve several protocolised layers:

Wallet

→ authentication

→ transaction instruction

→ blockchain execution

→ record creation

→ custody

→ settlement.

But the existence of the technical protocol does not automatically answer questions about:

authority;

ownership;

contractual obligation;

mistake;

fraud;

liability.

14. Case 7: Techteryx Ltd v Aria Commodities DMCC & Others [2025] DIFC DEC 001

This is an important modern Digital Economy Court authority.

The litigation involved digital assets/stablecoin-related arrangements, financial transfers, escrow and questions concerning beneficial ownership and tracing.

The DIFC Court granted significant proprietary and worldwide freezing relief, involving assets associated with approximately USD 456 million, together with subsequent disclosure and compliance orders.

Principle

Traditional civil remedies can be applied to technologically sophisticated assets.

Protocolisation significance

Even where assets exist within blockchain or digital systems, the court can ask conventional civil-law questions:

Who owns the asset?

Who has beneficial entitlement?

Was the transfer authorised?

Can the asset be traced?

What remedy is appropriate?

Can it be preserved pending final determination?

Thus:

Protocolised execution does not eliminate judicial control.

15. Case 8: Health Insights CFI 079/2023

The dispute involved software development, source code, modules, funding, corporate relationships and questions concerning authenticity and ownership.

The litigation demonstrates the complexity that can arise where multiple legal and technological layers overlap.

Principle

Software-related rights still require conventional legal analysis of:

ownership;

contractual arrangements;

development responsibilities;

evidence;

authenticity;

corporate relationships.

Protocolisation significance

A system may contain thousands of lines of code implementing contractual or regulatory rules, but the court may still need to identify:

Who legally owns the code and who bears responsibility for its operation?

16. Case 9: Alarabi Investments Limited v Cron AI Ltd [2026] DIFC CFI 030/2025

This is a recent AI-related DIFC matter.

The case involved an AI-related corporate entity and procedural applications concerning default judgment and setting aside/withdrawal issues.

It should not be treated as establishing that AI has independent legal personality.

Principle

AI-related companies remain subject to ordinary procedural and corporate legal rules.

Protocolisation significance

The fact that an organisation uses AI does not transfer legal responsibility from the organisation to the AI system.

The relevant legal actor remains the company or other legally recognised person unless applicable law provides otherwise.

17. What These Cases Establish Collectively

The cases do not establish one comprehensive doctrine called “protocolisation.”

Instead, collectively they support several propositions:

Proposition 1

Digital systems can create or implement legally binding contractual processes.

Proposition 2

Automated execution does not remove the underlying contract.

Proposition 3

Software can generate evidence relevant to civil claims.

Proposition 4

Digital assets remain subject to conventional property and remedial principles.

Proposition 5

Software cannot automatically manufacture jurisdiction.

Proposition 6

AI/software does not generally acquire independent legal personality merely through autonomous operation.

18. Legal Architecture of Protocolised Obligations

A sophisticated UAE system can be understood through seven layers.

Layer 1 — Legal obligation

Example:

Payment must receive two authorised approvals.

Layer 2 — Contractual obligation

The contract states:

No payment exceeding AED 500,000 may be made without two authorised signatures.

Layer 3 — Policy

The company adopts an internal approval policy.

Layer 4 — Protocol

The software is programmed:

IF amount > AED 500,000 THEN require two approvals

Layer 5 — Authentication

The system verifies:

identity;

authority;

digital signature.

Layer 6 — Automated execution

The transaction is released.

Layer 7 — Evidence

The system records:

time;

identity;

approval;

transaction;

system state;

electronic signature;

audit trail.

Thus:

Law → Contract → Policy → Protocol → Authentication → Execution → Evidence

19. Protocolisation and Legal Attribution

The most important legal question is often attribution.

Consider an automated trading system.

The system executes a transaction worth AED 10 million.

Who made the transaction?

Possibilities include:

employee;

company;

software developer;

platform operator;

automated agent;

customer;

malicious third party.

The UAE Electronic Transactions Law's automated-transaction and attribution framework is therefore highly significant.

The investigation should ask:

A. Who programmed it?

B. Who authorised it?

C. Whose system was it?

D. Was it properly authenticated?

E. Was the system operating normally?

F. Was there unauthorised access?

G. Did the system act within its programmed authority?

20. Protocolisation and Apparent Authority

This connects closely with UAE agency principles.

Suppose a company's software automatically sends purchase orders.

A supplier reasonably believes the system is authorised.

The company later argues:

“The software made the order, not our employee.”

That argument may not necessarily succeed.

The legal analysis can consider:

who controlled the system;

whether the company represented that the system was authorised;

whether the supplier reasonably relied on the system;

whether the transaction fell within the system's normal authority.

This is consistent with the broader agency principles seen in cases such as:

Khaled Salem Musabeh Humad Al Mheiri v John Cameron [2025] DIFC CA 008

and

Currency Matters Middle East v Michael Page International Ltd [2018] DIFC CFI 039.

The cases are useful for understanding attribution and authority, although they are not specifically “protocolisation” cases.

21. Protocolisation and Smart Contracts

A smart contract may contain:

IF payment = received THEN transfer token

The legal contract may contain:

“Upon verified payment, ownership shall transfer.”

The code therefore implements the contractual obligation.

But problems arise when:

Situation 1 — Code contains a bug

The system transfers the asset incorrectly.

Situation 2 — Contract and code conflict

The written contract says one thing while the code executes another.

Situation 3 — External data is incorrect

An oracle provides false information.

Situation 4 — Cyberattack

An unauthorised party manipulates the protocol.

Situation 5 — Legal prohibition changes

The transaction becomes prohibited under applicable law.

The central question becomes:

Does technical execution determine legal outcome, or can the legal relationship require correction, restitution or another remedy?

In civil law, technical execution does not necessarily end the legal analysis.

22. “Code Is Law” — UAE Civil-Law Qualification

The expression “code is law” should not be understood literally.

Software code can regulate behaviour technically, but it remains subject to the applicable legal order.

Therefore:

Code can implement law, but code does not automatically replace law.

A smart contract cannot simply eliminate:

mandatory legislation;

public order;

consumer protections;

data protection;

property rules;

court jurisdiction;

arbitration legislation;

fraud rules;

restitution;

judicial remedies.

23. Protocolisation and Consumer Protection

This is particularly important for online platforms.

Suppose a subscription system automatically:

renews the contract;

charges the customer;

refuses cancellation;

applies a penalty;

disables the account.

The fact that the software automatically executed the transaction does not necessarily mean the result is legally valid.

The system must be designed around applicable:

consumer rights;

contractual requirements;

disclosure requirements;

cancellation rights;

refund obligations;

data-protection requirements.

Thus:

Automation cannot be used as a mechanism for circumventing mandatory consumer law.

24. Protocolisation and Data Protection

Protocolised systems frequently process personal data.

Examples:

biometric authentication;

digital identity;

automated credit assessment;

employee monitoring;

fraud detection;

customer profiling;

automated access decisions.

The UAE Personal Data Protection Law becomes relevant.

The system should therefore incorporate:

purpose limitation;

appropriate security;

access controls;

retention controls;

correction/deletion mechanisms where applicable;

transparency;

lawful processing;

protection against unauthorised access.

This creates the concept of:

Privacy by protocol.

Instead of checking privacy only after a dispute, privacy requirements are built into the system from the beginning.

25. Protocolisation and Evidence

One of the major advantages of protocolisation is that it can create an audit trail.

For example:

09:01 — identity verified 09:02 — contract accepted 09:03 — payment authorised 09:04 — condition satisfied 09:05 — transaction executed 09:05 — electronic record created

Such records may help establish:

who acted;

what happened;

when it happened;

what information was available;

whether authorisation existed;

whether the system operated according to protocol.

But:

An automated record is evidence; it is not necessarily conclusive proof of every underlying legal fact.

Authenticity, integrity, reliability and context remain relevant.

26. Protocolisation and Legal Version Control

This issue is especially important after the UAE's transition to the 2025 Civil Transactions Law.

Suppose a company's compliance software was designed around the former 1985 Civil Transactions Law.

On 1 June 2026, the current Civil Transactions Law became effective.

The software continues applying the old legal logic.

This creates a new category of risk:

Legal obsolescence of software protocols.

Therefore, sophisticated legal-compliance systems need:

statutory version control;

effective-date monitoring;

rule updates;

jurisdiction-specific rules;

audit logs;

human escalation.

27. Protocolisation and AI

AI creates a more complicated form of protocolisation.

Traditional software:

IF X → THEN Y.

AI:

Analyse data → generate prediction → recommend action.

The legal risk is greater because AI may not always produce identical outputs.

Therefore, AI-based legal compliance should distinguish between:

Rule-based automation

Mandatory protocol

and

AI decision support

Recommendation subject to human review.

For high-impact legal decisions, the safer legal architecture is often:

AI recommendation → human verification → legal decision → recorded justification

rather than:

AI → automatic irreversible legal consequence.

28. Protocolisation and Corporate Governance

Corporate governance can also be protocolised.

For example:

Board approval

System checks:

authorised director;

quorum;

resolution;

voting threshold.

Related-party transaction

System checks:

relationship;

disclosure;

approval;

statutory threshold.

Payment

System checks:

authority;

amount;

budget;

dual approval.

Securities transaction

System checks:

restricted person;

trading window;

approval;

reporting obligation.

This creates:

Governance by software protocol.

However, software should not be treated as a substitute for the underlying legal duties of directors and officers.

29. Protocolisation and Corporate Liability

Suppose a company says:

“Our software made the mistake.”

That does not automatically eliminate corporate responsibility.

The court may investigate:

system design;

governance;

supervision;

testing;

cybersecurity;

authorisation;

maintenance;

human oversight.

This produces a useful principle:

Automation may change the mechanism of conduct without necessarily changing the identity of the legal actor.

30. Protocolisation and Force Majeure

Protocolised contracts create unusual force-majeure questions.

Suppose a smart contract automatically imposes a payment obligation even though:

a government restriction prevents performance;

a cyberattack disrupts infrastructure;

a natural disaster prevents delivery;

a critical external system fails.

The code may continue operating.

But the legal contract may contain force-majeure or impossibility provisions.

Therefore:

Automatic execution ≠ automatic exclusion of legal defences.

The legal question remains whether the relevant legal doctrine applies.

31. Protocolisation and Error

Errors can occur at different levels.

Legal drafting error

The legal obligation itself was drafted incorrectly.

Coding error

The software incorrectly implements the legal obligation.

Data error

The system receives incorrect information.

Authentication error

The wrong person is treated as authorised.

Oracle error

External information supplied to the system is wrong.

Cybersecurity error

An unauthorised party manipulates the system.

Each type may create different questions concerning:

breach;

negligence;

authority;

causation;

restitution;

damages.

32. Protocolisation and Proportionality

The proportionality principle discussed in the previous topic is highly relevant.

Suppose software automatically freezes an entire customer account because of a minor contractual default.

The question becomes:

Is the automated restriction proportionate to the legal obligation breached?

Similarly:

AED 1,000 default → AED 1 million automatic freeze;

minor breach → permanent account termination;

small payment delay → complete suspension of unrelated services.

Such automated consequences may require legal scrutiny under the applicable contractual, consumer and civil-law framework.

Thus:

Protocolised enforcement should be designed proportionately.

33. Protocolisation and Dispute Resolution

Software can also protocolise dispute resolution.

Examples include:

automated complaint escalation;

internal platform appeals;

automatic evidence preservation;

online dispute resolution;

smart-contract arbitration triggers;

automatic referral to an arbitrator.

However, an automated dispute mechanism cannot automatically eliminate:

procedural fairness;

jurisdictional requirements;

valid arbitration agreement requirements;

due process;

public policy;

judicial review where legally available.

34. Advantages of Protocolisation

1. Consistency

The same rule can be applied repeatedly.

2. Speed

Transactions can occur without manual intervention.

3. Auditability

Actions can be recorded.

4. Reduced human error

Routine mistakes can be reduced.

5. Compliance monitoring

Legal requirements can be checked continuously.

6. Transparency

A well-designed system can show why a transaction was accepted or rejected.

7. Prevention

The system can prevent prohibited actions rather than merely punish them later.

35. Risks of Protocolisation

1. Coding errors

A legal rule may be translated incorrectly.

2. Legal ambiguity

Some legal concepts cannot easily be reduced to binary rules.

Examples:

good faith;

reasonableness;

proportionality;

unconscionability;

causation.

3. Algorithmic bias

AI-based systems may systematically disadvantage certain users.

4. Automation bias

Humans may blindly trust system output.

5. Legal obsolescence

A system may continue applying an outdated law.

6. Cyberattack

Attackers may manipulate the protocol.

7. Attribution problems

It may become unclear who authorised the action.

8. Irreversibility

Blockchain transactions may be technically difficult to reverse even where legal restitution is required.

36. The UAE Legal Model

A useful conceptual model is:

Stage 1 — Identify law

What does legislation require?

↓

Stage 2 — Identify contract

What have the parties agreed?

↓

Stage 3 — Translate into protocol

How should the obligation be implemented?

↓

Stage 4 — Authenticate

Who is authorised?

↓

Stage 5 — Execute

Software performs the transaction.

↓

Stage 6 — Record

Electronic evidence is preserved.

↓

Stage 7 — Monitor

System detects deviations.

↓

Stage 8 — Escalate

Human/legal review occurs where necessary.

↓

Stage 9 — Remedy

Court/arbitrator applies the appropriate legal remedy.

37. Six Most Important Legal Rules

Rule 1 — Automation can be legally recognised

UAE electronic-transactions law expressly recognises automated electronic transactions.

Rule 2 — Automation does not automatically create legal personality

Software and AI generally remain instruments through which legally recognised persons act.

Rule 3 — Code does not automatically override mandatory law

The legal system remains superior to private software architecture.

Rule 4 — Attribution is central

The court must identify the person/entity responsible for the automated act.

Rule 5 — Electronic records can become evidence

Protocolisation creates an evidentiary trail, but reliability and authenticity remain relevant.

Rule 6 — Human legal review remains necessary for open-textured concepts

Software can enforce a clear rule more easily than concepts such as:

good faith;

proportionality;

reasonableness;

causation;

abuse of rights.

38. Case-Law Revision Table

39. One-Minute Revision

Protocolisation of Legal Obligations

Definition:

Conversion of legal or contractual obligations into software rules, protocols and automated workflows capable of verifying, preventing, executing, recording or escalating conduct.

Core UAE framework:

Civil Transactions Law — Federal Decree-Law No. 25 of 2025

Electronic Transactions and Trust Services Law — Federal Decree-Law No. 46 of 2021

Personal Data Protection Law — Federal Decree-Law No. 45 of 2021

Consumer Protection legislation

DIFC Digital Economy Court framework

Applicable sector-specific legislation

Central principles:

Law → Contract → Protocol → Authentication → Automated Execution → Evidence → Attribution → Human/Judicial Review

Most important cases:

Naima v Nadine — digital contract formation.

Linux v Lizeth — software contractual obligations.

Latha v Lavni — software licensing/development.

Nisan v Neysa — platform terms do not automatically establish jurisdiction.

Miran v Motab — digital records and economic rights.

Gate Mena v Tabarak — crypto transactions and authority.

Techteryx v Aria Commodities — digital assets and proprietary remedies.

Health Insights — software/source-code ownership.

Alarabi Investments v Cron AI — AI-related entity remains subject to ordinary legal procedure.

Conclusion

Protocolisation of legal obligations in software systems represents the movement from law as a document toward law as an operational system. UAE law is particularly suited to this development because Federal Decree-Law No. 46 of 2021 expressly recognises automated electronic transactions and provides rules concerning electronic attribution.

However, protocolisation does not mean that software becomes the law. The correct legal model is:

The law defines the obligation; the contract allocates the obligation; the protocol implements the obligation; the electronic record evidences performance; and the court ultimately determines legal responsibility and remedies.

The most important UAE principle is therefore “automation without automatic legal autonomy.” A software system may execute a legally significant act, but the legal system must still determine authority, attribution, validity, causation, evidence, proportionality and remedy.