ORLENE Technical Whitepaper

Kapitel 3 von 8

1. Zweck dieses Dokuments

1.1 Aktueller Stand

1.2 Architektur als lernendes System

2. Das Problem: Daten sind vorhanden, Wissen ist verteilt

2.1 ORLENE betrachtet die Situation anders

2.2 Warum klassische Software oft an Grenzen stößt

3. Die ORLENE Grundprinzipien

4. Zielbild: ORLENE als Wissens- und Integrationsschicht

4.1 Was ORLENE nicht sein soll

4.2 Was ORLENE sein soll

5. Objektzentrierte Architektur

5.1 Beispiele für Objekte

5.2 Gleiche Architektur, anderes Objekt

Einfaches Schema

6. Digitaler Wissensraum

6.1 Bestandteile eines Wissensraums

6.2 Praxisbeispiel Schuhhandel

6.3 Praxisbeispiel Zinshaus

7. Der ORLENE Core

7.1 Kernkomponenten

7.2 Architekturregel

7.3 Zusammenspiel der Core-Komponenten

8. OID - ORLENE Object Identity

8.1 Warum OID?

8.2 Beispiel

8.3 Offene technische Fragen

9. Relationship Engine

9.1 Beziehung als eigenes Element

9.2 Technisches Grundmodell

9.3 Risiken

10. Event Engine

10.1 Event-Grundmodell

10.2 Beispiele

10.3 Warum Events?

11. Knowledge Engine

11.1 Aufgaben

11.2 Wissensstatus

11.3 Architekturregel

11.4 Zusammenspiel mit anderen Engines

11.5 Technische Optionen

12. Connect Layer

12.1 Typische Quellen

12.2 Grundsatz Datenhoheit

12.3 Adapter-Architektur

13. Experience Engine - Erfahrungs-Engine

13.1 Wissensautor

13.2 Wissenspfad

13.3 Vom Pfad zum Wissensgesetz

13.4 Warum Prüfung wichtig ist

14. Nutzenmessung und Wissenswert

14.1 Moegliche Kennzahlen

14.2 Beispiel-Kennzahl

14.3 Anerkennung statt reine Gamification

15. ORLENE Ask und KI

15.1 Architekturregel fuer KI

15.2 Beispiel

15.3 Offene Fragen

16. Warum ORLENE keine klassische Warenwirtschaft ist

16.1 Unterschied

16.2 Konsequenz

17. Wachstumsmodell: Ein Wissensraum nach dem anderen

17.1 Schrittweiser Ausbau

17.2 Warum das realistisch ist

18. Minimal Viable Core - möglicher Startpunkt

18.1 MVC-Bausteine

18.2 Was bewusst später kommt

18.3 Vorschlag für ersten technischen Prototyp

19. Offene technische Fragen für den Entwickler

19.1 Was ich mir von der Rückmeldung wünsche

20. Zusammenfassung

Dokumentanfang

ORLENE 3.0

Dokumentanfang

Technical Whitepaper

Dokumentanfang

Architecture Overview fuer Entwickler und Softwarearchitekten

Dokumentanfang

Warum ORLENE anders gedacht ist

Dokumentanfang

Version 0.2 | Arbeitsentwurf | fuer technische Ersteinschaetzung

1. Zweck dieses Dokuments

Dieses Whitepaper ist kein Marketingdokument und keine fertige technische Spezifikation. Es ist ein kompakter Einstieg in die Architekturidee von ORLENE. Ziel ist, einem Entwickler oder Softwarearchitekten schnell zu zeigen, warum ORLENE anders gedacht ist, welche Bausteine bereits konzeptionell definiert wurden und welche technischen Fragen bewusst noch offen sind.

1. Zweck dieses Dokuments

Das Dokument soll eine ehrliche technische Diskussion ermöglichen. Es soll nicht beweisen, dass ORLENE bereits fertig ist. Es soll zeigen, dass hinter ORLENE eine klare Architektur, ein konsistentes Menschenbild und ein praktischer Ursprung stehen.

1.1 Aktueller Stand

ORLENE Retail existiert bereits als funktionierender Prototyp im Bereich Schuhhandel: Scanner, Etikettendruck, Preislogik, Lager-/Artikelbezug, Produktwissen und erste Vision-/OCR-Ansätze.

1.1 Aktueller Stand

Die Plattformidee wurde aus praktischen Problemen entwickelt: Informationen existieren, sind aber verteilt und müssen immer wieder gesucht werden.

1.1 Aktueller Stand

ORLENE 3.0 verallgemeinert diesen Ansatz zu einer objektzentrierten Wissens- und Integrationsplattform.

1.2 Architektur als lernendes System

ORLENE wird nicht als starres Softwaresystem entwickelt, sondern als lernende Architektur.

1.2 Architektur als lernendes System

Die einzelnen Architekturbausteine übernehmen dabei klar getrennte Aufgaben:

1.2 Architektur als lernendes System

Die Dialog Engine begleitet Menschen bei Gesprächen, Reviews, Entscheidungen und der gemeinsamen Entwicklung von Wissen.

1.2 Architektur als lernendes System

Die Memory Engine bewahrt Quellen, Gedanken, Erfahrungen und Entscheidungen in ihrem ursprünglichen Zusammenhang.

1.2 Architektur als lernendes System

Die Knowledge Engine verbindet freigegebene und bestätigte Inhalte zu einem nutzbaren Wissensraum.

1.2 Architektur als lernendes System

Die Experience Engine entwickelt aus bestätigten Wissenspfaden wiederverwendbare Erfahrung.

