You own the tenant, the data, the schema, and the corpus.

The intelligence layer that Nexa Intelligence operates is yours. The cloud account is yours. The raw conversations, the enriched fact store, the dashboards, the schema that types the corpus, and the AI agents that query against it live on infrastructure you control. If you decide to end the vendor relationship, your deployment keeps running on the same account, against the same data, under the same schema, with no break in continuity.

This page covers what ownership means in practice: the schema, the corpus format, the portability path, and what happens at the end of the engagement.

The Cloud Harness installs inside your own Cloudflare, AWS, Azure, or on-premise account. Storage, compute, the audit log, the secrets vault, and the key management all sit on credentials your IT controls. There is no separate Nexa-controlled environment that holds a copy of your data. See In-Tenant Deployment for the topology.

Billing for the underlying infrastructure goes to you, because the resources are yours. Our contract covers the operation of the platform, the methodology, and the agent-side intelligence work. The infrastructure cost is line-item separable from the engagement.

Every fact in the corpus is typed against the same schema. Ten dimensions cover the substance of a brand-perception interview: pain points, opportunity scoring, brand perception, market signal, customer-segment behavior, competitor mention map, AI-readiness scoring, training gaps, retention drivers, and regulatory or compliance risk. The schema is published. You can read it, fork it, and run your own analytics against it without our involvement.

The fact row carries three independent timestamps: learned_at (when the system observed the fact), valid_at (when the fact became true in the world), invalid_at (when it stopped being true). It also carries a sparse segment_vector describing which slice of the population the fact applies to. The schema is bi-temporal and segment-aware from the first deployment.

Provenance is part of the row. A source_chunk_id field of the form transcript_id / turn_id / sentence_id links every fact back to the exact sentence of the interview that produced it. The link is mandatory. There is no fact without a source chunk.

The raw datalake holds the original audio and transcripts in standard formats: .mp3 for audio, .json for transcripts and per-conversation metadata. The files sit in object storage (R2 on Cloudflare, S3 on AWS, Blob on Azure, MinIO on premise) with deterministic key prefixes that include the matrix identifier. Nothing about the file format is proprietary.

The enriched fact store sits in Postgres-compatible storage (Postgres with Apache AGE for the graph layer, or Cosmos DB / DynamoDB on the cloud variants). The schema is exposed as SQL views and as a REST API. The Model Context Protocol server that fronts the corpus for AI agents is the same surface a human analyst can query against. Standard SQL, standard REST, standard MCP.

Two open standards anchor the temporal model: the Zep bi-temporal model and the mem0 fact-decay model. Both are published. Our implementation extends them with the per-dimension half-life calibration and the segment vector. Replacing our implementation with an alternative one is a code change against the published spec. It is not a vendor re-platforming.

Two export paths cover the corpus. The first is a full object-storage copy of the datalake plus a SQL dump of the fact store. That single archive reconstructs the deployment elsewhere. The second is a streaming export against the query API and the MCP server, for partners who want to mirror the corpus into their own analytics platform on an ongoing basis.

Both paths preserve the chunk identifier on every fact, so provenance survives the export. A claim moved into your data warehouse can still be traced back to the source interview turn through the same identifier the dashboard uses.

Export is a button in the operator console. We do not gate it behind a renewal conversation or a paid request.

If you end the vendor relationship, the deployment on your cloud account continues to operate. The capture pipeline keeps writing to the datalake. The enrichment pipeline keeps producing fact rows against the same schema. The dashboards keep rendering. The AI-agent endpoints keep answering against the corpus. The methodology configuration is in your account, in the form of versioned plan blobs and registered prompt hashes. Nothing depends on a live connection to Nexa.

What you lose is operator support, methodology calibration, and platform updates. The system continues. The intelligence layer continues. Your IT can hand the operating responsibility to another vendor or operate the platform in-house. The contract names the transition runbook so the handover follows a procedure rather than a renegotiation.

The bi-temporal model gives you replay. A brand partner can run today’s query and the same query as it would have answered six months ago against the same corpus. The state of the corpus on April 12, 2026 is reconstructable from the timestamps on the fact rows. Audits that ask “what did the system say on the date of the buying decision” are answerable.

This is the property that makes a brand-partner API underwritable in a contract. A static RAG index cannot answer the as-of question. The bi-temporal fact store can.