CANONICAL INFORMATION MODEL

Daten erhalten Bedeutung durch Beziehungen und Verantwortung.

Das BLUETRIX Data Model beschreibt nicht nur Felder und Tabellen. Es definiert stabile Identitäten, fachliche Ownership, Beziehungen und zeitliche Veränderungen. Dadurch können unterschiedliche Plattformkomponenten dieselben Geschäftsobjekte verstehen, ohne ihre Verantwortung oder Wahrheit zu vermischen.

Datenmodell entdecken Architecture öffnen

Ziele

Bedeutung, Identität und Ownership bewahren.

stabile Identitäten
eindeutige fachliche Begriffe
sichtbare Ownership
Vermeidung redundanter Wahrheiten
Verbindung von Interaktionen und Geschäftsobjekten
nachvollziehbare zeitliche Veränderungen
kontrollierte Integration
freigegebener Kontext für AI-Agenten

Informationsklassen

Informationen nach Autorität und Herkunft unterscheiden.

Product-Owned Information

Autoritative Informationen eines konkreten Produktbereichs.

Shared Information

Kontrolliert gemeinsam verwendete Informationen mit definierter Quelle.

Composition Information

Zusammengesetzte Sichten aus mehreren Quellen.

Derived Intelligence

Scores, Klassifikationen, Zusammenfassungen, Muster und Empfehlungen.

Platform Information

Identität, Konfiguration, Betrieb, Security, Audit und Observability.

External References

Verweise auf Informationen, deren autoritative Quelle außerhalb von BLUETRIX liegt.

Kernidentitäten

Stabile Referenzen für verbundene Interaktionen.

Workspace: Organisatorischer und sicherheitsbezogener Ausführungskontext.
Organization: Unternehmen oder geschäftlich relevante Organisation.
Person: Natürliche Person, die in verschiedenen Rollen und Beziehungen auftreten kann.
Contact Point: Erreichbare Adresse oder Kennung wie E-Mail, Telefonnummer oder Kanalidentität.
Actor: Mensch, Team, Organisation, System oder AI-Agent, der an einer Interaktion beteiligt ist.
Interaction: Fachlich relevantes Ereignis zwischen Akteuren innerhalb eines bestimmten Kontexts.

Geschäftsobjekte

Fachliche Objekte ohne verbindliches öffentliches Schema.

Opportunity

Bedarf, Potenzial, Pipeline-Zustand, Wert, Beteiligte und nächste Aktion.

Commitment

Zugesagte oder erwartete Handlung mit Akteuren, Fälligkeit, Status, Ursprung und Erfüllung.

Service Request

Strukturiertes Anliegen mit Kategorie, Dringlichkeit, Verantwortung, Fristen, Übergaben und Abschluss.

Beziehungen statt Duplikate

Referenzen verbinden fachliche Wahrheiten.

Interaction verweist auf Actor.
Opportunity verweist auf Organization und Kontakte.
Commitment verweist auf seinen Ursprung.
Service Request verweist auf relevante Interaktionen.
Inbox, Timeline und Pipeline verwenden zusammengesetzte Sichten.

Interaction

Das verbindende Objekt.

Nicht jede Interaction muss mit allen Elementen verbunden sein.

Actor
Kanal
Contact
Organization
Opportunity
Commitment
Service Request
Kampagne
Formular
Bot
Automation
Aufgabe
Termin
Dokument
vorherige oder nachfolgende Interaction

Zeitmodell

Zeitpunkte fachlich nicht gleichsetzen.

Zeitpunkt des realen Ereignisses
Erfassungszeitpunkt
Verarbeitungszeitpunkt
Zeitpunkt der Zustandsänderung
Gültigkeitszeitraum
Fälligkeit
Abschlusszeitpunkt

Identität und Korrelation

Unterschiedliche Referenzarten.

Stable Identity

Dauerhafte fachliche Identität.

External Identity

Referenz einer extern autoritativen Quelle.

Correlation

Technische oder fachliche Zusammengehörigkeit.

Causation

Behaupteter Ursachenbezug, der gesondert begründet werden muss.

Ownership-Matrix

Verantwortung als lesbare Zuordnung.

Wer erstellt die Information?: Ursprung
Wer darf sie verändern?: Autorität
Wer ist verantwortlich?: Ownership
Wer darf sie lesen?: Zugriff
Wer darf sie ableiten?: Intelligence
Wer darf sie veröffentlichen?: Freigabe
Wie wird eine Änderung verteilt?: Event oder Synchronisation

Derived Intelligence

Ableitung verändert nicht automatisch die Produktwahrheit.

Intent
Sentiment
Dringlichkeit
Lead Score
Relationship Score
Zusammenfassung
Empfehlung
prognostischer Hinweis

Ausgangsdaten
Erstellungszeitpunkt
erzeugende Komponente
Modell- oder Regelversion
Unsicherheit oder Konfidenz
Aktualitätskontext
Status menschlicher Prüfung

Konzeptionelles JSON-Beispiel

Ein nicht normatives Modellbeispiel.

Dieses Beispiel veranschaulicht die Modellprinzipien. Feldnamen, Endpunkte und Schemas sind nicht als verbindliche öffentliche API-Spezifikation zu verstehen.

{
  "interactionId": "int_example",
  "workspaceId": "wsp_example",
  "actorRef": "actor_example",
  "channel": "website_form",
  "occurredAt": "2026-08-26T10:30:00Z",
  "contextRefs": {
    "organization": "org_example",
    "opportunity": "opp_example"
  },
  "derivedSignals": [{
    "type": "intent",
    "value": "request_demo",
    "status": "unreviewed"
  }]
}

Datenschutz und Datenminimierung

Modell- und Architekturprinzipien ohne Zertifizierungsclaim.

Zweckbindung
Datenminimierung
Rollen und Berechtigungen
Aufbewahrungsregeln
Löschung oder Anonymisierung
Herkunft und Einwilligung
Export und Auskunft
Audit und Nachvollziehbarkeit

Ein Datenmodell für lebendige Geschäftsbeziehungen.

Verbinde stabile Identitäten, klare Ownership und nachvollziehbare Interaktionen.

Architecture ansehen Technical Reference öffnen