Profonti is a single-tenant data repository your team operates, with citation and definition guarantees baked into the query path. This page describes what we promise — not how we make it work.
If you're evaluating Profonti as a CTO, architect, or DBA, this is the surface you need to understand. The deeper internals are intentionally not on the marketing site; we share them under engagement scope. Ask in Discovery and we'll go as deep as you need.
Single-tenant by default — your Profonti repository runs in your Kubernetes namespace, on your database, in your cloud or colocation account. There is no shared control plane and no cross-customer data path; there is nothing to "go wrong" between customers because there is no between.
Every answer Profonti returns carries the row set it was computed from, the query that produced it, and the timestamp of the underlying source data. This is a structural property of the query layer, not a post-hoc explanation step. If an answer can't be cited, it isn't returned.
Business terms are versioned and attached to queries. Re-running the same question against the same data version yields the same answer. Definition changes are explicit, dated, and visible in every downstream artifact — digest, alert, slide, CSV.
Each Profonti engagement runs as a self-contained workload in your environment.
There is no Profonti SaaS plane in the data path. Configuration and deployment automation live in our control plane; data, queries, and results stay in yours.
Each connector implements a small, well-defined contract: discover, pull, materialize, document. Discovery introspects the source schema; pulls run incrementally against a watermark; materialization lands the data into named tables in your repository; documentation emits a machine-readable description of what was loaded and when.
What this contract gives you in practice:
We ship connectors for the platforms enumerated on the Features page. Custom connectors are written under engagement scope; the code lands in your repository, under your perpetual license.
Cross-source identity resolution is the part of Profonti most people ask about. Without disclosing the internals:
vendor_email column in
System A is canonical for Customer").customer_id,
franchise_id, product_id, etc.) attached to every source row.The resolution strategy is part of the engagement scope and is documented in your Build deliverables. We do not publish the internals because the resolution graph is your competitive surface as much as it is ours.
| A common concern | Profonti's posture |
|---|---|
| "Will my data sit alongside someone else's?" | No. Each engagement is a separate cluster, separate database, separate namespace. |
| "Will the AI hallucinate a number?" | An answer without a citable row set is not returned. The query layer enforces it. |
| "Can I read what your code actually does?" | Yes — under the perpetual license, you have the source. Customers regularly review it during Discovery. |
| "What happens if Profonti the company disappears?" | You still have a running cluster, a database, and the source code. Your repository keeps working. |
| "How do I observe what it's doing?" | Standard Kubernetes telemetry — metrics, logs, traces — into your observability stack of choice. |
| "What about compliance?" | The data plane is yours. Apply the controls that apply to your environment; Profonti doesn't add a separate compliance surface. |
Profonti emits structured logs, OpenTelemetry traces, and Prometheus metrics in your namespace. There is nothing exotic to instrument; standard cluster tooling sees Profonti the same way it sees any other workload.
Specifically:
All of this lands in your stack: Grafana, Datadog, New Relic, Splunk — whatever you already run. Profonti does not host a parallel observability product.
We don't disclose:
If you're evaluating Profonti seriously, ask in Discovery. We share internals under engagement scope routinely; we just don't publish them.