The shape of what lands in your tenant.

The Intelligence Layer is the corpus that the platform produces and that your team queries. It is not a report. It is not a static dashboard. It is a per-tenant data substrate where every fact carries a timestamp, a segment scope, a confidence score, and a citation back to the exact moment in a real interview that produced it. You see it through dashboards, your brand partners see it through a scoped API, and your AI agents see it through MCP tools. All three read the same corpus.

This page describes the layer from the operator’s seat. What it contains, how a query against it returns, what a refresh cycle does, and how you control access. The pipeline that produces the layer is covered under Methodology. The tenant boundary that holds the layer is covered under Trust & Security.

Each enriched conversation is decomposed into ten typed dimensions: pain points, opportunity scoring, brand-perception map, AI-readiness scoring, retention drivers, market signal, regulatory and compliance risk, training gap, customer-segment behavior, and competitor mention map. These ten are the operative set for retail. For consulting, restaurants, pharmacy, and the other verticals the platform supports, two or three dimensions swap out, but the shape stays the same: ten typed slots, stable schema, one row per fact.

Each fact row carries the dimension, the claim, the source chunk identifier of the form transcript_id / turn_id / sentence_id, the bi-temporal window, the segment vector, a salience count (how many independent conversations corroborate it), a confidence score, and an embedding for vector retrieval. Your dashboards group these rows by dimension, by segment, by time. Your AI agents retrieve them with a tool call.

The dimensions are stable across markets and across time, which is what makes cross-market benchmarking possible. A pain point in one market is comparable to a pain point in any other because the same definition and the same probing protocol produced both.

Every fact carries three independent timestamps. learned_at is when the platform observed it (the interview date, the enrichment date). valid_at is when the fact became true in the world, often inferred from the conversation itself. invalid_at is when the fact stopped being true: set explicitly when a contradicting conversation lands, or set by half-life decay if no refresh confirms it. Brand-perception facts decay in weeks. Training-gap facts decay only when the training catalog changes. The half-lives are calibrated per dimension, per vertical.

The operational consequence is as-of replay. You can run a query against the corpus as it stood last May and compare against the same query today. A brand partner asking “what did your data say about our category six months ago, when we made the Q2 buying decision” gets the correct answer for both dates. Your AI agents are blocked from grounding a recommendation on facts whose validity window does not include today.

Refresh cadence is wired into the fact lifecycle. The console surfaces the staleness clock per market and per dimension: when twenty percent of a dimension’s facts have aged out of validity, the platform recommends a refresh cycle. This is how the layer keeps itself honest without you having to remember the calendar.

A fact is rarely true everywhere. “Foundation X gets rejected most often” might be true for Latin American mass-market stores and false for European boutiques. “The brand is a value-fashion destination” might be true for end customers today and contested at the franchise level. Every fact in the layer carries a sparse segment vector: a projection over the segmentation axes that matter for your vertical (tier, geography, store format, customer segment, brand partner, demographic).

This is what makes the brand-partner API tractable. When a partner queries through the API, their token projects onto their slice of the segment vector. They see facts whose segment vector intersects their projection. They see nothing outside it, and the platform gives them no signal that anything was filtered. The same corpus serves a hundred partners without leakage.

Every claim in every report, every row in every dashboard, every retrieval into your AI agent links back to the transcript that produced it through the chunk identifier. The link is always present, on every conversation, with no sampling. A brand partner asks why you claim their product loses to a substitute: the answer is three chunk-IDs, three advisor utterances, three timestamps, in three named stores. Not an inference. A receipt.

The verbatim chain is enforced by the pipeline. Every quote that leaves the system is a literal substring of a real user turn from a real interview. A deterministic filter verifies this before persistence. Invented quotes are deleted, never rewritten. The full description of the chain is on the Trust & Security foundation page.

The same corpus serves three surfaces. Your strategy, merchandising, or operations team consumes it through dashboards. Your brand partners consume it through a scoped API. Your AI agents consume it through MCP tools. Each surface enforces its own scope at the data path. A partner does not see another partner’s slice. An advisor copilot sees only the facts its OAuth session ticket allows. The full security cascade is documented under the Security Cascade.

The MCP surface hides the dual-store complexity. Agents do not have to choose between graph traversal and SQL. They call query_facts, traverse_relations, pivot_dimension, replay_as_of, and cite. Every answer comes back as structured rows with citation. The agent never sees the underlying store boundaries.

Inside your tenant, the operator console gives your team the working view of the layer. You see the corpus health per market and per dimension, the staleness clock for each dimension, the per-conversation quality scores from the interviewer audit, and the audit trail of every enrichment call. When something looks wrong, you can trace it back to the exact LLM call that produced it, with model identifier, prompt version, token counts, and duration.

When a domain expert in your team disagrees with an interpretation in their context, they correct it from the console. The Expert-in-the-Loop loop finds every conversation in the corpus that matches the context, re-pipelines them, and propagates the correction across the historical record. The prior interpretation stays in the audit trail. Nothing is silently overwritten.