Warum Erweiterbarkeit wichtig ist

Jede Ermittlungsdomäne hat ihre eigenen Datenquellen. Was ein Investigativjournalist im politischen Umfeld nutzt, unterscheidet sich fundamental von dem, was ein Kapitalmarkt-Forensiker braucht. Ein Umweltrechercheur arbeitet mit Satellitendaten und Schadstoffregistern. Ein Nachrichtendienst hat Zugriff auf proprietäre Quellen, die nirgendwo anders verfügbar sind.

Eine geschlossene Plattform müsste zwischen zwei Kompromissen wählen: entweder alle Datenquellen dieser Welt bereitstellen (unmöglich), oder nur einen allgemeinen Grundstock — der für Spezialisten zu allgemein bliebe.

Das Plugin-System löst den Konflikt. Der Kern bleibt stabil, spezielle Quellen werden als modulare Erweiterungen eingebunden — ohne dass irgendeine Zeile im eigentlichen SpectralQ-Code geändert werden muss. Was heute fehlt, ist morgen ein Plugin. Was übermorgen gebraucht wird, wird übermorgen programmiert.

Was ein Plugin in SpectralQ leisten kann

Plugins in SpectralQ haben drei Haupt-Funktionen, die einzeln oder kombiniert umgesetzt werden können:

1. Daten abrufen

Die klassische Plugin-Rolle: Eine externe Quelle wird angezapft. Ein Plugin für Immobiliendaten könnte Grundbuchauszüge abrufen, eines für Schifffahrtsbewegungen könnte AIS-Signale laden, eines für Unternehmensregister könnte Handelsregister-Eintragungen liefern.

Technisch wird dafür eine Funktion namens handle_fetch() implementiert. Sie nimmt Parameter entgegen (Zeitraum, Geo-Bereich, Suchbegriffe) und liefert ein standardisiertes Ergebnis zurück: eine Liste von Datenpunkten mit Zeitstempel, Ort, Inhalt und Metadaten.

2. Geodaten normalisieren

Jede Datenquelle liefert Ort-Informationen in eigenem Format. Manche nutzen Länge/Breite, andere Adressen, wieder andere geografische Codes. Die Funktion normalize_geodata() übersetzt diese Eingaben ins einheitliche Format, mit dem SpectralQ intern arbeitet (WGS84-Koordinaten plus optional Adresstext).

Das stellt sicher, dass Ihre eigenen Plugins nahtlos mit Karten, R/Z-Analyse und anderen räumlichen Werkzeugen zusammenarbeiten.

3. Analysen durchführen

Manche Plugins gehen einen Schritt weiter als reine Datenlieferung. Sie enthalten eigene Analyselogik, die über den normalen KI-Analysten hinausgeht. Die Funktion handle_analysis() bekommt Rohdaten oder vorberechnete Zeitreihen und liefert spezifische Analyseergebnisse zurück — etwa domänenspezifische Auffälligkeits-Erkennung, Mustererkennung, Spezialkennzahlen.

Ein gutes Beispiel: Ein Kapitalmarkt-Plugin könnte Handelsvolumen nicht nur anzeigen, sondern Anomalien im Orderbuch erkennen. Ein Telekommunikations-Plugin könnte Funkzellendaten nicht nur abbilden, sondern Cluster von Geräten rund um einen Ort analysieren.

Die Struktur eines Plugins

Ein SpectralQ-Plugin ist technisch ein Verzeichnis mit wenigen Pflicht-Bestandteilen:

Metadaten-Datei

Eine zentrale Datei (typischerweise YAML oder JSON) beschreibt das Plugin:

• Name und Beschreibung — wie das Plugin in der Oberfläche erscheint
• Version — für Kompatibilitäts-Checks mit SpectralQ-Updates
• Autor und Lizenz — rechtliche Einordnung
• API-Key-Felder — falls die Datenquelle Authentifizierung benötigt
• Parameter-Schema — welche Einstellungen bietet das Plugin an
• KI-Integration — ob ein LLM-Modul eingebunden werden soll (Anthropic, OpenAI, Gemini, Mistral)

Diese Datei macht das Plugin in der SpectralQ-Oberfläche installierbar und konfigurierbar.

Haupt-Implementierung