1.2 Architektur als lernendes System

Diese Trennung stellt sicher, dass Informationen, Gedanken, Erfahrung, Wissen und Entscheidungen nicht unkontrolliert miteinander vermischt werden. Jede Ebene bleibt in ihrer Herkunft, ihrem Status und ihrer Entwicklung nachvollziehbar.

1.2 Architektur als lernendes System

ORLENE darf aus Dialogen, Dokumenten und anderen Quellen Wissenskandidaten ableiten. Diese werden jedoch nicht automatisch zu bestätigtem Wissen. Erst durch Prüfung, Einordnung oder menschliche Freigabe erhalten sie einen verbindlichen Status.

1.2 Architektur als lernendes System

Dadurch wird ORLENE selbst zum ersten Anwendungsfall seiner eigenen Architektur.

1.2 Architektur als lernendes System

Die Entwicklung von ORLENE erfolgt schrittweise innerhalb des ORLENE Workspace. Dokumente, Dialoge, Entscheidungen, Entwicklungsaufträge und Rückmeldungen werden dort nicht nur gespeichert, sondern als nachvollziehbare Wissens- und Entscheidungsgeschichte miteinander verbunden.

2. Das Problem: Daten sind vorhanden, Wissen ist verteilt

Viele Unternehmen besitzen nicht zu wenige Daten. Sie besitzen zu viele unverbundene Informationsquellen: ERP, Warenwirtschaft, CRM, E-Mail, Excel, PDF-Ablagen, Papierordner, Scanner, Drucker, Webshops, Fachwissen einzelner Mitarbeiter und historische Entscheidungen.

2. Das Problem: Daten sind vorhanden, Wissen ist verteilt

Der Aufwand entsteht nicht nur beim Speichern von Informationen, sondern vor allem beim Wiederfinden und Einordnen. Eine einfache Frage kann mehrere Programme, Dokumente, Personen und Telefonate erfordern. Kommt danach eine Zusatzfrage, beginnt der Suchprozess häufig erneut.

2.1 ORLENE betrachtet die Situation anders

ORLENE geht nicht davon aus, dass alle bestehenden Systeme ersetzt werden müssen. ORLENE geht davon aus, dass in diesen Systemen bereits wertvolles Wissen steckt. Der Mehrwert entsteht durch Verbindung, Kontext und verstaendliche Bereitstellung.

2.2 Warum klassische Software oft an Grenzen stößt

Sie ist meist funktions- oder programmzentriert.

2.2 Warum klassische Software oft an Grenzen stößt

Sie besitzt eigene Datenhaltung, eigene Masken und eigene Logik.

2.2 Warum klassische Software oft an Grenzen stößt

Sie erzeugt oft neue Datensilos, statt bestehende Informationen zu verbinden.

2.2 Warum klassische Software oft an Grenzen stößt

Sie verlangt Schulung pro System und pro Oberfläche.

2.2 Warum klassische Software oft an Grenzen stößt

Sie bildet selten die gesamte Geschichte eines Objekts ab.

3. Die ORLENE Grundprinzipien

Die Grundprinzipien sind keine Dekoration. Sie sind Architekturregeln. Jede spaetere technische Entscheidung soll daran gemessen werden.

4. Zielbild: ORLENE als Wissens- und Integrationsschicht

ORLENE liegt nicht unter Betriebssystemen und nicht als Ersatz für bestehende Fachprogramme daneben. ORLENE liegt über bestehenden Anwendungen und verbindet ihre Informationen objektbezogen zu Wissen.

4.1 Was ORLENE nicht sein soll

keine klassische Warenwirtschaft

4.1 Was ORLENE nicht sein soll

kein Ersatz für jedes ERP-System

4.1 Was ORLENE nicht sein soll

kein zentraler Datensauger

4.1 Was ORLENE nicht sein soll

keine Plattform, die fremde Datenhoheit beansprucht

4.1 Was ORLENE nicht sein soll

keine Oberfläche, die Menschen zwingt, kompliziert zu arbeiten

4.2 Was ORLENE sein soll

eine objektzentrierte Wissensplattform

4.2 Was ORLENE sein soll

eine Integrationsschicht ueber bestehenden Systemen

4.2 Was ORLENE sein soll

ein Werkzeug zur Verknüpfung von Informationen

4.2 Was ORLENE sein soll

eine Plattform, die Erfahrungswissen bewahrt.

4.2 Was ORLENE sein soll

eine Grundlage für ORLENE Ask und spätere KI-Agenten

5. Objektzentrierte Architektur

Der zentrale Architekturwechsel lautet: ORLENE denkt nicht zuerst in Programmen, Tabellen oder Branchen, sondern in Objekten.

5.2 Gleiche Architektur, anderes Objekt

Ein Schuh, ein Fahrzeug und ein Zinshaus sind fachlich unterschiedlich. Architektonisch besitzen sie denselben Kern: Identität, Eigenschaften, Beziehungen, Ereignisse, Dokumente, Historie und Wissensraum.

6. Digitaler Wissensraum

Ein digitaler Wissensraum ist die vollständige digitale Repräsentation eines Objekts. Er kann Daten aus verschiedenen Systemen anzeigen, ohne die Datenhoheit zu übernehmen.

6.1 Bestandteile eines Wissensraums

OID und Basisdaten

6.1 Bestandteile eines Wissensraums

Eigenschaften und Status

6.1 Bestandteile eines Wissensraums

Dokumente und Medien

6.1 Bestandteile eines Wissensraums

Beziehungen zu anderen Objekten

6.1 Bestandteile eines Wissensraums

