Mastered by the Domain, Republished by the Hub

Weaving Intelligence (House AI Style), with Jeff Shabel’s Experiential Commentary

The governance question about master data usually arrives as a choice between two architectures. In one, a central hub holds the master records and stewards from every part of the business work inside it. In the other, each domain masters its own records. Asked which of those two I would build, I took the second and added the step it leaves out:

Each Domain masters their own and the Central Hub republishes the Domain’s ‘Mastered’ Data as the Authoritative Standard.

That sentence moves the stewardship to the domains and the publication to the centre. The second option's mastering stays; what it lacks is the republication. Two jobs are easy to confuse here, so I will separate them now. Value stewardship belongs to the domain: it matches within its own data, corrects and decides what its own records say. Cross-domain identity belongs to the hub: working out which of Marketing's, Sales's and Production's records describe the same product, and giving that product one enterprise identifier, is something no single domain can do for the others. The hub does not re-steward what it receives, whether a standard or a fact. It takes what the domain has mastered and puts it out under the enterprise's name, as the standard everyone else is expected to use; if its checks find a value that looks wrong, it flags that value for the domain to review and does not change it. The federated-or-centralised question assumes that whoever publishes the master record must also be the one who decides what it says. This arrangement separates the two, and once they are separate most of the argument about which model to pick stops being an argument about architecture.

Here is the claim I will defend. A master data hub's authority is borrowed. Where the enterprise adopts a domain's standard, the domain keeps authority over that data and the hub reinforces it; the hub does not hold a survivorship contest against the domain that owns the value. Where two domains claim the same attribute and cannot agree, the attribute is split into two columns, each owned by one domain, and the enterprise either picks one of them as its standard or adopts a third at its own level. That rules out three things: hub stewards overwriting a domain's mastered values, a single surviving value chosen by a rule when two owners disagree about what the value should mean, and an enterprise that negotiates its own standard with the domain whose standard is in question.

The menu, and what the field already concedes

The usual framing deserves a fair statement, because the research behind it is better than the menu it gets reduced to. Vijay Khatri and Carol Brown's design framework, which splits data governance into five decision domains, "Data principles; Data quality; Metadata; Data access; and Data lifecycle," holds that accountability for each "will be somewhere on a continuum between centralized and decentralized" [1]. Data quality decisions, in their reading, may sit with "business managers who are data owners in many different business units," while data principles sit closer to the centre, and their own conclusion is an organisation with "differing levels of centralized, decentralized, and shared decision rights" [1]. That is not a choice between two models. It is a different answer for each kind of decision.

Zhamak Dehghani's data mesh went further toward the domains. Her federated computational governance is "a decision making model led by the federation of domain data product owners and data platform product owners," with "domain-local decision making power, while creating and adhering to a set of global rules" [2]. She frames the design problem as deciding "what decisions need to be localized to each domain and what decisions should be made globally for all domains," and she names the hard case directly: governance is responsible for "modeling polysemes - data elements that cross the boundaries of multiple domains" [2]. An earlier essay made the same point about identity: to correlate data about one thing across domains, "we need to agree on how we identify an artist as a polyseme" [9].

The reports from organisations that tried it are less tidy. Jan Bode and colleagues interviewed fifteen industry experts on data mesh implementations and found that "organizations have difficulties with the transition toward federated governance associated with the data mesh concept"; their suggestions include a cross-domain steering unit [3]. In the implementations Bode and colleagues studied, a design meant to be decentralised reaches back for some kind of centre.

And one objection to a single enterprise model comes from software design, not governance. Martin Fowler, describing domain-driven design, writes that "Different groups of people will use subtly different vocabularies in different parts of a large organization," and that "Time and time again I see this confusion recur with polysemes like 'Customer' and 'Product'." He also quotes Eric Evans, author of Domain-Driven Design, that "total unification of the domain model for a large system will not be feasible or cost-effective" [4]. The alternative he describes is not chaos. "Different contexts may have completely different models of common concepts," he writes, "with mechanisms to map between these polysemic concepts for integration" [4].

