ORLENE Architektur Werk · ORLENE Reading Space

Kapitel 1 von 8

00 – Architekturübersicht

ORLENE 3.0

Einordnung

Inhaltsverzeichnis

Zweck des Dokuments

Was ORLENE 3.0 ist

Warum diese Architekturserie existiert

Die Lesereihenfolge

Die Architektur in einem Satz

Die Dokumente und ihre Rolle

Die Architekturbausteine im Zusammenspiel

Das ORLENE-Haus

Was ORLENE bewusst nicht ist

Die zentrale Bewegung

Warum First Light am Ende steht

Umgang mit späteren technischen Dokumenten

Dokumentenstatus

Änderungsverlauf

Schlussgedanke

Dokumentanfang

ORLENE

Dokumentanfang

00 – Architekturübersicht v1.0

Dokumentanfang

Der Weg durch die Architektur von ORLENE

Dokumentanfang

Dokument 00 von 09

ORLENE 3.0

Offizielle Architekturserie

Inhaltsverzeichnis

01 Zweck des Dokuments

Inhaltsverzeichnis

02 Was ORLENE 3.0 ist

Inhaltsverzeichnis

03 Warum diese Architekturserie existiert

Inhaltsverzeichnis

04 Die Lesereihenfolge

Inhaltsverzeichnis

05 Die Architektur in einem Satz

Inhaltsverzeichnis

06 Die Dokumente und ihre Rolle

Inhaltsverzeichnis

07 Die Architekturbausteine im Zusammenspiel

Inhaltsverzeichnis

08 Das ORLENE-Haus

Inhaltsverzeichnis

09 Was ORLENE bewusst nicht ist

Inhaltsverzeichnis

10 Die zentrale Bewegung

Inhaltsverzeichnis

11 Warum First Light am Ende steht

Inhaltsverzeichnis

12 Umgang mit späteren technischen Dokumenten

Inhaltsverzeichnis

13 Dokumentenstatus

Inhaltsverzeichnis

14 Änderungsverlauf

Inhaltsverzeichnis

15 Schlussgedanke

Inhaltsverzeichnis

Zweck des Dokuments

Dieses Dokument gibt Orientierung.

Zweck des Dokuments

Es erklärt nicht alle Inhalte im Detail. Es zeigt den Weg durch die Architektur.

Zweck des Dokuments

Die Architekturübersicht ist keine Zusammenfassung. Sie ist die Landkarte.

Zweck des Dokuments

Was ORLENE 3.0 ist

ORLENE ist kein Dashboard. ORLENE ist ein Arbeitsraum.

Was ORLENE 3.0 ist

ORLENE ersetzt nicht vorhandene Werkzeuge. ORLENE verbindet sie.

Was ORLENE 3.0 ist

ORLENE hilft Menschen, weniger zu suchen, Zusammenhänge schneller zu verstehen und vorhandene Fähigkeiten sinnvoll zu nutzen.

Was ORLENE 3.0 ist

ORLENE dient dem Menschen.

Was ORLENE 3.0 ist

Warum diese Architekturserie existiert

ORLENE 3.0 wird nicht nur über Funktionen definiert.

Warum diese Architekturserie existiert

ORLENE 3.0 wird über Haltung, Architektur und Benutzererfahrung definiert.

Warum diese Architekturserie existiert

Die Dokumente schaffen eine gemeinsame Sprache für Entwickler, Partner, Entscheider, spätere Kunden und den Gründer selbst.

Warum diese Architekturserie existiert

Die Lesereihenfolge

Die Serie wird als gedanklicher Weg gelesen.

Die Lesereihenfolge

• 00 Architekturübersicht

Die Lesereihenfolge

• 01 Founding Domains

Die Lesereihenfolge

• 02 Space Blueprint

Die Lesereihenfolge

• 03 Hausbewohner

Die Lesereihenfolge

• 05 Flow Engine

Die Lesereihenfolge

• 06 Capability Engine

Die Lesereihenfolge

• 07 Experience Engine

Die Lesereihenfolge

• 08 Knowledge Lineage Engine

Die Lesereihenfolge

• 09 First Light

Die Lesereihenfolge

Das Technical Whitepaper wird später als technische Umsetzung der fertigen Architektur neu eingeordnet. Es bleibt vorerst außerhalb von Band 1.

Die Lesereihenfolge

Die Architektur in einem Satz

Ein Satz hält den roten Faden zusammen.

Die Architektur in einem Satz

ORLENE schafft einen Arbeitsraum, in dem der Mensch seine Absicht äußert, vorhandene Fähigkeiten zusammenwirken und Wissen mit Herkunft, Zusammenhang und Entwicklung bewahrt wird.

Die Architektur in einem Satz

Die Dokumente und ihre Rolle

Jedes Dokument trägt eine eigene Verantwortung im Gesamtwerk.

Die Dokumente und ihre Rolle

Die Architekturbausteine im Zusammenspiel

Der Mensch beginnt nicht mit einem Programm. Er beginnt mit einer Absicht.

Die Architekturbausteine im Zusammenspiel

Die Flow Engine erkennt die Absicht. Die Capability Engine sucht die passende Fähigkeit. Die Experience Engine liefert Erfahrung aus bisheriger Zusammenarbeit.

Die Architekturbausteine im Zusammenspiel

Die Knowledge Lineage Engine bewahrt Herkunft und Zusammenhang des verwendeten Wissens. Die Hausbewohner führen konkrete Aufgaben aus. Der Space hält alles als gemeinsamen Arbeitsraum zusammen.

Die Architekturbausteine im Zusammenspiel

Das ORLENE-Haus

Das ORLENE-Haus ordnet Arbeit in lesbare Räume.

Das ORLENE-Haus

• Heute

Das ORLENE-Haus

• Arbeiten

Das ORLENE-Haus

• Finden

Das ORLENE-Haus

• Erkennen

Das ORLENE-Haus

• Wissen

Das ORLENE-Haus

• Verwalten

Das ORLENE-Haus

Diese Räume sind keine klassische Menüstruktur. Sie sind eine lesbare Ordnung menschlicher Arbeit.

Das ORLENE-Haus

Was ORLENE bewusst nicht ist

ORLENE definiert sich auch durch Grenzen.

Was ORLENE bewusst nicht ist

• ein weiteres Dashboard

Was ORLENE bewusst nicht ist

• ein Ersatz für alle Programme

Was ORLENE bewusst nicht ist

• eine reine KI

Was ORLENE bewusst nicht ist

• ein Datensammler

Was ORLENE bewusst nicht ist

• ein System zur Bewertung von Menschen

Was ORLENE bewusst nicht ist

• ein Zwangssystem

Was ORLENE bewusst nicht ist

ORLENE begleitet. ORLENE schlägt vor. Der Mensch entscheidet.

Was ORLENE bewusst nicht ist

Die zentrale Bewegung

Die Architektur dient nicht sich selbst.

Die zentrale Bewegung

Die Architektur dient dem Arbeitstag des Menschen.

Die zentrale Bewegung

Warum First Light am Ende steht

First Light steht am Ende, weil es das Zusammenspiel erlebbar macht.

Warum First Light am Ende steht

First Light zeigt, wie alle vorherigen Prinzipien erstmals in einem Arbeitstag spürbar werden.

Warum First Light am Ende steht

Es ist nicht die vollständige Vision. Es ist der erste Moment, in dem ORLENE als ORLENE spürbar wird.

Warum First Light am Ende steht

Umgang mit späteren technischen Dokumenten

Nach Band 1 folgt später ein technischer Band.

Umgang mit späteren technischen Dokumenten

Dieser kann Technical Whitepaper, technische Systemarchitektur, Datenmodell, Schnittstellen, Integrationen, Entwicklerleitfaden und First-Light-Umsetzungsplan enthalten.

Umgang mit späteren technischen Dokumenten

Band 1 beschreibt, wie ORLENE denkt. Band 2 beschreibt später, wie ORLENE gebaut wird.

Umgang mit späteren technischen Dokumenten

Dokumentenstatus

Dieses Kapitel hält Version, Reifegrad und Umsetzungsstatus fest.

Dokumentenstatus

Änderungsverlauf

Dieses Kapitel dokumentiert die erste beschlossene Fassung.

Änderungsverlauf

Version 1.0

Änderungsverlauf

Neu:

Änderungsverlauf

• Architekturübersicht als Eingangsdokument eingeführt

Änderungsverlauf

• Lesereihenfolge der ORLENE-3.0-Dokumentation definiert

Änderungsverlauf

• Rolle der einzelnen Architekturkapitel beschrieben

Änderungsverlauf

• Technical Whitepaper vorläufig aus Band 1 ausgegliedert

Änderungsverlauf

• Zusammenspiel der Engines zusammengefasst

Änderungsverlauf

• First Light als erlebbare Abschlussform eingeordnet

Änderungsverlauf

Schlussgedanke

Dieses Dokument ist die Eingangstür zum ORLENE-3.0-Architekturhandbuch.

Tabelle

ARCHITEKTURSERIE Dokument: 00 von 09 Dieses Dokument wird als erstes gelesen. Danach folgen: 01 Founding Domains · 02 Space Blueprint · 03 Hausbewohner · 05 Flow Engine · 06 Capability Engine · 07 Experience Engine · 08 Knowledge Lineage Engine · 09 First Light Hinweis: Das Technical Whitepaper bleibt vorerst außerhalb dieser konzeptionellen Architekturserie und wird nach Abschluss von Band 1 vollständig überarbeitet.

Tabelle

LEITFRAGE Wie liest man die ORLENE-3.0-Architektur so, dass der rote Faden von Anfang an verständlich wird?

Tabelle

ZENTRALE DEFINITION Die Architekturübersicht ist die Landkarte durch ORLENE 3.0. Sie ersetzt keines der Fachkapitel. Sie erklärt, wie die Kapitel zusammengehören.

Tabelle

Tabelle