Ereignisse und Historie

6.1 Bestandteile eines Wissensraums

Aufgaben und Workflows

6.1 Bestandteile eines Wissensraums

Wissenspfade und bestaetigte Wissensgesetze

6.1 Bestandteile eines Wissensraums

ORLENE Ask als sprachlicher Zugang

6.2 Praxisbeispiel Schuhhandel

Der bestehende ORLENE-Retail-Prototyp ist bereits ein erster kleiner Wissensraum: Ein Artikel kann gescannt, gefunden, bepreist, etikettiert und mit Lager- oder Produktinformationen verbunden werden. Genau dieses Prinzip soll später auf weitere Objekte und Branchen übertragen werden.

6.3 Praxisbeispiel Zinshaus

Ein Zinshaus kann einen Wissensraum besitzen, in dem Wohnungen, Eigentümer, Mieter, Schäden, Professionisten, Sanierungen, Rechnungen, Versicherungen und Historie verknüpft werden. ORLENE muss diese Daten nicht alle besitzen, sondern muss wissen, wie sie zusammenhängen und wie berechtigte Personen darauf zugreifen können.

7. Der ORLENE Core

Der ORLENE Core ist das technische Fundament. Er enthält keine Branchenlogik. Er weiß nicht, ob ein Objekt ein Schuh, ein Haus oder ein Fahrzeug ist. Er kennt universelle Konzepte.

7.2 Architekturregel

Der ORLENE Core besteht nicht nur aus technischen Infrastrukturkomponenten. Er verbindet technische Objekt-, Ereignis-, Integrations- und Sicherheitsarchitektur mit einer kontrollierten Wissensarchitektur.

7.2 Architekturregel

Die einzelnen Engines besitzen klar getrennte Verantwortlichkeiten.

7.2 Architekturregel

Dialog, Erinnerung, Wissen und Erfahrung dürfen nicht zu einer einzigen undurchsichtigen KI-Funktion verschmelzen.

7.2 Architekturregel

Die Dialog Engine begleitet die Entstehung von Gedanken und Rückmeldungen.

7.2 Architekturregel

Die Memory Engine bewahrt Quellen, Zusammenhänge und Wissenskandidaten.

7.2 Architekturregel

Die Knowledge Engine stellt bestätigte und berechtigte Inhalte im Kontext bereit.

7.2 Architekturregel

Die Experience Engine entwickelt daraus geprüfte und wiederverwendbare Wissenspfade.

7.2 Architekturregel

Diese Trennung ermöglicht Nachvollziehbarkeit, Korrekturfähigkeit, Rechtekontrolle und menschliche Verantwortung.

7.3 Zusammenspiel der Core-Komponenten

Die Komponenten des ORLENE Core arbeiten nicht isoliert nebeneinander. Sie bilden einen kontrollierten Kreislauf, in dem Daten, Ereignisse, Dialoge, Erinnerungen, Wissen und Erfahrung miteinander verbunden werden.

7.3 Zusammenspiel der Core-Komponenten

Ein typischer Entstehungsweg kann folgendermaßen aussehen:

7.3 Zusammenspiel der Core-Komponenten

Ein Mensch führt über die Dialog Engine ein Gespräch, einen Review, ein Interview oder einen Denkprozess.

7.3 Zusammenspiel der Core-Komponenten

Die Dialog Engine erzeugt keine automatische Wahrheit. Sie erzeugt strukturierte Beiträge, Fragen, Antworten und mögliche Wissenskandidaten.

7.3 Zusammenspiel der Core-Komponenten

Die Memory Engine bewahrt diese Inhalte gemeinsam mit ihrer Quelle, ihrem Zeitpunkt, ihrem Autor, ihrem Kontext, ihrem Status und ihrer Sichtbarkeit.

7.3 Zusammenspiel der Core-Komponenten

Die Knowledge Engine verbindet bestätigte und freigegebene Inhalte mit Objekten, OIDs, Beziehungen, Ereignissen und Dokumenten.

7.3 Zusammenspiel der Core-Komponenten

Die Experience Engine erkennt oder übernimmt daraus wiederkehrende Wissenspfade, die nach Prüfung als nutzbare Erfahrung bereitgestellt werden können.

7.3 Zusammenspiel der Core-Komponenten

Die Event Engine dokumentiert relevante Veränderungen, Bestätigungen, Freigaben, Anwendungen und Entscheidungen.

7.3 Zusammenspiel der Core-Komponenten

Die Security Engine stellt sicher, dass nur berechtigte Personen und Prozesse auf die jeweils zulässigen Quellen und Wissenselemente zugreifen.

7.3 Zusammenspiel der Core-Komponenten

Der Connect Layer und die API Engine verbinden diesen Prozess kontrolliert mit bestehenden Anwendungen und externen Systemen.

7.3 Zusammenspiel der Core-Komponenten

Architekturfluss: Mensch und Workspace → Dialog Engine → Memory Engine → Knowledge Engine → Experience Engine → Handlung, Entscheidung oder Wissenspfad → Event Engine

7.3 Zusammenspiel der Core-Komponenten

Dieser Ablauf ist kein starrer technischer Datenfluss.

7.3 Zusammenspiel der Core-Komponenten

Abhängig vom Anwendungsfall können einzelne Engines parallel oder wiederholt beteiligt sein.

7.3 Zusammenspiel der Core-Komponenten

Ein Wissenselement kann beispielsweise durch ein späteres Ereignis, neues Feedback oder eine korrigierte Quelle erneut geprüft und weiterentwickelt werden.

8. OID - ORLENE Object Identity

