Sie sind Eigentumer des Tenants, der Daten, des Schemas und des Korpus.

Die Intelligence Layer, die Nexa Intelligence betreibt, gehort Ihnen. Das Cloud-Konto gehort Ihnen. Die Rohgesprachsdaten, der angereicherte Fact Store, die Dashboards, das Schema, das den Korpus typisiert, und die KI-Agenten, die ihn abfragen, leben auf Infrastruktur, die Sie kontrollieren. Wenn Sie entscheiden, die Anbieterbeziehung zu beenden, lauft Ihr Deployment auf demselben Konto, gegen dieselben Daten, unter demselben Schema weiter - ohne Unterbrechung der Kontinuitat.

Diese Seite behandelt, was Eigentumerschaft in der Praxis bedeutet: das Schema, das Korpusformat, den Portierungspfad und was am Ende des Engagements geschieht.

Das Cloud Harness wird innerhalb Ihres eigenen Cloudflare-, AWS-, Azure- oder On-Premise-Kontos installiert. Speicherung, Compute, das Audit-Log, der Secrets-Tresor und das Schlusselmanagement befinden sich auf Anmeldedaten, die Ihre IT kontrolliert. Es gibt keine separate, Nexa-kontrollierte Umgebung, die eine Kopie Ihrer Daten halt. Siehe In-Tenant-Deployment fur die Topologie.

Die Abrechnung fur die zugrunde liegende Infrastruktur geht an Sie, da die Ressourcen Ihnen gehoren. Unser Vertrag deckt den Betrieb der Plattform, die Methodik und die agentenseitige Intelligence-Arbeit ab. Die Infrastrukturkosten sind als Posten vom Engagement trennbar.

Jede Tatsache im Korpus ist gegen dasselbe Schema typisiert. Zehn Dimensionen decken den Inhalt eines Markenwahrnehmungs-Interviews ab: Schmerzpunkte, Opportunitats-Scoring, Markenwahrnehmung, Marktsignal, Kundenssegmentverhalten, Wettbewerber-Erwahnung-Karte, KI-Bereitschafts-Scoring, Schulungsdefizite, Bindungsfaktoren sowie regulatorische oder Compliance-Risiken. Das Schema ist veroffentlicht. Sie konnen es lesen, ableiten und eigene Analysen dagegen ausfuhren, ohne unsere Beteiligung.

Die Faktenzeile tragt drei unabhangige Zeitstempel: learned_at (wann das System die Tatsache beobachtete), valid_at (wann die Tatsache in der Welt wahr wurde), invalid_at (wann sie aufhorte, wahr zu sein). Sie tragt auch einen sparsamen segment_vector, der beschreibt, auf welchen Bevolkerungsausschnitt die Tatsache zutrifft. Das Schema ist bi-temporal und segmentbewusst ab dem ersten Deployment.

Provenance ist Teil der Zeile. Ein source_chunk_id-Feld der Form transcript_id / turn_id / sentence_id verbindet jede Tatsache mit dem genauen Satz des Interviews, der sie erzeugt hat. Die Verknupfung ist verbindlich. Es gibt keine Tatsache ohne einen Quell-Chunk.

Der rohe Data Lake halt die Originalaudios und Transkripte in Standardformaten: .mp3 fur Audio, .json fur Transkripte und gesprachebasierte Metadaten. Die Dateien befinden sich im Objektspeicher (R2 auf Cloudflare, S3 auf AWS, Blob auf Azure, MinIO On-Premise) mit deterministischen Schlusselpr afixen, die den Matrix-Identifier enthalten. Nichts am Dateiformat ist proprietar.

Der angereicherte Fact Store liegt in Postgres-kompatiblem Speicher (Postgres mit Apache AGE fur die Graph-Schicht oder Cosmos DB / DynamoDB bei den Cloud-Varianten). Das Schema wird als SQL-Views und als REST-API exponiert. Der Model Context Protocol-Server, der den Korpus fur KI-Agenten bereitstellt, ist dieselbe Oberflache, gegen die ein menschlicher Analyst abfragen kann. Standard-SQL, Standard-REST, Standard-MCP.

Zwei offene Standards verankern das temporale Modell: das Zep bi-temporale Modell und das mem0 Fact-Decay-Modell. Beide sind veroffentlicht. Unsere Implementierung erweitert sie mit der dimensionsspezifischen Halbwertszeit-Kalibrierung und dem Segment-Vektor. Das Ersetzen unserer Implementierung durch eine Alternative ist eine Code-Anderung gegen die veroffentlichte Spezifikation. Es ist kein Vendor-Wechsel.

Zwei Exportpfade decken den Korpus ab. Der erste ist eine vollstandige Objektspeicher-Kopie des Data Lakes plus ein SQL-Dump des Fact Stores. Dieses einzelne Archiv rekonstruiert das Deployment anderswo. Der zweite ist ein Streaming-Export gegen die Abfrage-API und den MCP-Server, fur Partner, die den Korpus fortlaufend in ihre eigene Analyseplattform spiegeln mochten.

Beide Pfade erhalten den Chunk-Identifier auf jeder Tatsache, sodass die Provenance den Export uberlebt. Ein in Ihr Data Warehouse ubertragener Befund kann uber denselben Identifier, den das Dashboard verwendet, auf den Quell-Interview-Turn zuruckgefuhrt werden.

Der Export ist eine Schaltflache in der Betreiberkonsole. Wir sperren ihn nicht hinter einem Verlangsprungsgesprachoder einer kostenpflichtigen Anfrage.

Wenn Sie die Anbieterbeziehung beenden, lauft das Deployment auf Ihrem Cloud-Konto weiter. Die Erfassungspipeline schreibt weiterhin in den Data Lake. Die Anreicherungspipeline produziert weiterhin Faktenzeilen gegen dasselbe Schema. Die Dashboards rendern weiterhin. Die KI-Agenten-Endpunkte antworten weiterhin gegen den Korpus. Die Methodikkonfiguration befindet sich in Ihrem Konto in Form von versionierten Plan-Blobs und registrierten Prompt-Hashes. Nichts hangt von einer Live-Verbindung zu Nexa ab.

Was Sie verlieren, ist Betreiber-Support, Methodik-Kalibrierung und Plattform-Updates. Das System lauft weiter. Die Intelligence Layer lauft weiter. Ihre IT kann die Betriebsverantwortung an einen anderen Anbieter ubertragen oder die Plattform intern betreiben. Der Vertrag benennt das Ubergabe-Runbook, damit der Ubergang einer Prozedur folgt und keine Neuverhandlung erfordert.

Das bi-temporale Modell gibt Ihnen die Moglichkeit zur Wiedergabe. Ein Markenpartner kann die heutige Abfrage und dieselbe Abfrage, wie sie vor sechs Monaten geantwortet hatte, gegen denselben Korpus ausfuhren. Der Zustand des Korpus am 12. April 2026 ist aus den Zeitstempeln der Faktenzeilen rekonstruierbar. Audits, die fragen: "Was sagte das System zum Zeitpunkt der Kaufentscheidung?", sind beantwortbar.

Das ist die Eigenschaft, die eine Markenpartner-API in einem Vertrag zeichenfahig macht. Ein statischer RAG-Index kann die Stichtagsfrage nicht beantworten. Der bi-temporale Fact Store kann es.