Set that against the definition the master data discipline still works from. Gartner describes master data as "the least number of consistent and uniform sets of identifiers and extended attributes" that describe an enterprise's core entities, and master data management as a discipline that ensures "the uniformity, accuracy, stewardship, governance, semantic consistency and accountability" of "the enterprise's official shared master data assets" [5]. Uniformity and semantic consistency are the centre's virtues. Fowler's polysemes are the reason a domain resists them. The menu asks a programme to pick one virtue and live with the other's failure.

I have refused that menu before. Asked to choose between centralised, federated and embedded governance, I said it should be all three, with the centre holding the forms every domain must follow and each domain governing its own data inside them (A Distance From Perfect, Owned by Domain). Later I put it as rules of decreasing strictness, tier by tier (Rules of Decreasing Strictness). Neither of those pieces said what the master data hub should do under that model, record by record. That is this piece's question, and the answer starts with whose standard the hub is publishing.

Whose standard the hub is publishing

The first objection to a domain-mastered hub is that it seems to put two authorities over one record: the domain that owns the data and the enterprise that needs one published standard for it. Asked about exactly that tension, I said the conflict is smaller than it looks:

This isn’t as much of a conflict as one might think. If the Enterprise is enforcing a Standard, then the Enterprise enforces the Standard, even if they’re ‘borrowing’ that Standard from a Domain.

I still hold that, and the word doing the work is "borrowing". An enterprise standard does not have to be invented by the centre. Often some domain already maintains the best version of a value, because its own work depends on getting it right. When the enterprise adopts that version as its standard, it is not taking the data from the domain. It is lending the domain's standard its own reach: every consumer outside the domain is now expected to use it. The enforcement is the enterprise's; the content stays the domain's.

That separation is what makes the hub's job narrow. A hub that republishes a domain's mastered data is not a second steward. It does not re-survive or correct what the domain has decided, because doing so would create a second version of a standard whose whole point is that there is one. Matching records across domains is a different job, the identity job described at the top of this piece, and it stays with the hub. Its work is to make the domain's decision available, identifiable and traceable everywhere else. When a consumer finds a value it does not like, the complaint goes to the domain that owns it, not to a hub steward who could quietly change it.

The harder case is the one the question was really about: survivorship disputes, when parts of the business want a different answer from the one the domain has given. Asked what broke first when that happened and who settled it, I did not reach for an incident. I answered with where the dispute belongs:

Again, this is simpler than it might appear at first. If the Enterprise is supporting a Domain’s Standard, then that Domain has Authority over that data. All the Enterprise does is reiterate and reinforce that decision. The challenge is when elements of the Enterprise disagree with the Domain about the Standard—then what’s being called into question isn’t the Domain’s Standard, it’s the Enterprise’s and it needs to be resolved at that level with little or no input from the Domain.

This is the part of the pattern that is easiest to get wrong, so I want to be exact about it. When Sales objects to the product category Production maintains, the objection is not really to Production's data. For a value that is a standard, not a fact, Production's category is correct for Production's purposes, by definition, because Production owns it. What Sales is disputing is the enterprise's decision to make Production's category everyone's standard. That is a question about the enterprise standard, and it is answered where the enterprise standard is set. The domain whose standard is under review has little to add, because its answer is already known: it uses its own standard and will keep doing so.

Who answers it at that level is the question I have answered elsewhere, bluntly: whoever holds the authority and, more to the point, the power to enforce the decision makes it, and the other groups accept it (Rules of Decreasing Strictness covers that rule and the map it draws). The narrower point here is about whom that person needs to hear from. The parties who disagree with the domain's standard have something to contribute: their own needs, which the current standard does not meet. The domain's contribution is a defence of a standard it will keep for itself either way.

Here the strongest published design disagrees with me, and I would rather say so than smooth it over. Dehghani's federated governance puts global decisions with "the federation of domain data product owners" [2]; the domains, including the one whose standard is at issue, are the ones making the global rule. I part company with that only at one point. When a domain's standard has been adopted as the enterprise's and another part of the enterprise objects, a federation vote gives the owning domain a voice in judging its own case. Khatri and Brown describe what amounts to a hub-and-spoke arrangement, the hub acting "with business unit participation but not authority" [1]. It sits closer to what I am describing, though they apply it to access and lifecycle decisions, not to the content of a standard. The older advice in the field went the other way again. David Hatch, writing in 2008 on Aberdeen Group's findings, called one version of the truth elusive but achievable and recommended starting "with a single data set and a single department or operational area, then move to a cross-departmental committee" [6]. A cross-departmental committee is, applied to this case, the federation vote under another name, and it is the step I would leave out when the dispute is about whether one department's standard should stay the enterprise's.