BEWEGUNG Mensch ↓ Absicht ↓ Flow Engine ↓ Capability Engine ↓ Hausbewohner / Werkzeuge ↓ Knowledge Lineage ↓ First Light / erlebter Arbeitstag

Tabelle

Tabelle

SCHLUSSGEDANKE Wer es liest, soll nicht jedes Detail verstehen. Er soll den Weg erkennen. ORLENE beginnt mit einer Haltung. Aus dieser Haltung entsteht ein Raum. In diesem Raum arbeiten Fähigkeiten zusammen. Und aus diesem Zusammenspiel entsteht ein Arbeitstag, in dem der Mensch weniger suchen muss und mehr Zeit für das hat, was nur Menschen leisten können.

Kapitel 2 von 8

ORLENE Founding Domains

Dokumentanfang

ORLENE Founding Domains

Dokumentanfang

Eine Einladung zum Mitgestalten

Dokumentanfang

Redaktionelle Fassung Version 1.0

Dokumentanfang

Erfahrung darf nicht verloren gehen.

Dokumentanfang

Inhaltsverzeichnis

Dokumentanfang

1. Vielleicht beginnt alles mit einer einfachen Frage

Dokumentanfang

2. Warum ich dir schreibe

Dokumentanfang

3. Warum ORLENE entstanden ist

Dokumentanfang

4. Eine andere Sicht auf Software

Dokumentanfang

5. Aus Daten wird Wissen

Dokumentanfang

6. ORLENE Ask

Dokumentanfang

7. Warum gerade deine Erfahrung wichtig ist

Dokumentanfang

8. Founding Domains

Dokumentanfang

9. Erfahrung ist wertvoller als Titel

Dokumentanfang

10. Eine Plattform entsteht durch Vertrauen

Dokumentanfang

11. Eine neue Art von Anerkennung

Dokumentanfang

12. Wie ORLENE wachsen soll

Dokumentanfang

13. Drei Fragen

Dokumentanfang

14. Persönlicher Schlussgedanke

Dokumentanfang

1. Vielleicht beginnt alles mit einer einfachen Frage

Dokumentanfang

Was geschieht eigentlich mit dem Wissen, das ein Mensch im Laufe seines Berufslebens sammelt?

Dokumentanfang

Nicht mit dem Wissen, das in Zertifikaten steht. Nicht nur mit dem, was in Schulungen vermittelt wurde oder in einer Stellenbeschreibung auftaucht. Sondern mit dem Wissen, das durch Jahre entsteht: durch Entscheidungen, durch Irrtümer, durch Kunden, durch Lieferanten, durch Druck, durch Verantwortung und durch unzählige Situationen, in denen jemand nicht nach Handbuch gehandelt hat, sondern aus Erfahrung.

Dokumentanfang

Dieses Wissen ist oft schwer zu benennen. Es sitzt in Blicken, in Routinen, in Abwägungen. Ein erfahrener Mensch erkennt manchmal in wenigen Sekunden, was ein System nicht sieht. Er weiß, warum ein Artikel trotz guter Zahlen problematisch sein kann. Er erinnert sich an einen Lieferanten, der zuverlässig wirkt, aber in bestimmten Monaten regelmäßig schwankt. Er spürt, wann ein Prozess auf dem Papier richtig aussieht und im Alltag trotzdem nicht funktioniert.

Dokumentanfang

Und doch verschwindet genau dieses Wissen viel zu oft. Es geht verloren, wenn Menschen die Abteilung wechseln. Wenn ein Betrieb verkauft wird. Wenn jemand in Rente geht. Wenn neue Software eingeführt wird, die zwar Daten übernimmt, aber nicht die Geschichten dahinter. Dann bleiben Artikelnummern, Preise, Bestände und Tabellen erhalten. Aber die Erfahrung, die diesen Zahlen Bedeutung gibt, bleibt zurück.

Dokumentanfang

Erfahrung darf nicht verloren gehen.

Dokumentanfang

Dieser Satz ist der rote Faden von ORLENE Founding Domains. Er ist kein technischer Anspruch, sondern ein menschlicher. Denn Unternehmen bestehen nicht nur aus Prozessen. Sie bestehen aus Menschen, die über Jahre gelernt haben, wie ihre Branche wirklich funktioniert.

Dokumentanfang

2. Warum ich dir schreibe

Dokumentanfang

Ich schreibe dir nicht, weil ich dir eine Software verkaufen möchte. Ich schreibe dir, weil ich glaube, dass es Menschen gibt, deren Erfahrung für eine Branche zu wertvoll ist, um nur im eigenen Kopf, in einzelnen Gesprächen oder in verstreuten Dokumenten zu bleiben.

Dokumentanfang

Vielleicht gehörst du zu diesen Menschen. Vielleicht führst du ein Unternehmen. Vielleicht hast du eines aufgebaut, übernommen, durch schwierige Jahre getragen oder neu ausgerichtet. Vielleicht kennst du deinen Markt nicht, weil du ihn analysiert hast, sondern weil du ihn erlebt hast. Weil du mit Kunden gesprochen, mit Lieferanten verhandelt, Fehler bezahlt und Lösungen gefunden hast, die in keinem Lehrbuch standen.

Dokumentanfang

Genau deshalb richtet sich diese Einladung an dich. Nicht als Kunde in einem Programm. Nicht als Testnutzer. Nicht als Zielgruppe. Sondern als Mensch mit Domänenerfahrung: als jemand, der weiß, was in seiner Branche wirklich zählt.

Dokumentanfang

ORLENE Founding Domains ist eine Einladung an Unternehmerinnen, Unternehmer und erfahrene Praktiker, ihr Wissen nicht abzugeben, sondern es gemeinsam in eine Form zu bringen, die dem eigenen Unternehmen dient und später auch anderen helfen kann.

Dokumentanfang

3. Warum ORLENE entstanden ist

Dokumentanfang

ORLENE ist aus einer sehr einfachen Beobachtung entstanden: In vielen Unternehmen wird jeden Tag unglaublich viel gelernt, aber nur ein kleiner Teil davon wird wirklich bewahrt.

Dokumentanfang

Es gibt Warenwirtschaftssysteme, Tabellen, Ablagen, Preislisten, E-Mails, Notizen und Gespräche. All das ist wichtig. Aber oft bleibt Wissen dort liegen, wo es zufällig entstanden ist. Es wird nicht verbunden. Es wird nicht erklärt. Es wird nicht so zugänglich gemacht, dass ein anderer Mensch später verstehen kann, warum etwas so ist, wie es ist.

Dokumentanfang

Ich habe gesehen, wie viel Erfahrung in kleinen und mittelständischen Unternehmen steckt. Gerade dort, wo Menschen nicht in großen Stabsabteilungen arbeiten, sondern nah am Kunden, nah am Lager, nah am Einkauf, nah am Alltag. Dort entsteht Wissen, das unmittelbar brauchbar ist. Wissen, das nicht theoretisch glänzt, sondern praktisch trägt.

Dokumentanfang

ORLENE wurde entwickelt, um zu dienen.

Dokumentanfang

Dieser Satz ist wichtig. ORLENE soll Menschen nicht ersetzen. ORLENE soll nicht so tun, als wüsste eine Maschine besser, was ein erfahrener Unternehmer über Jahre gelernt hat. ORLENE soll zuhören, ordnen, verbinden und verfügbar machen. Es geht nicht darum, Erfahrung zu automatisieren. Es geht darum, Erfahrung sichtbar, nutzbar und weitergebbar zu machen.

Dokumentanfang

4. Eine andere Sicht auf Software

Dokumentanfang

Viele Softwareprojekte beginnen mit Funktionen. Was soll das System können? Welche Masken braucht es? Welche Schnittstellen? Welche Berichte? Diese Fragen sind nicht falsch. Aber sie führen oft dazu, dass Menschen sich an Software anpassen müssen.

Dokumentanfang

Sie lernen Menüs, Felder, Abkürzungen und Abläufe. Sie übersetzen ihre Arbeit in die Sprache des Systems. Was nicht in ein Feld passt, bleibt draußen. Was nicht sauber kategorisiert werden kann, wird zur Notiz, zur Erinnerung oder zum stillen Wissen einzelner Menschen.

Dokumentanfang

ORLENE beginnt an einer anderen Stelle. Nicht bei der Maske. Nicht beim Datenmodell. Sondern beim Menschen und bei seiner Erfahrung. Die zentrale Frage lautet nicht zuerst: Was kann die Software? Sondern: Was muss verstanden werden, damit die Arbeit eines Menschen, eines Teams oder eines Unternehmens leichter, klarer und verlässlicher wird?

Dokumentanfang

Software sollte nicht der Mittelpunkt sein. Sie sollte ein Werkzeug bleiben. Ein gutes Werkzeug drängt sich nicht vor. Es hilft, ohne die Hand zu ersetzen, die es führt.

Dokumentanfang

5. Aus Daten wird Wissen

Dokumentanfang

Daten allein sind noch kein Wissen. Eine Artikelnummer ist eine Zuordnung. Ein Bestand ist ein Zustand. Ein Preis ist ein Wert zu einem Zeitpunkt. All das ist notwendig, aber es erklärt nicht, warum ein Artikel wichtig ist, welche Rolle er im Betrieb spielt oder welche Geschichte mit ihm verbunden ist.

Dokumentanfang

Ein Beispiel: In einer klassischen Warenwirtschaft sieht Peter Wagner zu einem Artikel den Bestand, den Preis und die Artikelnummer. Er sieht, ob etwas verfügbar ist. Er sieht, was es kostet. Er sieht vielleicht noch den Lieferanten, eine Warengruppe oder eine Bewegungshistorie.

Dokumentanfang