Die eigentliche Logik — implementiert als Python-Code (bei Server-Plugins) oder JavaScript (bei Client-Plugins). Hier leben die drei Kernfunktionen handle_fetch(), normalize_geodata() und handle_analysis(). Nicht alle drei müssen implementiert werden — ein reines Daten-Plugin braucht nur handle_fetch(), ein Analyse-Plugin nur handle_analysis().

Optionale UI-Komponenten

Wenn das Plugin eine eigene Darstellung auf dem Murder Board braucht (etwa einen spezialisierten Widget-Typ), können UI-Komponenten hinzugefügt werden. Das ist fortgeschritten — die meisten Plugins kommen ohne eigene UI aus und nutzen die Standard-Darstellungen.

Das Plugin-Management in SpectralQ

Den Bereich Plugins finden Sie im Hauptmenü unter /plugins. Er zeigt eine Liste aller in Ihrem SpectralQ-System installierten Plugins — sowohl die mitgelieferten Standard-Plugins als auch selbst hinzugefügte.

Pro-Plugin-Anzeige

Für jedes Plugin sehen Sie:

• Name und Beschreibung
• Status — aktiv / deaktiviert / Fehler
• API-Key-Verwaltung — falls benötigt, können Sie hier Ihre Schlüssel hinterlegen
• KI-Modul-Zuordnung — wenn das Plugin eine LLM-Anbindung hat, wählen Sie Provider (Anthropic, OpenAI, Gemini, Mistral) und ggf. spezifisches Modell
• Konfigurations-Parameter — spezifisch je Plugin

Aktivierung und Deaktivierung

Plugins lassen sich einzeln aktivieren oder deaktivieren. Ein deaktiviertes Plugin erscheint nicht im Plus-Menü auf dem Board und kann keine Datenabrufe mehr machen. Das ist nützlich, wenn ein Plugin vorübergehend Probleme hat oder seine Quelle nicht verfügbar ist — Sie können es ausschalten, ohne es zu deinstallieren.

API-Keys absichern