A disclosure before the vendors' material, because what follows draws on their designs and pages. The practice behind this publication is a Profisee partner. Clients pay us for deployment work, a licence sale we refer earns us a referral fee, and our services revenue depends on master data management being bought. That interest runs toward praise of the category and of Profisee, so weigh anything favourable said here about either below any criticism of them. IBM, whose patent is described next, also sells master data software that competes with Profisee's; our interest runs against IBM, so discount any criticism of it here accordingly.

A vendor's own design shows that the question of which level settles a stewardship dispute is not hypothetical. An IBM patent filed in 2011 describes federated, multi-level master data systems with "a central MDM node assigned to manage MDM nodes for a group" and "a central system assigned to manage all group MDMs for the entire system," a root that records "which group MDM nodes have or own which data," and it states plainly that "it is possible to have conflict in data stewardship" [8]. In its worked example, two nodes name different stewards for the same entity and the conflict is resolved by taking the steward the group node names [8]. The general method adds a separate step, in which a conflict resolver may let a super user override the steward information [8]. A patent is a design, not evidence of what works in practice, and I cite it only for the shape: the people who drew a multi-level hub put the resolution above the domains in dispute. Figure 2 sets that design beside the other three and beside mine, on the one question that separates them.

Split the column

What follows comes from my own work, and I offer it as a pattern from practice, not as law.

Everything above assumes that one domain owns each attribute. The hard case in master data is the attribute two domains both claim, each with a standard it considers authoritative. Asked what to do when two domains own the same piece of data, I gave the rule I use:

If two Domains own the same piece of data, they need to split it into two columns if they can't agree on a consistent Standard. The Enterprise can then pick between the Standards or adopt a third at their level. I've run this at pretty much every client because Marketing, Sales, Production and Accounting almost always have different Product Category Hierarchies--none of which they're willing to abandon due to Institutional and Reporting Inertia.

I have split the column at almost every client, and the product category hierarchy is the case that keeps bringing me back to it. To show the kind of difference involved, not to report any one client: Marketing might group products by how they are sold, Sales by how its targets and territories are set, Production by how the products are made, and Accounting by how revenue and cost are reported. Each grouping can be right for the job its owner uses it for, and a single hierarchy imposed on all four risks being right for none of them. Fowler's polysemes are the general case [4]; the product hierarchy is the one that brings me to the split.

The split does three things, in order. It stops the argument about whose hierarchy is right, because both survive, each in a column its owner controls. It gives every consumer an honest choice: a report built for Marketing reads Marketing's column and gets Marketing's answer, without pretending it is the enterprise's. And it leaves one decision for the enterprise, made at its own level: which standard is the enterprise's. The enterprise may pick one of the domain columns, in which case that domain holds authority over the enterprise standard exactly as above. Or it may adopt a third, a classification of its own or a published one. GS1's Global Product Classification "classifies products by grouping them into categories based on their essential properties," from a top level, "a segment, which is defined as a particular industry," down to "a product code known as a brick" and the attributes beneath it [15] [16], and UNSPSC is "an open, global, multi-sector standard for efficient, accurate classification of products and services," with "a five-level hierarchical classification codeset" [17]. A third standard of that kind belongs to no domain, which is sometimes exactly why an enterprise chooses it.

I did not start out splitting columns. Early on I tried to put the whole enterprise on one standard for attributes every department touches, product line among them, and it did not hold; I am still for one enterprise-wide standard, but segments of the business needed to see alternatives and different values for backward compatibility and their own reports, and the pushback to keep each department's downstream reports matching its expectations has not stopped (Before It Had a Name tells that story). The split column is how I now keep both halves of that sentence. The enterprise standard survives as its own column. The alternatives survive as the domains' columns. Nobody has to pretend the two are the same value.

