# Gap Analysis — Concordia vs. Mediator.ai

Analysis date: **2026-04-23**

Scope: Phase 179 Concordia task `179.1.1.3`.

This analysis takes Mediator.ai as the nearest public frontier reference for
LLM-assisted cooperative bargaining and enumerates the gaps Phase 179
Concordia must close to reach and surpass it. It uses Mediator.ai's own
public architecture blog (2026-04-20) and its homepage (fetched 2026-04-23)
as the basis. It cross-references the Concordia competitive audit at
[`mediation-negotiation-2026.md`](./mediation-negotiation-2026.md) and the
source matrix at [`source-matrix.md`](./source-matrix.md).

The nine gap axes below are the ones named in `179.1.1.3`:

1. Multi-party support
2. Formal agreement DSL
3. Uncertainty-calibrated preference inference
4. Multimodal evidence
5. Provable privacy isolation
6. Domain-specific templates
7. Smart-contract execution
8. Governance appeal paths
9. Cross-domain Oshun integrations

For each axis: (a) the **Mediator.ai baseline** (what their public material
actually commits to), (b) the **Concordia requirement** (what Phase 179
demands), (c) the **gap** (what Concordia must build that Mediator.ai does
not do), (d) the **concrete task pointers** in Phase 179 that deliver it,
and (e) an **evidence note** flagging what is claim vs. verified.

---

## 0. Mediator.ai baseline summary

The public posture, captured 2026-04-23:

- **Two-party consumer cooperative negotiation.** Homepage and blog frame
  the system as "agreements that two people in conflict would both accept."
  No N-party claim anywhere.
- **Architecture (self-described):** an LLM used as a *pairwise preference
  ranker* inferring per-party utility; a *genetic algorithm* with crossover,
  mutation, and selection over candidate agreements; clause mutators
  implemented as isolated Lua scripts whose selection probability adapts to
  performance; *Nash bargaining* as the scoring rule.
- **Agreement output:** free-text drafts rendered from LLM generations (e.g.
  bakery partnership example). No typed clause model visible to users or
  callers.
- **Privacy:** "Parties walk through their side privately." No stated
  encryption, no per-party KMS key scoping, no isolated prompt-context
  guarantee, no data-residency posture, no published privacy policy beyond
  marketing text.
- **Compliance:** No SOC 2, GDPR, EU AI Act, UNCITRAL ODR, NIST AI RMF
  references.
- **Execution:** No smart-contract, escrow, or off-chain settlement
  execution path. The output is a draft, not an executable artifact.
- **Appeals / governance:** No reviewer queue, no human-mediator workflow,
  no override, pause, reopen, or incident reporting paths described.
- **Integrations:** None. Mediator.ai is a standalone consumer site.
- **Self-disclosed risks** in their blog: preference instability, BATNA
  manipulation, specification gaming, enforceability, incomplete option
  discovery, leverage-seeking counterparties. All six are live risks
  Concordia must address directly, not work around.

This baseline is not a straw man: Mediator.ai is the only public system
that names Nash bargaining and describes its optimization stack. It is
genuinely the right reference point. The gap below is measured against
this real posture, not a hypothetical.

---

## 1. Multi-party support

**Mediator.ai baseline.** Two-party only. The homepage and blog consistently
refer to "two people." The Nash product scoring generalizes to more parties
in theory, but Mediator.ai does not claim or demonstrate three-party or
coalition bargaining.

**Concordia requirement.** N-party bargaining with coalition reasoning.
Phase 179 names restorative circles (Kuanyin), DAO proposals (Themis),
procurement cohorts (Maat), creative royalty splits (Euterpe, Calliope),
and agent-to-agent contracts (Iris / Nous), all of which are N-party by
nature.

**The gap.** Mediator.ai has no blocking-coalition detection, no Shapley
attribution, no core-membership check, no bargaining set, and no
side-payment generation. Its GA mutators do not represent coalition
structure.

