Datenmodell — CJRM-Instanzschema und CJML-Transformation

Formalismus-Entscheidung: Property Graph, kein RDF/OWL

CJRM ist primär über Objekte und benannte Relationen definiert (14 Core Objects, ~28 primäre Relationen) — das ist die native Form eines Property Graph, nicht eines relationalen Schemas und nicht zwingend RDF/OWL. Eine formale Ontologiesprache ist für diese Schicht nicht nötig: ein dokumentiertes JSON-Schema genügt („Simple surface, rigorous substrate”). Serialisierung: JSON, text-first, git-diffbar.

Node-Schema (generisches Envelope)

{
  "id": "string (stabiler Slug oder UUID)",
  "type": "Actor | Job | Goal | State | Resource | Constraint |
           Capability | Mandate | Event | Outcome | Metric | Value |
           Claim | Evidence",
  "label": "string — menschenlesbar",
  "properties": { "...": "typspezifisch" },
  "provenance": {
    "source": "interview:<id> | document:<pfad> | workshop:<id>",
    "extracted_by": "human:<name> | agent:<model-id>",
    "extracted_at": "ISO-8601",
    "epistemic_status": "claim | evidence-backed"
  }
}

provenance ist auf jedem Node und jeder Edge Pflicht — nicht optional. Grund: die Regel „Evidence ≠ Interpretation” lässt sich nur durchsetzen, wenn jede Instanz nachweisbar auf ihre Quelle zurückführbar ist, besonders bei KI-synthetisierten Instanzen aus Interviews. epistemic_status: claim ist der Default; Aufwertung nur über eine explizite Evidence supports Claim-Edge.

Typspezifische Properties (Auszug)

Type	Properties
Actor	kind: human
Job	scope_test_passed: bool
Goal	function: terminal
State	kind: objective
Constraint	constraint_type: technological
Capability	capability_type: customer-side
Mandate	authorizes_event_types · scope · revocable: bool
Event	event_type: Action
Outcome	polarity: contributes
Metric	metric_class: state
Value	valence: positive
Claim	statement · confidence: low
Evidence	evidence_type · relation: supports

Die Bausteine des Journey Lab ergänzen diese Eigenschaften: Actor.persona (Rolle, Zitat, Ziele, Frust), Metric.value_by_phase (Wert je Etappe) sowie Claim.claim_kind (insight, opportunity, solution) mit insight_type und about_actor.

Ownership und Beneficiary sind kanonisch über Edges modelliert (Actor owns Goal), nicht als Property.

Warum diese Properties mehr als Enumerationen sind

Actor.kind — ai-agent ist die Voraussetzung für die Agency-Transfer-Filterregel unten: nur ein als ai-agent markierter Actor kann ein Event aus der Customer-Journey-View heraus- und in den Agent Execution Trace hineinfiltern lassen.

Goal.function / origin — function: instrumental ohne begründende Goal supports Goal-Edge ist ein Validierungsfehler, kein Stilfehler. origin ist ein Array, weil die Dimensionen kombinierbar sind (Beispiel: „Identität verifizieren = instrumental + institution-induced”).

Constraint.constraint_type — unterschiedliche Typen haben unterschiedliche Auflösungswege: technological wird meist durch neue Capability mitigiert (Constraint verschwindet), institutional eher durch Agency Transfer — die Vorschrift ändert sich nicht, nur wer sie erfüllt.

Event.event_type / status — nur Interaction wird zum CJML Communication Point. status: planned | actual unterscheidet hypothetische von beobachteten Events — Grundlage der CJML-Unterscheidung Planned vs. Actual Journey.

Edge-Schema

{
  "id": "string",
  "type": "eine der ~28 primären Relationen",
  "source_id": "Node-ID",
  "target_id": "Node-ID",
  "properties": { "...": "relationsspezifisch" },
  "provenance": { "wie bei Node" }
}

Entscheidend für die CJML-Transformation: Event involves Actor braucht zwingend role: initiator | recipient | participant. Ohne dieses Property lässt sich kein Sender/Empfänger ableiten.

Transformationslogik: CJRM-Instanz → CJML-View

