---
title: Concordia Governance Review — Phase 179.10.7
status: approved-for-release
review_date: 2026-04-25
phase_task: 179.10.7
next_review: 2026-07-25
scope_release: concordia-workbench v1.0.0
review_chair: Concordia program lead
quorum_required: 5 of 6 named reviewer roles
quorum_present: 6 of 6 (signoff table at §11)
---

# Concordia Governance Review — Phase 179.10.7

This is the §179.10.7 governance-review record. It approves the Concordia
release on seven topics — use-case boundaries, high-risk routing, human
oversight, audit logging, data retention, model cards, and incident response —
each backed by named, in-repo artifacts. Approval is for the
[concordia-workbench v1.0.0 system card](../cards/concordia/systems/concordia-workbench.md)
and the model / optimizer / evaluator / policy-bundle cards it references.

The review is reproducible: every approval below cites the file that holds the
approved artifact. A future reviewer can re-walk the same artifacts and reach
the same verdict.

> Scope discipline: this review covers Concordia release v1.0.0 ONLY. It does
> NOT approve §179.10.8 pilot deployments, which remain external operational
> events outside this record.

---

## 1. Use-case boundaries — APPROVED

**What is approved.** The 14-value `ConcordiaUseCaseClass` enum, the 13
hard-boundary kinds with their refusal / qualified-routing severities,
operational-mode banners, and per-class informed-consent gates.

**Backing artifacts.**

- `libs/contracts/concordia/src/use-case/use-case-class.ts` —
  `ConcordiaUseCaseClassSchema` (14 values), `USE_CASE_CLASS_PROFILES`
  (per-class risk tier, autonomous-acceptance gate, required reviewers,
  escalation policy, training-data eligibility, audit-retention floor,
  hard-boundary notes).
- `libs/contracts/concordia/src/boundaries/hard-boundary.ts` —
  `HardBoundaryKindSchema` (13 prohibited decision types) and
  `HardBoundaryRuleSchema` with severity (`refuse`, `route_to_qualified_human`,
  `conditional_route`, `informational`).
- `libs/contracts/concordia/src/banners/operational-mode.ts` —
  `ConcordiaOperationalModeSchema` with the six modes (`brainstorming`,
  `mediation_support`, `procurement_negotiation`, `governance_process`,
  `arbitration_support`, `legal_review_required_drafting`).
- `libs/contracts/concordia/src/consent/consent.ts` — `ConsentPurposeSchema`,
  `ConsentScopeSchema`, `ConsentStateSchema`; `CONSENT_PURPOSE_PROFILES` covers
  all nine purposes from §179.5.4.1.
- Test coverage: `use-case-class.test.ts`, `hard-boundary.test.ts`,
  `operational-mode.test.ts`, `consent.test.ts`.

**Reviewer findings.** No gaps. The 13 boundaries are exhaustive against the
§179.1.2.2 brief. Tenant configuration may _add_ boundaries; never remove. The
review confirms `legal_claim`, `medical_sensitive`, `regulated_financial`,
`family_sensitive`, and `employment_sensitive` are all wired to qualified-
human-review queues by default.

**Conditions.** None.

---

## 2. High-risk routing — APPROVED

**What is approved.** The escalation-decision derivation, reviewer-queue
operational contract (claim, dual-control, SLA expiry, no-silent-drops), and the
kill-switch / feature-flag surface.

**Backing artifacts.**

- `libs/contracts/concordia/src/escalation/escalation-policy.ts` —
  `ReviewerQueueSchema` (11 queue kinds), `EscalationTriggerSchema` (6
  triggers), `EscalationDecisionSchema` with priority, dual-control,
  block-autonomous-acceptance, staffing hint; `deriveEscalationDecision()`.
- `libs/contracts/concordia/src/reviewer-queue/reviewer-queue.ts` —
  `ReviewItemSchema`, `ReviewerQueueStateSchema`, `enqueueReviewItem`,
  `claimReviewItem`, `recordReviewSignoff`, `escalateReviewItem`,
  `releaseOverdueClaims`, `expireOverduePendingItems`. Dual-control enforcement
  and `maxConcurrentClaims` overload protection.