The cause I give for the refusal to abandon a hierarchy is inertia, institutional and reporting, and the reporting half is the one people underestimate. It comes down to one claim: an enterprise cannot easily retire data it has come to rely on, so a poor hierarchy stays:

That's exactly right. Once the business starts to rely on the data--even bad data--it becomes more and more difficult to recast or correct it because it would require significant disruption in ongoing forecasts as well as creating a potential need to restate previously filed regulatory reports.

A department's product hierarchy is that kind of data. Its forecasts are built on it, its targets are stated in it, and its history is reported in it. Changing the hierarchy does not only change future reports; it breaks comparison with every past one, unless the past is recast. Where the hierarchy feeds external reporting, the cost has a rule attached. Under the US segment reporting standard, if a public entity "changes the structure of its internal organization in a manner that causes the composition of its reportable segments to change," the "corresponding information for earlier periods, including interim periods, shall be restated unless it is impracticable to do so" [10]. The next paragraph of the codification, ASC 280-10-50-34A, as Deloitte's guide reproduces it, adds that "a fundamental reorganization of an entity may cause it to be very difficult and expensive to restate segment information and therefore it may not be practicable" [10]. So the standard itself excuses restatement where it cannot reasonably be done, and the cost I am pointing to is the one that is borne when it can. Not every product hierarchy is a segment structure, and I am not saying a split column has any accounting consequence. The point is narrower: a department that resists abandoning its hierarchy is often defending something it would be expensive to recast, and a design that asks it to abandon the hierarchy is asking for that expense. A split column asks for none of it.

Jim Harris made a version of the same observation more than a decade ago, arguing that an enterprise has not a single version of the truth but "various versions of verisimilitude," and that any one version "is essentially only one of the various, and business-justifiable, versions" [7]. Profisee's chief data officer, Malcolm Hawker, puts it more recently and more simply: "There is a single version of the truth within any one business context," but "across a global, functionally complex enterprise, there will always be multiple such truths," and "MDM doesn't create truth; it reconciles it" [22]. I agree with the first two sentences, and Hawker does not leave the enterprise out: he has MDM that "resolves those differences when needed" and calls for "cross-functional reconciliation when enterprise-level truth is required" [22]. What I add sharpens his position rather than rebutting it. He describes reconciliation proceeding "without demanding that one function change its internal processes" [22], and the split column honours that: it asks no function to change its internal processes. It does ask something of the enterprise, a decision about which column is the enterprise's. Reconciliation that never forces the enterprise to choose its own column leaves every consumer outside the four functions to guess which column to read.

What the hub has to store

A sponsor should care about this section because the pattern costs something to run. If the hub cannot say whose value it is publishing, every complaint lands on its own stewards, and the arrangement slides back into the hub-steward model it was meant to replace.

The pattern above is mine. What follows, the implementation it implies, is this publication's reading, not a report of tables, keys or messages I have built. It is drawn from vendor-neutral sources and the vendors' own documentation.

Cross-references, per domain. The hub keeps the map from each domain's identifier to the enterprise's identifier for the same thing. That is a registry's job and the cross-domain identity work set out at the top of this piece: the hub matches and maps across domains and leaves the values to the domain that owns them. Profisee's explanation of implementation styles describes the registry style as one in which "Source systems remain the SOR" [11], the system of record. The pattern here borrows that respect for the source and adds one thing a pure registry does not have: a published standard value per attribute, with its owner named.

An authority map, per attribute. Each standard column has exactly one owner, so the rule that decides its value is a single-source priority, with one source in the hierarchy. Survivorship is usually described as a contest the hub referees; Profisee's survivorship guide recommends that teams "Define rules at the attribute-level" [12], and under a domain-mastered pattern the contest disappears for the standard columns. Jens Bleiholder and Felix Naumann's classification of conflict handling calls a decision made in advance about whom to trust "trust your friends," and classes it as conflict avoidance rather than resolution [13]. That is the point: the domain-mastered hub avoids conflicts on owned attributes by deciding, once, whom to trust, and reserves resolution for the attributes no domain owns outright. That holds for the standards, like a category. For a fact about the world, like an address, an owner can simply be wrong. The hub's matching and quality checks still apply to it, but they detect and flag; they do not correct. In my practice the owning domain corrects the error. The hub is not the owner of that data, so changing it is not the hub's call; all it can do is flag the value for review. My own rule for a field fed by several systems is consistent with that: the master data system decides which value wins a place in the master record, and each source decides how it produced the value it sends. The appendix (Figure 4) writes the map out for a product category and an address.