Das ist nützlich. Aber Peter weiß aus Erfahrung mehr. Er weiß, dass dieser Artikel vor drei Jahren fast aus dem Sortiment gefallen wäre, weil die Nachfrage saisonal schwankte. Er erinnert sich an einen Kunden, der genau diesen Artikel immer in Kombination mit einem anderen brauchte. Er weiß, dass ein bestimmter Lieferant bei diesem Artikel zwar günstiger war, aber häufiger Qualitätsprobleme hatte. Er kennt den Grund, warum ein scheinbar ähnlicher Ersatzartikel in der Praxis nicht funktioniert.

Dokumentanfang

Eine klassische Warenwirtschaft zeigt Bestand, Preis und Artikelnummer. ORLENE soll zusätzlich die Geschichte des Artikels sichtbar machen.

Dokumentanfang

Nicht als Roman. Nicht als unnötige Ausschmückung. Sondern als Wissensraum: als Zusammenhang aus Daten, Entscheidungen, Erfahrungen, Ausnahmen, Kundenrealität und praktischer Bedeutung. Erst dort beginnt Wissen. Und erst dieses Wissen hilft einem Unternehmen, bessere Entscheidungen zu treffen.

Dokumentanfang

6. ORLENE Ask

Dokumentanfang

Heute lernen Menschen Software. Sie lernen, wo sie klicken müssen, welche Begriffe das System verwendet und wie sie ihre Fragen so formulieren, dass eine Maschine sie verarbeiten kann.

Dokumentanfang

ORLENE verfolgt ein anderes Ziel: Software soll Menschen besser verstehen.

Dokumentanfang

ORLENE Ask ist dafür ein zentraler Gedanke. Es geht darum, dass ein Mensch Fragen stellen kann, wie er sie auch einem erfahrenen Kollegen stellen würde. Nicht nur: Wie hoch ist der Bestand? Sondern: Warum verkaufen wir diesen Artikel kaum noch? Gibt es dazu eine Vorgeschichte? Welche Alternative hat sich bewährt? Worauf muss ich achten, wenn ich diesen Kunden berate? Welche Erfahrung gibt es mit diesem Lieferanten?

Dokumentanfang

Damit ORLENE sinnvoll antworten kann, braucht es mehr als Daten. Es braucht Bedeutung. Es braucht die Sprache der Menschen, die in der Branche arbeiten. Es braucht Erfahrung, die nicht in abstrakte Begriffe gepresst wird, sondern so erfasst wird, dass sie später wieder lebendig und brauchbar wird.

Dokumentanfang

ORLENE Ask ist deshalb kein Versprechen, dass Software alles weiß. Es ist der Versuch, Wissen so aufzubauen, dass Menschen leichter fragen, verstehen und handeln können.

Dokumentanfang

7. Warum gerade deine Erfahrung wichtig ist

Dokumentanfang

Jede Branche hat ihre eigene Logik. Von außen sieht vieles ähnlich aus: Produkte, Preise, Kunden, Lieferanten, Prozesse. Von innen weiß man, dass die entscheidenden Unterschiede oft im Detail liegen.

Dokumentanfang

Ein erfahrener Mensch erkennt diese Details. Er weiß, welche Begriffe in der Praxis anders verwendet werden als in der Theorie. Er weiß, welche Kennzahlen täuschen können. Er weiß, welche Kundenfragen eigentlich Warnsignale sind. Er weiß, welche Abläufe funktionieren, obwohl sie nie sauber dokumentiert wurden.

Dokumentanfang

Dieses Wissen kann ORLENE nicht erfinden. Es muss entdeckt werden. Deshalb beginnt ORLENE nicht mit Behauptungen, sondern mit Zuhören. Der Discovery-Prozess folgt einer einfachen Bewegung: Zuhören, Verstehen, Wissensraum, ORLENE.

Dokumentanfang

Zuerst wird zugehört. Dann wird verstanden, welche Erfahrungen, Begriffe, Entscheidungen und Zusammenhänge wirklich wichtig sind. Daraus entsteht ein Wissensraum. Erst danach wird ORLENE so aufgebaut, dass dieser Wissensraum dem Unternehmen dient.

Dokumentanfang

Der erste Nutznießer einer Founding Domain ist immer das Unternehmen des Domänenpartners. Nicht eine anonyme Plattform. Nicht ein späterer Markt. Sondern zuerst das eigene Unternehmen, die eigenen Mitarbeitenden, die eigenen Abläufe und die eigene Zukunftsfähigkeit.

Dokumentanfang

8. Founding Domains

Dokumentanfang

Founding Domains sind kein Kundenprogramm. Sie sind keine Marketingaktion und kein klassischer Pilot. Eine Founding Domain ist eine Einladung an Domänenexperten, gemeinsam einen Wissensraum aufzubauen, der aus echter Erfahrung entsteht.

Dokumentanfang

Der Begriff Domain meint dabei nicht eine Internetadresse. Er meint ein Erfahrungsfeld: eine Branche, ein Markt, ein Arbeitsbereich, eine gewachsene betriebliche Wirklichkeit. Founding bedeutet, dass dieser Wissensraum nicht nachträglich aufgesetzt wird, sondern von Anfang an mit Menschen entsteht, die die Domäne wirklich kennen.

Dokumentanfang

In einer Founding Domain wird Erfahrung nicht abgefragt wie in einem Formular. Sie wird gemeinsam freigelegt. Was ist selbstverständlich geworden, obwohl es für Außenstehende erklärungsbedürftig ist? Welche Entscheidungen fallen jeden Tag, ohne dass sie dokumentiert werden? Welche Geschichten erklären, warum bestimmte Prozesse so sind, wie sie sind?

Dokumentanfang

Eine Founding Domain entsteht dort, wo ein erfahrener Mensch bereit ist, seine Wirklichkeit so ernst zu nehmen, dass daraus ein Wissensraum werden kann.

Dokumentanfang

9. Erfahrung ist wertvoller als Titel

Dokumentanfang

ORLENE bewertet Menschen nicht nach Titel. Erfahrung entsteht nicht nur im Büro der Geschäftsführung, nicht nur in Studiengängen und nicht nur dort, wo Visitenkarten wichtig klingen.

Dokumentanfang

Erfahrung ist eine zweite Form von Bildung.

Dokumentanfang

Ein Fließbandarbeiter kann wissen, an welcher Stelle ein Prozess immer wieder stockt. Ein Lagerarbeiter erkennt, welche Artikel zwar selten auffallen, aber für den Ablauf entscheidend sind. Ein Fahrer hört beim Kunden Dinge, die in keinem CRM-System stehen. Eine Verkäuferin merkt, welche Frage ein Kunde stellt, wenn er eigentlich unsicher ist. Ein Monteur erkennt an einem Geräusch, dass etwas nicht stimmt, lange bevor eine Auswertung es zeigen würde.

Dokumentanfang

Dieses Wissen ist nicht weniger wert, nur weil es nicht immer in Berichten auftaucht. Oft ist es sogar besonders wertvoll, weil es nah an der Wirklichkeit entstanden ist.

Dokumentanfang

ORLENE soll helfen, diese Erfahrung sichtbar zu machen. Nicht, um Menschen zu vermessen. Nicht, um sie zu kontrollieren. Sondern um anzuerkennen, dass ein Unternehmen mehr weiß, als seine Systeme heute zeigen.

Dokumentanfang

10. Eine Plattform entsteht durch Vertrauen

Dokumentanfang

Eine Plattform, die mit Erfahrung arbeitet, kann nicht auf Misstrauen gebaut werden. Wer sein Wissen öffnet, muss spüren, dass damit respektvoll umgegangen wird.

Dokumentanfang

Deshalb beginnt ORLENE mit dem Unternehmen des Domänenpartners. Der erste Wert entsteht dort, wo die Erfahrung herkommt. Dort soll sie helfen, entlasten, klären und bewahren. Erst wenn Vertrauen gewachsen ist, kann daraus mehr entstehen.

Dokumentanfang

Vertrauen bedeutet auch, Grenzen zu achten. Nicht jedes Wissen muss öffentlich werden. Nicht jede Erfahrung gehört in einen allgemeinen Raum. Manche Erkenntnisse bleiben intern, weil sie zur Identität, zum Wettbewerb oder zur Verantwortung eines Unternehmens gehören.

Dokumentanfang

ORLENE soll nicht nehmen, sondern dienen. Eine Plattform entsteht nicht dadurch, dass möglichst viele Daten gesammelt werden. Sie entsteht dadurch, dass Menschen erleben, dass ihr Wissen geschützt, geordnet und sinnvoll genutzt wird.

Dokumentanfang

11. Eine neue Art von Anerkennung

Dokumentanfang

In vielen Unternehmen wird Erfahrung gebraucht, aber selten wirklich sichtbar gemacht. Man fragt die erfahrenen Menschen, wenn es brennt. Man ruft sie an, wenn niemand weiterweiß. Man verlässt sich auf sie, ohne immer zu benennen, was sie eigentlich leisten.

Dokumentanfang

ORLENE Founding Domains kann eine neue Art von Anerkennung schaffen. Nicht durch laute Auszeichnungen, sondern durch etwas Nachhaltigeres: Erfahrung wird so ernst genommen, dass sie Struktur bekommt.

Dokumentanfang

Wer an einer Founding Domain mitwirkt, gibt nicht einfach Wissen ab. Er prägt mit, wie seine Branche verstanden wird. Er hilft, Begriffe, Zusammenhänge, Geschichten und Entscheidungsmuster in eine Form zu bringen, die auch morgen noch zugänglich ist.

Dokumentanfang

Anerkennung bedeutet hier: Deine Erfahrung zählt nicht nur, solange du im Raum bist. Sie kann Teil eines Wissensraums werden, der anderen Orientierung gibt.

Dokumentanfang

12. Wie ORLENE wachsen soll

Dokumentanfang

ORLENE soll nicht wachsen, indem irgendwo ein allgemeines System über viele Branchen gelegt wird. ORLENE soll aus echten Wissensräumen wachsen. Schritt für Schritt. Branche für Branche. Mit Menschen, die wissen, worüber sie sprechen.

