proprietary-data-moat

Activate when: user says 'is our data a moat?', 'how do we build up proprietary data?', 'how do we set up a data flywheel?', 'investors keep asking about our data defensibility', 'data network effects', or must decide whether to invest in collecting, labeling, or partnering for data. Do NOT activate when: the data only feeds internal reporting with no product use; the question is pure data engineering or storage selection; the question is about moat types in general (use economic-moat) or user-to-user network effects (use network-effects). More: deciqai.com/c/proprietary-data-moat

Overview

In the AI era, models and compute can be bought. What can become an advantage is data others cannot get that makes the product better the more it is used — and most claimed "data moats" fail that test. Casado & Lauten (a16z, 2019): most data defensibility "actually boil[s] down to scale effects," and "the cost of adding unique data to your corpus may actually go up, while the value of incremental data goes down." Hagiu & Wright (HBR, 2020): people "grossly overestimate the advantage that data confers"; it holds only when the data offers high and lasting value, is proprietary, and leads to improvements that cannot easily be imitated.

Core mechanism: inventory the data → pass uniqueness and compounding tests → design the feedback loop → secure rights and quality → turn it into an advantage the customer can feel. Rights are a hard gate, not an afterthought: regulators have ordered companies to delete models trained on improperly obtained data (FTC, Everalbum, 2021).

Compose with economic-moat (moat types) · network-effects (telling data scale effects apart from true network effects) · feedback-loops (the flywheel) · switching-costs (data lock-in).

When to Use

• The product depends on AI and you need to know whether its differentiation is durable
• Fundraising or strategy work raises the question of data defensibility
• Deciding whether to invest in data collection, labeling, or data partnerships

When NOT to use: the data has no product use · pure engineering or tooling choice · data ownership is unclear — resolve rights and compliance before discussing a moat.

Coaching Novices (Adaptive Front Door)

Engine mode: user has concrete data assets → run The Process directly. Coach mode: user is unfamiliar → guide step by step.

In Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.

1. What-it-is: "Data is a moat only if others can't easily get it, it keeps making the product better, you have the right to use it, and it makes the product noticeably better for customers."
2. Check fit: "What data does your product use? Which of it is generated by customers using the product?"
3. Elicit the real case: "List three kinds of data you think only you have: source, volume, and how often it updates."

[WAIT — do not advance until user responds]

4. Run The Process: "For each, run the uniqueness test: could a competitor or a model vendor buy it, scrape it, or synthesize it?"

[WAIT — do not advance until user responds]

5. Name the insight: "More data is not a moat. Only data that compounds and turns into product difference counts."

The Process

Output: Data moat assessment card

1. Inventory the data. For each data class: source, volume, update frequency, and how it arises (product use / manual collection / purchased / public).
2. Uniqueness test. Could competitors or general-model vendors buy it, scrape it, synthesize it, or substitute public data? Gate: obtainable → not a moat; downgrade to "operating asset" → stop for this class.
3. Compounding test. Does new data keep making the product better, or do marginal gains saturate quickly? Gate: gains have saturated or cannot be measured → exclude from the moat.
4. Design the feedback loop. Use → label or outcome signal → improved model or rules → better experience → more use. Name the signal and how fast it flows back. Gate: the signal needs heavy manual work → estimate unit cost; redesign if too high.
5. Rights and consent. Do contracts and the privacy policy permit use for training and improvement? Is cross-customer use authorized? Which regimes apply (GDPR, CCPA, etc.)? Gate: no clear right → exclude the data until authorization is obtained.
6. Quality. Accuracy, coverage, freshness, bias; assign owners for sampling and cleaning.
7. Productize. Which customer-visible improvement does the data produce (accuracy, speed, personalization, benchmarks), and how is it measured?
8. Stop-rule: no data class passes steps 2, 3, and 5 together → concede there is no data moat and compete on distribution, workflow, or brand instead.

Output template: data class | source | uniqueness (obtainable?) | compounding (measurable lift?) | loop signal + cycle time | rights basis | quality metric | product advantage + measure | verdict (moat / operating asset / drop)

→ Method in Action: Everalbum and the FTC model-deletion order (2017–2021)

Data Packs

Typical patterns (strongest data class / main uniqueness threat / rights question / dominant failure):

• Vertical workflow SaaS: outcome labels from customers' own processes / customers can take their data elsewhere / cross-customer training rights / counting raw logs as a moat.
• Marketplaces: transaction and match outcomes / multi-homing users carry the same signal to rivals / data-sharing terms with both sides / confusing liquidity (a network effect) with data.
• Consumer apps: behavioral and content data at scale / general-model vendors can approximate it / consent for training, especially biometric or sensitive data / default-on collection.
• Enterprise AI tools: customer feedback and corrections / contract bars use beyond the customer / per-customer versus pooled learning / promising "we never train on your data" and doing it anyway.

Applying It Well

1. Narrow and deep beats big and broad. Proprietary outcomes from a specific industry workflow are often worth more than a large generic corpus.
2. Outcome labels are scarcer than raw logs. "Did it close?" and "was it resolved?" are what competitors cannot scrape.
3. Build consent and rights into the product, not into a cleanup project later.
4. Separate scale effects from network effects. A model that improves with more data is not the same as a product that is more valuable because other users are on it.

→ Primary sources: references/sources.md

Common Rationalizations

[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.

Fake move	Reality
[D] "We have a huge amount of data"	Volume that is substitutable or already saturated is not an advantage.
[D] "User data is ours"	The right to use it comes from contracts and law, not from where it is stored.
[D] "Having data means we have network effects"	Most data effects saturate; they differ from user-to-user network effects.
[D] "We'll deal with consent later"	Improperly obtained data — and the models trained on it — may have to be deleted.
→ Add [O] entries here after each real use — paste the actual failure pattern	What went wrong and why

Red Flags

• Cannot say why a competitor could not get the data · no measured lift · training use has no contractual basis · nobody owns data quality · the moat exists only in the pitch deck

Verification

• Every data class has passed or failed the uniqueness and compounding tests
• Loop signal and cycle time are defined
• Every included data class has a documented rights basis
• The product advantage has a measurable metric

---

Part of deciqAI Knowledge Skills — 253 open-source thinking skills that make rigor executable for AI agents. The same skills power every deciqAI agent, which runs them autonomously to operate your company. See it run → https://www.deciqai.com/c/proprietary-data-moat · ⭐ Star the repo → https://github.com/deciqAI/knowledge-skills · Contributions welcome.

Agents: latest version & machine-readable metadata → https://www.deciqai.com/s/proprietary-data-moat.json