Viele Plugins brauchen API-Schlüssel für externe Dienste. Diese Schlüssel werden verschlüsselt in der SpectralQ-Datenbank abgelegt. Im Plugin-Management erscheinen sie nur als Platzhalter („•••"). Nur beim expliziten Ändern werden sie neu eingegeben und gespeichert.

Die mitgelieferten Plugins als Basis

SpectralQ bringt von Haus aus eine umfangreiche Palette von Standard-Plugins mit. Jedes davon ist ein Beispiel für das Plugin-System in Aktion:

• News — Nachrichtenabrufe aus diversen Quellen
• Telegram — Kanal-Monitoring
• Reddit — Community-Aktivität
• Internet Health — Netzwerk-Metriken
• Wikipedia — Artikel- und Edit-Analysen
• GT Studio — Google Trends
• Satellit — Überflüge und Aufnahmen
• Wetter — Open-Meteo-Integration
• Seismik — Erdbebendaten
• Strahlung — Umweltwerte
• Nachtlicht — nächtliche Lichtemissionen aus Satellitendaten
• Funkmasten — Mobilfunk-Infrastruktur
• Flugzeuge — AIS- und ADS-B-Daten
• Schiffe — Maritime Bewegungen
• Traceroute — Netzwerk-Routing-Analysen
• Commodities — Rohstoffpreise
• OSM — OpenStreetMap-Abfragen
• NDVI — Vegetationsindex aus Satellitendaten
• Certwatch — TLS-Zertifikat-Monitoring
• Website — generisches Web-Scraping

Diese Vielfalt zeigt das Prinzip: alles, was sich in eine strukturierte Datenabfrage fassen lässt, kann in SpectralQ integriert werden. Die mitgelieferten Plugins sind selbst nach demselben Mechanismus gebaut wie eigene — sie haben kein Privileg gegenüber Community-Plugins.

Typische Erweiterungsszenarien

Szenario 1 — Unternehmensinterne Datenbank einbinden

Eine Wirtschaftsprüfungsgesellschaft nutzt SpectralQ für forensische Compliance-Untersuchungen. Sie hat eine interne Datenbank mit strukturierten Transaktionsdaten, Mitarbeiter-Zugriffs-Logs und Kommunikationshistorien.

Ein eigenes Plugin greift auf diese Datenbank zu. handle_fetch() akzeptiert Parameter wie Zeitraum, Abteilung, Transaktionstyp und liefert die relevanten Datensätze. Auf dem Murder Board erscheinen diese Daten wie jede andere Datenquelle — mit Verbindungen zu Elementen, Visualisierung auf Karten und Verlaufsgraphen.

Der Vorteil: Die interne Datenbank wird nahtlos Teil der forensischen Analyse, ohne dass Daten exportiert oder auf fremde Server geladen werden müssen.

Szenario 2 — Proprietäre API eines Datenanbieters

Eine Rechercheplattform kauft Zugriff auf eine kostenpflichtige API eines spezialisierten Datenanbieters — etwa für Unternehmensverflechtungen, Gerichtsdatenbanken oder Luftfahrt-Registerdaten. Die API gibt strukturierte Antworten zurück, die für die Ermittlung direkt relevant sind.

Ein Plugin kapselt die API-Nutzung. Der API-Schlüssel wird im Plugin-Management hinterlegt. Auf dem Board lassen sich die Daten abrufen, mit anderen Quellen trianguliert und in Hypothesen-Bausteine eingebunden.

Pluspunkt: Die API-Kosten sind kontrollierbar — das Plugin-Management zeigt Nutzungsstatistiken, und das Kontingent lässt sich beschränken.

Szenario 3 — Domain-spezifische Analyse

Ein IT-Sicherheitsteam analysiert regelmäßig Netzwerk-Anomalien. Dafür braucht es spezielle Erkennungsmuster, die das Standard-Werkzeug-Set nicht bietet — etwa Fingerprints bekannter Malware-Kommunikationsmuster oder Scan-Muster von Angreifern.

Ein Plugin implementiert die Erkennungslogik in handle_analysis(). Wenn Rohdaten (etwa Traceroute-Ergebnisse oder Zertifikats-Watches) in dieses Plugin einlaufen, werden sie auf die spezifischen Muster geprüft und mit Markierungen versehen. Das Plugin ergänzt die Plattform um domänenspezifische Intelligenz.

Szenario 4 — Eigene KI-Modelle einbinden

Eine Forschungsorganisation hat ein eigenes Sprachmodell trainiert — spezialisiert auf juristische Texte oder auf Domain-spezifische Fachsprache. Dieses Modell soll statt der Standard-Provider (Anthropic, OpenAI) genutzt werden.

Ein Plugin stellt eine Anbindung an das eigene Modell bereit. Über das KI-Modul-Feld im Plugin-Management wird der eigene Endpoint konfiguriert. Die Analyse-Funktionen nutzen dann automatisch dieses Modell statt der externen Anbieter.

Szenario 5 — Bestehende Plugins anpassen

Ein Plugin muss nicht von Grund auf neu gebaut werden. Oft reicht es, ein bestehendes Plugin als Basis zu nehmen und spezifische Anpassungen vorzunehmen — etwa um weitere Parameter zu unterstützen, die Ergebnisse in anderer Weise zu normalisieren oder spezielle Filterlogik einzubauen.

Da der Code aller Standard-Plugins offen dokumentiert ist, lässt sich das direkt als Ausgangspunkt nutzen. Eine angepasste Variante wird dann als separates Plugin installiert — das Original bleibt unverändert.

Plugins entwickeln — der Einstieg

Die Entwicklung eines Plugins setzt Grundkenntnisse in Python voraus. Die Basis ist überschaubar:

Schritt 1 — Dokumentation studieren. Im Abschnitt Entwickler der SpectralQ-Dokumentation finden Sie die vollständige Plugin-API. Lesen Sie mindestens die Kapitel zu handle_fetch(), normalize_geodata() und handle_analysis().

Schritt 2 — Bestehendes Plugin als Vorlage nehmen. Das einfachste Plugin, das SpectralQ mitbringt (etwa das Wetter-Plugin), ist ein guter Ausgangspunkt. Kopieren Sie es, ändern Sie den Namen und die Logik Stück für Stück.

Schritt 3 — Lokal testen. Plugins lassen sich in der eigenen SpectralQ-Instanz installieren, ohne dass jemand anderes sie sehen muss. Das erlaubt iterative Entwicklung mit sofortigem Feedback.

Schritt 4 — Dokumentieren. Ein Plugin braucht eine klare Beschreibung — was tut es, welche Datenquelle nutzt es, welche API-Schlüssel sind nötig, welche rechtlichen Einschränkungen gelten. Ohne diese Dokumentation wird das Plugin weder im eigenen Team noch in einer Community einsetzbar sein.

Schritt 5 — Teilen (optional). Eigene Plugins können innerhalb der eigenen Organisation geteilt, in Fach-Communities verteilt oder kommerziell vermarktet werden. SpectralQ schreibt das nicht vor — Sie behalten die volle Kontrolle.

Open Core — Core und Enterprise

SpectralQ unterscheidet zwischen zwei Ausführungen:

Core. Die Single-User-Variante. Komplett für eine Einzelperson gedacht. Kein Team-Management, keine Rollen, keine Kontingente. Der Kern ist Open Source — Sie können den Code einsehen, auditieren und anpassen.

Enterprise. Die Mehrnutzer-Variante. Mit:

• Benutzerverwaltung — Konten, Passwörter, Aktivierung
• Rollensystem — Admin, Analyst, Gast mit unterschiedlichen Rechten
• Teams — Gruppierung und gemeinsame Projektfreigabe
• Kontingente — Begrenzungen für LLM-Nutzung, Datenabrufe, Speicherplatz
• E-Mail-Integration — SMTP für Systemnachrichten
• Audit Trail für alle Nutzer — wer im Team hat was getan

Beide Varianten nutzen dasselbe Plugin-System. Was Sie für Core entwickeln, läuft auch in Enterprise, und umgekehrt.

LLM-Provider und Plugins

Wenn ein Plugin KI-Funktionen nutzt, lässt sich der dahinterstehende LLM-Provider frei wählen. SpectralQ unterstützt:

• Anthropic — Claude-Modelle
• OpenAI — GPT-Modelle
• Gemini — Googles Modelle
• Mistral — Mistral-Modelle

Die Provider-Wahl hat Konsequenzen:

• Sprache und Schwerpunkte — jedes Modell hat Stärken in bestimmten Aufgabenfeldern
• Datenschutz und Region — manche Organisationen müssen europäische Provider nutzen
• Kosten — Preise variieren je Provider und Nutzungsintensität
• Lokale Modelle — über eigene Plugins lassen sich auch self-hosted LLMs einbinden

Die Provider-Einstellung ist pro Plugin konfigurierbar. So kann die Faktenextraktion über einen preisgünstigen Provider laufen, während die Hypothesen-Generierung ein hochwertiges Modell nutzt.

Grenzen und Verantwortung

Das Plugin-System ist mächtig — und die Verantwortung liegt entsprechend beim Nutzer.

Rechtliche Grenzen. Nur weil ein Plugin technisch auf eine Datenquelle zugreifen kann, heißt das nicht, dass es das darf. Vor dem Einsatz:

• Sind die Nutzungsbedingungen der Quelle erfüllt?
• Gibt es datenschutzrechtliche Beschränkungen?
• Ist der Abruf rechtlich erlaubt im jeweiligen Land?

Das Plugin-System prüft nichts davon. Die Verantwortung bleibt vollständig beim Betreiber.

Sicherheitsaspekte. Plugins laufen im selben Prozess wie SpectralQ selbst. Ein fehlerhaftes oder böswilliges Plugin kann das System beschädigen. Installieren Sie nur Plugins, deren Quelle Sie vertrauen — bei Plugins aus Fremdquellen vorher Code-Review.

Wartung. Plugins, die externe APIs nutzen, brechen bei API-Änderungen. Rechnen Sie bei eigenen Plugins mit laufendem Wartungsaufwand. Vor allem bei Plugins, die Sie über längere Zeit nutzen wollen, ist ein Monitoring sinnvoll — damit Sie früh bemerken, wenn eine Quelle sich geändert hat oder ausfällt.

Qualität der Daten. Ein Plugin macht eine Datenquelle zugänglich — es prüft aber nicht, ob die Daten korrekt sind. Wenn die Quelle fehlerhafte oder manipulierte Daten liefert, landen diese ungefiltert in Ihrer Ermittlung. Die Qualitätsprüfung ist Ihre Aufgabe.