Dokumentanfang

Am Anfang steht immer eine konkrete Domäne. Ein Unternehmen. Eine Erfahrungsgeschichte. Ein Arbeitsfeld, das verstanden werden will. Daraus entsteht ein erster Wissensraum, der dem Unternehmen selbst dient.

Dokumentanfang

Wenn dieser Raum tragfähig ist, kann daraus mehr entstehen: bessere Übergaben, schnellere Einarbeitung, klarere Entscheidungen, weniger Abhängigkeit von Einzelpersonen, ein besseres Verständnis für Kunden, Produkte und Prozesse.

Dokumentanfang

Langfristig kann ORLENE wachsen, wenn viele solcher Wissensräume entstehen. Nicht als Sammlung beliebiger Daten, sondern als lebendige Landkarte praktischer Erfahrung.

Dokumentanfang

Der Maßstab bleibt dabei derselbe: Dient ORLENE den Menschen, die mit ihr arbeiten? Macht sie Erfahrung zugänglicher? Hilft sie, Wissen zu bewahren, bevor es verloren geht?

Dokumentanfang

13. Drei Fragen

Dokumentanfang

Vielleicht lässt sich diese Einladung auf drei einfache Fragen verdichten.

Dokumentanfang

Erstens: Welches Wissen in deinem Unternehmen wäre schwer zu ersetzen, wenn die Menschen, die es tragen, morgen nicht mehr verfügbar wären?

Dokumentanfang

Zweitens: Welche Geschichten, Entscheidungen und Erfahrungen erklären eure Arbeit besser als jede Tabelle?

Dokumentanfang

Drittens: Was würde sich verändern, wenn dieses Wissen nicht mehr nur zufällig weitergegeben würde, sondern als Wissensraum verfügbar wäre?

Dokumentanfang

Diese Fragen sind bewusst einfach. Aber sie führen oft sehr tief. Sie zeigen, wo Erfahrung still wirkt. Sie zeigen, wo ein Unternehmen verletzlich ist. Und sie zeigen, wo ORLENE dienen kann.

Dokumentanfang

14. Persönlicher Schlussgedanke

Dokumentanfang

Vielleicht beginnt ORLENE nicht mit Technologie. Vielleicht beginnt ORLENE mit einem Unternehmer, der innehält und erkennt, wie viel Wissen in seinem Unternehmen gewachsen ist.

Dokumentanfang

Mit einem Menschen, der weiß, dass Erfahrung nicht selbstverständlich ist. Dass sie Zeit gekostet hat. Dass sie durch Verantwortung entstanden ist. Dass sie nicht einfach verschwinden sollte, nur weil Systeme sie bisher nicht erfassen konnten.

Dokumentanfang

Wenn du dich in diesen Gedanken wiederfindest, dann ist diese Einladung an dich gerichtet. Nicht, weil ORLENE schon alles weiß. Sondern weil ORLENE dort lernen soll, wo echte Erfahrung zuhause ist.

Dokumentanfang

Vielleicht beginnt mit deiner Erfahrung der erste Wissensraum deiner Branche.

Kapitel 3 von 8

ORLENE Technical Whitepaper

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.

Kapitel 4 von 8

Software Architecture Specification (SAS)

ORLENE 3.0

Software Architecture Specification (SAS)

Inhaltsverzeichnis

1. Die Philosophie von ORLENE

1.1 Die Entstehung

1.2 Das eigentliche Problem

1.3 Die Grundidee

1.4 Leitsatz

1.5 Definition von ORLENE

1.6 Der digitale Wissensraum

7. Universelles Objektmodell

7.1 Wissensobjekte

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

7.3 Architekturprinzip

7.4 Beziehung zwischen Objektwelten

7.5 Architekturregel

7.6 Ausblick

TEIL II – WISSENSARCHITEKTUR

10. Dialog Engine

10.1 Ziel der Dialog Engine

10.2 Grundprinzip

10.3 Der Dialog als ORLENE-Objekt

10.4 Technisches Grundmodell eines Dialogobjekts

10.5 Dialogobjekt und Dialogverlauf

10.6 Dialogarten

10.7 Architektur eines Dialogs

10.8 Aufgaben der Dialog Engine

10.9 Verantwortung

10.10 Übergabe an die Memory Engine

10.11 Architekturregel

10.12 Typischer Architekturfluss

10.13 Offene Architekturfragen

11. Memory Engine

13. Experience Engine

Software Architecture Specification (SAS)

Masterdokument – Arbeitsentwurf Version 0.2 Stand: Juni 2026

Inhaltsverzeichnis

Vorwort

Inhaltsverzeichnis

1. Die Philosophie von ORLENE

Inhaltsverzeichnis

2. Die Entstehung – Vom Virtuellen Haus zu ORLENE

Inhaltsverzeichnis

3. Problem heutiger Unternehmenssoftware

Inhaltsverzeichnis

4. Vision von ORLENE

Inhaltsverzeichnis

5. Objektzentrierte Architektur

Inhaltsverzeichnis

6. ORLENE Core

Inhaltsverzeichnis

7. Universelles Objektmodell

Inhaltsverzeichnis

8. Event Engine

Inhaltsverzeichnis

9. Relationship Engine

Inhaltsverzeichnis

TEIL II – WISSENSARCHITEKTUR

Inhaltsverzeichnis

10. Dialog Engine

Inhaltsverzeichnis

11. Memory Engine

Inhaltsverzeichnis

12. Knowledge Engine

Inhaltsverzeichnis

13. Experience Engine

Inhaltsverzeichnis

14. Dokumenten- und Medienverwaltung

Inhaltsverzeichnis

15. Workflow Engine

Inhaltsverzeichnis

16. Connect Layer

Inhaltsverzeichnis

17. ORLENE Ask & KI

Inhaltsverzeichnis

18. API-Architektur

Inhaltsverzeichnis

19. Sicherheits- und Rollenmodell

Inhaltsverzeichnis

20. Branchenmodule

Inhaltsverzeichnis

21. Beispiele objektzentrierter Lösungen

Inhaltsverzeichnis

22. Roadmap ORLENE 3.x

Inhaltsverzeichnis

23. Anhang

1.1 Die Entstehung

Die Idee hinter ORLENE entstand nicht im Zusammenhang mit künstlicher Intelligenz oder moderner Cloud-Technologie. Ihr Ursprung reicht mehr als fünfzehn Jahre zurück. Damals entstand das Konzept »Virtuelles Haus«. Die ursprüngliche Vision war, sämtliche Informationen zu einer Liegenschaft digital an einem Ort verfügbar zu machen. Nicht nur Dokumente oder Rechnungen, sondern die gesamte Geschichte, alle Beteiligten, alle Ereignisse und alle Beziehungen. Mit ORLENE 3.0 wird diese Vision zu einer universellen, objektzentrierten Plattform weiterentwickelt.

1.2 Das eigentliche Problem

Unternehmen besitzen heute tausende Informationen, die auf unterschiedliche Programme, Dokumente und Personen verteilt sind. Das eigentliche Problem ist nicht das Erfassen von Daten, sondern das Auffinden von Wissen im richtigen Moment sowie das Erkennen von Zusammenhängen.

1.3 Die Grundidee

ORLENE betrachtet Unternehmen nicht aus Sicht einzelner Programme, sondern aus Sicht ihrer Objekte. Ein Objekt kann ein Gebäude, eine Wohnung, ein Fahrzeug, eine Maschine, ein Produkt, ein Vertrag oder jede andere reale oder digitale Einheit sein. Jedes Objekt besitzt eine Identität, Beziehungen, Ereignisse, Dokumente, Wissen und einen Lebenszyklus.

1.4 Leitsatz

„Jedes Objekt erzählt eine Geschichte. ORLENE bewahrt diese Geschichte, verbindet sie mit Wissen und macht sie jederzeit verständlich.“

1.5 Definition von ORLENE

ORLENE ist eine objektzentrierte Unternehmens-Wissensplattform zur digitalen Abbildung realer und digitaler Objekte, ihrer Beziehungen, ihrer Ereignisse und ihres gesamten Lebenszyklus.

1.6 Der digitale Wissensraum

Jedes Objekt besitzt seinen eigenen digitalen Wissensraum. Dieser umfasst den aktuellen Zustand, die vollständige Historie, alle Dokumente, Beziehungen, Aufgaben, beteiligte Personen sowie die Möglichkeit, mittels ORLENE Ask natürlichsprachlich auf dieses Wissen zuzugreifen. Das ursprüngliche Konzept des »Virtuellen Hauses« entwickelt sich dadurch zu einem universellen Prinzip für beliebige Objekte.

7.1 Wissensobjekte

Die objektzentrierte Architektur von ORLENE beschränkt sich nicht auf reale oder geschäftliche Objekte.

7.1 Wissensobjekte

Auch Wissen selbst wird objektorientiert beschrieben.

7.1 Wissensobjekte

Dadurch behandelt ORLENE nicht nur Gebäude, Fahrzeuge, Verträge oder Produkte als Objekte, sondern ebenso die Entstehung, Entwicklung und Nutzung von Wissen.

7.1 Wissensobjekte

Wissensobjekte besitzen – genau wie Geschäftsobjekte – eine Identität, Beziehungen, Ereignisse, einen Lebenszyklus und nachvollziehbare Veränderungen.

7.1 Wissensobjekte

Dadurch bleibt Wissen langfristig nachvollziehbar, versionierbar und mit seinem ursprünglichen Kontext verbunden.

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

ORLENE unterscheidet zwei grundlegende Objektarten.

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Geschäftsobjekte

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

beschreiben reale oder digitale Unternehmensobjekte.

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Beispiele:

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Gebäude

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Wohnung

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Artikel

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Fahrzeug

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Vertrag

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Maschine

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Werkzeug

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Kunde

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Lieferant

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Diese Objekte stehen im Mittelpunkt der eigentlichen Geschäftsprozesse.

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Wissensobjekte

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