CJML-Element	Ableitung aus CJRM-Instanz
Communication Point	Event mit event_type = Interaction
Sender / Empfänger	Actor via Event involves Actor, role = initiator / recipient
Kanal	Event.channel
Status	Outcome.polarity = contributes → completed · kein Outcome → missing · impairs → failing
Planned vs. Actual	Event.status
Swimlane je Akteur	Gruppierung aller Events nach beteiligtem Actor
Customer Journey vs. Agent Execution Trace	Events mit ausschließlich ai-agent-Actors unter Mandate werden gefiltert und separat als Agent Execution Trace gerendert

Die letzte Zeile ist die konkrete, schema-seitige Umsetzung des Agency-Transfer-Mechanismus (siehe Agency Transfer): Layer 1 entscheidet algorithmisch, nicht manuell, welcher Teil einer Journey noch „Customer Journey” ist.

Worked Example — Baufinanzierung mit delegierter Identitätsprüfung

Knoten

[
  {"id":"actor:kunde","type":"Actor","label":"Kunde","properties":{"kind":"human"}},
  {"id":"actor:kyc-agent","type":"Actor","label":"KYC-Agent","properties":{"kind":"ai-agent"}},
  {"id":"actor:bank","type":"Actor","label":"Bank","properties":{"kind":"organization"}},
  {"id":"goal:g1","type":"Goal","label":"Baufinanzierung erhalten",
   "properties":{"function":"terminal","origin":["job-derived"]}},
  {"id":"constraint:c1","type":"Constraint","label":"Regulatorische KYC-Pflicht",
   "properties":{"constraint_type":"institutional"}},
  {"id":"goal:g2","type":"Goal","label":"Identität verifizieren",
   "properties":{"function":"instrumental","origin":["institution-induced"]}},
  {"id":"mandate:m1","type":"Mandate","label":"Mandat Identitätsprüfung",
   "properties":{"authorizes_event_types":["Interaction"],
                 "scope":"KYC für diesen Baufinanzierungsantrag","revocable":true}},
  {"id":"event:e1","type":"Event","label":"Video-Ident-Prüfung (agentengeführt)",
   "properties":{"event_type":"Interaction","channel":"Agent-API","status":"actual"}},
  {"id":"outcome:o1","type":"Outcome","label":"Identität erfolgreich verifiziert",
   "properties":{"polarity":"contributes"}}
]

Kanten

[
  {"type":"Constraint induces Goal","source_id":"constraint:c1","target_id":"goal:g2"},
  {"type":"Goal supports Goal","source_id":"goal:g2","target_id":"goal:g1"},
  {"type":"Actor owns Goal","source_id":"actor:kunde","target_id":"goal:g1"},
  {"type":"Actor grants Mandate to Actor","source_id":"actor:kunde","target_id":"actor:kyc-agent",
   "properties":{"mandate_id":"mandate:m1"}},
  {"type":"Mandate authorizes Event/Decision","source_id":"mandate:m1","target_id":"event:e1"},
  {"type":"Event involves Actor","source_id":"event:e1","target_id":"actor:kyc-agent",
   "properties":{"role":"initiator"}},
  {"type":"Event involves Actor","source_id":"event:e1","target_id":"actor:bank",
   "properties":{"role":"recipient"}},
  {"type":"Event produces Outcome","source_id":"event:e1","target_id":"outcome:o1"},
  {"type":"Outcome contributes-to Goal","source_id":"outcome:o1","target_id":"goal:g2"}
]

event:e1 hat als initiator/recipient ausschließlich Agent und Bank — kein human-Actor direkt beteiligt. Nach der Filterregel landet es in der Agent Execution Trace. Die Customer Journey reduziert sich für diesen Teilschritt auf das Mandat-Erteilungs-Event: „grant Mandate → monitor/intervene → receive Outcome”.

Offene Punkte

• role-Taxonomie bei symmetrischen Events (z. B. beiderseitige Vertragsunterzeichnung) erzwingt künstliche Setzung — bei Tests mit Beispiel-Journeys bestätigt
• Constraint.constraint_type deckt relationale/vertrauensbasierte Constraints nicht sauber ab — bei Tests mit Beispiel-Journeys bestätigt
• Versionierung von Journeys über Zeit noch nicht entschieden
• Outcome.polarity/Value.valence sind Denormalisierungen mit Drift-Risiko gegenüber den kanonischen Edges
• Keine Persistenz-Engine für den Graphen festgelegt (Graph-Datenbank, JSON-Dateien oder eingebettete Lösung) — bewusst offen