Jedes Objekt erhält eine dauerhafte Identität: die OID. Sie bleibt stabil, auch wenn Name, Standort, Eigentümer, Status oder angebundene Systeme sich ändern.

8.1 Warum OID?

Dokumente bleiben langfristig dem richtigen Objekt zugeordnet.

8.1 Warum OID?

Ereignisse bilden eine durchgehende Historie.

8.1 Warum OID?

Beziehungen bleiben nachvollziehbar.

8.1 Warum OID?

ORLENE Ask und KI können eindeutig auf Objekte verweisen.

8.1 Warum OID?

Synchronisation mit Fremdsystemen wird robuster.

8.3 Offene technische Fragen

Format: sprechende OID oder UUID-basierter Identifier?

8.3 Offene technische Fragen

Mandantenfähigkeit: globale oder mandanteninterne Eindeutigkeit?

8.3 Offene technische Fragen

Mapping auf Fremdsystem-IDs: getrennte Mapping-Tabelle oder Metadata?

8.3 Offene technische Fragen

Versionierung: Objektversion separat von Eventhistorie?

9. Relationship Engine

Informationen werden erst wertvoll, wenn ihre Beziehungen sichtbar werden. Deshalb sind Beziehungen in ORLENE keine Nebensache, sondern ein eigener Architekturbaustein.

9.1 Beziehung als eigenes Element

Eine Beziehung verbindet mindestens zwei Objekte und besitzt eigene Eigenschaften wie Beziehungstyp, Status, Gültigkeit und Quelle.

9.2 Technisches Grundmodell

relationship_id

9.2 Technisches Grundmodell

source_oid

9.2 Technisches Grundmodell

target_oid

9.2 Technisches Grundmodell

relationship_type

9.2 Technisches Grundmodell

valid_from / valid_to

9.2 Technisches Grundmodell

source_system

9.2 Technisches Grundmodell

confidence / confirmation_status

9.3 Risiken

Beziehungsmodell darf nicht zu kompliziert für Benutzer werden.

9.3 Risiken

Automatische Beziehungserkennung muss immer korrigierbar bleiben.

9.3 Risiken

Berechtigungen müssen beziehungsübergreifend sauber gelöst werden.

10. Event Engine

Jedes Objekt hat eine Geschichte. Die Event Engine speichert, was mit einem Objekt passiert ist. Sie macht aus Stammdaten einen Lebenslauf.

10.1 Event-Grundmodell

event_id

10.1 Event-Grundmodell

oid

10.1 Event-Grundmodell

event_type

10.1 Event-Grundmodell

timestamp

10.1 Event-Grundmodell

actor

10.1 Event-Grundmodell

source_system

10.1 Event-Grundmodell

payload

10.1 Event-Grundmodell

visibility / permission_scope

10.2 Beispiele

Preis geaendert

10.2 Beispiele

Etikett gedruckt

10.2 Beispiele

Schaden gemeldet

10.2 Beispiele

Service durchgefuehrt

10.2 Beispiele

Dokument hinzugefuegt

10.2 Beispiele

Wissenspfad bestaetigt

10.3 Warum Events?

Viele Systeme zeigen nur den aktuellen Zustand. ORLENE soll auch zeigen, wie dieser Zustand entstanden ist. Das ist entscheidend für Nachvollziehbarkeit, Vertrauen, KI-Zusammenfassungen und spätere Analysen.

11. Knowledge Engine

Die Knowledge Engine verbindet Objekte, Beziehungen, Ereignisse, Dokumente und Erfahrungswissen zu einem nutzbaren Wissensraum. Sie ist der Baustein, der aus Daten Kontext und aus Kontext Wissen macht.

11. Knowledge Engine

Die Knowledge Engine erzeugt Wissen nicht direkt aus Dokumenten oder Daten.

11. Knowledge Engine

Sie arbeitet mit den Ergebnissen der Dialog Engine und der Memory Engine.

11. Knowledge Engine

Erst nachdem Inhalte strukturiert, eingeordnet und entsprechend ihres Status bewertet wurden, verbindet die Knowledge Engine diese mit Objekten, Ereignissen, Beziehungen und digitalen Wissensräumen.

11. Knowledge Engine

Dadurch trennt ORLENE die Entstehung von Wissen bewusst von dessen Bereitstellung.

11.1 Aufgaben

Indexierung von Dokumenten und Metadaten

11.1 Aufgaben

Verknuepfung von Informationen mit OIDs

11.1 Aufgaben

Bereitstellung fuer ORLENE Ask

11.1 Aufgaben

Zusammenfassung von Objekt-Historien

11.1 Aufgaben

Erkennung von Wissensluecken

11.1 Aufgaben

Vorbereitung für semantische Suche und KI-Auswertung

11.1 Aufgaben

Nutzung strukturierter Wissenskandidaten aus der Memory Engine

11.1 Aufgaben

Verknüpfung bestätigter Inhalte mit OIDs

11.1 Aufgaben

Verwaltung verschiedener Wissenszustände

11.1 Aufgaben

Kontextbezogene Bereitstellung für ORLENE Ask

11.1 Aufgaben

Nachvollziehbare Quellenreferenzen

11.1 Aufgaben

Erkennung widersprüchlicher Wissenselemente

11.1 Aufgaben

Bereitstellung von Wissen entsprechend Rollen und Berechtigungen

11.1 Aufgaben

Übergabe bestätigter Inhalte an die Experience Engine

11.2 Wissensstatus

Jedes Wissenselement besitzt einen definierten Status.

11.2 Wissensstatus