- `libs/contracts/concordia/src/feature-flags/feature-flags.ts` — 20
  `FeatureFlagSchema` flags covering `mediation_model_routing`,
  `autonomous_acceptance`, `smart_contract_execution`, eight search kernels, ten
  domain adapters. `FlagStateSchema` (`enabled`, `disabled`, `killed`);
  `killFlag()` short-circuits without dual- control re-enable.
- `libs/iris/concordia-assistant/src/unsuitable-for-ai.ts` and
  `safety-routing.ts` — "not appropriate for AI mediation" detection per
  §179.6.2.5.
- Test coverage: `escalation-policy.test.ts`, `reviewer-queue.test.ts`,
  `feature-flags.test.ts`, `unsuitable-for-ai.test.ts`.

**Reviewer findings.** No gaps. Escalation derivation is deterministic and
tested for the canonical cross-product of triggers and use-case classes. Kill-
switch surface covers every component the workbench can route through.

**Conditions.** Tenants must staff the reviewer queues their use-case mix
requires. Unstaffed queues block release of any case routed to them — this is
the structural defense against the "qualified human reviewer" being a paper
guarantee.

---

## 3. Human oversight — APPROVED

**What is approved.** The case-lifecycle state machine (pause, resume, complete,
archive, nullify, reopen, file appeal, resolve appeal, override) with immutable
audit trail and dual-control enforcement on appeals and overrides; the
board-oversight transparency aggregator; the mandatory-review flags on
jurisdiction / domain templates.

**Backing artifacts.**

- `libs/contracts/concordia/src/oversight/oversight.ts` — `ActorRoleSchema`,
  lifecycle-state schema, `LifecycleEventSchema` with actor, role, reason, ISO
  timestamp, before / after status. Dual-control invariants for appeals and
  overrides.
- `libs/contracts/concordia/src/board-oversight/board-oversight.ts` — periodic
  transparency-report aggregation; consent-event counts; incident summaries;
  reviewer-workload metrics (§179.5.5.1).
- `libs/contracts/concordia/src/dsl/templates.ts` — domain-template
  `mandatoryReview` field naming reviewer roles that must approve before a
  candidate flips to `accepted` (§179.2.3.5).
- `libs/contracts/concordia/src/reviewer-queue/reviewer-queue.ts` — dual-control
  on p0 / p1 items.
- Test coverage: `oversight.test.ts`, `board-oversight.test.ts`,
  `templates.test.ts`.

**Reviewer findings.** No gaps. The lifecycle state machine refuses
non-monotonic transitions and the audit trail is append-only. The
mandatory-review-flag mechanism is consulted by both the static validator
(§179.2.3.4) and the reviewer queue (§179.5.3) — a template-driven review cannot
be silently bypassed.

**Conditions.** Periodic board-level oversight report (§179.5.3.5) due
quarterly. The first report is due 2026-07-25.

---

## 4. Audit logging — APPROVED

**What is approved.** The reproducibility manifest, the audit-export endpoint,
observability traces, and the incident-audit lifecycle.

**Backing artifacts.**

- `libs/contracts/concordia/src/reproducibility/reproducibility.ts` —
  `ReproducibilityModelPinSchema` (modelId, version, provider, temperature,
  topP, maxTokens, seed, promptTemplateId, promptDigest); optimizer pins, data
  pins, policy pins (cooling-off, escalation, hard-boundary, DSL, use-case
  profiles, rate-limit, consent-purpose, data-rights), environment pins,
  `finalCandidateDigest`, `verifyReproduction()`.
- `libs/openapi/src/specs/concordia/concordia-api.yaml` —
  `GET /v1/concordia/audit/{caseId}` with `redactPrivateFields` query param,
  `sinceTimestamp` filter, RBAC enforcement; the audit payload covers consent
  grants / revocations, evidence uploads, preference queries, candidate scoring,
  review decisions, execution artifacts, escalations.
- `services/concordia/orchestrator/src/observability/case-trace.ts` — per-case
  audit event tracing.
- `libs/shared/audit-platform/src/audit-investigation-export.ts` and
  `rights-report-audit-export.integration.spec.ts` — RBAC-denied export tests.
- `libs/contracts/concordia/src/incidents/incidents.ts` — incident ledger with
  immutable lifecycle events.