**How Concordia closes it.** Task-level pointers:

- `179.4.2.7` — implement multi-party coalition stability: core membership,
  blocking coalition detection, Shapley-value attribution, bargaining set,
  side-payment generation.
- `179.4.1.2` — structured proposal decomposition so multi-party candidates
  can borrow clauses across parties.
- `179.4.2.2` — NSGA-II / MAP-Elites Pareto-frontier search that scales
  beyond two-objective optimization; required to render tradeoffs across
  three or more parties.
- `179.5.2.4` — collusion and coercion detection specifically framed for
  multi-party cases.

**Evidence note.** Mediator.ai's two-party posture is explicit in their
copy, not inferred. Concordia's N-party requirement traces to Phase 179's
named domains in §179.7. The academic grounding for coalition stability is
Shapley (1953) and the bargaining-set literature; ProMediate (2026)
further validates N-party proactive mediator evaluation.

## 2. Formal agreement DSL

**Mediator.ai baseline.** Free-text drafts. The bakery example reads as
natural-language prose. Mutators operate at the Lua-script level, not a
typed-clause level visible to callers.

**Concordia requirement.** Agreement terms must be **typed clauses with
variables, constraints, dependencies, temporal conditions, signatories,
enforcement paths, and review requirements** (per `179.2.3.1`). Terms must
be amenable to static validation (`179.2.3.4`) and mapped to jurisdiction
and domain templates (`179.2.3.5`).

**The gap.** Mediator.ai has no static validator, no clause provenance
trail, no jurisdiction-aware template registry, no human-review flag
system. If an LLM draft contains an impossible deadline, a contradictory
payment schedule, or an unlawful exclusivity clause, Mediator.ai's genetic
search has no formal machinery to catch it. This directly feeds the
specification-gaming risk Mediator.ai itself names.

**How Concordia closes it.** Task-level pointers:

- `179.2.3.1` — `AgreementDSL` typed clauses.
- `179.2.3.2` — common term families: money, equity, royalties,
  deadlines, deliverables, service levels, licensing, exclusivity,
  territory, data rights, governance rights, voting thresholds, apology,
  confidentiality, non-disparagement, restitution, restorative actions,
  access revocation, buy-sell clauses, escrow release, monitoring.
- `179.2.3.3` — clause-level provenance linking each term to its source
  (party interest, evidence, template, or optimizer move).
- `179.2.3.4` — static validator for impossible, contradictory, unlawful,
  unenforceable, unsafe, or policy-blocked clauses **before** candidates
  enter optimization.
- `179.4.1.3` — clause mutators run in a sandboxed DSL, not raw prompt
  text, so the search space is inspectable.

**Evidence note.** The DSL gap is the single most leveraged deliverable
against Mediator.ai's self-named risks: every one of specification gaming,
enforceability, and incomplete option discovery maps back to the absence
of a typed, validated clause model.

## 3. Uncertainty-calibrated preference inference

**Mediator.ai baseline.** Pairwise LLM prompts infer utility. Their blog
names preference instability as a risk but does not describe calibration,
active learning, or stability testing in their implementation.

**Concordia requirement.** Every utility score must carry posterior mean,
credible interval, comparison count, nearest known comparison, and
instability warnings (`179.3.2.5`). Low-confidence, unstable, refused,
redline-blocked, or morally / legally non-tradeable comparisons must be
abstained from, not laundered into a numeric score (`179.3.2.6`).

**The gap.** Mediator.ai collapses uncertainty into a point estimate and
feeds it to the GA. Concordia treats uncertainty as a first-class output
that the optimizer, the explanation layer, and the review gate must all
consume.

**How Concordia closes it.** Task-level pointers:

- `179.3.2.2` — Bradley-Terry, Thurstone-Mosteller, Plackett-Luce,
  Gaussian-process preference, and neural utility-ranking models trained
  and calibrated from pairwise comparisons.