beschreiben die Entstehung, Entwicklung und Nutzung von Wissen.

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Beispiele:

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Dialog

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Wissenskandidat

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Wissenselement

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Wissensgesetz

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Erfahrung

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Diese Objekte beschreiben nicht die Unternehmenswelt selbst.

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

Sie beschreiben,

7.2 Unterschied zwischen Geschäftsobjekten und Wissensobjekten

wie Wissen über diese Welt entsteht.

7.3 Architekturprinzip

Geschäftsobjekte und Wissensobjekte folgen denselben objektorientierten Grundregeln.

7.3 Architekturprinzip

Jedes Objekt besitzt:

7.3 Architekturprinzip

eine eindeutige Identität

7.3 Architekturprinzip

einen Typ

7.3 Architekturprinzip

Eigenschaften

7.3 Architekturprinzip

Beziehungen

7.3 Architekturprinzip

Ereignisse

7.3 Architekturprinzip

einen Lebenszyklus

7.3 Architekturprinzip

Berechtigungen

7.3 Architekturprinzip

Versionen

7.3 Architekturprinzip

Historie

7.3 Architekturprinzip

nachvollziehbare Herkunft

7.3 Architekturprinzip

Dadurch kann ORLENE Wissen genauso strukturiert verwalten wie reale Unternehmensobjekte.

7.4 Beziehung zwischen Objektwelten

Geschäftsobjekte und Wissensobjekte existieren nicht unabhängig voneinander.

7.4 Beziehung zwischen Objektwelten

Ein Wissensobjekt besitzt in der Regel einen Bezug zu einem oder mehreren Geschäftsobjekten.

7.4 Beziehung zwischen Objektwelten

Beispiele:

7.4 Beziehung zwischen Objektwelten

Ein Dialog bezieht sich auf ein Projekt.

7.4 Beziehung zwischen Objektwelten

Ein Wissenskandidat bezieht sich auf ein Dokument.

7.4 Beziehung zwischen Objektwelten

Ein Wissensgesetz bezieht sich auf einen Prozess.

7.4 Beziehung zwischen Objektwelten

Eine Erfahrung bezieht sich auf einen bestätigten Wissenspfad.

7.4 Beziehung zwischen Objektwelten

Dadurch entsteht ein zusammenhängender Wissensraum, in dem Geschäftsobjekte und Wissensobjekte miteinander verbunden werden können.

7.6 Ausblick

Die folgenden Kapitel beschreiben, wie diese Wissensobjekte innerhalb der Wissensarchitektur verarbeitet werden.

7.6 Ausblick

Dialog Engine

7.6 Ausblick

begleitet ihre Entstehung.

7.6 Ausblick

Memory Engine

7.6 Ausblick

bewahrt ihren ursprünglichen Zusammenhang.

7.6 Ausblick

Knowledge Engine

7.6 Ausblick

stellt bestätigte Wissensobjekte bereit.

7.6 Ausblick

Experience Engine

7.6 Ausblick

entwickelt daraus wiederverwendbare Erfahrung.

7.6 Ausblick

Dadurch entsteht ein durchgängiger objektorientierter Wissensprozess.

TEIL II – WISSENSARCHITEKTUR

Die folgenden Kapitel beschreiben die Wissensarchitektur von ORLENE.

TEIL II – WISSENSARCHITEKTUR

Während die vorherigen Kapitel den technischen Core, Objekte, Beziehungen und Ereignisse definieren, beschreiben die folgenden Komponenten, wie ORLENE Dialoge begleitet, Informationen bewahrt, Wissen strukturiert und daraus wiederverwendbare Erfahrung entwickelt.

TEIL II – WISSENSARCHITEKTUR

Diese Trennung gehört zu den grundlegenden Architekturprinzipien von ORLENE.

10.1 Ziel der Dialog Engine

Die Dialog Engine ist die zentrale Schnittstelle zwischen Mensch und ORLENE.

10.1 Ziel der Dialog Engine

Ihr Ziel besteht nicht darin, beliebige Gespräche zu führen oder Fragen möglichst schnell zu beantworten.

10.1 Ziel der Dialog Engine

Ihre Aufgabe besteht darin, strukturierte Dialoge zu begleiten, Informationen im richtigen Zusammenhang entstehen zu lassen und daraus nachvollziehbare Wissenskandidaten zu erzeugen.

10.1 Ziel der Dialog Engine

Die Dialog Engine ist damit der erste aktive Bestandteil der Wissensarchitektur.

10.1 Ziel der Dialog Engine

Jeder spätere Wissenspfad beginnt mit einem Dialog.

10.2 Grundprinzip

Die Dialog Engine führt keine Selbstgespräche.

10.2 Grundprinzip

Jeder Dialog besitzt:

10.2 Grundprinzip

einen Ursprung

10.2 Grundprinzip

einen Teilnehmer

10.2 Grundprinzip

einen Kontext

10.2 Grundprinzip

einen Zweck

10.2 Grundprinzip

einen Verantwortlichen

10.2 Grundprinzip

einen nachvollziehbaren Verlauf

10.2 Grundprinzip

Die Dialog Engine erzeugt selbst kein Wissen.

10.2 Grundprinzip

Sie begleitet den Entstehungsprozess.

10.2 Grundprinzip

Sie stellt Fragen.

10.2 Grundprinzip

Sie erkennt Zusammenhänge.

10.2 Grundprinzip

Sie fasst Ergebnisse zusammen.

10.2 Grundprinzip

Sie schlägt mögliche Wissenskandidaten vor.

10.2 Grundprinzip

Die Entscheidung darüber bleibt immer beim Menschen.

10.3 Der Dialog als ORLENE-Objekt

Ein Dialog ist in ORLENE nicht nur eine Folge von Nachrichten.

10.3 Der Dialog als ORLENE-Objekt

Ein Dialog ist ein eigenständiges, eindeutig identifizierbares Objekt innerhalb der ORLENE-Architektur.

10.3 Der Dialog als ORLENE-Objekt

Definition:

10.3 Der Dialog als ORLENE-Objekt

Ein Dialog ist ein zeitlich und sachlich abgegrenzter Wissensprozess zwischen einem oder mehreren Menschen und ORLENE.

10.3 Der Dialog als ORLENE-Objekt

Er besitzt einen definierten Ursprung, einen Zweck, einen Kontext, beteiligte Personen, einen nachvollziehbaren Verlauf sowie mögliche Ergebnisse.

10.3 Der Dialog als ORLENE-Objekt

Als ORLENE-Objekt kann ein Dialog:

10.3 Der Dialog als ORLENE-Objekt

eindeutig identifiziert werden,

10.3 Der Dialog als ORLENE-Objekt

mit Personen, Dokumenten, Projekten und anderen Objekten verbunden werden,

10.3 Der Dialog als ORLENE-Objekt

Ereignisse erzeugen,

10.3 Der Dialog als ORLENE-Objekt

einen Status besitzen,

10.3 Der Dialog als ORLENE-Objekt

versioniert werden,

10.3 Der Dialog als ORLENE-Objekt

archiviert werden,

10.3 Der Dialog als ORLENE-Objekt

Wissenskandidaten hervorbringen,

10.3 Der Dialog als ORLENE-Objekt

später nachvollzogen und erneut aufgerufen werden.

10.3 Der Dialog als ORLENE-Objekt

Ein Dialogobjekt ersetzt nicht den ursprünglichen Dialogverlauf.

10.3 Der Dialog als ORLENE-Objekt

Es verbindet den Verlauf mit Metadaten, Beziehungen, Ereignissen und Ergebnissen.

10.4 Technisches Grundmodell eines Dialogobjekts

Ein Dialogobjekt kann mindestens folgende Eigenschaften besitzen:

10.4 Technisches Grundmodell eines Dialogobjekts

dialog_id

10.4 Technisches Grundmodell eines Dialogobjekts

Eindeutige Identität des Dialogs.

10.4 Technisches Grundmodell eines Dialogobjekts

dialog_type

10.4 Technisches Grundmodell eines Dialogobjekts

Art des Dialogs, beispielsweise Reviewdialog, Wissensdialog oder Entwicklungsdialog.

10.4 Technisches Grundmodell eines Dialogobjekts

title

10.4 Technisches Grundmodell eines Dialogobjekts

Kurze verständliche Bezeichnung.

10.4 Technisches Grundmodell eines Dialogobjekts

purpose

10.4 Technisches Grundmodell eines Dialogobjekts

Definierter Zweck des Dialogs.

10.4 Technisches Grundmodell eines Dialogobjekts

owner

10.4 Technisches Grundmodell eines Dialogobjekts

Verantwortliche Person oder Rolle.

10.4 Technisches Grundmodell eines Dialogobjekts

participants

10.4 Technisches Grundmodell eines Dialogobjekts

Beteiligte Personen, Rollen oder Systeme.

10.4 Technisches Grundmodell eines Dialogobjekts

context_oid

10.4 Technisches Grundmodell eines Dialogobjekts

Verknüpfung mit dem primären Objekt oder Wissensraum.

10.4 Technisches Grundmodell eines Dialogobjekts

related_oids

10.4 Technisches Grundmodell eines Dialogobjekts

Weitere verbundene ORLENE-Objekte.

10.4 Technisches Grundmodell eines Dialogobjekts

started_at

10.4 Technisches Grundmodell eines Dialogobjekts

Zeitpunkt des Beginns.

10.4 Technisches Grundmodell eines Dialogobjekts

ended_at

10.4 Technisches Grundmodell eines Dialogobjekts

Zeitpunkt des Abschlusses.

10.4 Technisches Grundmodell eines Dialogobjekts

status

10.4 Technisches Grundmodell eines Dialogobjekts

Beispielsweise vorbereitet, aktiv, pausiert, abgeschlossen oder archiviert.