- Test coverage: `reproducibility.test.ts`, `incidents.test.ts`,
  `observability.test.ts`, `audit-investigation-export.spec.ts`,
  `rights-report-audit-export.integration.spec.ts`.

**Reviewer findings.** The reproducibility manifest is the load-bearing
mechanism for §179.5.3.3 — every accepted agreement carries a manifest that pins
every variable required for byte-identical replay. The audit endpoint is
RBAC-gated and tested for cross-tenant denial. Incident audit lifecycle is
append-only with dual-control closure on p0 / p1.

**Conditions.** None.

---

## 5. Data retention, consent, and evidence custody — APPROVED

**What is approved.** Consent ledger, revocation / withdrawal, evidence
chain-of-custody (with Merkle-chained custody events), redaction and
minimization, data-subject lifecycle (export, deletion, legal-hold, residency,
retention), and training-data governance.

**Backing artifacts.**

- `libs/contracts/concordia/src/consent-ledger/consent-ledger.ts` — append-only
  ledger with grant / revoke / extend / withdraw / expire, `LedgerEntrySchema`
  and the query helpers (`consentTimelineFor`, `activeGrantsFor`,
  `revokedGrantsFor`, `pendingExpiriesBefore`, `hasActiveConsentInLedger`).
- `libs/contracts/concordia/src/revocation/revocation.ts` — revocation planner
  with legal-hold gates and externalization checks; quarantines derived utility
  models on revocation per §179.5.4.2.
- `libs/contracts/concordia/src/evidence-custody/evidence-custody.ts` — malware
  scan verdict, source-kind, custody-event Merkle chain (`prevEventHash`),
  tamper-detection, admissibility score.
- `libs/contracts/concordia/src/redaction/redaction.ts` — PII detection and
  redaction policies per data-rights profile.
- `libs/contracts/concordia/src/data-subject/data-subject.ts` — artifact-kind
  taxonomy (raw_statement, evidence, utility_artifact, search_trace,
  audit_event, settlement_document); request kinds (export, deletion,
  legal_hold, release_legal_hold, residency_check); legal-hold enforcement;
  residency validation.
- `libs/contracts/concordia/src/training-data-governance/training-data-governance.ts`
  — de-identification verdict, re-identification risk, sensitive-case exclusion,
  dataset membership lifecycle, unlearning planner, model-card lineage.
- Test coverage: `consent-ledger.test.ts`, `revocation.test.ts`,
  `evidence-custody.test.ts`, `redaction.test.ts`, `data-subject.test.ts`,
  `training-data-governance.test.ts`.

**Reviewer findings.** No gaps. The consent ledger is the single source of truth
for what is permitted; every other gate (model scoring, reviewer access,
training-data reuse) consults it. Evidence custody Merkle chain detects tamper
between any two events. Sensitive use-case classes (`legal_claim`,
`family_sensitive`, `employment_sensitive`, `regulated_financial`,
`medical_sensitive`) are excluded from training-data reuse by structural rule,
not by configuration.

**Conditions.** None.

---

## 6. Model / system / optimizer / evaluator / policy-bundle cards — APPROVED

**What is approved.** The card framework (templates) AND the populated cards for
the v1.0.0 release as enumerated below. Per the templates' README, "Placeholder
TBD values block release" — every card cited here is fully populated; no card on
the v1.0.0 release list contains a TBD.

**Backing artifacts.**

- Templates:
  `docs/compliance/templates/{model,system,evaluator,optimizer,policy-bundle}-card.template.md`.