Dadurch kann ORLENE jederzeit nachvollziehen, woher Wissen stammt, wie zuverlässig es ist und welche Verarbeitung bereits erfolgt ist.

11.2 Wissensstatus

Mögliche Wissenszustände:

11.2 Wissensstatus

Quelle

11.2 Wissensstatus

Originaldokument oder ursprüngliche Information.

11.2 Wissensstatus

Gedanke

11.2 Wissensstatus

Erste Idee oder Beobachtung ohne Bewertung.

11.2 Wissensstatus

Wissenskandidat

11.2 Wissensstatus

Von ORLENE oder einem Menschen erkannter möglicher Wissensbaustein.

11.2 Wissensstatus

In Prüfung

11.2 Wissensstatus

Der Wissenskandidat wird aktuell bewertet oder überprüft.

11.2 Wissensstatus

Bestätigtes Wissen

11.2 Wissensstatus

Durch Menschen oder definierte Prozesse freigegebenes Wissen.

11.2 Wissensstatus

Wissensgesetz

11.2 Wissensstatus

Mehrfach bestätigtes und wiederholt erfolgreich angewendetes Wissen.

11.2 Wissensstatus

Historisch

11.2 Wissensstatus

Früher gültiges Wissen mit dokumentierter Historie.

11.2 Wissensstatus

Verworfen

11.2 Wissensstatus

Nicht bestätigtes oder bewusst zurückgezogenes Wissen.

11.2 Wissensstatus

Die Knowledge Engine speichert diese Zustände nicht nur, sondern berücksichtigt sie aktiv bei jeder Wissensbereitstellung.

11.4 Zusammenspiel mit anderen Engines

Die Knowledge Engine bildet den Mittelpunkt der Wissensarchitektur.

11.4 Zusammenspiel mit anderen Engines

Sie arbeitet mit mehreren spezialisierten Engines zusammen.

11.4 Zusammenspiel mit anderen Engines

Dialog Engine

11.4 Zusammenspiel mit anderen Engines

Begleitet Gespräche, Interviews, Reviews und Denkprozesse.

11.4 Zusammenspiel mit anderen Engines

↓

11.4 Zusammenspiel mit anderen Engines

Memory Engine

11.4 Zusammenspiel mit anderen Engines

Bewahrt Quellen, Gedanken, Wissenskandidaten und Zusammenhänge.

11.4 Zusammenspiel mit anderen Engines

↓

11.4 Zusammenspiel mit anderen Engines

Knowledge Engine

11.4 Zusammenspiel mit anderen Engines

Verbindet bestätigte Inhalte zu einem nutzbaren Wissensraum.

11.4 Zusammenspiel mit anderen Engines

↓

11.4 Zusammenspiel mit anderen Engines

Experience Engine

11.4 Zusammenspiel mit anderen Engines

Entwickelt daraus wiederverwendbare Wissenspfade und Erfahrung.

11.4 Zusammenspiel mit anderen Engines

↓

11.4 Zusammenspiel mit anderen Engines

ORLENE Ask

11.4 Zusammenspiel mit anderen Engines

Stellt berechtigten Benutzern nachvollziehbare Antworten mit Quellenbezug bereit.

11.4 Zusammenspiel mit anderen Engines

Die Knowledge Engine ersetzt keine dieser Komponenten.

11.4 Zusammenspiel mit anderen Engines

Sie verbindet deren Ergebnisse.

11.5 Technische Optionen

Relationale Datenbank für Kernobjekte und Transaktionen

11.5 Technische Optionen

Dokumentenindex für Volltextsuche

11.5 Technische Optionen

Vector Store fuer semantische Suche

11.5 Technische Optionen

Graph-Struktur für Beziehungen

11.5 Technische Optionen

Event Store für Historie

12. Connect Layer

ORLENE soll bestehende Systeme nicht zuerst ersetzen, sondern verbinden. Der Connect Layer ist die technische Schicht für diese Verbindung.

12.1 Typische Quellen

ERP / Warenwirtschaft: z. B. D&G

12.1 Typische Quellen

Buchhaltung: z. B. BMD

12.1 Typische Quellen

E-Mail und Dokumente: Outlook, Microsoft 365, lokale Ablagen

12.1 Typische Quellen

Webshops: Shopify, WooCommerce, Amazon

12.1 Typische Quellen

Scanner, Etikettendrucker, Kameras und mobile Geräte

12.1 Typische Quellen

CSV, Excel, PDF und OCR-Quellen

12.2 Grundsatz Datenhoheit

Der Connect Layer soll Daten nicht sinnlos kopieren. Er soll Zugriffswege, Metadaten, Verknüpfungen und Synchronisationslogik bereitstellen. Wo Daten lokal gespeichert werden müssen, soll dies transparent, minimal und begründet erfolgen.

12.3 Adapter-Architektur

Jeder Adapter übersetzt zwischen Fremdsystem und ORLENE Core.

12.3 Adapter-Architektur

Adapter dürfen den Core nicht mit branchenspezifischer Logik verunreinigen.

12.3 Adapter-Architektur

Import, Export, Synchronisation und Webhooks werden getrennt betrachtet.

12.3 Adapter-Architektur

Jede Verbindung braucht Rechte, Protokollierung und Fehlerbehandlung.

13. Experience Engine - Erfahrungs-Engine

Die Erfahrungs-Engine ist ein neuer Kernbaustein: ORLENE soll nicht nur von Programmen und Daten lernen, sondern von den Menschen, die täglich mit Wissen arbeiten.

13.1 Wissensautor

