Disciplines · Compliance

System Card — concordia-workbench v1.0.0

data-residency configuration in services/concordia/orchestrator/ mapped to the DataSubjectArtifactSchema.residencyRegion field.

14sections8 minread

On this page

1. System identity#

  • System name: concordia-workbench
  • Deployment region and data-residency posture: multi-region; per-tenant data-residency configuration in services/concordia/orchestrator/ mapped to the DataSubjectArtifactSchema.residencyRegion field. EU tenants pin to EU regions; US tenants to US; jurisdiction-restricted use-cases (legal_claim, regulated_financial) require region pinning before case creation.
  • Operator organization: Oshun (managed service); per-tenant configuration via the orchestrator's tenant policy bundle.
  • Intended deployers: Oshun for first-party domains (Iris, Maat, Themis, Kuanyin, Aje, Yemaya, Euterpe, Calliope, Maya, Lilith, Aphrodite, Aglaea, Freya, Asase, Cybele, Brigid, Saraswati, Nyx, Metis, Mnemosyne, Nisaba, Kalika, Veritas). Tenant-deployed deployments use the same workbench with tenant-scoped policy bundles.

2. Scope and non-scope#

  • Use-case classes served: all 14 ConcordiaUseCaseClass values are eligible for some operational mode. Routing per USE_CASE_CLASS_PROFILES enforces autonomous-acceptance gates, required-reviewer queues, and audit-retention floors per class.
  • Operational modes enabled: all six ConcordiaOperationalMode values (brainstorming, mediation_support, procurement_negotiation, governance_process, arbitration_support, legal_review_required_drafting). Per-jurisdiction tenant configuration further restricts which classes opt into which modes.
  • Explicitly-refused use cases: every HardBoundaryKind defined in libs/contracts/concordia/src/boundaries/hard-boundary.ts — binding legal claim resolution, custody, domestic-violence, coercive-control, employment adverse action, medical settlement, disability-rights settlement, financial product suitability, high- stakes rights waiver, minor-party-without-guardian, immigration, criminal matter settlement.
  • Tenant configuration highlights: model routing per use-case class; review thresholds; legal disclaimers (§179.6.3.5); execution adapters (Aje smart-contract integration is opt-in per tenant via the smart_contract_execution feature flag); retention policy overrides up to but not below the per-class minimum.

3. Architecture#

  • High-level diagram: see DOMAINS/concordia/architecture.md in this repo.
  • Key components:
    • apps/oshun/web/src/app/studio/concordia-workbench/ — Next.js workbench
    • services/concordia/orchestrator/ — case orchestration service
    • libs/iris/concordia-assistant/ — private-intake assistant (party-isolated, per-party context)
    • libs/nous/preference-inference/ — pairwise scoring + utility fitters
    • libs/nous/agreement-search/ — eight optimizer kernels
    • libs/nous/concordia-sealed-memory/ — envelope-encrypted per- party memory
    • libs/contracts/concordia/ — schemas, DSL, audit / consent / incidents / oversight contracts
    • libs/openapi/src/specs/concordia/concordia-api.yaml — REST surface
    • libs/proto/src/concordia/ — streaming RPC
    • libs/aje/settlement-escrow/ — opt-in smart-contract execution
  • Models in use: see related_cards.models above.
  • Optimizers in use: see related_cards.optimizers above.
  • Evaluators hooked into release gate: see related_cards.evaluators above.
  • Policy bundles: see related_cards.policy_bundles above; full set in docs/compliance/cards/concordia/policy-bundles/.
  • Third-party dependencies:
    • LLM providers: vendor-routed per use-case class. Vendor model cards are referenced from the pairwise-preference-ranker card.
    • Storage: per-tenant; HSM/KMS integration per §179.5.1.2.
    • Telemetry: orchestrator observability per §179.6.3.4.
    • Identity: tenant IdP via Lilith auth platform; MFA enforced for reviewer / counsel / auditor roles.

