VEN-06 · Data moat or data debt?

Inventory every piece of data your venture would need to build and run — training data, operational data, whatever accumulates from customers. Then mark the parts you do not have, cannot get, or have no permission to collect. Is what remains actually a moat, or is it a liability with a storage bill?

The venture concept and its model-dependent features. For each data need: what it is, where it would come from, who owns it, what permission would be required, and what it costs to obtain and hold. Where the data concerns students, patients, or minors, the applicable rule is part of the inventory — FERPA for education records (https://studentprivacy.ed.gov/), and the division's own policy where a school is the customer. This brief inventories; it collects nothing.

Assuming customer data is yours to train on because it passed through your product — that is a contract and consent question, not a technical one. Counting public data as a moat when a competitor can download it too. Ignoring retention and deletion cost, and what happens to the moat when a customer leaves and asks for their data back. Treating "we'll figure out permissions later" as a plan. Forgetting that data about minors changes the answer to nearly every question here.

A data inventory: every need with source, owner, permission required, and current status (have / could get / cannot get); a defensibility assessment stating plainly which items a competitor could replicate and how fast; the permission gaps marked as blockers, not to-dos; the retention, deletion, and breach-exposure cost of holding it; and a one-line verdict on whether this is a moat, a cost, or a liability.

CT: separating scarce data from merely accumulated data. CR: designing around what you cannot get. CO: a peer argues a competitor could replicate the moat next quarter. CM: an inventory a buyer's IT reviewer could read. CZ: the people whose data this is, who are not in the room.

A founder, data engineer, or privacy or compliance professional reviews the permission gaps. Standing instruction: reject any inventory that lists a permission gap as a to-do rather than a blocker. School-supervised.

R1: one venture, one complete inventory. R2: each item traceable to a named source and owner. R3: comparator is what a competitor could assemble from public data. R4: retention, deletion, and breach exposure addressed. R5: readable by a buyer's IT reviewer. R6: names what the venture will not collect.

(a) "Our data is our moat," with no inventory and no permission analysis. (b) A plan that quietly assumes customer data can be trained on by default.

Lane A immediately. Strong pairing with VEN-08. No verified credit claim.