Zwei Stores, eine Wirbelsäule, eine Vertragsschnittstelle.

Die Plattform basiert auf einer Dual-Store-Architektur, über die Sie als Operator nicht nachdenken müssen. Ein Graph-Store übernimmt Entdeckung und gesprächsübergreifende Kausalität. Ein Postgres-Store übernimmt Pivots, Aggregate und Zeitreihen. Beide Stores sind über einen unveränderlichen Chunk-Identifier verbunden, der jeden Fakt auf den exakten Moment im exakten Interview zurückführt, der ihn erzeugt hat. Eine MCP-Tool-Oberfläche liegt über beiden und stellt jedem Konsumenten einen kleinen, präzisen Satz an Abfragen bereit. Eine Wirbelsäule, drei Endpunkte.

Diese Seite beschreibt die operative Form des Systems. Sie behandelt, wofür jeder Store steht, warum beide existieren, wie die Chunk-ID-Wirbelsäule funktioniert und wie die MCP-Oberfläche aus Agentensicht aussieht. Die technische Entwicklerreferenz (Schema, Partitionierung, Embedding-Modell, genaue MCP-JSONSchemas) befindet sich in der Entwicklerreferenz, auf Anfrage erhältlich. Das ist das Dokument, das Ihre Platform-Ingenieure lesen. Diese Seite ist für Sie.

Entdeckungsfragen haben eine Graph-Form. "Warum steigt die Ablehnungsrate bei Foundation-Produkten für Kunden unter 25?" erfordert eine Traversierung über Substitutionskanten, Kausalbeziehungen und Wettbewerbserwähnungen, um das vorgelagerte Ereignis zu finden, das sie verbindet. Ein flacher Vektorindex kann das nicht. Gesprächsübergreifende Kausalketten sind erstklassige Graph-Objekte. K-nächste-Nachbarn-Retrieval bringt sie nur zufällig ans Licht.

Aggregationsfragen sind tabellarisch. "Wie viele Markenwahrnehmungs-Fakten sind diese Woche negativ geworden, nach Filiale, Region und Ebene?" ist ein Postgres-GROUP BY, keine Graph-Traversierung. Den Versuch, einen einzigen Store für beide Fragetypen zu nutzen, ist das, was die meisten Wissensprodukte bei Skalierung zum Scheitern bringt. Die Plattform trennt sie und verbindet sie am Chunk-Identifier.

Für die Graph-Implementierung verwendet die Plattform Apache AGE auf Postgres, mit dem bi-temporalen Modell basierend auf den Konventionen von Zep und mem0. Für den Fakt-Store hält dieselbe Postgres-Instanz die Zeilentabellen, mit pgvector für Embeddings. Eine Datenbank, zwei Abfragemuster, verbunden über die Chunk-ID.

Jeder Chunk jedes Interviews erhält einen unveränderlichen Identifier der Form transcript_id / turn_id / sentence_id. Dieser Identifier ist die Wirbelsäule. Jeder Anreicherungsfakt referenziert ihn. Jede Zeile im Postgres-Fakt-Store referenziert ihn. Jeder Knoten im Graph referenziert ihn. Wenn eine Dashboard-Zelle fragt "Was ist die Quelle dieser Zahl", ist die Antwort ein oder mehrere Chunk-IDs. Zitierung ist strukturell.

Ein Markenpartner fragt: "Warum behaupten Sie, mein Produkt verliert gegenüber Substitut X?" Die Antwort sind drei Chunk-IDs, drei Berater-Aussagen, drei Zeitstempel, in drei benannten Stores. Die Darstellungsschicht formatiert sie. Das Substrat garantiert sie. Die Herkunftskette ist ausführlich beschrieben unter der Verbatim-Herkunftskette.