10.4 Technisches Grundmodell eines Dialogobjekts

source

10.4 Technisches Grundmodell eines Dialogobjekts

Ursprung des Dialogs, beispielsweise Workspace, mobile Eingabe, Dokumentreview oder importierter Chat.

10.4 Technisches Grundmodell eines Dialogobjekts

visibility_scope

10.4 Technisches Grundmodell eines Dialogobjekts

Festgelegte Sichtbarkeit und Berechtigung.

10.4 Technisches Grundmodell eines Dialogobjekts

summary

10.4 Technisches Grundmodell eines Dialogobjekts

Nachvollziehbare Zusammenfassung.

10.4 Technisches Grundmodell eines Dialogobjekts

outcome

10.4 Technisches Grundmodell eines Dialogobjekts

Ergebnis oder aktueller Stand des Dialogs.

10.4 Technisches Grundmodell eines Dialogobjekts

memory_reference

10.4 Technisches Grundmodell eines Dialogobjekts

Referenz auf die durch die Memory Engine bewahrten Inhalte.

10.4 Technisches Grundmodell eines Dialogobjekts

created_by

10.4 Technisches Grundmodell eines Dialogobjekts

Person oder System, das den Dialog angelegt hat.

10.4 Technisches Grundmodell eines Dialogobjekts

version

10.4 Technisches Grundmodell eines Dialogobjekts

Version des Dialogobjekts.

10.4 Technisches Grundmodell eines Dialogobjekts

Dieses Modell ist zunächst konzeptionell.

10.4 Technisches Grundmodell eines Dialogobjekts

Die genaue technische Umsetzung wird in späteren Architekturversionen festgelegt.

10.5 Dialogobjekt und Dialogverlauf

Das Dialogobjekt und der Dialogverlauf sind voneinander zu unterscheiden.

10.5 Dialogobjekt und Dialogverlauf

Der Dialogverlauf enthält die tatsächlichen Beiträge, Fragen, Antworten und Zwischenschritte.

10.5 Dialogobjekt und Dialogverlauf

Das Dialogobjekt beschreibt den übergeordneten Zusammenhang.

10.5 Dialogobjekt und Dialogverlauf

Der Dialogverlauf ist damit eine Quelle.

10.5 Dialogobjekt und Dialogverlauf

Das Dialogobjekt ist die strukturierte Repräsentation des gesamten Dialogprozesses.

10.5 Dialogobjekt und Dialogverlauf

Diese Trennung ermöglicht:

10.5 Dialogobjekt und Dialogverlauf

Schutz privater Originalinhalte,

10.5 Dialogobjekt und Dialogverlauf

rollenabhängige Sichtbarkeit,

10.5 Dialogobjekt und Dialogverlauf

strukturierte Suche,

10.5 Dialogobjekt und Dialogverlauf

nachvollziehbare Zusammenfassungen,

10.5 Dialogobjekt und Dialogverlauf

Verknüpfung mit anderen Objekten,

10.5 Dialogobjekt und Dialogverlauf

spätere Wiederverwendung von Erkenntnissen,

10.5 Dialogobjekt und Dialogverlauf

getrennte Aufbewahrungs- und Löschregeln.

10.5 Dialogobjekt und Dialogverlauf

Ein Benutzer kann daher Zugriff auf das Dialogobjekt oder eine freigegebene Zusammenfassung besitzen, ohne automatisch den vollständigen ursprünglichen Dialogverlauf lesen zu dürfen.

10.6 Dialogarten

Die Dialog Engine unterscheidet unterschiedliche Dialogtypen.

10.6 Dialogarten

Zum Beispiel:

10.6 Dialogarten

Wissensdialog

10.6 Dialogarten

Reviewdialog

10.6 Dialogarten

Interviewdialog

10.6 Dialogarten

Entwicklungsdialog

10.6 Dialogarten

Strategiedialog

10.6 Dialogarten

Entscheidungsdialog

10.6 Dialogarten

Schulungsdialog

10.6 Dialogarten

Projektdialog

10.6 Dialogarten

Dokumentendialog

10.6 Dialogarten

Supportdialog

10.6 Dialogarten

Neue Dialogtypen können später ergänzt werden, ohne die Architektur verändern zu müssen.

10.7 Architektur eines Dialogs

Ein ORLENE-Dialog besteht nicht aus einer einfachen Frage-Antwort-Struktur.

10.7 Architektur eines Dialogs

Er durchläuft mehrere logisch getrennte Phasen.

10.7 Architektur eines Dialogs

Beispiel:

10.7 Architektur eines Dialogs

Kontext ↓ Fragestellung ↓ Rückfragen ↓ Antworten ↓ Zusammenfassung ↓ Wissenskandidaten ↓ Übergabe an Memory Engine

10.7 Architektur eines Dialogs

Dadurch entsteht aus einem Gespräch eine nachvollziehbare Entwicklung und keine lose Sammlung einzelner Nachrichten.

10.8 Aufgaben der Dialog Engine

Die Dialog Engine besitzt unter anderem folgende Aufgaben:

10.8 Aufgaben der Dialog Engine

Gespräche strukturieren

10.8 Aufgaben der Dialog Engine

Kontext erkennen

10.8 Aufgaben der Dialog Engine

Rückfragen stellen

10.8 Aufgaben der Dialog Engine

Informationen ordnen

10.8 Aufgaben der Dialog Engine

Zusammenfassungen erzeugen

10.8 Aufgaben der Dialog Engine

offene Fragen erkennen

10.8 Aufgaben der Dialog Engine

Entscheidungen dokumentieren

10.8 Aufgaben der Dialog Engine

Widersprüche erkennen

10.8 Aufgaben der Dialog Engine

Wissenskandidaten identifizieren

10.8 Aufgaben der Dialog Engine

Übergabe an die Memory Engine vorbereiten

10.8 Aufgaben der Dialog Engine

Sie bestätigt jedoch niemals selbst Wissen.

10.9 Verantwortung

Die Dialog Engine

10.9 Verantwortung

entscheidet nicht.

10.9 Verantwortung

Sie bewertet Menschen nicht.

10.9 Verantwortung

Sie ersetzt keine Verantwortung.

10.9 Verantwortung

Sie bestätigt keine Wissensgesetze.

10.9 Verantwortung

Sie löscht keine Quellen.

10.9 Verantwortung

Sie dokumentiert den Weg bis zu einer möglichen Entscheidung.

10.10 Übergabe an die Memory Engine

Am Ende eines Dialogs erzeugt die Dialog Engine keine endgültigen Ergebnisse.

10.10 Übergabe an die Memory Engine

Sie übergibt strukturierte Informationen an die Memory Engine.

10.10 Übergabe an die Memory Engine

Beispiele:

10.10 Übergabe an die Memory Engine

Dialogverlauf

10.10 Übergabe an die Memory Engine

Zusammenfassung

10.10 Übergabe an die Memory Engine

Wissenskandidaten

10.10 Übergabe an die Memory Engine

offene Fragen

10.10 Übergabe an die Memory Engine

Entscheidungen

10.10 Übergabe an die Memory Engine

Aufgaben

10.10 Übergabe an die Memory Engine

Quellen

10.10 Übergabe an die Memory Engine

Verweise

10.10 Übergabe an die Memory Engine

Erst dort beginnt die dauerhafte Speicherung.

10.13 Offene Architekturfragen

Wie werden Dialogtypen technisch modelliert?

10.13 Offene Architekturfragen

Welche Metadaten besitzt jeder Dialog?

10.13 Offene Architekturfragen

Wie werden parallele Dialoge verwaltet?

10.13 Offene Architekturfragen

Wie wird Sprachdialog integriert?

10.13 Offene Architekturfragen

Wie wird Mehrsprachigkeit unterstützt?

10.13 Offene Architekturfragen

Wie werden externe Teilnehmer eingebunden?

10.13 Offene Architekturfragen

Wann endet ein Dialog?

10.13 Offene Architekturfragen

Wie werden Dialoge versioniert?

10.13 Offene Architekturfragen

Wie werden Dialoge archiviert?

10.13 Offene Architekturfragen

Ist ein Dialogobjekt ein spezieller Objekttyp innerhalb der Object Engine oder ein eigener Wissensobjekttyp?

10.13 Offene Architekturfragen

Wie werden Dialogverlauf und Dialogobjekt technisch getrennt gespeichert?

10.13 Offene Architekturfragen

Welche Teile eines Dialogobjekts dürfen sichtbar sein, wenn der Originaldialog privat bleibt?

10.13 Offene Architekturfragen

Wie werden Dialogobjekte mit OIDs, Wissenskandidaten, Entscheidungen und Aufgaben verknüpft?

10.13 Offene Architekturfragen

Welche Aufbewahrungs- und Löschregeln gelten für Dialogobjekte und Originalverläufe?

10.13 Offene Architekturfragen

Diese Fragen bleiben bewusst offen und sollen in späteren Architekturversionen beantwortet werden.

11. Memory Engine

Status: Platzhalter für Version 0.2 Untertitel: Wird in der nächsten Überarbeitung ergänzt.

13. Experience Engine

Status: Platzhalter für Version 0.2 Untertitel: Wird in der nächsten Überarbeitung ergänzt.

Tabelle

Architekturregel ORLENE denkt in Objekten. Diese Regel gilt gleichermaßen für reale Unternehmensobjekte und für die Entstehung von Wissen. Ein Dialog ist ein Objekt. Ein Wissenskandidat ist ein Objekt. Ein Wissenselement ist ein Objekt. Ein Wissensgesetz ist ein Objekt. Eine Erfahrung ist ein Objekt. Dadurch bleibt die objektzentrierte Architektur von ORLENE über alle Ebenen hinweg konsistent.

Tabelle

Architekturregel ORLENE führt keine Chats. ORLENE begleitet Dialoge. Ein Dialog besitzt immer einen Zweck. Der Zweck bestimmt den Kontext. Der Kontext bestimmt die Bedeutung. Die Bedeutung bestimmt den möglichen Wissenswert.

