Disciplines · Research

Concordia Research Refresh Gate

1.

7sections10 minread
Markdown source
On this page

Last executed: 2026-04-23 (initial gate construction; no prior run).

Scope: Phase 179 Concordia task 179.1.1.6.

The refresh gate is a mandatory checkpoint that must complete with a signed-off checklist before either (a) any Phase B task is scheduled for implementation, or (b) any Concordia pilot is launched into a domain (Maat procurement, Themis governance, Kuanyin restorative, Iris personal, Aje escrow, Yemaya creative, or any subsequent Phase C / D pilot).

The gate exists because the competitive audit, source matrix, gap analyses, and bibliography in docs/research/ are dated snapshots of a landscape that moves. Product pricing, compliance posture, vendor traction claims, regulatory text, and peer-reviewed preprints all change without notice. Without a refresh discipline, Concordia will:

  • Build gap analyses against a posture that no longer exists.
  • Mis-cite a superseded arXiv version of a paper Concordia's design relies on.
  • Launch a pilot whose jurisdiction has just regulated against a Concordia capability (e.g., a new state AI act adopted after the design was locked).
  • Miss a new entrant that has moved the frontier since the last audit.

This document is the gate procedure. It is a living checklist that Concordia operators execute and sign off on. A passing gate produces:

  1. A dated refresh record under docs/research/refresh-log/YYYY-MM-DD.md.
  2. Updated versions of mediation-negotiation-2026.md, source-matrix.md, gap-analysis-mediator-ai.md, gap-analysis-pactum-nibble.md, and bibliography.md — or explicit "no change" annotations on each.
  3. Dated HTML / text archives of every vendor homepage under docs/research/archive/YYYY-MM-DD/<source>.html.
  4. A go / no-go decision on the pending Phase B transition or pilot launch.

A failing gate blocks the pending transition or launch. The block is lifted only after the responsible task owner reviews the findings and either (a) updates the Concordia design to absorb the change, or (b) documents a conscious decision to proceed despite the change, with rationale signed by the Concordia product owner, engineering lead, and counsel (where the change is regulatory or legal-posture).

When the gate runs#

Mandatory triggers:

  1. Before any Phase B task (179.9.2.*) is scheduled for start.
  2. Before every Phase C pilot (179.9.3.*) — one gate run per domain pilot, not once per phase.
  3. Before any Phase D task (179.9.4.*) is scheduled for start.
  4. At a minimum of once every 90 days while Concordia is under active development, regardless of phase state. "90-day idle refresh" is logged under the same refresh-log/ pattern as trigger-driven runs.
  5. On receipt of any incident report (Phase 179 §179.5.3.4) that touches a capability covered by one of the research documents — e.g., a privacy-leak incident triggers a refresh of §179.5.1 and §179.5.4 references.

Optional triggers (run the gate partially):

  • A vendor named in the audit announces a major product change (new category, acquisition, pivot, shutdown, funding round, certification win or loss) — refresh that vendor's row only.
  • A new regulatory instrument is promulgated in a Concordia target jurisdiction (EU, US state, UK, Canada, Australia) — refresh the standards / regulatory sections.
  • A new preprint on LLM negotiation, mediation, or bargaining is published that contradicts a Concordia design decision — refresh the bibliography and any affected gap analysis.

Partial runs still produce a refresh-log entry scoped to the subset that was re-checked.

Gate procedure#

The gate has six phases. Each phase produces an artifact or decision that the next phase consumes. All phases must complete before a pass / fail determination is possible.

Phase R1 — Snapshot the current baseline#

  1. git log --oneline -- docs/research/ for the last 90 days; confirm no stale-but-unrecorded edits.
  2. Record the current HEAD commit on main.
  3. Record the current date as the refresh date.
  4. Create docs/research/refresh-log/YYYY-MM-DD.md from the template in Appendix A — Refresh-log template.
  5. Record the trigger (Phase B start, specific pilot name, 90-day idle, incident ID, etc.).

Phase R2 — Re-fetch and archive vendor and standards sources#

The source matrix (source-matrix.md) is authoritative for what to re-fetch. For every row:

  1. Re-fetch the URL with a fresh, non-cached fetcher from a residential or mobile IP where possible (vendor WAFs often block datacenter IPs; the initial audit encountered this on ZODR and Dyspute.ai).
  2. Store the fetched HTML under docs/research/archive/YYYY-MM-DD/<slug>.html. <slug> is stable-derived from the source column in the matrix (e.g., mediator-ai-home, pactum-procurement-agents, jams-ai-rules).
  3. Diff the new fetch against the prior archive for the same source. If no prior archive exists, record the archive as the baseline.
  4. Record material changes in the refresh-log entry. "Material" means: pricing change, autonomy-posture change, compliance-certification change, named-customer change, funding / acquisition change, product shutdown, legal posture change, rule text change, privacy-policy change.
  5. For the (403) and (404) URLs in the prior matrix, explicitly retry from a different vantage; record the retry outcome.