Ein Benutzer, der einen Wissenspfad beschreibt, ist ein Wissensautor. Er programmiert ORLENE nicht. Er teilt den Weg, den er bisher gegangen ist, um eine Antwort zu finden.

13.3 Vom Pfad zum Wissensgesetz

Benutzer beschreibt seinen Wissenspfad.

13.3 Vom Pfad zum Wissensgesetz

ORLENE speichert ihn als Vorschlag.

13.3 Vom Pfad zum Wissensgesetz

Verantwortliche Person oder Team prüft den Pfad.

13.3 Vom Pfad zum Wissensgesetz

Pfad wird mehrfach erfolgreich angewendet.

13.3 Vom Pfad zum Wissensgesetz

Pfad wird als Wissensgesetz freigegeben.

13.3 Vom Pfad zum Wissensgesetz

ORLENE kann ihn später vorschlagen oder automatisch nutzen.

13.4 Warum Prüfung wichtig ist

ORLENE darf nicht jeden beschriebenen Pfad ungeprüft übernehmen. Wissen wird erst dann zur Regel, wenn es bestätigt wurde. Dadurch entsteht kontrolliertes Lernen statt unkontrollierter Automatisierung.

14. Nutzenmessung und Wissenswert

Die Erfahrungs-Engine kann später sichtbar machen, welchen Wert ein Wissenspfad erzeugt. Das ist für Mitarbeiter, Manager und Unternehmer interessant.

14.1 Moegliche Kennzahlen

Anzahl der Anwendungen eines Wissenspfades

14.1 Moegliche Kennzahlen

geschätzte Zeitersparnis pro Anwendung

14.1 Moegliche Kennzahlen

gesamte Zeitersparnis

14.1 Moegliche Kennzahlen

vermiedene Fehler

14.1 Moegliche Kennzahlen

unterstützte neue Mitarbeiter

14.1 Moegliche Kennzahlen

geschätzter wirtschaftlicher Nutzen

14.1 Moegliche Kennzahlen

Qualitaetsbewertung durch Benutzer

14.3 Anerkennung statt reine Gamification

Ein Belohnungssystem ist denkbar, sollte aber vorsichtig gestaltet werden. Der wichtigste Antrieb bleibt der gemeinsame Nutzen. Wirtschaftliche Beteiligung kann später eine Option sein, wenn Nutzen und Qualität nachvollziehbar messbar sind.

15. ORLENE Ask und KI

ORLENE Ask ist die sprachliche Schnittstelle zur Plattform. Die KI soll nicht frei in beliebigen Daten suchen, sondern kontrolliert über Core, OID, Rechte, Wissensräume und Wissenspfade arbeiten.

15.2 Beispiel

Frage: Welche Sanierungen gab es in den letzten zehn Jahren an diesem Zinshaus? ORLENE Ask identifiziert das Objekt, prüft Rechte, nutzt Events, Dokumente, Beziehungen und bestätigte Wissenspfade und erzeugt eine nachvollziehbare Antwort mit Quellenbezug.

15.3 Offene Fragen

Wie werden Quellen in Antworten transparent gemacht?

15.3 Offene Fragen

Wann darf KI nur vorschlagen und wann automatisch handeln?

15.3 Offene Fragen

Wie wird Halluzination technisch und organisatorisch reduziert?

15.3 Offene Fragen

Wie werden sensible Daten und Rollen in RAG/KI-Kontexten kontrolliert?

16. Warum ORLENE keine klassische Warenwirtschaft ist

ORLENE Retail kann Funktionen besitzen, die wie Warenwirtschaft wirken: Artikel, Preise, Etiketten, Lagerplatz und Scans. Der Kern von ORLENE ist jedoch nicht Warenwirtschaft, sondern objektzentriertes Wissen.

16.2 Konsequenz

ORLENE kann in Retail starten, darf aber architektonisch nicht auf Retail begrenzt werden. Genau deshalb ist der Core branchenneutral.

17. Wachstumsmodell: Ein Wissensraum nach dem anderen

ORLENE muss nicht von Anfang an alle Branchen und alle Systeme verbinden. Das realistische Wachstumsmodell lautet: ein Objekt, ein Wissensraum, ein Anwendungsfall nach dem anderen.

17.1 Schrittweiser Ausbau

Retail: Artikel/Schuh als erster Wissensraum.

17.1 Schrittweiser Ausbau

Real Estate: Zinshaus/Gebäude als nächster Wissensraum.

17.1 Schrittweiser Ausbau

Automotive: Fahrzeug als weiterer Wissensraum.

17.1 Schrittweiser Ausbau

Danach: Maschine, Vertrag, Container, Patient, Werkzeug oder weitere Objekte.

17.2 Warum das realistisch ist

Der Core bleibt gleich. Neue Branchen erweitern vor allem Objekttypen, Adapter und Wissenspfade. Dadurch entsteht Wachstum nicht durch komplette Neuentwicklung, sondern durch Erweiterung der Plattform.

18. Minimal Viable Core - möglicher Startpunkt

Um den Berg klein zu machen, braucht ORLENE einen bewusst kleinen Start-Core. Dieser muss nicht alles können, aber die richtigen Prinzipien enthalten.

18.1 MVC-Bausteine

Objektanlage mit OID

18.1 MVC-Bausteine

einfache Eigenschaften je Objekt

18.1 MVC-Bausteine

Dokumentverknüpfung

18.1 MVC-Bausteine

einfache Beziehungen zwischen Objekten

18.1 MVC-Bausteine

Event-Log pro Objekt

18.1 MVC-Bausteine

manuelle Wissenspfade

18.1 MVC-Bausteine