Tabelle

Übergeordnete Architekturregel ORLENE denkt in Objekten und handelt als stiller Begleiter des Menschen. Objektzentrierung beschreibt, wie ORLENE Informationen, Beziehungen, Ereignisse und Wissen architektonisch ordnet. Der stille Begleiter beschreibt, wie ORLENE dem Menschen gegenüber handelt. ORLENE darf strukturieren, erinnern, verbinden, erklären und Vorschläge machen. ORLENE darf den Menschen jedoch nicht unnötig verdrängen, bevormunden oder seine Verantwortung übernehmen. Jede neue Funktion muss deshalb zwei Fragen beantworten: 1. Ist sie objektzentriert aufgebaut? 2. Begleitet sie den Menschen, statt ihn zu ersetzen? Nur wenn beide Bedingungen erfüllt sind, entspricht sie der ORLENE-Architektur.

Tabelle

Mensch ↓ ORLENE Workspace ↓ Dialog Engine ↓ Memory Engine ↓ Knowledge Engine ↓ Experience Engine ↓ ORLENE Ask

Kapitel 5 von 8

Kapitel 19 – Referenzarchitekturen

ORLENE 3.0

Kapitel 19 – Referenzarchitekturen

A. Die Idee

B. Die Architektur

C. Technische Umsetzung

D. Praxisbeispiele

E. Zukunft

F. Notizen des Erfinders

Kapitel 19 – Referenzarchitekturen

Software Architecture Specification (SAS) Arbeitsentwurf 0.1

A. Die Idee

Beispielhafte Gesamtlösungen für verschiedene Branchen.

B. Die Architektur

Handel

B. Die Architektur

Hausverwaltung

B. Die Architektur

Fahrzeughandel

B. Die Architektur

Industrie

C. Technische Umsetzung

Wird in Version 1.0 der Architektur detailliert beschrieben.

D. Praxisbeispiele

Zeigt den praktischen Einsatz.

E. Zukunft

Dieses Kapitel wird in der nächsten Ausbaustufe um Diagramme, Datenmodelle und Beispiele erweitert.

F. Notizen des Erfinders

Architektur wird greifbar.

Kapitel 6 von 8

Kapitel 2 – Die objektzentrierte Architektur

ORLENE 3.0

Kapitel 2 – Die objektzentrierte Architektur

2.1 Paradigmenwechsel

2.2 Was ist ein Objekt?

2.3 Das Objekt als Mittelpunkt

2.4 Das digitale Abbild

2.5 Der digitale Wissensraum

2.6 Beziehungen

2.7 Vergleich

2.8 Die Vision

Schlüsseldefinition

Kapitel 2 – Die objektzentrierte Architektur

Software Architecture Specification (SAS) Arbeitsentwurf 0.1

2.1 Paradigmenwechsel

Die meisten Unternehmensprogramme sind funktionsorientiert aufgebaut. ORLENE verfolgt einen anderen Ansatz: Nicht Programme, Funktionen oder Branchen stehen im Mittelpunkt, sondern ausschließlich das Objekt. Alle Informationen werden objektzentriert organisiert.

2.2 Was ist ein Objekt?

Ein Objekt ist jede eindeutig identifizierbare reale oder digitale Einheit.

2.2 Was ist ein Objekt?

Gebäude

2.2 Was ist ein Objekt?

Wohnung

2.2 Was ist ein Objekt?

Fahrzeug

2.2 Was ist ein Objekt?

Maschine

2.2 Was ist ein Objekt?

Produkt

2.2 Was ist ein Objekt?

Werkzeug

2.2 Was ist ein Objekt?

Vertrag

2.2 Was ist ein Objekt?

Rechnung

2.2 Was ist ein Objekt?

Dokument

2.2 Was ist ein Objekt?

Projekt

2.2 Was ist ein Objekt?

Kunde

2.2 Was ist ein Objekt?

Lieferant

2.2 Was ist ein Objekt?

Mitarbeiter

2.3 Das Objekt als Mittelpunkt

In klassischen Softwaresystemen stehen Funktionen im Vordergrund. In ORLENE bildet das Objekt den Mittelpunkt. Eigenschaften, Dokumente, Ereignisse, Beziehungen und Wissen beziehen sich stets auf dieses Objekt.

2.4 Das digitale Abbild

Eigenschaften

2.4 Das digitale Abbild

Beziehungen

2.4 Das digitale Abbild

Ereignisse

2.4 Das digitale Abbild

Dokumente

2.4 Das digitale Abbild

Bilder

2.4 Das digitale Abbild

Historie

2.4 Das digitale Abbild

Wissen

2.4 Das digitale Abbild

KI-Auswertungen

2.4 Das digitale Abbild

Aufgaben

2.4 Das digitale Abbild

Workflows

2.5 Der digitale Wissensraum

Jedes Objekt besitzt einen eigenen digitalen Wissensraum. Dieser umfasst sämtliche Informationen, die während des gesamten Lebenszyklus eines Objekts entstehen. Alle Daten werden zentral am Objekt organisiert und stehen allen berechtigten Beteiligten zur Verfügung.

2.6 Beziehungen

Objekte existieren niemals isoliert. Sie sind über Beziehungen miteinander verbunden. Dadurch entsteht ein Wissensnetzwerk, das Zusammenhänge sichtbar macht und von der KI ausgewertet werden kann.

2.7 Vergleich

Klassische Software

2.7 Vergleich

Daten verteilt

2.7 Vergleich

Programme getrennt

2.7 Vergleich

Mehrfache Datenspeicherung

2.7 Vergleich

Unvollständige Historie

2.7 Vergleich

Wissen in einzelnen Systemen

2.7 Vergleich

ORLENE

2.7 Vergleich

Objektzentriert

2.7 Vergleich

Eine Identität

2.7 Vergleich

Ein Wissensraum

2.7 Vergleich

Eine Historie

2.7 Vergleich

Beziehungen statt Datensilos

2.7 Vergleich

KI versteht Zusammenhänge

2.8 Die Vision

ORLENE bildet keine Programme digital ab. ORLENE bildet die Realität digital ab.

Schlüsseldefinition

Ein digitaler Wissensraum ist die vollständige digitale Repräsentation eines realen oder digitalen Objekts über seinen gesamten Lebenszyklus hinweg. Er umfasst den aktuellen Zustand, die Historie, Beziehungen, Dokumente, Ereignisse, Wissen und KI-gestützte Auswertungen.

Kapitel 7 von 8

ORLENE Space Interaction Model 1.0

Grundlegendes Architekturmodell der Interaktionsgesetze, Aufmerksamkeit und Mensch-Wissen-Beziehung im ORLENE Space.

Ziel des Dokuments

Dieses Dokument definiert nicht die grafische Oberfläche von ORLENE. Es definiert die grundlegenden Interaktionsgesetze des ORLENE Space.

Ziel des Dokuments

Der Space soll sich nicht an klassischen Softwareoberflächen orientieren, sondern am natürlichen Denken und an der Aufmerksamkeit des Menschen. Dieses Dokument besitzt grundlegenden Architekturstatus. Alle zukünftigen Workspace-, Knowledge- und Retail-Oberflächen sollen sich an diesen Prinzipien orientieren.

Einleitung

ORLENE ist kein klassisches Programm.

Einleitung

ORLENE ist ein Raum.

Einleitung

Menschen betreten diesen Raum. Sie bewegen sich nicht durch Menüs. Sie folgen ihrer Aufmerksamkeit.

Einleitung

Der ORLENE Space passt sich dem Menschen an. Nicht der Mensch dem Space.

Einleitung

Die folgenden Prinzipien wurden aus der Beobachtung menschlichen Denkens entwickelt. Sie bilden die Grundlage sämtlicher zukünftiger Oberflächen.

1. Grundprinzip

Der ORLENE Space orientiert sich nicht an Dateien oder Funktionen. Er orientiert sich an der Beziehung zwischen Mensch und Wissen.

1. Grundprinzip

Dateien, Dokumente und Funktionen bleiben notwendige technische Strukturen. Für die Interaktion stehen jedoch nicht diese Strukturen im Vordergrund, sondern die Bedeutung, die ein Inhalt für einen Menschen im jeweiligen Moment besitzt.

2. Bedeutung

Bedeutung entsteht ausschließlich im Menschen.

2. Bedeutung

Nicht ORLENE entscheidet, was wichtig ist. Der Mensch verleiht einem Gedanken, Dokument oder einer Aufgabe Bedeutung. ORLENE beobachtet diese Bedeutung lediglich anhand des Verhaltens.

2. Bedeutung

Das System darf beobachtete Signale ordnen und Beziehungen sichtbar machen. Es darf daraus jedoch keinen Anspruch auf die innere Bedeutung eines Inhalts ableiten. Bedeutung bleibt eine menschliche Zuschreibung.

3. Aufmerksamkeit

Aufmerksamkeit folgt der Bedeutung.

3. Aufmerksamkeit

Sie ist nicht binär. Sie besitzt Intensität und verändert sich ständig. Aufmerksamkeit verschwindet selten vollständig. Sie wechselt zwischen Vordergrund und Hintergrund.

3. Aufmerksamkeit

Der Space behandelt Aufmerksamkeit deshalb nicht als einfachen Zustand wie „aktiv“ oder „inaktiv“. Er versteht sie als zeitlichen Verlauf, dessen Richtung und Intensität sich aus wiederholten Begegnungen entwickeln.

Gesetz 1: Aufmerksamkeit ist fließend

Aufmerksamkeit bewegt sich. Sie kann wachsen, nachlassen, ruhen und später erneut entstehen. Der Space muss diese Bewegung ermöglichen, ohne sie in starre Zustände zu zwingen.

Gesetz 2: Der Mensch entscheidet über seine Aufmerksamkeit

