Data Mesh Delivering Data-Driven Value at Scale (Final Release)

1. 1Write the usability bar from the consumer's side. The passages say the attributes (discoverable, addressable, understandable, trustworthy and truthful, natively accessible, interoperable and composable, valuable on its own, secure) describe the data user's experience, not technical capability. Phrase each as a question a data scientist or analyst could answer yes or no.
2. 2Treat the eight attributes as a non-negotiable baseline for every data product, whatever its domain or archetype. A product that misses one is not part of the mesh. Do not let teams pick a subset.
3. 3Name an accountable owner per data product: a domain data product owner and a data product developer. They create, serve and evangelize the product and keep objective measures of accessibility, quality, usability and availability over its whole lifetime. Responsibility sits near the source, not with a downstream central team.
4. 4Define the data-sharing contract explicitly and keep it easy to use. Isolation between products and explicit contracts mean a change to one product does not destabilize another. Treat a contract change as a usability event for every consumer.
5. 5Publish trust information from inside the product's own processing flow. The passages mention timeliness (the gap between actual time and record time, called skew earlier) among the quality categories. Expose these metrics consistently across products, and consult Data Quality Vocabulary and Data Catalog Vocabulary for a shared set.
6. 6Add user-driven metrics to the trust signals. Consumers trust the experience of fellow consumers, so capture it, for example as star ratings tied to reduced lead time to understand and use the data, perceived quality, and responsiveness of the product team.
7. 7Measure success by data-user happiness, not data volume. Track the friction the passages name: the effort to discover, understand, trust, explore and consume. Use lead time to discover and use a data product as the operating number.
8. 8For source-aligned products, model business reality as closely as possible with minimal assumptions about use. Serve it in a form that keeps future consumers' options open, such as a high-resolution event log, and still meet every baseline attribute for today's known consumers.

The source's running company is Daff, a music streaming business. A source-aligned domain there captures play events. The passages call capturing all play events as an infinite high-resolution log a safe choice, because future users can build transformations and infer insights nobody has thought of yet. Usability asks whether those future users can actually benefit. Walk the attributes as a consumer. Discoverable: can an analyst find the play-events product without asking around? Addressable: does it have a stable, unique address? Understandable: do the meaning and provenance of the events travel with the data? Trustworthy: does the product publish its own timeliness (the gap between when a play happened and when it was recorded) and its consumers' star ratings? Natively accessible, interoperable, secure: can a data scientist and an analyst each use it in their native way, combine it with other products, and get access safely? Valuable on its own: is it useful without being joined to anything else? The product owner then tracks lead time to discover and use the product as the success measure, and fixes whichever attribute lengthens it. The motivation is the Anaconda finding in the passages that nearly half of a data scientist's time goes to data preparation, which this check is meant to cut.

• If a team proposes shipping a data product that lacks any one of the eight attributes, then it is not ready to join the mesh. The baseline is non-negotiable.
• If the team's success report is about data volume or number of platform capabilities, then replace it with user happiness and lead time to discover and use.
• If consumers still spend large effort cleansing and preparing data, then treat it as a usability defect in the product, not as a consumer skill gap.
• If a product is source-aligned, then model reality with minimal assumptions about future use. If it is consumer-aligned, then it can be shaped more tightly to its known consumers.
• If trust metrics differ across products, then standardize them across the mesh and use the existing vocabularies rather than letting each team invent its own.

• Reading the attributes as a technical checklist. The tell: the review discusses storage formats and pipelines, and nobody has asked a consumer about their experience.
• Distributing ownership without product thinking, so silos and a regression in usability appear. The tell: each domain has data, but consumers cannot find or understand it outside that domain.
• Leaving trust to the central team or an external catalog. The tell: quality and timeliness information is missing from the product itself, or each product reports it differently.
• Ignoring consumer feedback as a trust signal. The tell: no ratings or responsiveness measures exist, and users rely on word of mouth.
• Optimizing a source-aligned product only for today's known use case. The tell: the data is shaped so narrowly that future consumers cannot reuse it for new insights.

• ▸Data product name and domain: state the product and whether it is source-aligned or consumer-aligned.
• ▸Accountable owners: name the domain data product owner and the data product developer.
• ▸Discoverable / Addressable: record how a new consumer finds the product and what its address is.
• ▸Understandable: list the meaning and provenance information that travels with the data.
• ▸Trustworthy and truthful: list the published quality metrics, including timeliness, and where consumer star ratings appear.
• ▸Natively accessible / Interoperable: state how each consumer type (analyst, data scientist) accesses it and which other products it combines with.
• ▸Valuable on its own / Secure: state the standalone value and the access and security controls.
• ▸Data-sharing contract: link the explicit contract and note any pending change that affects consumers.
• ▸Lead time to discover and use: record the current figure and the attribute causing the most delay.

1. 1Name the roles you are optimizing for before you design anything: data product developer, data product owner, and data product consumer. Write each role's journey as a sequence of steps, e.g., build, test, deploy, monitor, evolve for developers; search, discover, connect, query, subscribe, join for consumers.
2. 2Treat the platform as a set of well-integrated services (APIs, SDKs, libraries), not one monolith. Map where each journey crosses into operational systems (e.g., streaming from a microservice) or ML tooling (experiment tracking, GPUs), and make those crossings seamless.
3. 3Split the platform into two planes. The experience plane optimizes the logical interaction with a single data product for a generalist developer. The utility/infrastructure plane handles physical and machine optimization: polyglot storage, query and workload processing across products, search and indexing, reduced data movement.
4. 4Enforce a one-way rule between the planes: a lower-plane decision (e.g., separating compute from storage, co-locating data) must not impair the developer experience, and an experience-plane decision must not deoptimize the machine.
5. 5Move governance into the platform as automation. Offer policies such as PII de-identification on write/read and standardized discoverability APIs as built-in capabilities, so a developer gets compliance by default rather than through after-the-fact intervention.
6. 6Standardize only the global interoperability surface: data sharing APIs, metadata (SLOs, documentation, data modeling language), and shared entity IDs. Everything else stays with the domain team so they are not blocked.
7. 7Give domain teams automated continuous delivery for data products, including integration with the source, building and testing transformation code, and serving, so a generalist can ship without a central middleman.
8. 8Measure enablement with the signals Daff tracks: lead time to access data, risk of change, waste in developing data products, connectivity between data products, number of teams building data solutions, and cost of data ownership. Back it with a data literacy program and career paths for the new roles.