Failed archives (persistent 403 / 404 / timeout) are allowed provided the refresh-log entry names the URL, the attempted vantages, and the substitute source (third-party press, cached snapshot, web.archive.org).

Phase R3 — Re-fetch regulatory and standards sources#

From bibliography.md §13 Standards and Regulation and §12 Mediation Ethics, re-check:

  • EU AI Act implementing acts, delegated acts, and guidance published since the prior gate date.
  • NIST AI RMF updates, new profiles, or published working-group notes.
  • JAMS Rules, AAA Rules (Commercial, Consumer, Employment, Construction, Mass), CPR Rules, ICC Rules — whichever have new versions since the prior gate.
  • US state AI acts (Colorado, California, New York, Texas), EU member- state implementing legislation, Canadian AIDA status, UK AI regulation status, Australian AI status.
  • Uniform Mediation Act amendments, state-level mediation confidentiality statute changes, ABA Model Rules amendments.

For every confirmed change, map it to the Concordia task that depends on the prior version and record a follow-up. If a change invalidates a design decision, the refresh-log entry flags it as a blocking item.

Phase R4 — Re-check peer-reviewed and preprint sources#

From bibliography.md §5, §6, §7, §8, §9:

  1. For every arXiv-identified source, fetch the canonical abs page and record whether the version bump has substantive content changes. v2 → v3 with only typo fixes is non-blocking; a new section or result is blocking for any Concordia component that cites it.
  2. Search for new preprints on LLM negotiation, LLM mediation, mediator-agent evaluation, preference instability, strategic reasoning in LLMs, and multi-party bargaining since the prior gate date. Add Concordia-relevant entries to the bibliography.
  3. Cross-reference the new preprints with the gap analyses. If a new preprint reveals a capability Concordia's design does not account for, flag as a refinement target.

Search corpus: arXiv cs.AI / cs.CL / cs.GT / cs.MA / cs.CY, NeurIPS, ICML, AAAI, IJCAI, AAMAS, ACL, EMNLP, CHI, CSCW, FAccT proceedings. For legal / ODR scholarship: SSRN, Kluwer Arbitration Blog, Arbitration Law Review, Harvard Negotiation Law Review, International Journal of Online Dispute Resolution.

Phase R5 — Apply changes and regenerate docs#