- `179.3.2.3` — active-learning selection of comparison pairs that
  maximally reduce uncertainty near the Pareto frontier and redlines.
- `179.3.2.4` — preference-stability tests: paraphrase, prompt-template,
  model-version, order-effect, adversarial framing.
- `179.3.2.5` — uncertainty output on every score.
- `179.3.2.6` — abstention and incomparability states.
- `179.3.3.2` — hard constraints and soft preferences separated so redlines
  cannot be laundered by an optimizer into high utility.

**Evidence note.** The "LLM Rationalis?" arXiv 2025 paper and "The Price
of Thought" 2025 directly document preference instability in LLM
negotiators. Concordia's calibration requirement is not speculative.

## 4. Multimodal evidence

**Mediator.ai baseline.** Text-only. No evidence upload, no image / audio
/ video / document handling, no authenticity confidence, no malware
scanning, no redaction.

**Concordia requirement.** Evidence with chain-of-custody, malware
scanning, file hash, uploader identity, source assertion, timestamp,
redaction state, authenticity confidence, privilege flag, retention
class, and tamper detection (`179.5.4.3`). Redaction and minimization
before evidence enters prompts, vector stores, logs, candidate clauses,
shared explanations, or benchmark datasets (`179.5.4.4`).

**The gap.** Mediator.ai has no evidence layer at all. For any dispute
grounded in documents, photographs, messages, contracts, invoices,
receipts, or recorded conversations, Concordia must bring its own
evidence pipeline — Mediator.ai simply cannot represent them.

**How Concordia closes it.** Task-level pointers:

- `179.2.1.1` — `EvidenceItem` is a first-class Concordia contract.
- `179.5.4.3` — full chain-of-custody pipeline.
- `179.5.4.4` — redaction and minimization pipeline.
- `179.6.1.1` — workbench evidence room with mediator-only and
  party-specific views.
- `179.7.4.5` — Themis Universal Originality Shield integration so
  evidence carries originality confidence and source overlap attribution
  on IP-related disputes.

**Evidence note.** Multimodal evidence is common across target domains —
Yemaya production deliverables, Euterpe sample clearance, Aglaea / Freya
returns with photos, Kuanyin restorative timelines, Maat supplier
quality claims. The gap is not hypothetical.

## 5. Provable privacy isolation

**Mediator.ai baseline.** Informal private-caucus framing. No stated
physical prompt isolation, no per-party data keys, no HSM / KMS, no
zero-retention mode, no confidential-compute story, no red-team against
prompt injection or side-channel leakage.

**Concordia requirement.** Physically separate prompt contexts per party;
no shared model call may include opposing-party private fields
(`179.5.1.1`). Sealed-memory stores with envelope encryption, per-party
data keys, HSM / KMS integration, audit logs on every read (`179.5.1.2`).
Zero-retention local-model mode through Nous for privileged / sensitive /
air-gapped cases (`179.5.1.3`). Secure-enclave / confidential-compute
execution for utility scoring where the platform should not see raw
inputs (`179.5.1.4`). Privacy red-team tests for prompt injection, tool
exfiltration, summary leakage, side-channel inference, and
shared-explanation leakage (`179.5.1.5`).

**The gap.** The gulf is enormous. Mediator.ai describes privacy as a
user-experience pattern; Concordia treats it as an architectural
property with cryptographic, isolation-mode, and red-team evidence.

**How Concordia closes it.** Task-level pointers:

- `179.2.1.2` — privacy-scoped fields on every contract
  (`visibility`, `legalSensitivity`, `safetySensitivity`,
  `retentionPolicy`, `privilegeClaim`) with enumerated visibility values
  including `private_to_party`, `mediator_only`, `reviewer_only`,
  `sealed_until_consent`.
- `179.2.1.5` — contract tests ensuring no private party fields can
  serialize into shared views or opposing-party prompts.