Daff's playlist team shows the pattern. By 2019 a central data team and monolithic architecture had become a bottleneck, and returns had plateaued. Daff moved data ownership into its existing business-dev-ops domain teams, so generalist technologists became data developers. The platform's experience plane let that team create and evolve partner playlists and sports playlists data products in a short time. The flow covered integration with the source, building and testing the transformation code, and serving the data. Consuming teams could then search, connect, query, subscribe to, and join partnerships, listeners, and music profiles products to build new playlists. Meanwhile the utility plane handled polyglot storage, query processing, indexing, and reduced data movement out of the developers' sight. Global standards on APIs, metadata, and entity IDs made the cross-team joins work. Daff reports shorter lead time to access data, less waste from automated continuous delivery, more teams engaged in data-driven solutions, and lower cost of data ownership.

• If a platform optimization (storage layout, compute separation, co-location) would change what the developer must know or do, then redesign it or hide it in the utility plane; never trade developer experience for machine efficiency, or the reverse.
• If a governance requirement can be automated (PII de-identification, discoverability APIs, sensitivity levels), then build it into the platform as default behavior rather than a manual review step.
• If domain teams are duplicating effort or total cost of ownership is rising, then the fix is a platform capability that lowers their cognitive load, not a recentralized data team.
• If a user journey crosses into operational or ML tooling, then integrate that handoff into the platform instead of leaving developers to stitch it together.
• If you are starting out, then design the journey for one or two roles and pick the teams with the least headwind to change, get wins, and expand.

• Building one monolithic 'platform' instead of integrated services. The tell: developers still hop between disconnected tools and manual steps to complete a single journey.
• Optimizing the user experience at the expense of the machine, or the reverse. The tell: either slow, costly queries and heavy data movement, or infrastructure changes that force developers to relearn how they work.
• Governance as after-the-fact policing with tools that qualify and fix problems once data lands in a lake. The tell: errors are found late, far from the source, and domains wait on a central function.
• Asking generalists to take on data work with no education or career path. The tell: data skills stay concentrated in specialists and the central team remains the bottleneck.
• Over-standardizing beyond the global surface, or leaving it unstandardized. The tell: either domains wait on central approvals, or data products can't be joined because APIs, metadata, and entity IDs differ.

• ▸Role: name the persona (data product developer, owner, or consumer) whose journey you are auditing.
• ▸Journey steps: list each step in order (e.g., integrate source, build/test transform, deploy, serve, monitor, evolve).
• ▸Manual or specialist-only steps: mark every step that still needs a ticket, a central team, or deep data-engineering knowledge.
• ▸Platform service covering each step: name the API, SDK, or service that makes the step self-serve; write 'gap' if none.
• ▸Experience-plane vs utility-plane owner: state which plane handles each concern and confirm the lower plane does not leak into the developer's work.
• ▸Cross-boundary handoffs: note points where the journey touches operational systems or ML tooling and whether the handoff is seamless.
• ▸Automated policies: list governance rules (PII handling, sensitivity levels, discoverability) applied automatically versus manually.
• ▸Enablement metrics: record baseline and target for lead time to access data, waste in delivery, number of teams building data products, and cost of ownership.
• ▸Skill and training gap: note the literacy or career-path support the role needs.