ORLENE folgt dieser Entscheidung. Das System kann Angebote machen und Zusammenhänge sichtbar halten, aber die Richtung der Aufmerksamkeit bleibt beim Menschen.

Gesetz 3: ORLENE konkurriert niemals um Aufmerksamkeit

ORLENE wartet. Es drängt sich nicht auf. Hinweise bleiben ruhig, nachvollziehbar und verhältnismäßig. Das System erzeugt keinen künstlichen Handlungsdruck.

Gesetz 4: Gedanken bleiben bestehen

Gedanken verschwinden nicht. Sie wechseln lediglich zwischen Vordergrund und Hintergrund. Was im Moment nicht betrachtet wird, bleibt als Teil des Wissensraums erhalten und kann wieder hervortreten.

Gesetz 5: Entscheidend ist die Entwicklung der Beziehung

ORLENE orientiert sich an der Entwicklung der Beziehung zwischen Mensch und Inhalt, nicht an einzelnen Klicks. Ein isoliertes Ereignis ist ein Signal, aber noch kein belastbares Muster.

Begegnung

Ein Mensch nimmt einen Inhalt erstmals wahr. Die Begegnung erzeugt noch keine Aussage über seine langfristige Bedeutung. Sie eröffnet lediglich die Möglichkeit einer Beziehung.

Begegnung

↓

Neugier

Ein Aspekt des Inhalts löst kurzfristige Aufmerksamkeit aus. Der Mensch betrachtet, öffnet oder untersucht ihn. Neugier ist ein erster Impuls, aber noch keine stabile Bindung.

Neugier

↓

Rückkehr

Der Mensch kehrt aus eigener Entscheidung zu einem Thema zurück. Diese Wiederkehr unterscheidet eine flüchtige Begegnung von einer beginnenden Beziehung.

Rückkehr

> **Erst die Rückkehr zu einem Thema zeigt, dass mehr als flüchtiges Interesse entstanden ist.**

Rückkehr

↓

Aufmerksamkeit

Durch wiederholte Rückkehr gewinnt das Thema an Präsenz. Es tritt deutlicher in den Vordergrund, ohne andere Gedanken vollständig zu verdrängen.

Aufmerksamkeit

↓

Vertiefung

Der Mensch investiert Zeit, stellt Verbindungen her und prüft Zusammenhänge. Aus Aufmerksamkeit wird eine bewusste Auseinandersetzung mit dem Inhalt.

Vertiefung

↓

Bedeutung

Der Inhalt erhält einen erkennbaren Platz im Denken oder Handeln des Menschen. Diese Bedeutung wird nicht durch ORLENE vergeben. Sie entsteht aus der menschlichen Beziehung zum Inhalt.

Bedeutung

↓

Erfahrung

Aus angewandter oder reflektierter Bedeutung entsteht Erfahrung. Sie verbindet Inhalt, Situation, Handlung und Wirkung und kann später als Orientierung in den Wissensraum zurückkehren.

Erfahrung

ORLENE bewertet deshalb nicht einzelne Klicks. ORLENE erkennt Muster menschlicher Aufmerksamkeit. Ein Muster ist nur dann belastbar, wenn es sich über Zeit, Rückkehr und Vertiefung entwickelt.

6. Konsequenzen für zukünftige Oberflächen

Der ORLENE Space besitzt keine klassische Startseite. Er besitzt einen Raum.

6. Konsequenzen für zukünftige Oberflächen

Der Benutzer bewegt sich nicht zwischen Menüs. Der Raum verändert sich entsprechend der Aufmerksamkeit des Menschen.

6. Konsequenzen für zukünftige Oberflächen

Dokumente verschwinden nicht. Sie treten lediglich in den Hintergrund. Zusammengehörige Themen nähern sich langsam an – nicht aufgrund starrer Oberflächenregeln, sondern aufgrund beobachteter Aufmerksamkeit.

6. Konsequenzen für zukünftige Oberflächen

Daraus folgen verbindliche Gestaltungsrichtungen:

6. Konsequenzen für zukünftige Oberflächen

- Vordergrund und Hintergrund ersetzen das Prinzip von sichtbar und verschwunden. - Wiederkehr wiegt stärker als ein einzelner Zugriff. - Beziehungen entwickeln sich graduell und bleiben nachvollziehbar. - Hinweise unterstützen Aufmerksamkeit, ohne mit ihr zu konkurrieren. - Der Mensch kann die vom System beobachtete Entwicklung jederzeit übersteuern. - Die Oberfläche erklärt, warum Inhalte näher, ferner oder erneut sichtbar werden.

7. Ausblick

Dieses Dokument definiert ausschließlich die Interaktionsphysik des ORLENE Space. Es beschreibt bewusst weder Farben noch konkrete Layouts.

7. Ausblick

Diese entstehen später aus den hier beschriebenen Gesetzen. Jede zukünftige visuelle oder funktionale Entscheidung muss sich daran messen lassen, ob sie menschlicher Aufmerksamkeit folgt, Bedeutung beim Menschen belässt und eine ruhige, nachvollziehbare Beziehung zwischen Mensch und Wissen ermöglicht.

7. Ausblick

*ORLENE schafft keinen Wettbewerb um Aufmerksamkeit. ORLENE schafft einen Raum, in dem Aufmerksamkeit ihrer Bedeutung folgen kann.*

Kapitel 8 von 8

Erster ORLENE Platform Server – Infrastruktur-Meilenstein

Am 27.07.2026 wurde mit „orlene-platform-01“ der erste dedizierte Server der ORLENE Platform eingerichtet. Dieser Schritt schafft die zentrale Grundlage für geräteunabhängige Entwicklung, Dokumentation, Releases, Downloads und spätere Updateprozesse.

Infrastruktur-Meilenstein vom 27.07.2026

Am 27.07.2026 wurde der erste dedizierte Server für die ORLENE Platform eingerichtet.

Infrastruktur-Meilenstein vom 27.07.2026

Damit erhält ORLENE erstmals eine eigene zentrale Infrastruktur außerhalb eines einzelnen lokalen Entwicklungsgeräts.

Technische Einordnung

Servername:

Technische Einordnung

orlene-platform-01

Technische Einordnung

Anbieter:

Technische Einordnung

Hetzner

Technische Einordnung

Standort:

Technische Einordnung

Nürnberg

Technische Einordnung

Servertyp:

Technische Einordnung

CPX22

Technische Einordnung

Architektur:

Technische Einordnung

x86 / AMD

Technische Einordnung

Betriebssystem:

Technische Einordnung

Ubuntu 26.04 LTS

Technische Einordnung

Ausstattung:

Technische Einordnung

- 2 vCPU - 4 GB RAM - 80 GB SSD - IPv4 und IPv6 - SSH-Key-Zugriff - aktivierte Server-Backups

Zweck

Der Server ist als erste Infrastrukturinstanz der ORLENE Platform vorgesehen.

Zweck

Er soll schrittweise folgende Aufgaben übernehmen:

Zweck

- zentrale Entwicklungsumgebung, - ORLENE Documentation Space, - Release-Ablage, - Downloadbereich für Installationspakete, - spätere Updateverwaltung, - spätere Fehlerberichte, - technische Platform-Verwaltung.

Abgrenzung

Der Server ist nicht als gemeinsame operative Produktivdatenbank der Peter-Wagner-Standorte vorgesehen.

Abgrenzung

Die drei ORLENE-Footwear-Installationen bleiben eigenständig:

Abgrenzung

- PW-WIEN - PW-ASTEN - PW-MESSE-01

Abgrenzung

Sie besitzen eigene lokale Daten, eigene Installationsprofile und bleiben entsprechend ihres Einsatzzwecks offlinefähig.

Architektonische Bedeutung

Bisher war die ORLENE-Entwicklung wesentlich an lokale Geräte und insbesondere an die bestehende Notebook-Installation gebunden.

Architektonische Bedeutung

Mit dem ersten Platform-Server entsteht eine zentrale Infrastruktur, über die ORLENE künftig:

Architektonische Bedeutung

- von mehreren freigegebenen Geräten entwickelt werden kann, - Releases kontrolliert veröffentlichen kann, - Installationspakete bereitstellen kann, - Dokumentation und Entwicklungswissen zentral bewahren kann, - Produktivinstallationen klar von der Entwicklung trennen kann.

Bedeutung für ORLENE Footwear

Für ORLENE Footwear bildet der Server die zukünftige Quelle für:

Bedeutung für ORLENE Footwear

- freigegebene Setup-Dateien, - Releaseinformationen, - Updatepakete, - Installationsdokumentationen, - spätere Fehlerberichte.

Bedeutung für ORLENE Footwear

ORLENE Footwear selbst bleibt lokal installierbar und offlinefähig.

Grundsatz

„Wir entwickeln ORLENE bereits mit ORLENE.“

Grundsatz

Der Platform-Server ist die erste technische Infrastruktur, auf der dieser Grundsatz praktisch umgesetzt wird.

Grundsatz

Die ORLENE Platform wird damit selbst zur ersten Referenzanwendung ihrer Architektur-, Wissens-, Dokumentations- und Review-Prinzipien.

Aktueller Status

Der Server wurde erstellt.

Aktueller Status

Die technische Basiseinrichtung ist noch nicht abgeschlossen.

Aktueller Status

Noch ausständig sind insbesondere:

Aktueller Status

- Erstzugriff per SSH, - Systemaktualisierung, - administrativer Benutzer, - SSH-Härtung, - Firewall, - ORLENE-Verzeichnisstruktur, - Downloadbereich, - Releasebereich, - spätere Entwicklungsumgebung.

Nächster Meilenstein

Der nächste Meilenstein ist:

Nächster Meilenstein

„ORLENE Platform – Serverbasiseinrichtung 1.0“

Nächster Meilenstein

Dieser umfasst die sichere Grundkonfiguration des Servers und die Vorbereitung des ersten geschützten Downloadbereichs für ORLENE Footwear.