# UNCITRAL ODR Principles — Concordia Product-Requirement Mapping

Mapping date: **2026-04-23**

Scope: Phase 179 Concordia task `179.1.3.1`.

This document maps the seven UNCITRAL principles for online dispute resolution —
**fairness, transparency, due process, accountability, accessibility,
neutrality, and party control** — onto concrete Concordia product requirements,
Phase 179 task pointers, and testable acceptance criteria.

The source text is the **UNCITRAL Technical Notes on Online Dispute Resolution**
(2016, non-binding) and the principles consistently echoed by UNCITRAL Working
Group III in subsequent sessions, cross-read with the UNCITRAL ODR portal at
https://uncitral.un.org/en/texts/onlinedispute/explanatorytexts/technical_notes
(fetched 2026-04-23, see
[`../research/source-matrix.md`](../research/source-matrix.md) row D1).

The mapping is **not** a legal-compliance certification. UNCITRAL Technical
Notes are non-binding guidance, not a law Concordia must satisfy. This document
is an engineering artifact: it shows where Concordia's existing design already
implements each principle, names the gaps that remain, and links both to the
corresponding Phase 179 tasks so the product team can track coverage.

---

## Table of contents

1. [Principle summaries](#principle-summaries)
2. [Fairness](#1-fairness)
3. [Transparency](#2-transparency)
4. [Due process](#3-due-process)
5. [Accountability](#4-accountability)
6. [Accessibility](#5-accessibility)
7. [Neutrality](#6-neutrality)
8. [Party control](#7-party-control)
9. [Coverage matrix](#coverage-matrix)
10. [Named gaps and follow-ups](#named-gaps-and-follow-ups)

---

## Principle summaries

The seven principles named in `179.1.3.1` map roughly to the following UNCITRAL
text families:

- **Fairness** — equitable treatment, informed participation, avoidance of
  systematic disadvantage to any party.
- **Transparency** — the rules, roles, process steps, and the outputs of those
  steps are visible to participants.
- **Due process** — each party has a genuine opportunity to present and respond,
  on reasonable timelines, with access to the information being acted upon.
- **Accountability** — identified actors are responsible for actions taken in
  the process; decisions leave an auditable trail.
- **Accessibility** — the platform does not systematically exclude parties on
  the basis of language, disability, device, connection quality, technical
  literacy, or cost.
- **Neutrality** — the platform itself and any neutral it supports do not favor
  one party; the appearance of bias is avoided.
- **Party control** — parties retain meaningful agency over whether and how they
  participate, what data they share, and when they withdraw.

Below, each principle has (a) UNCITRAL anchor text, (b) the Concordia product
requirement, (c) Phase 179 task pointers, (d) testable acceptance criteria, and
(e) named gaps.

---

## 1. Fairness

**UNCITRAL anchor.** Technical Notes §III ("General principles") and §IV
("Stages of ODR proceedings") frame ODR around equitable treatment: both parties
have a genuine opportunity to participate; neither is disadvantaged by the
platform's default settings; the process should not embed substantive bias.

**Concordia product requirement.**

1. Symmetric surface: identical intake flows, candidate-generation budgets,
   search quality, explanation quality, and acceptance UI for every party in a
   case.
2. Private-caucus parity: each party has the same private-statement capacity,
   the same evidence upload quota, the same preference-query budget.
3. Fairness metrics are first-class: every run tracks Nash product,
   Kalai-Smorodinsky proportional gains, utilitarian sum, max-min, egalitarian
   welfare, envy, and regret.
4. Sensitive-attribute fairness: demographic or protected-class signals never
   drive disparate treatment of parties in candidate scoring.

**Phase 179 task pointers.**

- `179.3.3.4` — fairness metric suite (Nash product, utilitarian sum, max-min,
  egalitarian welfare, Kalai-Smorodinsky, envy, regret, inequality, burden
  symmetry, procedural dignity).
- `179.3.3.5` — cultural / organizational / domain-specific fairness profiles
  without demographic-driven disparate treatment.
- `179.5.2.4` — collusion and coercion detection (unbalanced concessions,
  identical language patterns).
- `179.8.2.1` — fairness-metric tracking in benchmark harness.
- `179.10.6` — fairness thresholds in release gates.

**Testable acceptance criteria.**

- Every accepted run emits fairness metrics; no run accepted without them.
- Benchmark gate `179.10.6` fails when fairness metrics degrade below per-domain
  thresholds.
- Red-team test `179.8.3` proves no protected-class signal meaningfully shifts
  the fairness metric distribution.

**Gaps.** Cultural fairness profiles (§179.3.3.5) are not yet implementable at
the contracts layer; they require the preference- inference pipeline in §179.3.2
to be landed first.

---

## 2. Transparency

**UNCITRAL anchor.** Technical Notes §III: ODR procedures should be
"transparent, consistent, and effective." Participants must understand the
process, the roles, the rules that apply, and the consequences of choices they
make.

**Concordia product requirement.**

1. Every case surfaces the operational-mode banner from §179.1.2.3
   (brainstorming / facilitated mediation support / procurement negotiation /
   governance process / arbitration support / legal-review drafting) with
   plain-language headline, subhead, and disclaimer.
2. Every candidate agreement carries clause-level provenance (§179.2.3.3)
   tracing each term to a party interest, evidence item, template, or optimizer
   move.
3. Preference inference outputs carry uncertainty (§179.3.2.5): posterior mean,
   credible interval, comparison count, instability warnings.
4. Search results surface the Pareto-frontier explanation (§179.4.3.1) and
   party-specific private explanations (§179.4.3.2) with explicit concession
   disclosure.
5. Model and optimizer versions are pinned per accepted agreement (§179.5.3.3)
   so the decision can be reproduced.

**Phase 179 task pointers.** `179.1.2.3`, `179.2.3.3`, `179.3.2.5`, `179.4.3.*`,
`179.5.3.3`, `179.6.3.4` (observability), `179.10.1` (contracts:check drift
prevention).

**Testable acceptance criteria.**

- Every case in Playwright fixture (`179.10.4`) renders the banner before any
  intake collection.
- `GET /concordia/audit/{id}` (`179.2.2.1`) returns a reproducible trail
  including model and optimizer versions.
- Explanation layer emits both shared-neutral and party-specific views
  (`179.4.3.1`–`179.4.3.3`) on every run.

**Gaps.** Transparency of multi-party explanations is explicitly a Phase B
deliverable (§179.9.2.2) — the contracts layer exposes the shape but the
implementation lands after Phase A foundations.

---

## 3. Due process

**UNCITRAL anchor.** Technical Notes §IV: each party must have a reasonable
opportunity to present the party's case, respond to the other party's
submissions, and correct the information being acted upon. ODR platforms must
not effectively shorten these opportunities simply because the medium is
electronic.

**Concordia product requirement.**

1. Every party has a private-intake flow (§179.3.1.\*) with correction surfaces
   (§179.3.1.5) where they can review and correct the inferred priorities before
   any search run begins.
2. Evidence upload, private-caucus, and preference-query pacing respect per-case
   timelines; no candidate enters acceptance without both parties having had
   matched opportunities.
3. Parties have the right to review and correct their inferred utility model
   (§179.3.1.5) and to contest the Pareto-frontier scoring before accepting.
4. "Cooling-off" and delayed confirmation for sensitive / high-value settlements
   (§179.5.2.5).
5. Appeal, pause, reopen, and nullification workflows (§179.5.3.2) preserve
   post-acceptance due-process remedies.

**Phase 179 task pointers.** `179.3.1.*`, `179.4.3.4` (protect-this-term and
human-mediator-review controls), `179.5.2.5`, `179.5.3.2`, `179.10.3`
(integration tests), `179.10.13` (settlement lifecycle verification).

**Testable acceptance criteria.**

- Integration test `179.10.3` proves every party had intake correction access
  before search-run entry.
- Cooling-off timers configurable per tenant and use-case class.
- Appeal workflow exercisable end-to-end in Playwright coverage.

**Gaps.** Cooling-off timer specification lives at the orchestrator
(`179.6.3.*`), not in contracts; track as a refinement task when the
orchestrator lands.

---

## 4. Accountability

**UNCITRAL anchor.** Technical Notes §III calls for clear identification of
actors, roles, and responsibilities, plus an auditable trail of decisions and
actions taken by each actor.

**Concordia product requirement.**

1. Typed identity and authority fields on every contract (§179.2.1.3):
   `canNegotiate`, `canAccept`, `canBindOrganization`, `requiresHumanApproval`,
   `requiresCounselReview`, `requiresGuardianOrRepresentative`,
   `settlementLimit`.
2. RBAC / ABAC policies for every role (§179.2.5.2) with tenant / case-level
   isolation.
3. Conflict-of-interest disclosures and assignment rules (§179.2.5.3) for
   mediators, reviewers, counsel, procurement approvers, DAO stewards.
4. Audit events (§179.2.2.3) emitted on every material step: case created, party
   joined, intake completed, issue identified, preference updated, offer
   generated, offer compared, search completed, draft reviewed, settlement
   accepted, execution completed, escalation required.
5. Incident reporting (§179.5.3.4) for unsafe recommendations, privacy leaks,
   biased outcomes, unauthorized acceptance, execution mismatch.
6. Reviewer-queue operations (§179.5.5.1): SLA, assignment, dual-control,
   calibration, audit sampling, unstaffed-gate block.

**Phase 179 task pointers.** `179.2.1.3`, `179.2.2.3`, `179.2.5.*`,
`179.5.3.1`–`179.5.3.5`, `179.5.5.1`, `179.5.4.3` (evidence chain-of-custody),
`179.10.10` (authorization automation), `179.10.11` (consent and evidence
tests).

**Testable acceptance criteria.**

- Negative authorization tests (`179.2.5.4`) prove no cross-party, cross-tenant,
  or reviewer-only field leakage.
- Audit-event contract tests in `contracts:check` (`179.10.1`).
- `GET /concordia/audit/{id}` reproduces every material action with actor,
  timestamp, and artifact version.

**Gaps.** None at contracts layer. Real-time queue SLA monitoring is a
§179.5.5.1 orchestrator deliverable.

---

## 5. Accessibility

**UNCITRAL anchor.** Technical Notes §III and §IV repeatedly emphasize that the
ODR platform must be usable by parties of differing technical sophistication,
device capabilities, languages, and accessibility needs. ODR must not re-create
digital divides.

**Concordia product requirement.**

1. Accessibility, localization, and low-bandwidth support in the workbench
   (§179.6.1.5) for mediation beyond high-end devices and English speakers.
2. Accessibility automation in release gates (§179.10.12) covering axe / WCAG
   checks, keyboard-only flows, screen-reader labels, focus order, localization,
   low-bandwidth mode, mobile viewport behavior.
3. Multilingual intake with language-preserving summaries (§179.3.1.3) and
   explicit detection of internal-reasoning language drift.
4. Two-device / multi-device private intake (§179.6.2.2) for participants who
   share physical space but need isolated Concordia sessions.

**Phase 179 task pointers.** `179.3.1.3`, `179.6.1.5`, `179.6.2.2`, `179.10.12`.

**Testable acceptance criteria.**

- Axe / WCAG coverage gate `179.10.12` blocks release on regressions.
- Multilingual fixture suite covers a spoken-language set defined by per-tenant
  jurisdiction posture.
- Mobile-viewport and low-bandwidth Playwright fixtures pass for every workbench
  role.

**Gaps.** Reading-level analysis of Concordia disclaimer copy (simple, plain
language at roughly a 7th-8th grade level per UNCITRAL accessibility norms) is
not currently a named task. Track as a follow-up under `179.6.1.5`.

---

## 6. Neutrality

**UNCITRAL anchor.** Technical Notes §III: neutrals must be impartial and
independent of the parties; the platform itself must not prefer one party's
interests. This is a dual requirement — neutral personnel and neutral
infrastructure.

**Concordia product requirement.**

1. Physically isolated per-party prompt contexts (§179.5.1.1): no shared model
   call may include opposing-party private fields. The platform has no
   structural preference because it literally cannot see one side while acting
   on the other.
2. Per-party data keys, HSM / KMS integration (§179.5.1.2).
3. Conflict-of-interest disclosures and assignment rules (§179.2.5.3) for every
   reviewer role.
4. Mediator-assist mode (§179.6.1.2) produces suggestions for the human
   mediator; the mediator remains the neutral, Concordia is supporting
   infrastructure.
5. The explanation layer produces party-specific private explanations and
   shared-neutral explanations separately (§179.4.3.2–`179.4.3.3`); the shared
   explanation never reveals private concessions or reservation points.
6. Coercive-choice safeguards (§179.4.3.5): no dark patterns, no countdown
   pressure, no hidden settlement authority, no manipulated anchors.

**Phase 179 task pointers.** `179.2.5.3`, `179.4.3.2`–`179.4.3.5`,
`179.5.1.1`–`179.5.1.5`, `179.6.1.2`, `179.10.5` (security tests preventing
private-field leakage).

**Testable acceptance criteria.**

- Privacy red-team test (`179.5.1.5`) proves prompt-injection, tool
  exfiltration, side-channel leakage cannot cross the party boundary.
- Shared-explanation test proves no private concession leaks in cross-party
  rendering.
- Coercive-pattern lint test rejects countdown timers, hidden-accept buttons, or
  asymmetric disclosure in workbench fixtures.

**Gaps.** Secure-enclave execution for utility scoring (§179.5.1.4) is an
explicit Phase D target; the contracts layer does not gate on it today.

---

## 7. Party control

**UNCITRAL anchor.** Technical Notes §III and §V: parties must retain agency
over whether to participate, what data they share, when they withdraw, and
whether they accept a proposed resolution. Consent must be informed and ongoing.

**Concordia product requirement.**

1. Explicit informed consent (§179.1.2.4) — per-purpose, narrow default scope,
   opt-in, captured with prompt text and version for audit. Implemented in
   `@concordia/contracts/consent`.
2. Revocation and withdrawal workflows (§179.5.4.2): parties can stop future
   processing, quarantine derived utility models, withdraw entirely.
   Quarantine-aware by design.
3. Data-subject export, deletion, legal-hold, residency, retention workflows
   (§179.5.4.5).
4. Party review / correction of inferred priorities before any search run
   (§179.3.1.5).
5. Candidate controls ("show me more like this," "protect this term," "do not
   show this style again," "human mediator review"; §179.4.3.4).
6. Cooling-off / delayed confirmation for sensitive or high-value settlements
   (§179.5.2.5).
7. Party identity verification, representative delegation, organization
   authority proof, guardian / counsel linkage before any acceptance or
   execution workflow (§179.2.5.1).

**Phase 179 task pointers.** `179.1.2.4` (landed), `179.3.1.5`, `179.4.3.4`,
`179.5.2.5`, `179.5.4.*`, `179.2.5.1`, `179.10.11` (consent and evidence tests).

**Testable acceptance criteria.**

- Consent ledger coverage test (`179.10.11`): collection consent, sharing
  consent, consent revocation, withdrawal, legal hold, redaction, evidence
  chain-of-custody, malware rejection, tamper detection, data export / deletion.
- `missingCoreConsents()` helper returns the seven §179.1.2.4 core purposes when
  no grants exist (verified in
  `libs/contracts/concordia/src/consent/consent.test.ts`).
- Revocation test: after a party revokes, downstream model scoring stops,
  derived artifacts are quarantined, and the party's consent record reflects the
  state transition.

**Gaps.** Revocation quarantine of derived utility models is a §179.5.4.2
orchestrator behavior; the consent contracts ledger exposes the state
transitions it consumes but does not implement the quarantine.

---

## Coverage matrix

| UNCITRAL principle | Contracts layer landed?                            | Orchestrator / services deferred to | Release gate |
| ------------------ | -------------------------------------------------- | ----------------------------------- | ------------ |
| Fairness           | partial (use-case tiers, boundaries, escalation)   | 179.3.3._, 179.8.2._                | 179.10.6     |
| Transparency       | partial (operational-mode banners, consent)        | 179.2.3.3, 179.4.3.\*, 179.5.3.3    | 179.10.1     |
| Due process        | partial (escalation, use-case tiers)               | 179.3.1.\*, 179.5.2.5, 179.5.3.2    | 179.10.3     |
| Accountability     | partial (authority intent, boundaries, escalation) | 179.2.5._, 179.5.3._, 179.5.5.1     | 179.10.10    |
| Accessibility      | not in contracts                                   | 179.6.1.5, 179.3.1.3                | 179.10.12    |
| Neutrality         | partial (banners, use-case tiers)                  | 179.5.1._, 179.4.3._                | 179.10.5     |
| Party control      | landed (consent module) + partial (use-case tiers) | 179.5.4.\*, 179.3.1.5, 179.4.3.4    | 179.10.11    |

"Landed" entries have passing tests in `libs/contracts/concordia/`. "Partial"
entries have typed contracts that downstream layers will consume. "Not in
contracts" entries are orchestrator / frontend concerns tracked in their own
phase tasks.

---

## Named gaps and follow-ups

The following are called out by this mapping but are not yet explicit Phase 179
tasks. They should be picked up in the next §179.6._ or §179.10._ refinement:

- **Reading-level and plain-language audit** of Concordia disclaimer copy
  (UNCITRAL accessibility norm: roughly 7th-8th grade reading level). Currently
  no task specifies this; add under `179.6.1.5` or `179.10.12`.
- **Translation / localization coverage matrix** — which locales must pass the
  release gate. Currently implicit in `179.10.12`; a named locale set helps.
- **Cooling-off timer specification** — durations per use-case class and value
  threshold. Contracts layer can carry the field; orchestrator implements. Add
  under `179.5.2.5`.
- **Reviewer-disclosure transparency** — when a reviewer dispositions a case,
  the parties see _that_ it was reviewed but not _who_. UNCITRAL neutrality
  principle suggests this is correct; make it explicit in `179.4.3.3`.
- **Ongoing-consent re-prompt cadence** — for long-running cases (procurement
  campaigns, DAO governance over months), periodic re-confirmation of consent.
  Not named today; add under `179.5.4.1`.

These gaps do not modify the Phase 179 TODO list from this task alone but are
tracked so the next refinement pass incorporates them.

## Refresh policy

The UNCITRAL portal at
https://uncitral.un.org/en/texts/onlinedispute/explanatorytexts/technical_notes
is re-checked at every gate firing per
[`../research/refresh-gate.md`](../research/refresh-gate.md) §R3. Any material
text change re-triggers this mapping and any dependent Phase 179 tasks.