- `179.5.1.1`–`179.5.1.5` — the full privacy architecture stack.
- `179.2.5.4` — negative-authorization tests proving users cannot infer,
  list, search, export, log, or subscribe to another party's private
  fields.
- `179.10.5` — release gate requiring proof that private party data
  cannot leak through shared summaries, explanations, logs, traces,
  generated agreements, or domain events.

**Evidence note.** This is where Concordia's architecture substantively
exceeds every reviewed competitor, not just Mediator.ai. Only Disputell
disclosed a strong private-caucus posture in the audit, and it is
intake-only. Pactum and Nibble have compliance certifications
(SOC 2 Type II, ISO 27001) but not per-prompt isolation.

## 6. Domain-specific templates

**Mediator.ai baseline.** Generic two-party framing. No named
procurement templates, no royalty templates, no DAO templates, no
restorative templates, no employment or family templates (and no stated
refusal to handle those high-risk classes either).

**Concordia requirement.** Jurisdiction and domain template registries
with mandatory human-review flags for legal, employment, family,
regulated finance, healthcare, and minors-related clauses (`179.2.3.5`).
Domain candidate generators for procurement, creative royalties, DAO
governance, platform moderation appeals, marketplace disputes, cofounder
equity, supplier service levels, collaborative production, multiplayer
guild governance, and agent-to-agent contracts (`179.4.1.4`).

**The gap.** Without a template layer, an LLM draft floats without
anchoring in the statutes, market norms, or professional conventions of
the domain it is operating in. This is a large part of Mediator.ai's
self-named enforceability risk.

**How Concordia closes it.** Task-level pointers:

- `179.2.3.5` — template registries.
- `179.4.1.1` — initial candidates drawn from party proposals, mediator
  templates, domain playbooks, precedent agreements, policy constraints,
  and LLM brainstormed tradeoff bundles.
- `179.4.1.4` — domain-specific generators.
- `179.7.1.1` through `179.7.6.5` — full ecosystem integration map
  defining per-domain template families.
- `179.1.2.1` — `ConcordiaUseCaseClass` enumeration formalizes the
  domain boundaries that template selection must respect.

**Evidence note.** JAMS AI Rules and AAA panel specializations show that
domain-specific procedural templates are table stakes in institutional
ADR. Mediator.ai's absence of such templates is the expected posture for
a consumer MVP but disqualifies it as an enterprise or legal-grade
substrate.

## 7. Smart-contract execution

**Mediator.ai baseline.** None. The output is a draft agreement; parties
take it to whatever channel they prefer for signing and enforcement.

**Concordia requirement.** Smart-contract escrow for deposits, milestone
payouts, royalties, refunds, arbitration bonds, agreement-hash
anchoring, and on-chain execution after required review (`179.7.2.4`).
Off-chain settlement lifecycle with versioned redlines, counsel
comments, e-signature, document export, acceptance ceremony, amendment,
rescission, default notice, remedy tracking, obligation completion
monitoring (`179.5.5.2`). Kill-switch and feature-flag controls
(`179.5.5.3`). Sanctions / KYC, payment rails, invoice reconciliation,
tax treatment, currency exposure, approval thresholds, segregation of
duties (`179.5.5.4`).

**The gap.** Execution is where Mediator.ai ends and Concordia begins.
Procurement (Maat), DAO (Themis, Aje), creative royalty (Yemaya,
Euterpe), and marketplace (Aglaea, Freya) workflows require executable
settlements, not drafts.

**How Concordia closes it.** Task-level pointers:

- `179.2.1.1` — `SettlementDraft` and `ExecutionArtifact` contracts.
- `179.5.5.2` — off-chain settlement lifecycle.
- `179.7.2.4` — Aje smart-contract escrow integration.
- `179.7.2.5` — optional Kleros / optimistic-challenge adapters as
  arbitration backstops, explicitly not as default decision-makers.