Split columns as first-class attributes. A split column is not a set of per-source copies. It is one column per owning domain, each with a named owner, plus an enterprise column that is the enterprise's decision. A customer master record can fail in two opposite ways, and I have seen both: by keeping every feeding system's version of a name, with a "master" name put on top, and by forcing one mailing address on a business that needs separate addresses for different purposes (Sixteen Name Fields and One Mailing Address). The split column avoids both, and the difference is ownership. Sixteen name fields are sixteen sources, none of them responsible for a standard. Four product category columns are four standards, each with a named owner, a code list and a reason to exist. In warehouse terms the enterprise column is the conformed dimension, "defined once in collaboration with the business's data governance representatives" [14]. The domain columns do not need to conform to each other; the enterprise column is the one every fact table can share.

Provenance on every published value. Every published attribute carries the domain it is attributed to, and every enterprise column says whether it was picked from a domain or adopted as a third standard. That makes the authority visible at the point of use, and it routes the complaint about a value to its owner instead of to a hub steward. The W3C's provenance vocabulary has a term for the stamp: "Attribution is the ascribing of an entity to an agent" [18].

Publish and subscribe, by column. A consumer subscribes to a column, not to the hub: one that needs the enterprise standard subscribes to the enterprise column, and one that serves a single function subscribes to that function's column and knows it. Republishing is a distribution problem with a well-known shape, a channel "which delivers a copy of a particular event to each receiver" [19]. For a hierarchy two functions use, the split may be more structure than the problem needs. For four functions and every report that crosses them, it is less structure than the arguments it replaces.

A contract that names the authority. The contract the consumers read says which domain is authoritative for which attribute and who in that domain answers for it. The Open Data Contract Standard lets a contract delegate "the definition or authority to a third party system" [20], and its team section records the members and "the history of their relation with this data contract" [21]. When a domain changes its own standard, which it is entitled to do, the contract is where consumers find out before the change reaches their reports.

When each model succeeds

The usual question is when federated and centralised models each succeed. Under this pattern the question splits in two, because the two words describe different things: who masters the record and who publishes the standard. Figure 3 lays the two questions out as a grid: the two options on the usual menu fill two of its cells, with the Registry cell standing for the usual "federated" option reduced to its hub behaviour, and the arrangement I have been describing fills a third.

The figure says where each arrangement fits; the conditions behind it are what a programme can check. A centralised standard needs the enterprise to own the content, so that the hub is the source and there is nothing to borrow. Profisee's description of its most centralised style, in which "the MDM platform is both the SOR and the only database that accepts updates" [11], fits those attributes and few others. Federated mastering needs four things to be true together: the authority map names the owner, the hub does not re-steward the owner's values, disputes about the enterprise's choice are settled at the enterprise's level, and an attribute claimed by two owners is split rather than fought over.

Four signs show the borrowed pattern failing, and they share one cause: each is the federated-or-centralised argument reappearing inside a design that was meant to end it. A hub steward correcting values a domain owns has made the hub the owner again. One column carrying a value two domains each believe is theirs has an owner in dispute and should have been split. A dispute about the enterprise standard sent back to the domain has returned it to the party the pattern says should not settle it. An enterprise column nobody has decided is the one most easily missed, because it breaks nothing until a consumer has to guess which column to read. I have no incident to report for any of the four; they are where I would look.

Whose standard is it?

The federated-or-centralised question asks where the stewards should sit. The more useful question, attribute by attribute, is whose standard the hub is publishing. If it is a domain's, the domain masters it and keeps authority over it, and the hub's job is to republish it with the domain's name attached. If two domains claim it and will not agree, it splits, and the enterprise makes its own choice at its own level. If it is the enterprise's own, the centre is the source, and the hub is a centralised hub for that attribute and nothing else.

