Concordia Governance Review — Phase 179.10.7

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)#

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 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, utility-fitters.
  • Optimizers (8): nash-genetic, nsga-ii, map-elites, mcts-lats, cp-sat, bayesian-optimization, psro-opponent-model, coalition-stability.
  • Evaluators (3): preference-stability, baseline-benchmark-gate, fairness-suite.
  • Policy bundles (3): maat-procurement-standard, themis-dao-governance-standard, kuanyin-restorative-standard.
  • System (1): concordia-workbench.

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 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.

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#

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).