- `179.10.13` — settlement lifecycle verification gate.

**Evidence note.** MediationAI's "court-enforceable" smart-contract
framing is marketing without verified jurisdictional backing.
Concordia's posture — execution only behind qualified-review gates and
documented settlement lifecycle — is the defensible path.

## 8. Governance appeal paths

**Mediator.ai baseline.** None described. No reviewer queue, no human
override, no incident reporting, no appeal surface, no model-version
pinning for reproducibility.

**Concordia requirement.** Reviewer queues for human mediators, counsel,
compliance, DAO stewards, procurement officers, safety teams, and domain
experts (`179.5.3.1`). Override, pause, reopen, appeal, nullification
workflows with full audit trail (`179.5.3.2`). Model and optimizer
version pinning so every accepted agreement can be reproduced
(`179.5.3.3`). Incident reporting for unsafe recommendations, privacy
leaks, biased outcomes, unauthorized acceptance, execution mismatch
(`179.5.3.4`). Integration with Maat governance and Themis audit reports
for periodic board-level oversight (`179.5.3.5`).

**The gap.** Appeals infrastructure is the difference between a
consumer negotiation toy and an ODR-grade or procurement-grade system.
UNCITRAL ODR principles and EU AI Act high-risk requirements both
demand it.

**How Concordia closes it.** Task-level pointers:

- `179.1.2.5` — escalation policies mapping use-case risk to reviewer
  queues.
- `179.5.3.1`–`179.5.3.5` — full governance and oversight stack.
- `179.5.5.1` — reviewer capacity controls, queue SLA, dual-control for
  high-risk cases, calibration review, audit sampling, escalation when
  no qualified reviewer is available; blocked launch status for
  unstaffed gates.
- `179.6.1.1` — workbench surfaces for mediator, party, reviewer.
- `179.10.7` — governance-review gate in completion criteria.

**Evidence note.** JAMS AI Rules formalize expert appointment,
secured-environment inspection, and expedited procedures; AAA AI-Native
Arbitrator requires human review of AI-drafted awards. These are the
external reference points. Mediator.ai has none of them.

## 9. Cross-domain Oshun integrations

**Mediator.ai baseline.** Standalone consumer site. No integrations, no
SDKs beyond the web app, no event surface, no ecosystem adapters.

**Concordia requirement.** First-class integration with Maat, Themis,
Kuanyin, Iris, Aje, Yemaya, Euterpe, Calliope, Lilith, Aphrodite, Tara,
Isis, Aja, Bellona, Neith, Maya, Hathor, Aglaea, Freya, Asase, Demeter,
Hestia, Annapurna, Cybele, Seshat, Athena, Brigid, Saraswati, Lakshmi,
Nyx, Metis, Mnemosyne, Nisaba, Kalika, Veritas, Psyche (per §179.7.*
subsections). Agent-to-agent negotiation protocol across Iris / Nous /
Neith / Maya (`179.7.6.*`). Event-bus integration with
`@oshun/contracts/events` (`179.6.3.3`).

**The gap.** This is the single biggest strategic wedge. Mediator.ai
solves one consumer use case; Concordia is the cooperative-decision
substrate for an entire ecosystem. Every pilot domain in `179.9.3`
compounds value because they share the same bargaining substrate,
privacy model, contracts, and audit trail.

**How Concordia closes it.** Task-level pointers:

- `179.2.2.1`–`179.2.2.4` — OpenAPI / proto / event surface.
- `179.2.4.1`–`179.2.4.5` — repo integration, Nx graph, codegen,
  App Router mount, service-layer decision.
- `179.7.1.*`–`179.7.6.5` — full ecosystem integration map.
- `179.6.3.1`–`179.6.3.5` — orchestrator service, background workers,
  event bus, observability, tenant / domain configuration.