- Populated v1.0.0 cards under `docs/compliance/cards/concordia/`:
  - **Models (2):**
    [pairwise-preference-ranker](../cards/concordia/models/pairwise-preference-ranker.md),
    [utility-fitters](../cards/concordia/models/utility-fitters.md).
  - **Optimizers (8):**
    [nash-genetic](../cards/concordia/optimizers/nash-genetic.md),
    [nsga-ii](../cards/concordia/optimizers/nsga-ii.md),
    [map-elites](../cards/concordia/optimizers/map-elites.md),
    [mcts-lats](../cards/concordia/optimizers/mcts-lats.md),
    [cp-sat](../cards/concordia/optimizers/cp-sat.md),
    [bayesian-optimization](../cards/concordia/optimizers/bayesian-optimization.md),
    [psro-opponent-model](../cards/concordia/optimizers/psro-opponent-model.md),
    [coalition-stability](../cards/concordia/optimizers/coalition-stability.md).
  - **Evaluators (3):**
    [preference-stability](../cards/concordia/evaluators/preference-stability.md),
    [baseline-benchmark-gate](../cards/concordia/evaluators/baseline-benchmark-gate.md),
    [fairness-suite](../cards/concordia/evaluators/fairness-suite.md).
  - **Policy bundles (3):**
    [maat-procurement-standard](../cards/concordia/policy-bundles/maat-procurement-standard.md),
    [themis-dao-governance-standard](../cards/concordia/policy-bundles/themis-dao-governance-standard.md),
    [kuanyin-restorative-standard](../cards/concordia/policy-bundles/kuanyin-restorative-standard.md).
  - **System (1):**
    [concordia-workbench](../cards/concordia/systems/concordia-workbench.md).

**Reviewer findings.** The 17 populated cards cover the canonical v1.0.0
surface: every model and optimizer named in §179.3 / §179.4 has a card; the
three policy bundles cover the three first-pilot domains (Maat procurement,
Themis DAO governance, Kuanyin restorative) per §179.9.3.1; the three evaluator
cards cover the release-gate evaluators consumed by §179.10.6. Additional domain
policy-bundle cards for Iris, Aje, Yemaya, Euterpe, Calliope, Maya, Lilith,
Aphrodite, Aglaea, Freya, Asase, Cybele, Brigid, Saraswati, Nyx, Metis,
Mnemosyne, Nisaba, Kalika, Veritas remain in the template-only state and are
required before each domain enters its own pilot under §179.10.8 (which is out
of scope for THIS review).

**Conditions.**

1. Each domain pilot under §179.10.8 must produce a populated policy-bundle card
   before launch.
2. Vendor model upgrades (e.g., a new base-LLM minor version) require a
   model-card version bump and a re-run of the
   [preference-stability](../cards/concordia/evaluators/preference-stability.md)
   evaluator before the new model goes live.
3. The next card review is 2026-07-25; cards drift in 90 days unless refreshed.

---

## 7. Incident response — APPROVED

**What is approved.** The incident-report contract, the dual-control closure
rule for p0 / p1 incidents, and the runbook surface.

**Backing artifacts.**

- `libs/contracts/concordia/src/incidents/incidents.ts` — `IncidentKindSchema`
  (9 kinds), `IncidentSeveritySchema` (p0..p3), `IncidentStatusSchema` (open,
  triaged, investigating, mitigated, closed, reopened); immutable lifecycle
  events; dual-control requirement for closing p0 / p1; `followupRequired` flag
  for cooling-off propagation.
- `docs/reference/runbooks/incident-response.md` — Oshun general incident
  response: severity, quick assessment, common-incident playbooks.
- `docs/domains/isis/runbooks/compliance-incident-response.md`,
  `isis-security-incident-response.md` — domain-specific compliance / security
  runbooks; the patterns are reusable for Concordia incidents.
- Test coverage: `incidents.test.ts` for the contract layer.

**Reviewer findings.** Concordia-specific runbook coverage is partial. The
incident-contract layer is fully implemented and tested; the operational runbook
for Concordia-specific incident classes (`unsafe_recommendation`,
`privacy_leak`, `biased_outcome`, `unauthorized_acceptance`,
`execution_mismatch`, `reproducibility_failure`, `reviewer_misconduct`) inherits
from `docs/reference/runbooks/incident-response.md` and the Isis playbooks but
does not yet have a dedicated Concordia runbook.

**Conditions.**

1. A Concordia-specific incident-response runbook
   (`docs/runbooks/concordia-incident-response.md`) is required before the first
   §179.10.8 production pilot. Existing inherited runbooks suffice for v1.0.0
   release readiness; pilot launch needs the dedicated runbook.
2. Quarterly incident-report review by the Concordia program lead, with findings
   linked from this governance review at the next refresh.

---

## 8. Cross-cutting checks

These checks are required by §179.10.7 across all topics.

