Regulierte Suche · Private Beta · Open-Source-Veröffentlichung geplant
EGOTHOR v4
Eine neue Generation der Egothor-Suchinfrastruktur für Informationsumgebungen, in denen Relevanz nur die halbe Antwort ist. Suche muss auch Sichtbarkeit, Clearance, Klassifizierung, Integrität, Compartments und Konfliktgrenzen bewahren, bevor ein Ergebnis offengelegt werden darf.
Suche, wenn ein Treffer nicht automatisch offengelegt werden darf
Traditionelle Enterprise-Suche fragt häufig, ob ein Benutzer eine Anwendung betreten darf, und durchsucht anschließend den darin verfügbaren Index. Regulierte Informationssysteme brauchen eine präzisere Frage: Darf dieses Subjekt genau dieses Ergebnis in diesem Kontext erhalten, ohne eine Klassifizierungs-, Compartment- oder Konfliktgrenze zu überschreiten?
EGOTHOR v4 ist um diese Unterscheidung herum entworfen. Identität und MFA stellen fest, wer fragt; Retrieval findet die passenden Inhalte; die Informations-Policy entscheidet, was offengelegt werden darf. Die Disclosure-Grenze bleibt sichtbar, statt erst nach einer uneingeschränkten Suche in einem Präsentationsfilter versteckt zu werden.
- Policy ist kein nachträglicher kosmetischer Filter.
- Resident Retrieval bleibt deterministisch, damit Verhalten testbar und nachvollziehbar ist.
- Disclosure ist Teil der Korrektheit, wenn Informationsklassen und Compartments zählen.
- Security und Retrieval bleiben als getrennte Belange sichtbar.
Ein Suchkernel mit expliziten Invarianten
Die aktuelle Engineering-Arbeit trennt Indexaufbau und Resident Querying. Der Write-Pfad kann Strukturen aufbauen und validieren, während der kritische Read-Pfad über kompakte Repräsentationen mit vorhersehbarer Semantik arbeitet.
Resident Retrieval
Suche arbeitet über eine spezielle leseorientierte Repräsentation, statt Indexmutationen in denselben Hot Path zu mischen.
Deterministisches Top-K
Ranking und Tie-Verhalten sind reproduzierbare Verträge: gleicher Suchzustand plus gleiche Query ergibt eine stabile Ergebnisreihenfolge.
Live-Document-Visibility
Dokumentsichtbarkeit kann sich ändern, ohne dass gelöschte oder ersetzte Records weiter als zulässige Treffer erscheinen müssen.
Streaming Ingest
Indexkonstruktion basiert auf Barrel-Assembly und kontrollierter Publikation statt auf einem monolithischen In-Memory-Build.
API-Grenzen
Ingest, Resident Access und Query-Verträge bleiben getrennt, damit Performance- oder Storage-Änderungen die öffentliche Suchsemantik nicht stillschweigend verändern.
Evidenzorientiertes Engineering
Tests und Benchmarks sind Teil des Kernel-Vertrags, einschließlich der Unterscheidung zwischen Public API und Steady-State-Performance.
Retrieval-Policy ist kein Nachgedanke
Suchkernel und Informationskontrollmodell beantworten unterschiedliche Fragen und benötigen unterschiedliche Evidenz. Der Kernel zeigt, dass Matching und Ranking korrekt arbeiten; die Policy entscheidet, ob ein passender Record dem effektiven Subjekt offengelegt werden darf.
Welche Informationsebene darf das Subjekt empfangen?
Welche Behandlungsklasse gilt für Record oder Collection?
Welche Trust-Bedingungen müssen erfüllt sein, bevor Information nutzbar ist?
Welche Informationsdomänen müssen selbst innerhalb desselben Suchdiensts getrennt bleiben?
Welche Kombinationen dürfen nicht gemeinsam offengelegt werden, obwohl jedes Element einzeln zugänglich wäre?
Wie werden Änderungen an Identität, Administration und Policy sichtbar und auditierbar?
Was die private Beta beweisen soll
Die Beta ist nicht bloß ein UI-Meilenstein. In dieser Phase müssen Suchmechanik und Security-Grenzen als ein Betriebssystem funktionieren: authentifizierter Zugriff, Index-Lifecycle, deterministisches Query-Verhalten, Administration, Live-Visibility und Disclosure-Policy müssen auch unter Veränderung verständlich bleiben.
Das Kernsystem kann Inhalte ingestieren und Queries ausführen.
Identity Assurance ist Teil des Betriebssystems, kein späteres Add-on.
Resident-Strukturen, Suchsemantik, Tests und Performance werden für eine saubere öffentliche Library-Grenze verfeinert.
Autorisierung und Informations-Policy werden als erstklassige Suchsystem-Randbedingungen ausgestaltet.
Der Sourcecode wird veröffentlicht, sobald öffentliche Architektur und Verträge für externe Nutzung bereit sind.
Das nächste Egothor, kein Kompatibilitätsprojekt
Die historischen Egothor-Maschinen untersuchten Java-Volltext-Retrieval, verteilte Suche und dynamische Indexpflege. Version 4 kehrt mit moderner Implementierung zum Suchkern zurück und adressiert ein anderes Security-Problem: hochwertiges Retrieval in Systemen, in denen Informationsgrenzen Teil der Korrektheit sind.