06-reference/research

data infra closed loops deployment telemetry

2026-05-11·research-brief
moat-thesisdata-flywheelvendor-lock-indata-sovereigntycontract-termstelemetryrdco-positioning

Data-Infrastructure Closed Loops: Who Closes the Telemetry-to-Training Loop, and How

Headline finding

In data infrastructure today, the legitimate "deployment telemetry trains the vendor's next product version" loop is the exception, not the rule. The two pure cases are Salesforce Einstein (default-on, opt-out, recently softened to self-service in Spring 2026 after backlash) and Palantir Foundry (opt-in by design, mediated through the Ontology). Snowflake and Databricks both publicly disclaim training on customer data; their loop is the opposite shape — customer-data-stays-put, vendor brings the model. dbt, Tableau, and Power BI collect product telemetry (events, usage), not customer data, and offer opt-outs. The "loop is the moat" pattern Avedissian describes for robotics has weaker analogs in data infra than the framing implies, because contract terms and enterprise procurement actively block the loop closure that he names as the moat.

Implication for the personal-data-sovereignty thesis: the differentiation thins. RDCO's "user owns their data" pitch is not meaningfully differentiated against Snowflake, Databricks, dbt, or even Tableau, all of which already disclaim training on customer data in their enterprise tier. It IS differentiated against Salesforce (default-on telemetry training until Spring 2026) and against any consumer-grade SaaS where the loop is closed by acceptance of free service. The sharper RDCO wedge is not "we don't train on your data" (that's table stakes in enterprise data infra) but "we don't extract derived insights, query patterns, or usage analytics that constitute a parallel data asset for us" — the Datadog-style human-interface harvest, which is structurally different from model training.

Method

Taxonomy: three distinct loop-closure shapes in data infra

The robotics-style "deployment telemetry trains the next model" loop is one shape. In data infra, it splits into three:

Shape A: Locked-in telemetry training (vendor harvests by default)

Mechanism: Master Subscription Agreement grants vendor rights to use customer data for "service improvement" / "model training" / "research and development." Default-on. Opt-out exists but is buried.

Canonical example: Salesforce Einstein (pre-Spring 2026).

This is the closest SaaS analog to Avedissian's robotics loop. Notable that Salesforce got pressured into a self-service opt-out in Spring 2026 — a signal that the "default-on training" model is becoming socially expensive even when contractually permitted.

Shape B: Opt-in flywheel (vendor closes loop only with explicit customer cooperation)

Mechanism: customer explicitly chooses to share derived assets (RL traces, deployment outcomes, fine-tuned weights) back to the vendor in exchange for product improvement, often as part of a paid co-development or beta program.

Canonical example: Palantir Foundry + AIP.

Secondary example: Turing. Per [[06-reference/2026-04-30-jonathan-siddharth-turing-superintelligence-loop]], Turing positions its data-deployment loop as the moat — but the loop closes through Turing's engineers deployed into Fortune 500 enterprises, generating data Turing then sells to frontier labs. Customer signs a services contract, not a data-share agreement. The loop is mediated by labor, not by terms-of-service-grant. This is closer to a consultancy-flywheel than a true SaaS telemetry loop.

Shape C: Vendor improves itself, not its model, from product telemetry

Mechanism: vendor collects anonymized product-usage events (which buttons clicked, which queries ran, which errors hit) to improve the product UX. Customer's actual data is never touched. This is the dominant pattern.

Examples and contract specifics:

The structural pattern

In SaaS data infra, the loop that Avedissian names as the moat is contractually disclaimed by the leaders. Snowflake and Databricks compete on not harvesting customer data. The reason is procurement: Fortune 500 buyers won't sign deals where the vendor can train on their proprietary data. The "we don't train on your data" clause is now table-stakes in enterprise data-infra MSAs.

This means the loop closes elsewhere:

  1. Through the product UX (telemetry on which features get used → roadmap)
  2. Through Snowflake/Databricks's own model training corpora (Arctic, DBRX) trained on public/licensed data, then sold back to customers as in-platform inference
  3. Through pattern accumulation in the vendor's professional services / ecosystem (Palantir's Ontology playbook, Turing's deployment muscle)

The contract terms that would enable the robotics-style loop are precisely the terms enterprise data-infra vendors had to give up to win enterprise deals.

Cross-check: does this contradict the vault thesis cluster?

It partially does, and that's the most useful finding.

The vault thesis (Turing piece, Mitohealth 5-layer piece, Avedissian piece) treats "the loop is the moat" as a near-universal AI-era pattern. In enterprise data infrastructure, contract terms and procurement reality have shut the loop in its strongest form. What remains is opt-in flywheels (slower, smaller telemetry pool) and product-UX telemetry (doesn't actually train the next model, just informs the next roadmap).

The Datadog/Natkins piece [[06-reference/2026-04-28-semi-structured-datadog-moat-human-keyboard]] is consistent with this finding but at a different layer: Datadog's moat is human-interface lock-in, NOT customer-data harvesting. Datadog doesn't train models on customer telemetry; it charges customers to store their own telemetry and locks them in via dashboard muscle memory. That's a fourth shape: Shape D — interface lock-in masquerading as a data loop.

Implications for RDCO

Personal-data-sovereignty thesis: re-assess

The May 10 thesis (RDCO differentiates by "user owns their data, vendor doesn't harvest") needs sharpening:

Sanity Check angle (NOT derivative)

The vault Sanity Check ban on derivative pieces is satisfied here. Original re-frame: "In data infrastructure, the loop the AI thesis crowd celebrates is the loop the contracts forbid." The robotics framing assumes vertical-integration freedom that doesn't exist in B2B data; the contract-terms reality is the missing factor in the loop-is-moat thesis cluster. Worth queueing.

What to track

  1. Does Salesforce's Spring 2026 self-service opt-out cause measurable opt-out rates, and do other vendors follow? (Tells us whether the harvest model is dying in real-time.)
  2. Does Palantir's opt-in-by-Ontology pattern get copied? (Tells us whether the Shape B compromise is the sustainable middle ground.)
  3. Does any data-infra vendor try to build a cross-tenant training loop with explicit customer revenue-share? (Would be a genuinely new shape — closest analog: Foursquare's location-data-as-product play.)

Follow-up questions surfaced

  1. What does the Salesforce Master Subscription Agreement actually say about "Customer Data" use rights for AI training, verbatim? (VantagePoint piece references it but doesn't quote.)
  2. Has any enterprise customer publicly negotiated a data-sovereignty rider into a Snowflake/Databricks contract? Procurement intelligence on what's actually negotiable.
  3. What's Hex's actual telemetry posture? They sit between dbt and the warehouse and their notebooks contain analyst intent — extremely high-signal training data if they harvest it.
  4. Does Glean / Notion AI / Dropbox AI train on customer corpora? These are the closer enterprise-collaboration analogs to the robotics loop and weren't covered in this pass.
  5. What's the right RDCO contract-clause language to make "no derived-asset extraction" enforceable, given that Snowflake-style "no model training" disclaimers leave Shape C harvesting wide open?

Sources

Vault:

Web: