Due store, una colonna portante, una superficie contrattuale.

La piattaforma e costruita attorno a un'architettura a doppio store di cui voi, come operatori, non dovete preoccuparvi. Uno store grafo gestisce la discovery e la causalita tra conversazioni. Uno store Postgres gestisce pivot, aggregati e serie temporali. I due store sono uniti su un identificatore di chunk immutabile che collega ogni fatto al momento esatto nell'intervista esatta che lo ha prodotto. Una superficie di strumenti MCP si posiziona sopra entrambi e presenta un insieme ristretto e preciso di query a ogni consumer. Una colonna portante, tre endpoint.

Questa pagina descrive la forma operativa del sistema. Copre la funzione di ciascuno store, il motivo per cui esistono entrambi, come funziona la colonna portante degli ID chunk e come appare la superficie MCP dal lato dell'agente. Il riferimento ingegneristico approfondito (schema, partizionamento, modello di embedding, JSONSchema MCP esatti) e nel riferimento ingegneristico, disponibile su richiesta. E il documento che leggono i vostri ingegneri di piattaforma. Questa pagina e per voi.

Le domande di discovery hanno forma di grafo. "Perche il tasso di rifiuto del fondotinta aumenta per i clienti under 25?" richiede una traversata attraverso archi di sostituzione, relazioni di causalita e menzioni di concorrenti, facendo emergere l'evento a monte che li collega. Un indice vettoriale piatto non puo farlo. Le catene di causalita tra conversazioni sono oggetti grafo di primo livello. Il recupero K-nearest-neighbor le fa emergere solo per coincidenza.

Le domande di aggregazione sono tabulari. "Quanti fatti di percezione del brand sono diventati negativi questa settimana, per negozio, per regione, per livello?" e un GROUP BY Postgres, non una traversata di grafo. Cercare di far rispondere un unico store a entrambi i tipi di domanda e cio che fa collassare la maggior parte dei prodotti di conoscenza su scala. La piattaforma li separa e li unisce sull'identificatore di chunk.

Per l'implementazione del grafo la piattaforma utilizza Apache AGE su Postgres, con il modello bi-temporale basato sulle convenzioni di Zep e mem0. Per lo store dei fatti, la stessa istanza Postgres contiene le tabelle di righe, con pgvector per gli embedding. Un unico database, due pattern di query, uniti sull'ID chunk.

Ogni chunk di ogni intervista riceve un identificatore immutabile nella forma transcript_id / turn_id / sentence_id. Quell'identificatore e la colonna portante. Ogni fatto di arricchimento vi fa riferimento. Ogni riga nello store dei fatti Postgres vi fa riferimento. Ogni nodo nel grafo vi fa riferimento. Quando una cella del dashboard chiede "qual e la fonte di questo numero", la risposta e uno o piu ID chunk. La citazione e strutturale.

Un partner di marca chiede "perche affermate che il mio prodotto perde rispetto al sostituto X". La risposta e tre ID chunk, tre enunciati di consulenti, tre timestamp, in tre store nominati. Il livello di presentazione la formatta. Il substrato la garantisce. La catena di provenienza e descritta in dettaglio sotto la catena di provenienza verbatim.

La superficie MCP e il contratto tra il corpus e ogni consumer: dashboard, API per partner di marca, agenti IA. Gli strumenti sono deliberatamente pochi. query_facts restituisce righe strutturate filtrate per dimensione, segmento e finestra temporale. traverse_relations percorre il grafo per catene di causalita e sostituzione. pivot_dimension aggrega su un asse di segmento. replay_as_of esegue qualsiasi query sul corpus com'era a una data passata. cite risolve un ID chunk nel suo verbatim sorgente.

Ogni chiamata passa attraverso lo stesso controllo di perimetro. Il ticket di sessione del chiamante porta un perimetro; quel perimetro si propaga su quali strumenti si risolvono, quali nodi del grafo sono attraversabili, quali righe Postgres sono leggibili e quali chunk si risolvono quando vengono citati. Una chiave partner puo chiamare cite; i chunk che ottiene in risposta sono all'interno della sua porzione. Non ha alcun percorso verso nulla al di fuori. La cascade di sicurezza completa si trova sotto Fiducia e sicurezza.

I JSONSchema esatti per ogni strumento si trovano nel riferimento ingegneristico, disponibile su richiesta per gli ingegneri che collegano un agente alla piattaforma. Dalla console operatore vedete quali agenti sono connessi, quale perimetro detengono e cosa hanno interrogato questa settimana.

Il substrato predefinito e Cloudflare, all'interno del vostro account Cloudflare. Il Cloud Harness installa la piattaforma li. AWS, Azure e on-premise seguono la stessa forma su un substrato diverso. I due store risiedono nel vostro account. Il calcolo che fa funzionare l'agente di intervista risiede nel vostro account. I worker di arricchimento, il server MCP e la console operatore vengono tutti eseguiti all'interno del vostro tenant. I dati non lasciano il vostro perimetro per essere elaborati.

Il contratto LLM con Anthropic e il contratto vocale con ElevenLabs sono le due chiamate ai confini. Entrambe vengono eseguite sotto accordi di no-retention (nessun training su tutti i piani LLM, nessuna retention su Enterprise; nessuna retention su tutti i piani vocali). La descrizione completa di tali contratti e della gestione dei dati al confine si trova su l'hub Fiducia.

A 100 interviste (un pilota di livello Pulse), il grafo e sparso, le query delimitate per segmento sono direzionalmente utili ma non statisticamente significative, e lo store dei fatti contiene qualche migliaio di righe. Il dashboard funziona. La superficie di replay funziona. Il modello bi-temporale porta principalmente learned_at; il decadimento non ha ancora preso avvio.

A 2.000 interviste, il grafo si densifica, gli archi di sostituzione e causalita formano catene di tre o quattro hop con un peso di evidenza reale, lo store dei fatti contiene circa 200.000 righe, e le query delimitate per segmento diventano statisticamente significative. Le prime 500 conversazioni escono dallo stato di recenti. L'economia degli aggiornamenti inizia a contare. L'API per partner di marca diventa conveniente da fatturare a perimetro di singola regione.

A 50.000 interviste su aggiornamento settimanale, il corpus supporta le distribuzioni piu grandi in qualsiasi verticale. Il benchmarking cross-mercato e in tempo reale e statisticamente significativo per mercato. La validita per segmento e cio che rende gestibili centinaia di tenant di partner di marca su un unico corpus. L'architettura e stata progettata per questo caso gia dalla distribuzione a 100 conversazioni. Lo store non viene ricostruito man mano che il corpus cresce.