Data as a product, and its contract

Nothing on Tideline's screen is lying, in the sense session 1's Tufte lens checks. The number is computed correctly. What is missing is everything that would let a stranger decide whether to trust it: what unit is 48231 in, who is accountable when it is wrong, where did it come from, and is it safe to look at with someone else in the room. A chart can be perfectly drawn and still fail every one of those.

Data Mesh names the underlying shift directly: treat data as a product, not as a by-product of some other system. A product has a spec. A by-product has whatever fell out of the pipeline that day.

• Data contract - a written promise about a dataset: its owner, its schema, its licence, its freshness, and how it can be reached. What this session's validator scores.
• Data product - Data Mesh's term for a dataset treated as something with a consumer, not just an artifact of a pipeline.
• Provenance / lineage - a traceable record of where a piece of data came from and what transformed it along the way.
• Data-quality dimension - one axis a dataset can be measured against, such as timeliness or completeness. DAMA UK names six.
• Modelling fork - two architectures that solve the same problem from opposite ends, neither one strictly correct. Kimball and Inmon is the classic example.

A data contract is the artifact that makes the second principle concrete. It is the spec a consumer reads before trusting a number, and it is exactly what the validator later in this session scores.

"Federated computational governance" is the principle most often skipped, because it sounds like a committee. Dehghani's point is closer to the opposite: rules like classification and access policy should be enforced by the platform automatically, the same way a schema is enforced automatically, rather than relying on every team remembering a wiki page. D17 is exactly what happens when governance is a wiki page - a rule that exists, unread, while the emails sit in the clear regardless.

R1.2, detailed provenance, is D16 by another name: no lineage means the Reusable principle fails before anyone even gets to licensing. F4, indexed in a searchable resource, is why nobody outside the team who built Tideline's contract knows it exists at all - there is no catalog entry, so the dataset cannot be found by anyone who did not already know to look. A1.2, authentication where needed, is the FAIR sub-point that D17 violates in spirit even though D17 is not primarily a FAIR failure: access exists, but nothing about it distinguishes who should and should not see a customer's email address.

FAIR was written for scientific data repositories, where the cost of an unfindable or unreusable dataset is a paper nobody can reproduce. The same fifteen sub-points map cleanly onto enterprise analytics because the underlying failure mode is identical: a number exists, but nobody besides its creator can locate it, trust its origin, or reuse it without re-deriving it from scratch. The vocabulary changes - "repository" becomes "catalog", "researcher" becomes "analyst" - the checks do not.

Dehghani's eight characteristics - Discoverable, Addressable, Understandable, Trustworthy and truthful, Natively accessible, Interoperable and composable, Valuable on its own, Secure - come from the 2022 book, Data Mesh: Delivering Data-Driven Value at Scale, which is paywalled. Her original 2020 martinfowler.com article, which is freely readable, uses looser and explicitly non-exhaustive phrasing: "discoverability, security, explorability, understandability, trustworthiness, etc." Cite the book for the count of eight, and the article for where the idea originated.

DAMA UK's six data-quality dimensions - accuracy, completeness, consistency, timeliness, validity, uniqueness - come from an October 2013 whitepaper behind a members-only wall. The six names are stable across every secondary source that quotes them, which is why this session teaches them with confidence, but the exact wording of each definition should be treated as travelling through a paraphrase rather than a direct quote.

Ralph Kimball's bus architecture and Bill Inmon's Corporate Information Factory are both full books' worth of design guidance, not manifestos, and neither author ever compressed his approach into a numbered set of tenets the way Nielsen or Wilkinson's teams did. What survives in practice is the fork itself: build fast, process-oriented marts first and unify them later with conformed dimensions, or build one normalized source of truth first and let marts derive from it. Most real warehouses today are some negotiated mixture of both, which is itself evidence that neither side ever needed a numbered list to be useful.

The honest framing matters here for the same reason it mattered for Norman and Tufte in session 1: presenting either architect's ideas as "the seven principles of Kimball" invents a citation that does not exist.