Die MCP-Oberfläche ist der Vertrag zwischen dem Korpus und jedem Konsumenten: Dashboards, Markenpartner-APIs, KI-Agenten. Die Tools sind bewusst wenige. query_facts gibt strukturierte Zeilen zurück, gefiltert nach Dimension, Segment und Zeitfenster. traverse_relations traversiert den Graph für Kausal- und Substitutionsketten. pivot_dimension aggregiert entlang einer Segmentachse. replay_as_of führt jede Abfrage gegen den Korpus zu einem vergangenen Datum aus. cite löst eine Chunk-ID in ihr verbatimes Quelldokument auf.

Jeder Aufruf durchläuft dieselbe Scope-Prüfung. Das Sitzungs-Ticket des Aufrufers trägt einen Scope; dieser Scope filtert, welche Tools sich auflösen, welche Graph-Knoten traversierbar sind, welche Postgres-Zeilen lesbar sind und welche Chunks bei einer Zitierung aufgelöst werden. Ein Partnerschlüssel kann cite aufrufen; die zurückgegebenen Chunks liegen innerhalb seiner Scheibe. Er hat keinen Pfad zu etwas außerhalb. Die vollständige Sicherheitskaskade befindet sich unter Trust & Security.

Die genauen JSONSchemas für jedes Tool befinden sich in der Entwicklerreferenz, auf Anfrage erhältlich für die Ingenieure, die einen Agenten an die Plattform anschließen. In der Operator-Konsole sehen Sie, welche Agenten verbunden sind, welchen Scope sie haben und was sie diese Woche abgefragt haben.

Das Standard-Substrat ist Cloudflare, innerhalb Ihres eigenen Cloudflare-Kontos. Der Cloud Harness installiert die Plattform dort. AWS, Azure und On-Premise folgen demselben Muster auf einem anderen Substrat. Beide Stores liegen in Ihrem Konto. Die Rechenleistung für den Interview-Agenten liegt in Ihrem Konto. Die Anreicherungs-Worker, der MCP-Server und die Operator-Konsole laufen alle innerhalb Ihres Tenants. Daten verlassen Ihren Perimeter nicht zur Verarbeitung.

Der LLM-Vertrag mit Anthropic und der Sprachvertrag mit ElevenLabs sind die zwei Grenzaufrufe. Beide laufen unter Nicht-Retention-Vereinbarungen (kein Training auf allen LLM-Plänen, keine Retention auf Enterprise; keine Retention auf allen Sprachplänen). Die vollständige Beschreibung dieser Verträge und der Datenverarbeitung an der Grenze befindet sich auf dem Trust-Hub.

Bei 100 Interviews (ein Pilotprojekt der Pulse-Ebene) ist der Graph dünn besetzt, segmentbegrenzte Abfragen sind richtungsweisend, aber nicht statistisch signifikant, und der Fakt-Store enthält einige tausend Zeilen. Das Dashboard funktioniert. Die Replay-Oberfläche funktioniert. Das bi-temporale Modell trägt hauptsächlich learned_at; der Zerfall hat noch nicht eingesetzt.

Bei 2.000 Interviews verdichtet sich der Graph, Substitutions- und Kausalkanten bilden Ketten von drei oder vier Hops mit echtem Beweisgewicht, der Fakt-Store enthält rund 200.000 Zeilen, und segmentbegrenzte Abfragen werden statistisch bedeutsam. Die ersten 500 Gespräche verlieren ihren Frischestatus. Die Aktualisierungsökonomie beginnt eine Rolle zu spielen. Die Markenpartner-API lohnt sich auf Einzelregions-Ebene zur Abrechnung.

Bei 50.000 Interviews auf wöchentlicher Aktualisierung unterstützt der Korpus die größten Deployments in einer einzelnen Branche. Cross-Market-Benchmarking ist Echtzeit und statistisch signifikant pro Markt. Per-Segment-Gültigkeit ist das, was Hunderte von Markenpartner-Tenants auf einem Korpus handhabbar macht. Die Architektur wurde für diesen Fall bereits beim 100-Gespräche-Deployment gebaut. Der Store wird nicht neu aufgebaut, wenn der Korpus wächst.