Two stores, one spine, one contract surface.

The platform is built around a dual-store architecture that you, as an operator, do not have to think about. A graph store handles discovery and cross-conversation causality. A Postgres store handles pivots, aggregates, and time-series. The two stores are joined at an immutable chunk identifier that links every fact back to the exact moment in the exact interview that produced it. An MCP tool surface sits on top of both and presents a small, sharp set of queries to every consumer. One spine, three endpoints.

This page is the operational shape of the system. It covers what each store is for, why both exist, how the chunk-ID spine works, and what the MCP surface looks like from the agent’s side. The deep engineering reference (schema, partitioning, embedding model, exact MCP JSONSchemas) is in the engineering reference, available on request. That is the document your platform engineers read. This page is for you.

Discovery questions are graph-shaped. “Why does the foundation rejection rate spike for under-25 customers?” wants a traversal across substitution edges, cause relations, and competitor mentions, surfacing the upstream event that connects them. A flat vector index cannot do this. Cross-conversation chains of cause are first-class graph objects. K-nearest-neighbor retrieval surfaces them only by coincidence.

Aggregation questions are tabular. “How many brand-perception facts shifted negative this week, by store, by region, by tier?” is a Postgres GROUP BY, not a graph traversal. Trying to make one store answer both kinds of question is what makes most knowledge products collapse at scale. The platform separates them and joins them at the chunk identifier.

For the graph implementation the platform uses Apache AGE on Postgres, with the bi-temporal model based on the Zep and mem0 conventions. For the fact store, the same Postgres instance holds the row tables, with pgvector for embeddings. One database, two query patterns, joined at the chunk-ID.

Every chunk of every interview gets an immutable identifier of the form transcript_id / turn_id / sentence_id. That identifier is the spine. Each enrichment fact references it. Each row in the Postgres fact store references it. Each node in the graph references it. When a dashboard cell asks “what is the source of this number,” the answer is one or more chunk-IDs. Citation is structural.

A brand partner asks “why do you claim my product loses to substitute X.” The answer is three chunk-IDs, three advisor utterances, three timestamps, in three named stores. The display layer formats it. The substrate guarantees it. The provenance chain is described in detail under the Verbatim Provenance Chain.

The MCP surface is the contract between the corpus and every consumer: dashboards, brand-partner APIs, AI agents. The tools are deliberately few. query_facts returns structured rows filtered by dimension, segment, and time window. traverse_relations walks the graph for cause and substitution chains. pivot_dimension aggregates across a segment axis. replay_as_of runs any query against the corpus as it stood on a past date. cite resolves a chunk-ID into its source verbatim.

Every call hits the same scope check. The session ticket of the caller carries a scope; the scope filters which tools resolve in the first place, which graph nodes are traversable, which Postgres rows are readable, and which chunks resolve when cited. A partner key can call cite; the chunks they get back are inside their slice. They have no path to anything outside it. The full security cascade lives under Trust & Security.

The exact JSONSchemas for each tool are in the engineering reference, available on request for the engineers wiring an agent to the platform. From the operator console you see which agents are connected, what scope they hold, and what they queried this week.

The default substrate is Cloudflare, inside your own Cloudflare account. The Cloud Harness installs the platform there. AWS, Azure, and on-premise follow the same shape on a different substrate. The two stores live in your account. The compute that runs the interview agent lives in your account. The enrichment workers, the MCP server, and the operator console all run inside your tenant. Data does not leave your perimeter to be processed.

The LLM contract with Anthropic and the voice contract with ElevenLabs are the two boundary calls. Both run under no-retention agreements (no-training on every LLM plan, no-retention on Enterprise; no-retention on every voice plan). The full description of those contracts and the data-handling at the boundary is on the Trust hub.

At 100 interviews (a Pulse-tier pilot), the graph is sparse, segment-scoped queries are directionally useful but not statistically significant, and the fact store holds a few thousand rows. The dashboard works. The replay surface works. The bi-temporal model is mostly carrying learned_at; decay has not kicked in yet.

At 2,000 interviews, the graph densifies, substitution and cause edges form chains of three or four hops with real evidence weight, the fact store holds around 200,000 rows, and segment-scoped queries become statistically meaningful. The first 500 conversations age out of fresh status. Refresh economics start mattering. The brand-partner API becomes worth charging for at single-region scope.

At 50,000 interviews on weekly refresh, the corpus supports the largest deployments in any single vertical. Cross-market benchmarking is real-time and statistically significant per market. Per-segment validity is what makes hundreds of brand-partner tenants on one corpus tractable. The architecture was built for this case at the 100-conversation deployment. The store does not get rebuilt as the corpus grows.