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 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
2. Fairness
3. Transparency
4. Due process
5. Accountability
6. Accessibility
7. Neutrality
8. Party control
9. Coverage matrix
10. 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#

"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 §R3. Any material text change re-triggers this mapping and any dependent Phase 179 tasks.