**Evidence note.** The cross-domain wedge is not a Mediator.ai
deficiency per se — it is a different product category. But the Phase
179.1.1.3 gap analysis requires naming it because surpassing
Mediator.ai by pure algorithm quality alone is insufficient; the lasting
advantage is ecosystem integration.

---

## Summary table

| Axis | Mediator.ai posture | Concordia delta | Primary task pointers |
| --- | --- | --- | --- |
| 1. Multi-party | 2-party only | N-party + coalitions + Shapley | 179.4.2.7, 179.4.1.2, 179.5.2.4 |
| 2. Agreement DSL | free-text drafts | typed clauses + static validation + provenance | 179.2.3.*, 179.4.1.3 |
| 3. Preference uncertainty | point estimates | calibrated posteriors, active learning, stability tests, abstention | 179.3.2.2–179.3.2.6, 179.3.3.2 |
| 4. Multimodal evidence | text only | full evidence chain-of-custody and redaction | 179.5.4.3–179.5.4.4, 179.6.1.1 |
| 5. Privacy isolation | informal caucus | physical prompt isolation, KMS, zero-retention, enclave, red-team | 179.5.1.*, 179.2.1.2, 179.2.5.4, 179.10.5 |
| 6. Domain templates | none | jurisdiction + domain registries; 10+ domain generators | 179.2.3.5, 179.4.1.1, 179.4.1.4, 179.7.* |
| 7. Execution | none | off-chain lifecycle + smart-contract escrow behind review | 179.5.5.2, 179.7.2.4, 179.10.13 |
| 8. Governance appeals | none | reviewer queues, override / pause / reopen / appeal, model pinning, incidents | 179.5.3.*, 179.5.5.1, 179.10.7 |
| 9. Cross-domain | standalone | full Oshun ecosystem surface + events + SDKs | 179.2.2.*, 179.2.4.*, 179.7.*, 179.6.3.* |

---

## Strategic read

The nine gaps cluster into three strategic moves:

- **Formalization** (gaps 2, 3, 6) — replace LLM-generated prose and
  point-estimate utilities with a typed clause model, calibrated
  uncertainty, and domain-specific template registries. This alone
  neutralizes Mediator.ai's self-named specification-gaming,
  enforceability, and incomplete-option-discovery risks.
- **Enterprise / legal safety** (gaps 4, 5, 7, 8) — multimodal evidence,
  provable privacy isolation, executable settlement lifecycle, and
  governance appeals. These take Concordia out of the "consumer
  negotiation app" category and into the UNCITRAL ODR / EU AI Act /
  NIST AI RMF / JAMS AI Rules reference tier.
- **Ecosystem leverage** (gaps 1, 9) — N-party coalition bargaining and
  full Oshun integration across Maat, Themis, Kuanyin, Iris, Aje,
  Yemaya, and beyond. Mediator.ai solves one vignette per run;
  Concordia solves a substrate used by dozens of domains.

These three moves map cleanly to the Phase 179.9 sequence: Phase A
(foundation) lands formalization and the minimum privacy / governance
stack; Phase B (surpass Mediator.ai) closes the enterprise / legal
safety gaps and lands coalition search; Phase C (ecosystem rollout)
delivers integration leverage. Phase D's confidential-compute and
learned mediator policies push past Mediator.ai's entire category.

## Caveats

- Mediator.ai's posture could change without notice. The
  `179.1.1.6` refresh gate requires rerunning this analysis before
  Phase B and before every pilot.
- Any claim in this document sourced to Mediator.ai's blog is a
  self-architecture claim (strength `C` in the source matrix). The
  bargaining literature cited (Nash, Kalai-Smorodinsky, Rubinstein) is
  peer-reviewed and strength `A`; Concordia should anchor its public
  posture in those, not in Mediator.ai's framing.
- This gap analysis is against Mediator.ai specifically. The Pactum
  and Nibble gap analysis at `179.1.1.4` covers the procurement /
  commerce vertical where Mediator.ai does not play.