Prüfstatus für Wissenspfade

18.1 MVC-Bausteine

einfache Suche

18.1 MVC-Bausteine

Basisrechte

18.1 MVC-Bausteine

ein Adapter oder Importweg, z. B. Excel/CSV/D&G-Datenexport

18.2 Was bewusst später kommt

vollständige KI-Agenten

18.2 Was bewusst später kommt

automatische Beziehungserkennung

18.2 Was bewusst später kommt

komplexer Graph-Store

18.2 Was bewusst später kommt

umfangreiche Mandanten- und Rechtehierarchien

18.2 Was bewusst später kommt

automatische Nutzenberechnung

18.2 Was bewusst später kommt

viele parallele Connect-Adapter

18.3 Vorschlag für ersten technischen Prototyp

Ein schlanker Python/Flask-Prototyp könnte Objekte, OIDs, Events, Beziehungen und Wissenspfade speichern. Der Fokus wäre nicht perfekte Skalierung, sondern die Validierung des Architekturprinzips.

19. Offene technische Fragen für den Entwickler

Diese Fragen sind bewusst offen. Sie sollen im Gespräch mit einem Entwickler kritisch diskutiert werden.

19. Offene technische Fragen für den Entwickler

Welche Datenbankstrategie ist für den ersten Core sinnvoll: SQLite/PostgreSQL + später Suchindex oder früh Graph/Vector Store?

19. Offene technische Fragen für den Entwickler

Wie soll die OID technisch aufgebaut sein?

19. Offene technische Fragen für den Entwickler

Wie lassen sich Beziehungen flexibel halten, ohne Chaos zu erzeugen?

19. Offene technische Fragen für den Entwickler

Wie kann der Connect Layer so gebaut werden, dass der Core sauber bleibt?

19. Offene technische Fragen für den Entwickler

Wie prüft man Wissenspfade pragmatisch, ohne Benutzer mit Bürokratie zu belasten?

19. Offene technische Fragen für den Entwickler

Wie kann ORLENE Ask sicher mit Rechten, Quellen und Halluzinationsschutz umgehen?

19. Offene technische Fragen für den Entwickler

Welche Teile können heute einfach gebaut werden und welche sollten bewusst warten?

19. Offene technische Fragen für den Entwickler

Wie kann der bestehende ORLENE-Retail-Code in Richtung Core 3.0 refaktoriert werden?

19.1 Was ich mir von der Rückmeldung wünsche

Was wirkt architektonisch schlüssing?

19.1 Was ich mir von der Rückmeldung wünsche

Wo siehst du technische Risiken?

19.1 Was ich mir von der Rückmeldung wünsche

Was ist zu gross gedacht?

19.1 Was ich mir von der Rückmeldung wünsche

Was sollte zuerst gebaut werden?

19.1 Was ich mir von der Rückmeldung wünsche

Welche Teile sollten wir anders benennen oder strukturieren?

19.1 Was ich mir von der Rückmeldung wünsche

Wenn du es bauen müsstest: Womit würdest du anfangen?

20. Zusammenfassung

ORLENE ist eine objektzentrierte Wissens- und Integrationsplattform. Sie soll bestehende Systeme nicht blind ersetzen, sondern Wissen aus vorhandenen Quellen verknüpfen. Der Core arbeitet mit Objekten, OIDs, Beziehungen, Events, Wissensräumen, Connect-Adaptern und der Erfahrungs-Engine.

20. Zusammenfassung

Der wichtigste Unterschied zu vielen klassischen Systemen liegt nicht nur in der Technik, sondern in den Grundprinzipien: Datenhoheit bleibt beim Eigentümer, der Mensch steht im Mittelpunkt, Wissen wächst durch Teilen, und Zeit ist die wertvollste Ressource.

Tabelle

Leitsatz Hardware ermöglicht Betriebssysteme. Betriebssysteme ermöglichen Anwendungen. Anwendungen erzeugen Daten. ORLENE verbindet daraus Wissen.

Tabelle

Bitte an den technischen Leser Lies dieses Dokument nicht als fertiges Pflichtenheft. Lies es als Architekturentwurf. Mich interessiert besonders: Was ist schlüssig? Was ist riskant? Was wuerdest du technisch anders loesen?

Tabelle

Kernsatz ORLENE wurde entwickelt, damit Menschen weniger Zeit mit dem Suchen nach Informationen verbringen und mehr Zeit für Wissen, Entscheidungen, Zusammenarbeit und Wertschöpfung haben.

Tabelle

Prinzip | Bedeutung | Mensch im Mittelpunkt | ORLENE passt sich dem Menschen an - nicht der Mensch an ORLENE. | Zeit als wertvollste Ressource | Zeit ist die einzige Ressource, die niemand zurückbekommt. ORLENE soll Zeit sinnvoller nutzbar machen. | Datenhoheit | Die Datenhoheit verbleibt immer beim Eigentümer der Daten. | Ursprung jeder Information | Jede Information besitzt einen Ursprung. Dieser Ursprung wird respektiert. | Integration vor Ersatz | ORLENE verbindet bestehende Systeme und ersetzt sie nur, wenn dies ausdrücklich gewünscht ist. | Objektzentrierung | Nicht Programme stehen im Mittelpunkt, sondern reale und digitale Objekte. | Komplexitaet in der Architektur | Komplexität gehört in die Architektur - niemals zum Benutzer. | Wissen teilen | Jeder Mensch kann Autor von Wissen werden. Geteiltes Wissen vergrößert seinen Wert.

Tabelle