For every material change found in R2–R4:

  1. Update the affected docs/research/*.md file with the new fact, and either strike through (with commit-trail) or delete superseded text. Do not silently overwrite historical audit text — the mediation-negotiation-2026.md file is a dated snapshot; new audits belong in a file named for the new audit date (e.g., mediation-negotiation-2026-Q3.md) with a pointer back from the original.
  2. Update source-matrix.md rows with the new date, new strength tag if evidence changed, and new claim-type tag if posture changed.
  3. Update gap-analysis-mediator-ai.md or gap-analysis-pactum-nibble.md if a vendor change alters the gap delta or requires a new gap axis.
  4. Update bibliography.md with new preprints, new versions, and any newly-identified primary sources.
  5. Add entries to CHANGELOG.md under docs/research/ if one exists (create if not), noting the dated refresh and the high-level diff.

Phase R6 — Pass / fail determination#

The refresh-log entry closes with an explicit decision line:

  • GATE: PASS — proceed with <trigger>.
  • GATE: PASS-WITH-FOLLOWUPS — proceed; follow-up tasks <list> must be filed within 7 days.
  • GATE: FAIL — block <trigger>; required updates <list>.

A FAIL explicitly lists:

  • Which Concordia tasks or design artifacts are invalidated.
  • Which documents must be updated before re-running the gate.
  • Which stakeholders must sign off on any alternative proceed decision (product owner, engineering lead, counsel, Maat / Themis / Kuanyin domain owners if the pilot is in those domains, safety review if the change touches §179.5 safety posture).

A PASS is recorded; the pending trigger (Phase B task, pilot launch) is unblocked; the refresh-log entry is merged with the trigger action in the same PR where practical.

Blocking criteria#

Any one of the following automatically triggers a FAIL:

  1. A competitor named in the audit has shipped a capability Concordia had listed as a durable differentiator, and Concordia has not updated its gap analysis to reflect this.
  2. A jurisdiction in Concordia's pilot footprint has adopted new regulation that prohibits or restricts a capability in the pending trigger, and Concordia has not updated its posture.
  3. A peer-reviewed paper or high-quality preprint has reported a fundamental failure mode in a Concordia building block (e.g., a new demonstration that a particular preference-inference technique is badly calibrated on sensitive domains), and Concordia's tests (179.3.2.4) do not already cover it.
  4. A vendor homepage returns 404 / domain-parked / pivoted and the audit still describes them as operational.
  5. An incident report that triggered the gate has not been linked to the refresh-log entry.
  6. The archive directory under docs/research/archive/YYYY-MM-DD/ is missing for any source that was re-fetched successfully — archives are required evidence, not optional.
  7. More than two rows in the source matrix have moved from strength A or B down to C or D since the prior refresh (indicates significant evidence-quality degradation).

Non-blocking findings#

Findings that do not block the trigger but must be filed as follow-up tasks:

  • New preprints that extend but do not invalidate Concordia's design.
  • Non-material vendor changes (logo refresh, copy edits, minor pricing updates that do not change the pricing-model category).
  • Peer-reviewed version bumps with only editorial changes.
  • Additional regulatory guidance clarifying — not changing — a posture Concordia already mapped.

Automation#

The gate is human-executed today. Components that should be automated in Phase B or Phase C:

  • Scheduled re-fetching of every URL in source-matrix.md (weekly cron). Produce diffs and surface them to the research-maintainer queue; do not auto-update the docs.
  • arXiv / Google Scholar alerts for the search terms in R4.
  • Regulatory-tracker subscriptions (EU Official Journal, US Federal Register, state AI-act trackers).
  • Link-health monitor producing a weekly report of 403 / 404 / timeout URLs in the source matrix.

Automation output feeds a human-reviewed refresh run; the gate decision itself remains a human responsibility signed off by the Concordia product owner and — for regulatory / safety / high-risk changes — counsel and the safety reviewer lead.

Appendix A — Refresh-log template#

Save as docs/research/refresh-log/YYYY-MM-DD.md.

markdown
# Concordia Research Refresh — YYYY-MM-DD

**Trigger:** <Phase B start | pilot: {Maat, Themis, Kuanyin, Iris, Aje,
Yemaya, ...} | 90-day idle | incident: ID-####>
**Prior gate date:** YYYY-MM-DD (or `initial`)
**Baseline commit:** <short-sha on main>
**Executor:** <name>
**Sign-off:** <product owner>, <engineering lead>, <counsel if
applicable>, <safety reviewer if applicable>

## R1 — Baseline snapshot

- HEAD: <sha>
- Last `docs/research/` change: <sha> (<date>)
- Stale-edit check: <pass | findings>

## R2 — Vendor and standards source re-fetch

| Source | URL | Prior date | New date | Change | Archive path |
| --- | --- | --- | --- | --- | --- |
| ... | ... | ... | ... | ... | ... |

### Material changes

- <source>: <change description and link to updated doc>

### Failed fetches

- <source>: <attempted vantages>, <substitute source>

## R3 — Regulatory and standards re-check

- EU AI Act: <unchanged | changes summary + links>
- NIST AI RMF: <...>
- JAMS AI Rules / AAA Rules / CPR Rules / ICC Rules: <...>
- US state AI acts (CO, CA, NY, TX): <...>
- Uniform Mediation Act / ABA Model Rules: <...>
- Blocking items: <list or none>

## R4 — Academic and preprint re-check

- arXiv version bumps: <list with version and significance>
- New preprints added to bibliography: <list>
- New peer-reviewed papers added: <list>
- Design-invalidating findings: <list or none>

## R5 — Doc updates

- `mediation-negotiation-2026.md`: <updated | new dated snapshot at
  <filename> | no change>
- `source-matrix.md`: <diff summary>
- `gap-analysis-mediator-ai.md`: <diff summary>
- `gap-analysis-pactum-nibble.md`: <diff summary>
- `bibliography.md`: <diff summary>
- `CHANGELOG.md`: <entry added>

## R6 — Decision

`GATE: PASS | PASS-WITH-FOLLOWUPS | FAIL`

### Follow-ups

- [ ] <task ref> <description> — due YYYY-MM-DD

### Blocks

- <task or pilot> blocked pending <fix>

### Sign-offs

- Product owner: <name, date>
- Engineering lead: <name, date>
- Counsel: <name, date> (if regulatory / legal)
- Safety reviewer: <name, date> (if §179.5 touched)

Appendix B — Initial gate decision (2026-04-23)#

This document is being landed alongside the initial research artifacts; no prior gate has executed. Accordingly:

  • R1: baseline is HEAD at the commit of this task.
  • R2: the initial competitive audit captures the current vendor state as of 2026-04-23. Archive directory docs/research/archive/2026-04-23/ is not yet populated; this is tracked as a non-blocking follow-up task — the gate procedure requires archives for refresh runs, not for the initial authoring run.
  • R3–R4: covered by the initial audit, source matrix, and bibliography.
  • R5: all five docs/research/*.md files are freshly authored; no supersession events.

GATE: PASS — initial authoring run; no trigger pending. Next mandatory gate fires at: Phase B start, first Phase C pilot launch, or 2026-07-23 (90-day idle), whichever comes first.

Follow-ups (non-blocking)#

  • Populate docs/research/archive/2026-04-23/ with fetched HTML copies of every vendor page in the source matrix. The fetched content lives in the agent transcripts that produced the initial audit; re-fetching is preferable to ensure fidelity.
  • Add docs/research/CHANGELOG.md at first refresh run to capture the diff history going forward.
  • Decide whether the automated URL-diff cron in the Automation section is Phase B or Phase C scope; file a task accordingly.

These follow-ups do not modify the Phase 179 TODO list but are tracked inline here so the next refresh picks them up.