None of this makes the politics go away. Four functions will still want four hierarchies, and they will keep wanting them for as long as their forecasts and their history are stated in them. What the pattern changes is what the hub has to win. A hub that tries to settle every dispute inherits every dispute. A hub that publishes borrowed standards, splits the contested ones and leaves the enterprise's choice to the enterprise has to win nothing at all, except the right to be the place everyone looks.

Appendix: the authority map, written out

The authority map from "What the hub has to store," for one product category and one address. Each cell restates a sentence from that section; the map is this publication's reading, not a schema.

References

[1] Vijay Khatri and Carol V. Brown, "Designing Data Governance," Communications of the ACM 53, no. 1 (January 2010): 148–152, doi:10.1145/1629175.1629210. Read 2026-10-18 at a copy hosted by Khon Kaen University (the ACM page could not be fetched). Cited for the five decision domains (p. 149), the continuum (p. 151), the decentralised data-quality case and the hub-and-spoke phrase (p. 152) and the conclusion's phrase (p. 152). https://hs-cims-v2.kku.ac.th/uploads/files/646e37d9d9d78_1629175.1629210.pdf

[2] Zhamak Dehghani, "Data Mesh Principles and Logical Architecture," martinfowler.com, 3 December 2020. Read 2026-10-18. Cited for the definition of federated computational governance, the localised-versus-global decision question and the polyseme responsibility. https://martinfowler.com/articles/data-mesh-principles.html

[3] Jan Bode, Niklas Kühl, Dominik Kreuzberger, Sebastian Hirschl and Carsten Holtmann, "Towards Avoiding the Data Mess: Industry Insights from Data Mesh Implementations," arXiv:2302.01713, version 4, 6 June 2024 (version 1, 3 February 2023). Read 2026-10-18 at the abstract page only. Fifteen semi-structured expert interviews. Cited for the sentence quoted and the cross-domain steering unit among the suggestions. https://arxiv.org/abs/2302.01713

[4] Martin Fowler, "Bounded Context," martinfowler.com, 15 January 2014. Read 2026-10-18 in full. Cited for the sentences quoted, including his quotation of Eric Evans on total unification (footnote 1). https://martinfowler.com/bliki/BoundedContext.html

[5] Gartner, "Master Data Management: Definition, Process, Framework and Template," Gartner topic page, undated. Read 2026-10-18 at the former glossary address, which redirects here in a browser. Cited for the definitions of master data and master data management quoted. https://www.gartner.com/en/data-analytics/topics/master-data-management

[6] David Hatch, "Is One Version of the Truth Still Achievable?" TDWI, 8 October 2008 (Aberdeen Group research summarised by its author). Read 2026-10-18 in full. Cited for the recommendation quoted and for his statements that one version of the truth is elusive and, on Aberdeen's finding, achievable. https://tdwi.org/articles/2008/10/08/is-one-version-of-the-truth-still-achievable.aspx

[7] Jim Harris, "The antimatters of MDM (part 2)," SAS Data Management blog, 25 September 2013. Read 2026-10-18 in full. Cited for the two phrases quoted. https://blogs.sas.com/content/datamanagement/2013/09/25/the-antimatters-of-mdm-part-2/

[8] Rangachari Anand, Stacy F. Hobson, Juhnyoung Lee, Xuan Liu and Jeaha Yang (assignee International Business Machines Corp.), "Data stewardship in federated multi-level master data management systems," US Patent 8,601,029 B2, filed 27 May 2011, granted 3 December 2013. Read 2026-10-18, the first 100,000 of 137,921 characters of the Google Patents text (the passages cited are inside that span). A patent is a design, not evidence of practice. Cited for the group and root nodes, the ownership record, the sentence on stewardship conflict, the worked example's resolution (the group node's steward) and the general method's super-user override step. https://patents.google.com/patent/US8601029B2/en

[9] Zhamak Dehghani, "How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh," martinfowler.com, 20 May 2019. Read 2026-10-18. Cited for the sentence quoted, on agreeing how to identify an artist as a polyseme. https://martinfowler.com/articles/data-monolith-to-mesh.html