4. Data flow#

  • Inputs: party-private intake statements, evidence uploads, candidate proposals, mediator-only preparation notes, reviewer decisions, settlement authority records.
  • Storage: per-party private fields sealed via @nous/concordia-sealed-memory with envelope encryption and per-party data keys; HSM/KMS integration; auditable read events per §179.5.1.2. Shared / mediator-only / reviewer-only views are separate stores with their own access policies.
  • Outputs: AgreementCandidate records, SettlementDraft, ReviewDecision, ExecutionArtifact, audit events. Audit endpoint at GET /v1/concordia/audit/{caseId} per the OpenAPI spec.
  • Retention policy: per-class minimum from USE_CASE_CLASS_PROFILES[*].minimumAuditRetentionDays; tenant overrides may raise but never lower the minimum. Legal hold freezes deletion per §179.5.4.5.
  • Cross-border transfers: explicit per-tenant configuration. EU tenants default to no extra-EU transfers without standard contractual clauses + data-protection impact assessment recorded on the case.

5. Identity and access#

  • RBAC / ABAC model: §179.2.5.2 — RBAC roles (party, mediator, reviewer, counsel, procurement officer, DAO steward, safety reviewer, auditor); ABAC attributes (tenant id, case id, party id, review queue id). Negative-authorization tests in libs/contracts/concordia/src/identity-access/ and the audit-export RBAC tests in libs/shared/audit-platform/src/rights-report-audit-export.integration.spec.ts.
  • Roles served: as above.
  • Authentication provider: tenant IdP via Lilith auth platform; MFA required for reviewer / counsel / auditor roles.
  • Conflict-of-interest handling: §179.2.5.3 disclosures and assignment rules implemented in the reviewer-queue contract (libs/contracts/concordia/src/reviewer-queue/).
  • Rate limits and abuse controls: §179.2.5.5 — case-invitation throttle, evidence-download caps, suspicious-access alerts.

6. Privacy posture#

  • Party-isolation guarantees: §179.5.1.1 physically separate prompt contexts. The party-isolated-context.ts enforces a function-signature-level guarantee that a single model call cannot see opposing-party private fields. Coverage in libs/iris/concordia-assistant/src/privacy-red-team.test.ts and party-isolated-context.test.ts.
  • Consent surface: §179.1.2.4 informed-consent gates + §179.5.4.1 consent ledger (libs/contracts/concordia/src/consent-ledger/consent-ledger.ts) with collection / processing / sharing / model-scoring / reviewer- access / transcription / settlement-export / training-data-reuse / smart-contract-execution purposes.
  • Data subject rights: export, deletion, legal-hold, portability via libs/contracts/concordia/src/data-subject/. Revocation workflow via libs/contracts/concordia/src/revocation/.
  • Incident disclosure cadence: SEV-1 / SEV-2 incidents notify party + tenant + (where applicable) regulator within tenant SLA; see docs/reference/runbooks/incident-response.md for severity definitions.

7. Safety posture#

  • Hard boundaries active by default: every HardBoundaryKind. Tenants may add boundaries; never remove.
  • Kill-switch surface: libs/contracts/concordia/src/feature-flags/feature-flags.ts flags: mediation_model_routing, autonomous_acceptance, smart_contract_execution, eight search kernels, ten domain adapters. killFlag() is operator-callable; killed flags cannot be re-enabled without dual-control.
  • Reviewer-queue staffing: SLA per queue; dual-control on p0 and p1; unstaffed-gate block via releaseOverdueClaims / expireOverduePendingItems. Calibration review via the board-oversight aggregator (§179.5.3.5).
  • Cooling-off durations per class: encoded in USE_CASE_CLASS_PROFILES; legal_claim, family_sensitive, regulated_financial, medical_sensitive, employment_sensitive carry the longest cooling-off windows.