Architekturidee Hardware -> Betriebssysteme -> Anwendungen -> Datenquellen -> ORLENE -> Wissen für Menschen

Tabelle

Definition: Objekt Ein Objekt ist jede eindeutig identifizierbare reale oder digitale Einheit, zu der Informationen, Beziehungen, Ereignisse und Wissen entstehen können.

Tabelle

Tabelle

Objekt -> Identität -> Beziehungen -> Ereignisse -> Dokumente -> Wissen -> Entscheidungen Dieser Ablauf bleibt über Branchen hinweg gleich. Nur die fachlichen Details unterscheiden sich.

Tabelle

Komponente | Aufgabe | Object Engine | Verwaltet Objekte, OIDs, Eigenschaften und Status. | Relationship Engine | Verwaltet Beziehungen zwischen Objekten. | Event Engine | Speichert Ereignisse und den nachvollziehbaren Lebenslauf eines Objekts. | Dialog Engine | Begleitet strukturierte Gespräche, Reviews, Interviews, Entscheidungen und Denkprozesse zwischen Menschen und ORLENE. | Memory Engine | Bewahrt Quellen, Gedanken, Wissenskandidaten, Erfahrungen und Entscheidungen in ihrem ursprünglichen Zusammenhang und mit ihrem jeweiligen Status. | Knowledge Engine | Verbindet bestätigte und freigegebene Inhalte zu einem nutzbaren digitalen Wissensraum. | Connect Layer | Verbindet externe Systeme, Anwendungen, Geräte und Datenquellen mit dem ORLENE Core. | Experience Engine | Entwickelt aus beschriebenen, geprüften und bestätigten Wissenspfaden wiederverwendbare Erfahrung. | Security Engine | Steuert Identitäten, Rollen, Rechte, Sichtbarkeit und Zugriff auf Quellen, Wissen und Funktionen. | API Engine | Stellt einheitliche und kontrollierte Schnittstellen für ORLENE-Komponenten und externe Systeme bereit.

Tabelle

Core bleibt universell Branchenmodule dürfen den Core erweitern, aber nicht verbiegen. Retail, Real Estate oder Automotive sind Sichten auf denselben Core.

Tabelle

ORLENE Workspace Zugang für Menschen ↕ Wissensarchitektur Dialog Engine ↔ Memory Engine ↔ Knowledge Engine ↔ Experience Engine ↕ Objektbezogene Grundlage Object Engine ↔ Relationship Engine ↔ Event Engine Querschnitt und Verbindung Connect Layer | Security Engine | API Engine

Tabelle

Architekturregel: Trennung der Wissensebenen Eine Quelle ist nicht automatisch Wissen. Ein Gedanke ist nicht automatisch eine Entscheidung. Eine wiederholte Handlung ist nicht automatisch eine bewährte Erfahrung. ORLENE bewahrt diese Unterschiede technisch und organisatorisch. Erst durch Kontext, Prüfung, Berechtigung und menschliche Freigabe kann aus einem Wissenskandidaten bestätigtes Wissen oder wiederverwendbare Erfahrung entstehen.

Tabelle

OID-OBJ-00000127 Typ: Building | Name: Zinshaus Feldgasse 12 | Beziehungen: Wohnung 1-18, Versicherung, Professionisten, Dokumente, Events

Tabelle

Beispiel Gebäude -> enthält -> Wohnung -> vermietet an -> Mieter -> meldet -> Schaden -> bearbeitet von -> Installateur

Tabelle

Architekturregel Nicht jede Information wird automatisch Wissen. Nicht jedes Dokument besitzt denselben Wissenswert. Nicht jede KI-Antwort besitzt denselben Vertrauensgrad. Die Knowledge Engine stellt deshalb ausschließlich Wissen bereit, dessen Herkunft, Status und Berechtigung nachvollziehbar sind.

Tabelle

Tabelle

Wichtiger Hinweis Diese Technologien müssen nicht alle sofort gebaut werden. Version 0.1 kann mit einem einfachen relationalen Kern, Suchindex und klaren OID-Verknüpfungen starten. Version 0.2 konzentriert sich bewusst auf eine klare Trennung zwischen Dialog, Gedächtnis, Wissen und Erfahrung. Diese Architektur ermöglicht es, zukünftige KI-Modelle oder Wissensquellen auszutauschen, ohne den grundlegenden Wissensprozess von ORLENE zu verändern.

Tabelle

Definition Ein Wissenspfad beschreibt Schritt für Schritt, wie ein Mensch zu einer Antwort gelangt: Welche Programme, Dokumente, Personen, Entscheidungen und Prüfungen waren notwendig?

Tabelle

Wissensautor: Max Mustermann 27 Wissenspfade | 19 bestätigte Wissensgesetze | 3.842 Anwendungen | 1.250 Stunden geschätzte Zeitersparnis | 185.000 EUR geschätzter Nutzen

Tabelle

KI arbeitet über den Core ORLENE Ask greift nicht direkt beliebig auf Datenbanken zu. Es verwendet den ORLENE Core, Berechtigungen, OIDs, Dokumentindexe und bestätigte Wissenspfade.

Tabelle

Tabelle

Wichtiger Architekturgedanke ORLENE wird nicht gebaut, indem alles auf einmal verbunden wird. ORLENE wächst, indem immer mehr Wissensräume kontrolliert hinzukommen.

Tabelle

Letzter Gedanke Dieses Dokument beschreibt keine fertige Software. Es beschreibt eine Richtung. Der nächste Schritt ist, diese Richtung technisch kritisch zu prüfen und in einen kleinen, sauberen ORLENE Core zu überführen.