[10] Deloitte, Roadmap: Segment Reporting, section 4.9, "Restatement of Segment Data Because of Changes in Reportable Segments or Segment Expenses," Deloitte Accounting Research Tool (page copyright 2026), quoting ASC 280-10-50-34 and 50-34A. Read 2026-10-18. Cited for the codification text quoted (current wording; the page shows pending content replacing "restated" with "recast" under ASU 2023-07), including the 50-34A sentence on fundamental reorganisations as the page reproduces it. https://dart.deloitte.com/USDART/home/codification/presentation/asc280-10/roadmap-segment-reporting/chapter-4-disclosure-requirements/4-9-restatement-segment-data-because

[11] Benjamin Bourgeois, "Master Data Management (MDM) Implementation Styles, Explained," Profisee blog, 12 February 2024 (page metadata shows a modification on 22 August 2026). Read 2026-10-18. Vendor explainer (the vendor we partner with). Cited for the registry and centralised style definitions quoted. https://profisee.com/blog/master-data-management-implementation-styles/

[12] Benjamin Bourgeois, "MDM Survivorship: How to Choose the Right Record," Profisee blog, 23 October 2025. Read 2026-10-18. Vendor explainer (the vendor we partner with). Cited for the attribute-level recommendation quoted, and for the term single-source priority that Figure 4 uses. https://profisee.com/blog/mdm-survivorship/

[13] Jens Bleiholder and Felix Naumann, "Conflict Handling Strategies in an Integrated Information System," Informatik-Berichte 197, Institut für Informatik, Humboldt-Universität zu Berlin, 12 April 2006, doi:10.18452/2460. Read 2026-10-18. Cited for the "trust your friends" strategy quoted and its classing as conflict avoidance. https://edoc.hu-berlin.de/bitstreams/d61400e7-efd0-4654-b042-7acdd463bac4/download

[14] Kimball Group, "Conformed Dimensions," Kimball Dimensional Modeling Techniques, undated. Read 2026-10-18. Cited for the governance phrase quoted. https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/conformed-dimension/

[15] GS1, "Global Product Classification (GPC)," gs1.org, undated. Read 2026-10-18. Cited for the sentence quoted. https://www.gs1.org/standards/gpc

[16] GS1, "How GPC works," gs1.org, undated. Read 2026-10-18. Cited for the segment and brick definitions quoted. https://www.gs1.org/standards/gpc/how-gpc-works

[17] UNSPSC, home page, unspsc.org (managed by GS1 US for the UN Development Programme), undated. Read 2026-10-18. Cited for the two phrases quoted. https://www.unspsc.org/

[18] W3C, "PROV-O: The PROV Ontology," W3C Recommendation, 30 April 2013. Read 2026-10-18 at the definitions of attribution, derivation and agent. Cited for the definition of attribution quoted. https://www.w3.org/TR/prov-o/

[19] Gregor Hohpe and Bobby Woolf, "Publish-Subscribe Channel," Enterprise Integration Patterns pattern page (page credit © 2003, 2023 Bobby Woolf). Read 2026-10-18. Cited for the solution statement quoted. https://www.enterpriseintegrationpatterns.com/patterns/messaging/PublishSubscribeChannel.html

[20] Bitol project, LF AI & Data Foundation, "Authoritative Definitions," Open Data Contract Standard v3.2.0 documentation. Read 2026-10-18. Cited for the phrase quoted. https://bitol-io.github.io/open-data-contract-standard/latest/authoritative-definitions/

[21] Bitol project, LF AI & Data Foundation, "Team," Open Data Contract Standard v3.2.0 documentation. Read 2026-10-18. Cited for the phrase quoted. https://bitol-io.github.io/open-data-contract-standard/latest/team/

[22] Malcolm Hawker, "The Myth — And Reality — Of a Single Version of the Truth," Profisee blog, 12 May 2025. Read 2026-10-18. The vendor we partner with; its chief data officer's argument. Cited for the six phrases quoted. https://profisee.com/blog/is-a-single-source-of-truth-relevant/