8. Reliability posture#

  • Availability target (SLO): tenant-configurable; default 99.9% monthly for managed-service tenants.
  • Latency targets: workbench p95 ≤ 2 s for non-search interactions; search runs are explicit asynchronous jobs with progress streaming via the protobuf surface.
  • Disaster recovery: RPO ≤ 24 h; RTO ≤ 4 h for managed-service tenants. Per-tenant overrides on signed-contract basis.
  • Observability: §179.6.3.4 — traces per case, scoring cost, model latency, candidate diversity, preference uncertainty, agreement rate, escalation rate, privacy-gate failures (services/concordia/orchestrator/src/observability/).

9. Change management#

  • Deployment cadence: weekly for non-breaking changes; major contract changes go through pnpm contracts:check + the baseline-benchmark gate.
  • Release gate passage: §179.10.1–.6, .9–.14 are automated; this card is the §179.10.7 governance-review artifact.
  • Model / optimizer version pinning: §179.5.3.3 ReproducibilityModelPin records the exact model id, version, provider, temperature, top-p, max tokens, seed, prompt template id, and prompt digest for every accepted agreement. Implementation: libs/contracts/concordia/src/reproducibility/reproducibility.ts.
  • Rollback procedure: feature flags allow per-component rollback without a full redeploy. killFlag short-circuits any kernel / domain adapter that fails post-deploy.

10. Regulatory posture#

  • EU AI Act high-risk classification: mediation in justice- adjacent contexts (legal_claim, employment_sensitive, family_sensitive, regulated_financial, medical_sensitive) is treated as Annex III high-risk in the orchestrator routing. All documentation obligations under Article 11 / Annex IV are satisfied by the model / optimizer / system / evaluator / policy- bundle cards in this directory plus docs/compliance/eu-ai-act-mapping.md.
  • GDPR basis: lawful basis is per-case consent (§179.1.2.4) for EU tenants; controller is the tenant; processor is Oshun. DPIA required for every new tenant per managed-service onboarding checklist.
  • UNCITRAL ODR alignment: see docs/compliance/uncitral-odr-mapping.md.
  • Sector-specific regulation: AAA Mediator Code of Professional Responsibility informs mediator-assist mode; JAMS AI Rules inform arbitration_support mode; sector-specific rules (finance, healthcare) trigger qualified-reviewer gates per USE_CASE_CLASS_PROFILES.
  • Certifications: SOC 2 Type II carried at the Oshun platform level; ISO 42001 alignment is on the roadmap and not certified today.

11. Incident response#

  • On-call rotation: Oshun platform on-call + Concordia program on-call rotate per the schedule in docs/reference/runbooks/incident-response.md.
  • Incident severity taxonomy: §179.5.3.4 — unsafe_recommendation, privacy_leak, biased_outcome, unauthorized_acceptance, execution_mismatch, reproducibility_failure, reviewer_misconduct, security_event, other. Severity p0|p1|p2|p3 with dual-control closure for p0 and p1.
  • Communication plan: party + tenant + (where applicable) regulator; SLA per severity in docs/reference/runbooks/incident-response.md. The audit endpoint exposes redacted incident summaries to authorized roles.

12. Sunset and decommissioning#

  • End-of-life plan: at tenant offboarding the orchestrator exports all artifacts under §179.5.4.5 data-subject export, marks the tenant as legal-hold-only for the §179.5.4.5 retention floor, and emits a deprecation notice to all affected parties and reviewers. Smart-contract artifacts on chain remain on chain; off-chain operator-controlled data is purged at the end of the retention floor.

13. References#

  • DOMAINS/concordia/architecture.md
  • services/concordia/orchestrator/README.md
  • apps/oshun/web/src/app/studio/concordia-workbench/
  • libs/contracts/concordia/
  • docs/compliance/eu-ai-act-mapping.md
  • docs/compliance/uncitral-odr-mapping.md
  • docs/compliance/nist-ai-rmf-mapping.md
  • docs/reference/runbooks/incident-response.md