1. 1Name the cross-domain questions first. Pick the joins, filters, and aggregations the mesh must support (for example, artist activity across play events and royalty payments). Interoperability exists to produce higher-order value from correlated, independent data products, so standardize only what those questions need.
2. 2Define a common, explicitly defined type system for fields. Every data product declares field types from this one system, so a join never depends on guessing what a column means.
3. 3Pick a global identifier scheme for polysemes, the entities that cross domain boundaries. List each entity that appears in several domains (artist is the passage's example), then agree on one global identification scheme. Each domain keeps its local attributes and identifiers but also carries the global one.
4. 4Allocate every data product a unique global address under a uniform scheme, so consumers connect to any product the same way.
5. 5Standardize common metadata fields, especially two time representations: when the data occurs and when it is recorded. Make these mandatory on every product.
6. 6Enable schema linking and data linking. Let products reuse types defined by other products and map to data in other products. Record the degree of linkage as a data maturity factor.
7. 7Set a schema stability rule: schemas evolve only in backward-compatible ways, so downstream composition does not break when an owning domain changes.
8. 8Where a domain standard exists, adopt it (FHIR HL7 in healthcare) and declare the conformance. Then have the platform check these standards automatically on every product, notify when they are missing, and add adoption of the latest global policy to each domain owner's success measures.

At Daff, artist is a core concept in several domains. The play events data product knows the artist one way, and the payment domain, which handles invoices and royalty payments, knows it another way. The artist is the same global entity, but its attributes and likely its identifiers differ in each domain. To correlate play activity with royalty payments, Daff has to agree on how an artist is identified globally across all data products. Each product then carries that global identifier next to its local one. The products also share a type system, a uniform global address scheme, and common time fields (occurred and recorded). With those in place, an analyst can join play events to payments by artist and aggregate without a bespoke mapping between the two domains. The two domain teams still own and evolve their own products.

• If an entity appears in more than one domain with different identifiers, then define a global polyseme identifier before anyone builds cross-domain joins.
• If a standard would force domains into a shared model, then standardize only the linking surface (identifiers, types, addresses, metadata) and leave internal modeling to the domain. The aim is to balance domain autonomy with global interoperability.
• If a global policy competes with domain feature priorities, then add adoption of that policy to the data product owner's incentives.
• If a recognized domain data model exists (such as FHIR HL7 in healthcare), then adopt it to widen interoperability with internal and external consumers.
• If a schema change would break existing consumers, then handle it as a backward-compatible evolution, not a silent edit.

• Standardizing nothing across domains, so each domain's identifiers diverge. The tell: joining two data products requires a hand-built mapping table, or the same artist shows up under unrelated keys.
• Treating interoperability as a one-time rule. The tell: nobody checks that products conform, and non-conforming products appear in the mesh without notification. The platform should verify continuously and notify.
• Imposing global standards with no incentive for domains. The tell: domain teams deprioritize the policy in favor of richer features, and adoption stalls.
• Breaking schemas without regard for backward compatibility. The tell: downstream consumers' pipelines fail after an upstream domain release.
• Reading FAIR interoperability as the whole job. The tell: products are findable but lack global addresses, schema linking, or data linking, so they can't be composed.

• ▸Data product name and owning domain: identify the product and its owner.
• ▸Global address: record the unique address and confirm it follows the uniform scheme.
• ▸Field type system: state whether all fields use the common explicitly defined types, and list any exceptions.
• ▸Polyseme identifiers: list each cross-boundary entity (e.g., artist) and the global identifier carried alongside the local one.
• ▸Common metadata fields: confirm the occurred-time and recorded-time fields are present.
• ▸Schema links: list the types reused from other data products.
• ▸Data links: list the data in other products this product maps or links to.
• ▸Schema stability: state the backward-compatibility rule and the date of the last schema change.
• ▸Standards conformance: name any domain standard adhered to (e.g., FHIR HL7), or write none.

1. 1Map the current hand-offs for one real use case before changing anything. List every central team the request touches (central data and AI team, lake or warehouse team, governance team, pipeline engineering team) and record the wait at each. The Daff pre-mesh scenario is the template: prioritization queue, access request, data discovery, then a pipeline request for missing partner data.
2. 2Classify each hand-off as architectural or human. The passages name data lakes and warehouses as architectural bottlenecks and a centralized data team or intermediary pipeline team as the human ones. Look specifically for focal points of multiparty synchronization, because those are what the passages treat as bottlenecks.
3. 3Assign long-term ownership of each data product to the domain closest to the source. Daff gave partner playlist data to the partnership team because it controls the partner relationship and knows what affects the data. Write the ownership heuristic down so later assignments follow the same policy.
4. 4Replace the central lake/warehouse hop with direct consumption from source data products. Each data product exposes versioned interfaces and a stated contract for each native access mode (SQL, files, events). Consumers such as an ML training job or a report read the products directly, with no intermediary pipeline team.
5. 5Turn pipelines into internal implementation details of the data product. Pipelines stop being shared infrastructure that other teams must request changes to. They live inside the product's own logic, so an upstream change no longer cascades through a chain of copies.
6. 6Let domains change models without synchronization. Drop the shared canonical model. Have each contract support older revisions until consumers have migrated to the new one, so the domain changes its model on its own schedule.
7. 7Move governance from approval tickets to automated policy. A federated group of domain representatives defines global policies (standard sharing APIs, standard metadata including SLOs and documentation, standard shared entity IDs) and the platform enforces them automatically. Nobody queues for a governance team.
8. 8Provide self-serve platform services so teams do not wait on infrastructure. Make the platform's experience plane lower the cognitive load of data product developers. Keep physical and machine optimization (polyglot storage, query processing, indexing, reduced data movement) in the utility plane, out of the user's way.
9. 9Measure the reduction directly. Track lead time to access data, the number of teams building data-driven solutions, and connectivity between data products. These are the measures Daff used to show the bottleneck removal was real.

Daff's playlist team wants a new sports playlist. Three years earlier, this meant asking the central data and AI team to prioritize a model. Its data scientists then competed with other ML initiatives, requested data from a lake or warehouse team, and requested access from a central governance team, which added days. The data turned out to be stale because new partner integrations had not reached the central store. They also had trouble understanding it, and the lake team then had to go to a pipeline engineering team for more partner music data. The result was weeks of work, many handovers, and poor-quality data, and the effort likely never started. With the mesh, the playlist team uses partnerships, listeners, and music profiles data products directly. The partnership team owns partner playlist data because it is closest to the source. Global policies for APIs, metadata, and entity IDs are defined by a federated group of domain representatives and automated by the platform. Daff reports it reduced lead time to access data by removing central and middleman bottlenecks. New playlists are added as more connected data products rather than as requests to a central team.

• If a request needs sign-off or work from a team that does not own the data product, then treat that team as a bottleneck candidate and move the capability into the owning domain or the platform.
• If a consumer needs data it can already reach in a source data product, then connect it directly to the product's versioned interface instead of copying it through a lake, warehouse, or new pipeline.
• If a domain wants to change its data model, then have it do so locally and keep the old contract revision alive until consumers migrate, rather than negotiating a shared canonical model.
• If a governance rule can be expressed as a computable check (API standard, metadata, SLO, entity ID), then automate it in the platform instead of a review step.
• If a platform feature improves user experience but degrades machine performance, then reject the tradeoff and push the optimization into the utility plane so the user experience stays simple.

• Relocating the bottleneck: the central team is dissolved but a new platform or governance team still approves every product. The tell is that lead time to access data does not drop and requests still queue.
• Keeping the lake as a mandatory hop: data products exist but consumers still go through the central warehouse. The tell is that pipelines and copies persist between source and consumer.
• Skipping contracts and versioning: domains change models freely but with no support for older revisions, so downstream consumers break and demand coordination again. The tell is that model changes trigger cross-team synchronization meetings.
• Manual governance in a decentralized shell: policies are written but enforced by review and tickets rather than automation. The tell is access or publishing delays that resemble the old central governance queue.
• Optimizing the experience at the cost of the machine, or the reverse: a friendly platform that duplicates data and slows queries, or an efficient one that is hard to use. The tell is that teams bypass the platform or performance degrades as products are added.

• ▸Use case: name one concrete data initiative to trace end to end.
• ▸Hand-off list: each central team or manual step the request passes through, in order.
• ▸Wait per hand-off: elapsed time at each step, so the largest delays are visible.
• ▸Bottleneck type: architectural (lake, warehouse) or human (central team, pipeline team) for each step.
• ▸Owning domain: the domain closest to the source that should own the data product.
• ▸Direct access path: the versioned interface and access mode (SQL, files, events) consumers will use instead.
• ▸Policy to automate: the governance rule (API, metadata/SLO, entity ID) that the platform enforces instead of a ticket.
• ▸Contract revision plan: how old revisions stay supported and the date consumers must migrate.
• ▸Success metric: baseline and target lead time to access data.

1. 1Name the growth axes you must absorb before you design anything. The passages list three: more data sources, more data consumers, and more diversity of use cases. Write down your current count and your 12-month expected count for each. Treat these as the load your organization must carry without slowing down.
2. 2Find where change currently forces cross-team synchronization. Take your last three data changes, such as a new source or a new metric. List every team that had to touch the work (ingestion, cleansing, aggregation, enrichment, serving). If one change touched most of the stages, your decomposition is orthogonal to the axis of change.
3. 3Replace top-level technical partitioning with top-level domain partitioning. Embed the technical functions (ingest, clean, aggregate, enrich, serve) inside each domain, so a domain change is managed locally with no top-level synchronization.
4. 4Reorganize teams around an outcome (delivery of new, quality, trustworthy data), not an activity. Give each domain team end-to-end responsibility for its data's life cycle. Retire activity-oriented groups, such as an ingestion team or a mart-serving team, as the owner of delivery.
5. 5Put ownership at the domain closest to the data: either the source or its main consumers. Align business, technology, and analytical data in the same domain boundary. Check fit first: if your business already runs domain-aligned business-dev-ops teams, extend those teams with data capabilities instead of building a new structure.
6. 6Fund a self-serve platform to keep decentralization cheap. Its purpose is to cut the total cost of decentralized ownership, abstract data management complexity, and lower domain teams' cognitive load. It should let generalist technologists build data products without deep specialization.
7. 7Install federated computational governance so scale does not break interoperability. Form a team of domain representatives, platform people, and subject-matter experts (legal, compliance, security). Codify policies and automate them per data product through platform services, which removes manual synchronization between domains and the governance function.
8. 8Measure agility with the tells the passages imply: how many teams a new data feature needs to coordinate, how fast it ships as sources and use cases grow, and the ratio of value from data to investment. Review these on a fixed cadence and treat a plateau in returns as the signal to restructure.

Daff, the music streaming company in the passages, began with songs and albums, then added music events, podcasts, and radio shows. Its centralized, monolithic data architecture became a bottleneck as data sources, inside and outside the company, and their use cases multiplied. The data team slowed substantially and returns on investment plateaued. Enabling one feature, such as visibility into the podcast play rate, required changes across every pipeline component: new ingestion services, new cleansing, and so on, with synchronization between the teams for each stage. Daff checked fit before moving. Its business-dev-ops teams were already domain-aligned, and the centralized data team was one of the last functionally divided teams. So it extended domain teams with data ownership and capabilities, instead of inventing a new structure. The target outcomes were to retain agility under rapid growth and to get more value per unit of investment by mobilizing generalist technologists as data developers and users.

• If a single new data feature requires changes in most pipeline stages and meetings across several teams, then partition by domain and outcome, not by technical function or activity.
• If your business and engineering organization is already domain-aligned, then extend those teams with data ownership. If it is not, expect the organizational change to be the harder part and sequence it deliberately.
• If returns on data investment have plateaued while sources and use cases keep growing, then suspect the centralized team and architecture as the bottleneck, not the tooling.
• If decentralizing creates silos or incompatible domains, then add data-as-a-product responsibility and federated computational governance instead of pulling ownership back to the center.
• If domain teams are overloaded by data management complexity, then invest in the self-serve platform to reduce their cognitive load. Do not add specialist handoffs.

• Decomposing the data platform by pipeline stage (ingestion, cleansing, serving) and calling it scalable. The tell: every new feature needs sign-off and changes from several stage teams, and delivery slows as sources are added.
• Optimizing activities instead of outcomes. The tell: the ingestion team reports better ingestion patterns while time to deliver new trustworthy data keeps rising.
• Decentralizing ownership without a platform. The tell: each domain rebuilds its own data infrastructure, cognitive load rises, and only specialists can ship data products.
• Decentralizing without governance and interoperability. The tell: domains form silos, their data products are incompatible, and cross-cutting security and privacy need manual synchronization with a governance team.
• Adopting domain ownership without checking organizational fit. The tell: the organization has no domain-aligned teams to extend, so ownership has no natural home and the data team keeps carrying the load.

• ▸Growth axes (now vs. 12 months): count of data sources, consumers, and use-case types today and projected.
• ▸Recent change log: list the last three data changes (e.g., new source, new metric, new feature).
• ▸Teams touched per change: for each change, list every team or pipeline stage that had to change.
• ▸Synchronization points: name the handoffs, approvals, or meetings each change required.
• ▸Current decomposition: note whether top-level partitioning is by technical function, activity, or domain/outcome.
• ▸Domain alignment check: list existing business-dev-ops domain teams that could own data, and the functionally divided teams that remain.
• ▸Platform gaps: list what domain teams must build themselves that a self-serve platform should abstract.
• ▸Governance automation: list policies (security, privacy, compliance) that are still manual versus codified per data product.
• ▸Agility metrics and review date: record teams per change, lead time, value-to-investment ratio, and the next review date.

1. 1Write the ratio down before you build anything. The numerator is business value (new revenue, cost savings, better decisions). The denominator is total cost of ownership across technology, people, and processes. The passages give no formula or figures, so you set your own units and keep them stable.
2. 2Establish the baseline plateau. Daff's trigger was that investment in lakes and warehouses had continued while returns had 'plateaued' and the central team 'had substantially slowed down.' Record current spend and current outcomes so a flat or falling marginal return is visible, not anecdotal.
3. 3Split the numerator into external and internal measures. Daff tracked externally: deeper user engagement and a growing number of active listeners from applying ML and data across touchpoints. Internally it tracked lead time to access data, risk of data change, waste in developing data products, and cost of data ownership. Pick one measure per category and assign an owner.
4. 4Measure application of data as connectivity. Daff gauged data use 'by the amount of connectivity between their data products.' Count connections between data products as the network-effect indicator: more connections mean more data shared between domains to produce higher-order insight.
5. 5Count the people doing data work. Daff increased the number of teams engaged in creating data-driven solutions by embedding data ownership in each domain. Value per dollar rises when generalist technologists become data developers and users, so track the number of teams building and consuming data products.
6. 6Put the platform inside the denominator and track its effect on it. The platform's stated objectives are to lower domain teams' cognitive load, reduce unnecessary effort, increase productivity, and lower total cost of ownership. Measure end-to-end data solution creation cost and effort before and after platform services, and watch for duplicated effort across domains.
7. 7Track waste and risk as cost reducers. Daff cut waste with automated continuous delivery for data products and cut change risk with standard contracts and interfaces. Record rework, failed changes, and integration breakages as cost items in the denominator.
8. 8Review the ratio on a fixed cadence against the baseline. Ask whether the numerator measures are rising while ownership cost is flat or falling. If returns flatten again, treat it as the same signal Daff saw in 2019 and look for a new bottleneck.

Daff, the company in the passages, had invested in data lakes, data warehousing, and a large central data and AI team under a chief data and AI officer. By 2019 the central team and monolithic architecture were a bottleneck, and 'the returns of investments had now plateaued.' Daff moved to data mesh with domain ownership, data as a product, a self-serve platform, and federated governance, and then tracked the return explicitly. Externally it saw deeper user engagement and more active listeners from ML applied across touchpoints. Internally it saw shorter lead time to access data (no central middlemen), lower risk of data change (standard contracts), less development waste (automated continuous delivery), more connectivity between data products, more teams building data-driven solutions, and lower cost of ownership and of end-to-end solution creation through platform services. Daff reports the direction of each improvement but the passages give no numbers, so you copy its measurement categories, not its results. The ratio improved because the numerator grew (engagement, listeners, data use) while the denominator's per-solution cost fell.

• If investment is rising but outcomes are flat, treat it as a plateau signal and examine the operating model and architecture for a central bottleneck before adding more technology spend.
• If a cost reduction claim comes from the platform, then verify it with end-to-end solution creation cost and developer experience, not with infrastructure spend alone.
• If you can only measure one internal value indicator, pick connectivity between data products, since Daff used it as its measure of data application across the business.
• If domain ownership produces duplicated effort or higher ownership cost, then address it through self-serve platform capabilities rather than recentralizing.
• If you cannot name the business-side measure (engagement, listeners, revenue, decisions) for a data investment, then do not count it in the numerator.

• Counting only technology spend as the denominator. The tell: people and process costs (central team load, cross-team coordination, rework) are missing from the calculation.
• Reporting activity instead of value, such as pipelines built or data volume captured. The tell: capture and storage grow while engagement, decisions, or revenue stay flat, as in Daff's lake-and-warehouse period.
• Decentralizing without a platform, so domains duplicate effort. The tell: ownership cost and effort per data product rise and data sharing productivity falls.
• Measuring benefits once at launch. The tell: no baseline and no recurring review, so a new plateau goes unnoticed until the team is slow again.
• Ignoring the network effect. The tell: many data products exist but few connect, so data is not shared between domains and higher-order insight does not appear.

• ▸Baseline period and plateau evidence: state current spend and the outcome trend that shows whether returns are flat.
• ▸External value measures: list engagement, active users, revenue, or similar outcomes tied to data, with current values.
• ▸Internal efficiency measures: lead time to access data, risk of data change, development waste, with current values.
• ▸Data application measure: number of connections between data products today.
• ▸Teams engaged: count of teams building or consuming data-driven solutions.
• ▸Cost of ownership components: technology, people, process costs listed separately.
• ▸End-to-end solution creation cost: average cost or effort to deliver one data solution.
• ▸Review date and next-period targets: set the cadence and the expected direction of each measure.
• ▸Bottleneck check: name any central team or architecture constraint limiting returns.

1. 1Name the failure you are fixing before you move any ownership. Check for the Daff symptoms: a central data team that has become a bottleneck, data that is stale because new integrations have not reached the central warehouse or lake, and data scientists who cannot understand the data they are handed. If you see none of these, you have no case for change.
2. 2Identify the cross-functional domain teams that already exist around business capabilities. Ownership attaches to these teams, not to a new data-only group. Each team combines application and data roles, and the passages say data providers such as application teams and data engineers move into these domain teams.
3. 3Assign each analytical dataset a long-term owner using the Daff heuristic: the owner is the domain closest to the source, or the primary consumer, and the one that controls the relationship with the source. State the reason in a sentence. For partner playlists, it is the partnership team, because it controls the partner relationship and knows what affects partnership data.
4. 4Make the accountability long-term and explicit. Put a data product owner in each cross-functional domain team, responsible for sharing data successfully. The team owns the data's discoverability, understandability, accessibility, and usability. It does not hand the data to a central team.
5. 5Remove the middleman in the data path. The consuming domain works directly with the providing domain, peer to peer. Replace the old route of central data/AI team prioritization, then lake or warehouse team, then governance team, with a direct request to the owning domain.
6. 6Define the sharing interface the way you would for operational data. Domains publish analytical data through well-defined APIs and standard contracts, so consumers learn the meaning and provenance of the data and so the data can evolve. Harmonize identifiers across products. Daff maps music track IDs to its global track ID system.
7. 7Write the ownership heuristics down as policy. A federated group of domain representatives defines the policy, such as 'assigning long-term owners to data products,' and the platform automates it. Do not decide ownership case by case in meetings.
8. 8Provide self-serve platform services before you scale the number of owning domains. Without automated access control, default encryption of personal information, and registration in a global discovery tool, domain teams cannot take on the work. Then measure: lead time to access data, risk of change, number of teams building data-driven solutions, and connectivity between data products.

Daff's playlist team wants an intelligent sports playlist and needs data on what members play and like in a partner cycling and workout app. Three years earlier, the playlist team would have asked a central data and AI team to prioritize the model. Data scientists would then have requested data from a central lake or warehouse team and access from a central governance team, which adds days. Even then, the data would have been stale, because the partnership team's new integrations had not reached the central store, and the data scientists likely would not have understood it. Under decentralized ownership, the partnership team owns partner playlists, since it is closest to the source and controls the partner relationship. It uses the platform's data product life cycle tools to pull tracks from the partner's APIs and publish them as near-real-time snapshots of delta files. Its transformation code harmonizes the music track ID with the global track ID system so the data joins with other products. The product is built and deployed to the mesh within a few hours, and the playlist team continues its experiment without handovers.

• If a domain is closest to the source and controls the relationship that produces the data, then it owns the data product, as the partnership team does for partner playlists.
• If the domain that generates data is not the one that consumes it most, then still assign ownership by closeness to source or primary consumer, and make the owner publish through a standard interface so the other side consumes directly.
• If a request would route through a central data, lake/warehouse, or governance team before reaching the data, then treat it as an ownership gap and connect the consumer directly to the owning domain.
• If a domain cannot publish data without custom infrastructure work, then fix the self-serve platform (access control, encryption, discovery registration) before assigning it more data products.
• If an ownership dispute recurs, then take it to the federated group of domain representatives and encode the outcome as a policy the platform enforces, rather than settling each case ad hoc.

• Renaming the central team instead of distributing ownership. The tell: domain teams still file tickets with a central group to get data published, and lead time to access data does not fall.
• Assigning ownership without long-term accountability. The tell: no named data product owner in the domain team, and consumers cannot find anyone responsible when the data is wrong or stale.
• Decentralizing without a self-serve platform. The tell: each domain builds its own access control, encryption, and discovery, and publishing takes weeks rather than hours.
• Letting domains publish data in isolation with no shared contracts or identifiers. The tell: consumers cannot join products, because each domain keys entities differently (no global track ID equivalent), and the old problem of conflicting 'customer' models returns.
• Leaving ownership decisions to ad hoc negotiation instead of federated policy. The tell: similar datasets get different owners depending on who argues loudest, and the platform cannot automate the rule.

• ▸Data product name: the name of the analytical dataset being assigned, e.g. partner playlists.
• ▸Source or primary consumer: which one is the basis for ownership, and why.
• ▸Owning domain team: the cross-functional team holding long-term accountability.
• ▸Data product owner: the named person in that team responsible for sharing the data successfully.
• ▸Closeness rationale: one sentence on how the team controls the source relationship and knows what affects the data.
• ▸Consuming domains: the teams that will use the product directly, with no middleman.
• ▸Interface and contract: how the data is published (API/format/mode, e.g. near-real-time delta snapshots) and what the contract guarantees.
• ▸Shared identifiers: which global IDs the product harmonizes to so it integrates with other products.
• ▸Platform services used: access control, encryption of personal data, and discovery registration, each marked automated or manual.
• ▸Policy reference and review date: the federated governance heuristic applied and when ownership is re-examined.

1. 1Name the owning domain first. The business unit that produces the data becomes responsible for publishing it as analytical data, the same way it already publishes operational data. If no domain team can be named as owner, the data is not yet a product.
2. 2Name the consumers and their needs before choosing a model. The source states that the central warehouse team struggled because it lacked a good understanding of the data and of its consumers' conflicting needs. Write down who consumes the data and what they do with it, and talk to them directly, because the product relationship is a collaboration.
3. 3Publish through an explicit interface, treated as an API, and not as a table or file dump. Treat the interface as a standard contract for discovering and sharing the data. In the Daff example, standard contracts and interfaces are what reduce the risk of change.
4. 4Make meaning and provenance part of the product. Document what the data means and where it came from. The data lake became a swamp because of 'poor understanding and provenance', so a product that ships without both has not left the swamp.
5. 5Define the usability characteristics as acceptance criteria: discoverable, addressable, trustworthy, and the others in your list. State explicit quality guarantees the consumer can rely on. Do not leave quality as an unstated intention.
6. 6Encapsulate the data together with the code that serves it. A data product is one unit, not a dataset with a pipeline somewhere else. This is what separates it from a data lake drop.
7. 7Build and release it with software practices: testing, abstraction building, refactoring, and automated continuous delivery. The source says operational developers know these are essential and that vendor tooling often fails to support them for data.
8. 8Use the shared platform and federated governance to keep the work affordable and coherent. Domains should not rebuild infrastructure. Measure the result as Daff does: lead time to access data, risk of change, development waste, connectivity between data products, number of teams building data-driven solutions, and cost of ownership.

Daff, Inc., a digital streaming company, reached its inflection point in 2019. It had invested in data lakes and warehousing under a chief data and AI officer, but the central data team and monolithic architecture had become a bottleneck. Its data aspirations had outgrown its ability to execute. Its response was to embed data ownership in each domain and treat the data as products with standard contracts and interfaces for discovery and sharing. A platform supplied the build-and-publish services, and automated continuous delivery was applied to data products. Daff then tracked measurable outcomes. Lead time to access data fell because the central middleman was removed. Risk of change fell because of the standard contracts. Development waste fell because of automated delivery. Connectivity between data products rose, which Daff used as the measure of data being applied across the business. More teams engaged in creating data-driven solutions, and the cost of data ownership fell because developers used platform services. Externally, Daff reports deeper user engagement and more active listeners from applying ML and data across touchpoints.

• If a dataset has no named domain owner, then do not call it a data product. Assign ownership to the producing domain or leave it as raw data.
• If consumers cannot say what the data means or where it came from, then the product is not ready. Add meaning and provenance documentation before adding more data.
• If a change to the data would silently break consumers, then put a standard contract or interface in front of it. Contracts are what reduce risk of change.
• If every domain team is building its own infrastructure, then move the repeated work into the platform. The cost of data ownership should fall because teams use platform services.
• If you cannot show a measurable improvement such as access lead time, development waste, or data-product connectivity, then you cannot tell whether the product orientation is working. Pick the measures before launch, as Daff did.

• Centralized ownership under a new label: a central team still builds the data and domains only consume it. The tell is that the central team is still the bottleneck for new data and consumer needs still conflict in one queue.
• Swamp with a catalog: data is published but meaning and provenance are missing. The tell is that consumers ask the producer what columns mean or whether they can trust the data.
• Dataset without code: the data is shared but the code that serves it lives elsewhere and is not versioned or delivered with it. The tell is that no one can test or refactor the product as a unit.
• No explicit guarantees: quality is promised informally. The tell is that consumers build their own validation layers, or changes arrive without warning.
• Vendor-shaped centralization: tooling that assumes a central model, with no support for testing, abstraction building, or refactoring, shapes the practice. The tell is that data pipelines cannot be tested or refactored the way application code is.

• ▸Product name and owning domain: name the domain team accountable for it.
• ▸Primary consumers and their use: list who uses it and for what, drawn from direct conversations.
• ▸Interface and contract: describe the API or standard interface through which the data is discovered and accessed.
• ▸Meaning and provenance: summarize what the data represents and where it comes from.
• ▸Usability checks: mark discoverable, addressable, trustworthy, and any others you adopt, each with its evidence.
• ▸Quality guarantees: state the explicit guarantees consumers can rely on, and how they are tested.
• ▸Delivery practice: describe the tests and the automated continuous delivery used to release changes.
• ▸Platform services used: list the shared platform capabilities this product relies on.
• ▸Success measures: choose from access lead time, risk of change, waste, connectivity to other data products, and cost of ownership, with a baseline for each.

1. 1Define the platform's boundary by splitting data product work into two piles. Domain-specific pile: transformation code, build-time tests for data integrity, runtime tests for quality guarantees, metadata (schema, documentation), and the declaration of required infrastructure. Domain-agnostic pile: storage, accounts, compute, encryption, key management, and everything else in provisioning. The platform owns the second pile entirely.
2. 2Identify the consumers of the platform by journey, not by org chart. Start with the data product developer: develop, test, deploy, monitor, update, and maintain integrity and security, with continuous delivery in mind. Treat the data product's code, data, and policies as one unit that the platform manages together.
3. 3Expose a set of platform APIs through which a developer declares infrastructure needs. Have developers state the what: the structure of the data, its retention period, its potential size, and its confidentiality class. The platform decides the how: creating data structures, provisioning storage, applying automatic encryption, managing and rotating keys.
4. 4Use declarative modeling where the target state is describable, such as provisioned infrastructure and the infrastructure that manages a data product's life cycle. Do not force it onto complex transformation logic, where declarations hit diminishing returns quickly. Let developers write that logic in code.
5. 5Automate the manual steps in the developer journey. Provision the underlying data infrastructure with infrastructure-as-code techniques. Then automate actions along the data value stream, starting with certification or verification approval: verify data integrity, apply statistical tests on the nature of the data, and use machine learning to find unexpected outliers.
6. 6Build life cycle management tooling as one coherent set of services so a domain team can go from API access to a deployed data product without a ticket to a central team. The measure of success is hours, not weeks, from idea to a product on the mesh.
7. 7Include platform-wide conventions that make products composable, for example a shared global ID system that transformation code harmonizes to, so independently built products integrate easily.
8. 8Judge each platform capability by cognitive load: does it reduce the detail a developer must hold in working memory to get the job done? Remove or hide any capability that exposes domain-agnostic detail.

At Daff, the playlist domain's data product owner tells the partnership team they need the tracks that workout platforms play during activities, plus the tracks members like. The conversation leads to prioritizing a partner playlists data product, which fits the partnership team's goal of seamless integration with partner platforms. The team knows the partner APIs and their life cycle, so they are best placed to build it. Because Daff built self-serve infrastructure over three years, the work is fairly simple. They start with one popular cycling and workout partner and use its APIs to get tracks members played and liked. They use the platform's data product life cycle management tools to write the transformation logic, publishing initially as near-real-time snapshots of delta files. Their code harmonizes the music track ID to Daff's global track ID system used across all data products, which eases integration with other products. In a few hours the product is built, deployed to the mesh, and available to the playlist teams to continue their experiment. The partnership team writes only domain logic; the platform handles everything else.

• If a task requires specialized knowledge of today's tooling and would be difficult to replicate in each domain, then move it into the platform rather than asking domains to learn it.
• If the thing being specified is a state (provisioned infrastructure, retention, confidentiality class), then model it declaratively; if it is complex transformation logic, then keep it as code, because declarations stop paying off.
• If a step in the data product journey is manual and error-prone (such as certification or verification approval), then automate it with integrity checks, statistical tests, and outlier detection.
• If a capability forces a developer to describe how rather than what for domain-agnostic concerns, then redesign it so the developer declares intent and the platform implements it.
• If a domain-specific concern (transformation code, tests, metadata) is being pulled into the platform, then leave it with the domain team, since the platform covers only domain-agnostic, cross-functional capabilities.

• Domains still provision storage, accounts, and compute themselves. The tell: each domain team has its own infrastructure specialists, and the same tooling work is replicated across domains.
• The platform exposes imperative, step-by-step provisioning rather than declarative intent. The tell: developers must know encryption and key rotation details to ship a data product.
• Declarative modeling is applied to everything, including complex transformation logic. The tell: declarations grow convoluted and developers fight the abstraction to express domain logic.
• Verification and certification stay manual. The tell: approvals queue up, errors arise from manual steps, and integrity is checked inconsistently.
• The platform offers disconnected tools rather than managing code, data, and policies as one unit. The tell: developers stitch together separate deploy, test, and security processes for each product, so cross-product integration (like a shared track ID) is ad hoc.

• ▸Capability: name the capability (e.g., storage provisioning, key rotation, certification).
• ▸Domain-specific or domain-agnostic: classify it; only domain-agnostic goes to the platform.
• ▸Journey stage: develop, test, deploy, monitor, update, or secure.
• ▸Developer declares (the what): list the declarations, such as structure, retention, size, confidentiality class.
• ▸Platform performs (the how): list the actions hidden from the developer.
• ▸Declarative or code: state whether it is modeled declaratively or left as code, and why.
• ▸Automation: identify the manual step removed and the automated check that replaces it.
• ▸Cognitive load removed: describe the detail the developer no longer holds in mind.
• ▸Time-to-product check: estimate hours from need to deployed data product using this capability.

1. 1Map governance to your organizational seams first. Daff's governance "followed the organizational seams" of its existing business-dev-ops domain teams. List your domains and name who speaks for each. These representatives become the federated body.
2. 2Seat the federated group with domain representatives. In Daff, a federated group of domain representatives defines the policies and the platform automates them. A central governance team that decides alone, without domain knowledge, recreates the old bottleneck.
3. 3Write each policy as a plain-language statement plus the heuristics behind it. Daff's policy was "assigning long-term owners to data products". Its heuristics were that the owner is the team closest to the source, controls the relationship with the source partners, and best understands the factors that affect the data. A decision that looks organic is repeatable only when the heuristics are written down.
4. 4Sort every policy into two groups: those that can be enforced by the platform and those that need a human judgment. Daff's platform services already cover automated access control, encryption of personal information by default, and registering all data products with a global discovery tool. Put every policy that can be computed into the first group.
5. 5Embed each computable policy in the self-serve platform and in the data products, which are the nodes on the mesh. A domain team that publishes a data product gets the policy by default and does not request a review. Governance moves from top-down, human-intervened operation to computational policies in the nodes.
6. 6Keep global rules to what interoperability requires, such as discovery registration, ownership, and protection of personal data, and leave everything else to the domain. The goal is to balance domain autonomy with global interoperability, not to maximize central control.
7. 7Test against the before-state. Before mesh, access required a request to a centralized governance team, which "added another few days". After mesh, a team in Daff's position should be able to find, get access to, and use a data product without any human handoff for policy reasons. If a handoff remains, treat it as an automation gap.
8. 8Revisit policies on a cadence owned by the federated group. Move any heuristic that keeps being applied by hand into the platform.

Daff's playlist team wants to build a sports-playlist model that needs partner music data. Before data mesh, the work needed a central data and AI team to prioritize it, a lake or warehouse team to supply data, a central governance team to approve access (a few more days), and a data engineering team to build new ETL pipelines. Those engineers then had to spend days learning the partnership domain. The data came back stale and poorly understood, and the partnership team had little incentive to support the pipelines. After data mesh, the partnership team owns the partner playlists data. That ownership comes from the governance policy "assigning long-term owners to data products", applied through the heuristic of who is closest to the source and controls the partner relationship. The data product is registered in the global discovery tool, its access control is automated, and personal information is encrypted by default. The playlist team finds the product and uses it directly, and no central governance team sits in the path. A federated group of domain representatives defined the policy, and the platform enforces it.

• If a policy can be expressed as a check the platform runs, then automate it in the platform and the data products. Do not leave it as a review step performed by people.
• If a policy needs context about the data or its consumers, then let domain representatives in the federated group decide it. A central group without that understanding struggles with it.
• If a decision about data ownership comes up, then apply the heuristic of the team closest to the source that controls the source relationship. The partnership team owning partner playlists is the model.
• If a rule does not serve interoperability across the mesh, then leave it to the domain rather than making it a global policy.
• If domain teams still wait on a governance handoff, then count it as a failure of the computational half and find the policy that was never automated.

• Federation in name only: a central governance group still decides and domains are merely consulted. The tell is access or publishing requests still queuing for a central team, adding days.
• Policies exist only as documents. The tell is that compliance depends on people remembering rules, and personal data is not encrypted or products are not registered unless someone checks.
• Ownership assigned by convenience, not heuristics. The tell is a data product owned by a team far from the source, which then lacks the incentive and knowledge to maintain it. This is the central data engineering problem of the pre-mesh playlist scenario.
• Governance disconnected from the domain structure. The tell is a federated body whose members do not map to the actual domain teams, so policies ignore how teams really work.
• Over-centralizing automation so the platform dictates everything. The tell is that domain autonomy erodes and teams cannot tell which global policies are required for interoperability and which are not.

• ▸Policy name: the short statement, e.g. "Assign long-term owners to data products".
• ▸Federated group sponsor: the domain representative accountable for this policy.
• ▸Heuristics: the written rules used to apply it, e.g. closest to the source, controls the relationship, knows the influencing factors.
• ▸Interoperability purpose: what global interoperability need this policy serves.
• ▸Enforcement type: automated by the platform, embedded in the data product, or human judgment.
• ▸Platform mechanism: the service that enforces it, e.g. automated access control, default encryption of personal information, global discovery registration.
• ▸Domain autonomy left open: what domains remain free to decide.
• ▸Manual handoffs remaining: any step where a person still approves, and the plan to remove it.
• ▸Review date: when the federated group next reassesses the policy.

1. 1Assign each analytical data product to one cross-functional domain team that owns it long term. Use the Daff rule that the partnership team owns 'partner playlists' and the playlist team owns 'playlists'. Write the owner down so nobody has to ask who owns what data.
2. 2Embed a data product owner in each domain team. Make that person responsible for the data and for sharing it successfully, so data providers (application teams, data engineers) work inside the domain rather than in a central data team.
3. 3Give the team end-to-end responsibility for the life cycle: build, deploy, monitor, evolve. Test this by asking whether the team can create and evolve a data product without opening a ticket on another team's backlog.
4. 4Set the data product's quality bar as discoverable, understandable, accessible, and usable. Check each of the four before you call a version shared, because ownership without them produces silos.
5. 5Cut dependencies by giving the team self-serve platform APIs for building, deploying, registering, and securing data products. The platform should supply automated access control, encryption of personal information by default, and registration in a global discovery tool, so the team doesn't build these itself.
6. 6Hold the autonomy boundary at the interoperability contract. Each product implements the standard contracts for data access and sharing, for example harmonizing the music track ID with the global track ID system. Inside the contract the team decides freely.
7. 7Let consumers work directly with the owning team, without a middleman. Domain teams collaborate with consumers on needs and iterate, as the playlist team did with the partnership team.
8. 8Measure autonomy by outcomes: lead time to access data, risk of change to data, and waste in developing data products. These are the measures Daff tracked after removing central bottlenecks.

At Daff, the playlist team is running an experiment on sports playlists and needs partner playlist data that does not yet exist as a data product. Under the old model, the central data team would have queued the request behind a growing backlog, and that team had slowed substantially as sources and use cases multiplied. After the move to data mesh, the playlist domain works directly with the partnership domain. The partnership team becomes the owner of 'partner playlists' and uses the platform's data product life cycle tools to build the transformation logic. It presents the data in multiple modes, starting with near-real-time snapshots of delta files. The code harmonizes the music track ID with Daff's global track ID system so the product connects to other data products. Within a few hours, the new data product is built, deployed to the mesh, and available to the playlist teams. Access control, default encryption of personal information, and registration in the global discovery tool come from platform services, and the teams do none of that work by hand. Daff reports shorter lead times to access data, lower risk of change, and less waste as a result.

• If a domain team must file a request on another team's backlog to share or consume data, then the platform or the ownership assignment is incomplete. Fix the self-serve capability or move the ownership.
• If a data product has no named long-term owner inside a domain team, then assign it to the domain that best understands the data, before building anything further.
• If a domain team is spending its effort on infrastructure, security plumbing, or specialist data engineering, then push that work into platform services to cut cognitive load rather than hiring specialists into each team.
• If a domain wants to define its own standards for IDs, access, or sharing, then hold the line on the global interoperability contracts and leave everything inside the contract to the team.
• If domains begin hoarding data inside their boundaries, then enforce the data-as-a-product responsibility to be discoverable, understandable, accessible, and usable.

• Ownership is declared but the central data team still does the work. The tell: domain teams' data requests still flow through the central team's queue and lead times do not fall.
• Autonomy without a platform. The tell: each team builds its own access control, encryption, and discovery, and the load on domain teams rises while their output slows.
• Autonomy without shared contracts. The tell: data products from different domains cannot be joined because they use incompatible IDs and semantics, so the mesh is disconnected.
• Accountability stops at producing data. The tell: the team has no data product owner, and consumers cannot discover, understand, or trust the data, so silos form inside domains.
• Governance applied manually. The tell: domains wait on reviews from the governance function, which brings back the bottleneck the structure was meant to remove.

• ▸Data product name: the data product under review (e.g., partner playlists).
• ▸Owning domain team and data product owner: name the team and the person accountable long term.
• ▸Life cycle steps the team performs itself: mark build, deploy, monitor, and evolve as yes or no.
• ▸Backlog dependencies on other teams: list each request to another team and why it is needed.
• ▸Platform self-serve capabilities used: list the APIs and services used, such as access control, encryption, and discovery registration.
• ▸Interoperability contracts met: state which global standards it follows (e.g., global track ID, standard access and sharing contracts).
• ▸Four quality checks: record discoverable, understandable, accessible, usable as pass or fail, with evidence.
• ▸Consumer collaboration: name the consumer team working directly with the owner and how feedback arrives.
• ▸Outcome measures: record lead time to access data, risk of change, and development waste, each against its baseline.