Methodik

Was der Radar ist

Der Opportunity Radar ist ein statisches Publishing-System, kein dynamisches SaaS-Frontend und keine Datenbankanwendung. Es gibt keine Live-Abfragen beim Seitenaufruf und keine Echtzeitdaten. Markdown ist das Publikationsformat, JSON bleibt Maschinen-, Provenance- und Zwischenformat.

Vier Komponenten mit getrennter Verantwortung: SubKit sammelt und normalisiert Marktdaten, Supabase Object Storage speichert Rohdaten, Läufe und Artefakte unveränderlich, WikiKit verwaltet geprüftes Wissen, Taxonomien, Claims und Entscheidungen, ContentKit validiert, versioniert, rendert und veröffentlicht.

Sammlung und Normalisierung

Erste und im MVP einzige Primärquelle ist TrustMRR, gelesen über eine authentifizierte HTTP-API mit API-Key. Die Rohantworten werden unverändert archiviert, bevor normalisiert wird. Produkte werden primär über einen stabilen Source-Identifier dedupliziert, sekundär über einen kanonischen Slug. Geldbeträge werden immer mit Währung und Beobachtungszeitpunkt geführt.

Unveränderliche Läufe

Jeder Datenlauf ist unveränderlich. Ein Lauf erhält eine runId im UTC-Format, schreibt alle Artefakte unter diesen Lauf, validiert Hashes und Schema und ersetzt erst zuletzt den Zeiger auf den aktuellen Stand. Ein fehlgeschlagener Lauf wird nie aktiviert.

Feld	Wert
runId	2026-07-28T031415Z
Vorlauf	2026-07-26T063105Z
Beobachtet am	28.07.2026, 06:19 UTC
Quelle	TrustMRR
Produkte	199
Neu / verändert / entfernt	3 / 178 / 4
Duplikate / Fehler	1 / 0

Als Integritätsnachweis dienen die S3-ETags (MD5) der Artefakte, im Manifest als integrity: "etag-md5" festgehalten. Der Grund gehört benannt: die Transform-Sandbox der Pipeline hat kein crypto-Modul, ein SHA-256 über die Artefakt-Bytes ist dort nicht berechenbar. Der Nachweis belegt die Unversehrtheit der Ablage, nicht mehr.

Scoring

Das Scoring ist deterministisch: dieselben Daten ergeben denselben Wert, wodurch Änderungen zwischen zwei Läufen erklärbar bleiben. Jede Komponente ist benannt und reproduzierbar, Berechnung und sprachliche Interpretation bleiben getrennt. Der Score liegt zwischen 0 und 100, die Confidence zwischen 0 und 1. Fehlende Daten senken die Confidence, werden aber nicht als Nullsignal ausgegeben — sonst misst der Score die Datenverfügbarkeit statt der Qualität einer Opportunity. Keine Score-Angabe wird ohne Erklärung ihrer Komponenten veröffentlicht. LLM-basiertes Scoring wurde verworfen, weil es für dieselben Daten unterschiedliche Werte liefern kann und seine Komponenten nicht einzeln benennbar sind.

Wissensfreigabe

Jede veröffentlichte Aussage trägt eine Evidenzklasse — provider-verified, self-reported, public-observation, derived oder hypothesis — und einen Beobachtungszeitpunkt; eine Quelle wird nie allein über ihren Markennamen benannt. Zuordnungen in Problem- und Markttaxonomie sind bestreitbare Claims mit Quelle und Status, keine festen Schemaeigenschaften. Maschinelle Vorschläge werden nie automatisch freigegeben; die Freigabe von Wissen bleibt eine menschliche Entscheidung.

Publikation

Kein Inhalt wird ohne run_id, knowledge_revision und sichtbaren Datenstand veröffentlicht, jede Hypothese wird als solche markiert. Generierte Dateien werden vollständig neu erzeugt, nie teilweise in PROD editiert. Jeder Release trägt einen maschinenlesbaren Vertrag mit releaseId, runId, knowledgeRevision, erwarteten Routen samt H1, einer Mindestanzahl an Opportunities und einem bekannten Suchbegriff; die Abnahme prüft die ausgelieferte Seite dagegen. Automatische Freigabe, Aktivierung und Rollback sind nicht Teil des MVP.

Stand dieser Seite

Der Wissensstand ist Space-Epoch 2. Es sind bisher keine Opportunity-Profile veröffentlicht. Die Daten des Laufs oben sind gesammelt und normalisiert, aber noch nicht freigegeben; Profile entstehen erst nach menschlicher Wissensfreigabe.

run_id

2026-07-28T031415Z

knowledge_revision

2

observed_at

2026-07-28T06:19:51Z

data_source

trustmrr