| Check                                                                          | Status | Reference                       |
| ------------------------------------------------------------------------------ | ------ | ------------------------------- |
| `pnpm contracts:check` passes                                                  | passes | §179.10.1 (verified milestone)  |
| Unit tests (preference, DSL, search, privacy, domain adapters)                 | passes | §179.10.2 (verified milestone)  |
| Integration tests (intake → score → search → draft → review → execute → audit) | passes | §179.10.3 (verified milestone)  |
| Playwright workbench coverage (every role)                                     | passes | §179.10.4 (verified milestone)  |
| Security tests prove no private-data leakage                                   | passes | §179.10.5 (verified milestone)  |
| Baseline benchmark gate (≥ 6 of 8 vs every baseline)                           | passes | §179.10.6 (verified milestone)  |
| Repo integration / Nx graph / contracts coverage of Concordia paths            | passes | §179.10.9 (verified milestone)  |
| Authorization automation (RBAC, tenant, reviewer-only, cross-party)            | passes | §179.10.10 (verified milestone) |
| Consent / evidence tests                                                       | passes | §179.10.11 (verified milestone) |
| Accessibility automation (axe / WCAG, kbd-only, screen reader, locale)         | passes | §179.10.12 (verified milestone) |
| Settlement lifecycle tests                                                     | passes | §179.10.13 (verified milestone) |
| Training-data gates (consent, de-identification, lineage, sensitive)           | passes | §179.10.14 (verified milestone) |

These automated gates are the structural guarantee that this review's approval
is grounded in code, not just documentation.

---

## 9. Open conditions and risks summary

Carried from §§3, 6, 7:

1. **Periodic board-level oversight report** due 2026-07-25 (§3).
2. **Domain-specific policy-bundle cards** required before each §179.10.8 pilot
   launch (§6).
3. **Vendor model upgrade flow:** model-card bump + preference- stability re-run
   before any base-LLM upgrade goes live (§6).
4. **Concordia-specific incident-response runbook** required before first
   §179.10.8 pilot (§7).
5. **Quarterly incident-report review** linked from the next refresh (§7).

These are conditions on future releases / pilots, not blockers for the v1.0.0
governance approval recorded here.

---

## 10. Approval

This review approves the v1.0.0 Concordia release on the seven §179.10.7 topics.
Approval is recorded by reviewer-role signoff below; each row is an approval
that the named reviewer accepts the artifacts cited under their topic and
accepts the open conditions.

Approval is bounded to v1.0.0. Any change that materially alters a cited
artifact requires a card-version bump and a refresh of the relevant section of
this review.

---

## 11. Signoff table

| Reviewer role                  | Topic primarily owned                              | Status   | Date       |
| ------------------------------ | -------------------------------------------------- | -------- | ---------- |
| Concordia program lead (chair) | §1 use-case boundaries                             | Approved | 2026-04-25 |
| Compliance officer             | §1 use-case boundaries, §5 data retention          | Approved | 2026-04-25 |
| Safety reviewer                | §2 high-risk routing, §7 incident response         | Approved | 2026-04-25 |
| Engineering lead (Concordia)   | §3 human oversight, §4 audit logging               | Approved | 2026-04-25 |
| Privacy / data-protection lead | §5 data retention, §4 audit logging                | Approved | 2026-04-25 |
| ML / model-card review lead    | §6 model / system / optimizer / evaluator / bundle | Approved | 2026-04-25 |

Quorum: 6 of 6 named reviewer roles signed. Quorum requirement: 5 of 6. Quorum
met.

---

## 12. References

- `docs/compliance/cards/concordia/` — populated v1.0.0 cards.
- `docs/compliance/templates/` — card templates.
- `docs/compliance/eu-ai-act-mapping.md`,
  `docs/compliance/uncitral-odr-mapping.md`,
  `docs/compliance/nist-ai-rmf-mapping.md` — regulatory mappings.
- `docs/research/mediation-negotiation-2026.md`,
  `docs/research/source-matrix.md`, `docs/research/gap-analysis-mediator-ai.md`,
  `docs/research/gap-analysis-pactum-nibble.md`,
  `docs/research/refresh-gate.md`, `docs/research/bibliography.md` — research
  basis.
- `docs/reference/runbooks/incident-response.md` — incident response baseline.
- `TODOS/phase-179.md` — phase task index this review closes (§179.10.7).