Two Features and a Rulebook: Federated Governance in Profisee

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

Ask how Profisee implements federated and centralised governance, and the honest first answer is that it does not, at least not as a feature. Profisee's public pages describe a "centralized" implementation style among several and say that "Profisee supports any implementation style" [1]; its documented governance integration is with Microsoft Purview, where the catalogue may define rules and Profisee "is the system that enforces these rules" [2]. Neither Profisee's public pages nor the matching and survivorship pages of its customer help that I read offer a federated governance model as something you switch on. So I was asked a narrower question: which mechanisms in the product actually carry a federated model with a centralised core? My answer named two:

To do a properly Federated MDM solution with Enterprise-level Centralization, I need to take advantage of only Profisee’s core features: Data Modeling of Entities and Attributes and Mastering Strategies that handle Mastering and Survivorship.

That is less than the question offered. For the core of the design I did not name permissions, the FastApp portal, Profisee Connect or the Purview integration, although all of them exist and all of them matter to a running estate; Connect comes back later, as the way a domain's records leave. The claim of this piece is that a federated master data model with an enterprise core is built out of the two most ordinary things in the product, the data model and the matching strategy, and that what makes it federated is not a setting but a set of decisions about which attributes belong to whom. Profisee gives you the parts. The rulebook that says how they are assembled is yours, and it is most of the work.

The governance model is not in the box

Start with why the question cannot be answered as it is usually asked. A governance operating model is an organisational arrangement before it is anything else. Gartner defines master data management itself as "a technology-enabled business discipline in which business and IT work together" to secure "the uniformity, accuracy, stewardship, governance, semantic consistency and accountability of the enterprise’s official shared master data assets" [3]. Technology enables it; the discipline is the business's. Irina Steenbeek, writing on the DAMA body of knowledge, puts the dependency the right way round: the governance operating model "will follow the business operating model" [4]. The UK government's guidance on data ownership says the same of ownership: it "is the responsibility of the business and not the technology domain" [5]. McKinsey's version of a working model has a central office, "governance roles organized by data domain where the day-to-day work is done", and a council that brings the two together [6]. None of these is something a vendor can ship.

What a platform can do is make one arrangement cheap to run and another expensive. That is the question worth asking of Profisee, and it is a question about mechanisms.

I have said before that the choice between centralised, federated and embedded governance is a false menu: it should be all three, with rules of decreasing strictness at each level. The enterprise level enforces systems compatibility, naming standards and documentation; the hybrid level makes clear which domain is responsible for what, and where each is constrained or free; the local level states plainly what it enforces, why and how. Rules of Decreasing Strictness sets that model out tier by tier, and one of its checks asks for a written map of which domain is responsible for which master data entity "and, where it is split, each attribute". This piece is about the split. In Profisee, that is where the three tiers meet the product.

Zhamak Dehghani's account of data mesh frames the same split from the other side. Federated governance, in her formulation, is the work of deciding "what decisions need to be localized to each domain and what decisions should be made globally for all domains" [7]. Her example is a podcast company: each domain models its own data, but how to identify a listener across every domain is a global decision. Identity is the centre's; the domain's own description of the listener is the domain's. Hold that distinction, because the design below is a way of putting both in one record without letting either overwrite the other.

The structure: a core entity with attributes that belong to someone

The first of the two mechanisms is the data model:

Establishing Enterprise-level ‘Core’ Entities and adding Domain-specific Attributes gives me the Data Structure to support a Federated Data Model.

In concrete terms, picture a Customer entity. Some of its attributes are the enterprise's: the legal name, the registered address, the tax identifier, the enterprise customer type, the parent in the enterprise hierarchy. Every domain reads them, and the enterprise tier sets their standard. Others are a domain's: the payment terms and credit limit Finance works with, the preferred channel and campaign segment Marketing works with, the service tier Support assigns. Those attributes are no less real for being local. They are simply answers to questions only one domain asks. (The attribute names here are illustrations of the shape, not any organisation's model.)

A Profisee entity holds both kinds without strain. An entity is a set of attributes, free-form or domain-based, and nothing in the product requires every attribute on an entity to be governed the same way. What makes the entity federated is not its shape but the rule written beside it: this attribute is the enterprise's, that one is Finance's, and the owner of each decides how its value is chosen.

There is a failure hiding in this, and I have written about it before. In Sixteen Name Fields and One Mailing Address the federated failure was a customer record that kept every source's copy of the customer's name, SF_Name and SAP_Name and the rest, with a "master" name on top, a registry wearing a consolidation's badge. A domain attribute must not be that. The test I gave there still applies: does the distinction change what somebody does? Finance's credit limit passes, because no other domain decides it and Finance acts on it. A Finance copy of the customer's legal name fails, because it is the same answer to the same question as the enterprise attribute, held twice. Domain attributes are different questions, not different copies. That piece applied the test the other way as well: billing, legal and delivery addresses pass it, because each leads to a different action, which is why a record that allows exactly one address fails too. The same test, applied to every proposed domain attribute, decides which ones earn a place. Keep that line and the core entity stays a single record with several owners; lose it and the entity becomes the sixteen-name-field record by another route.

The data warehouse world solved a cousin of this problem decades ago. Kimball's conformed dimensions are dimension tables that "conform when attributes in separate dimension tables have the same column names and domain contents"; built once, with the business's governance representatives, they let results from separate fact tables be aligned on the same rows in a drill-across report [8], and the enterprise bus architecture grows the warehouse one process at a time around them [9]. The enterprise attributes of a core entity are conformed attributes in that sense. That is what makes the roll-ups possible later, and it is why the enterprise tier's naming standard is not bureaucracy: it is the condition for two domains being able to join on anything at all.

The mechanism: strategies that write only what they own

The second mechanism is the matching strategy, and it is where the separation is enforced rather than merely drawn:

A properly filtered and configured Matching Strategy with Survivorship populates the Attributes based upon the individual needs of the various Domains and allow an ‘Enterprise-level’ Mastering Strategy to handle Mastering and Survivorship into the Enterprise level Attributes while leaving the Domain level Attributes alone.

That is my description. Here is what Profisee's own documentation supports, read in its customer help wiki (login required), which says it applies from 2023 R2 onward.

A strategy is per entity, and there can be more than one. "Strategies are specific to a model, version and entity" [10]. The matching options advise clearing one setting "if you intend to run multiple strategies in a sequence" [11], and the promotion page says promotion must run before harmonisation, "either using the same strategy or in different strategies" [12]. Several strategies can work on one entity.

A strategy can be confined to a subset of records. The matching criteria let "the matching process [be] executed for a subset of the records in the entity", processing "only the records meeting the defined criteria"; each matching attribute set can carry its own filter criteria as well [11]. A domain's strategy can be told to look only at that domain's records, its own source systems, for instance, identified by the source attribute the documentation recommends creating before matching [13].

Survivorship writes only the attributes it is given. Survivorship in Profisee is configured as attribute sets, and "this attribute set determines which attributes will be considered for survivorship"; "you can create multiple attribute sets in order to promote and/or harmonize different attributes using different criteria" [14]. Each set has its own optional filter, "to isolate the records which will be considered for promotion", its own sort, its own promotion criteria (record completeness, value occurrence, record recency) and its own action policy, from "only copy if the attribute is blank" to "always copy (overwrite)" [14]. An attribute that is in none of a strategy's sets is not one that strategy promotes.

Put those three together and the design follows. The enterprise strategy matches across every source and survives the enterprise attributes, by the enterprise's criteria. Each domain's survivorship draws only on the records its filter admits and writes only the attributes the domain owns, by the domain's criteria. Finance can let its system of record win on credit terms while Marketing lets the most recently updated record win on channel preference, and neither touches the legal name. For those values to land on the enterprise golden record, the domain must survive onto the enterprise's match groups, not form its own. My reading of the documented settings is that there are two ways to do that: the domain's attribute sets live inside the enterprise strategy, or they live in a separate strategy that includes survivorship but not matching (a strategy's components are chosen separately) and that selects the enterprise strategy's existing control attributes rather than creating new ones [10] [12]. The first route is the one the documentation shows directly; the second rests on settings the pages describe separately, and none of the pages I read shows one strategy promoting onto golden records another strategy created, so test it in your release before you design around it. The documentation does not lay out this pattern; it is my assembly of documented settings, and the one design decision the documentation leaves to you is the one that matters, which attribute goes in whose set.

Three details from the same pages are worth knowing before you build it. First, value occurrence is evaluated "for the complete attribute set, not for individual attributes", so attributes that must be judged independently need separate sets [14]; an attribute set is a unit of ownership and also a unit of evaluation, and the two had better coincide. Second, the page warns that when matching and survivorship run together, recency by last-updated date "becomes a random way to select a record", because matching itself changes that date [14]. A domain whose rule is "most recent wins" needs to know which recency it is getting. Third, each strategy writes its results to control attributes it names, Group ID and Match Status among them, created on the entity as restricted attributes [10], and, when survivorship is on, a Golden Record attribute that maps each match group's records to their golden record [14]. That is the line between a band and a domain master. A domain strategy that does its own matching forms its own groups, and on my reading it would need control attributes of its own, or it would overwrite the enterprise's grouping; it produces golden records of its own, which is the domain-master route of a later section, not a band on the enterprise record. My reading is that every strategy of that kind adds a handful of system attributes to the shared entity, a cost that is small per strategy and real in aggregate. The help pages I read do not describe what an operator sees when an enterprise run and a domain run are sequenced badly; test the order of runs before production, not after.

The mechanism, in short, is not a governance feature. It is an ownership rule expressed as configuration: each attribute appears in the survivorship sets of exactly one owner. Profisee will run whatever sets you give it. Nothing on those pages describes a warning when two owners put the same attribute in their sets, and the documentation explicitly allows it: "You can use the same attribute across multiple attribute sets" [14]. That check is the hybrid tier's job, and it belongs in your deployment gate, not in a steward's memory.

Side by side: one record, several readings

The payoff comes in the next part of my answer:

In this way, Enterprise and Domain models can live side by side in the same Golden Records and Entities, facilitating crosswalks, roll-ups and aggregations across multiple different dimensions.

Because the domain attributes sit on the same golden record as the enterprise attributes, they share the enterprise's identity. A report that rolls Finance's credit exposure up the enterprise customer hierarchy, cut by Marketing's segment, is a query over one entity, not a reconciliation across three systems, once every domain's data has been loaded into Profisee, which is itself a cost I come back to below. The crosswalk comes with the record too: the documented Golden Record attribute maps each record in a match group to its golden record [13] [14], so every source record is linked, through its golden record, to every other source's record for the same customer.

This is the answer to the oldest objection to master data, that there is no single version of the truth. Jim Harris put it memorably: what an organisation actually has is "various versions of verisimilitude", each fit for its own purpose [15]. Tomi Dahlberg went further and declared the golden record dead, because "data may have several true meanings depending on its use context" [16]. I agree with the premise and not with the funeral. The design above keeps one record for identity and the enterprise's shared facts, and lets each domain keep its own true meaning beside it, survived by its own rules. Dahlberg's remedy, interoperable attributes and their metadata, appears from his abstract, which is all I have read, to land close to the same place from the opposite direction. Domain-driven design's version of the problem is the bounded context, where Martin Fowler quotes Eric Evans that "total unification of the domain model for a large system will not be feasible or cost-effective", and argues for explicit mappings between contexts [17]. The core entity with domain attributes is a mapping held inside the record rather than between systems. That is its strength, and as the next section argues, it is also where it can fail.

Domain masters, and the CRM 114

Some domains do not want a column on the enterprise record. They want records of their own: a population the enterprise does not master, or masters differently, and that the domain must be able to export as its own. My answer covered that case with an analogy:

It’s even possible to create ‘Domain Masters’ for specific Domains that require stand-alone records. By modifying the ‘Master’ code prefix, similar to the CRM-114, code-based filters can restrict data exports to Domains based upon their specific sub-set of Master Records.

The reference is to Stanley Kubrick's Dr. Strangelove (1964), in which a coded device on each bomber, the CRM 114, lets a message through only if it is preceded by the correct three-letter code prefix [20] [21]. It is a filter on a prefix, and that is the mechanism.

Profisee documents the setting it rests on. On a strategy's survivorship options, the golden-record code format takes a prefix: "The character string that will prefix each golden record. Use the default "Golden Record-" value, or specify a different prefix up to 10 characters" [14]. A domain strategy whose golden records carry their own prefix produces a population that any code-based filter can separate from the enterprise's (and, on my reading, the enterprise strategy's matching criteria have to exclude that population, for instance on Record Source, if your release does not already leave golden records out of matching, or the enterprise risks matching the domain's golden records back into its own groups; the Criteria tab that confines a strategy to a subset of records [11] is the place to do it), and the documentation notes that golden records "may optionally be created in the same entity" as the source records [13]. The filter is configured, not bought. Profisee Connect, the product's own integration tool, supports filters on both its import and its export strategies, on my account; its help page lists an "On-Demand asynchronous filter" among a strategy's run options [18], and, as I recall the screen in later releases, the schedule form for a Connect strategy carries a Filter box beside its name and its cron schedule; the help page documents the named schedules and the cron expression, though not the box itself [18]. Outside Connect, Profisee's public REST connector documents a record filter "in OData format" and a "comma-separated list of record codes" [19]. Neither page shows a filter that tests the start of a code, so check how your release expresses one before you rely on it. And nothing in the product is called a domain export: which filter serves which domain, and what it selects, is configuration you design and own.

The film also carries a warning that is worth more than the analogy. In the film, the bombers will only hear a message preceded by the right code, and finding it by trying every permutation would take two days; on one aircraft the radio is damaged, and that crew can never be recalled [20]. A prefix filter is exactly as good as the governance of the prefix. Who may create one, how it is registered, what it is allowed to look like and who is told when it changes are enterprise-tier questions, the naming standard and documentation requirement from the top of the ladder, and ten characters is not much room for a naming standard to work in. An unregistered prefix is a domain that has quietly left the enterprise.

The case against putting the domains in the record

The strongest objection to this design comes from the people who argue for federation most strongly. Dehghani writes that the old emphasis on certifying golden datasets "as a central function of governance is no longer relevant" [7]. Piethein Strengholt, writing about master data inside a mesh, warns: "Don't fall into the trap of enterprise data unification by selecting all data", and wants the mastered attributes "in the tens, not the hundreds" [22]. Ole Olesen-Bagneux, quoting Strengholt's book, gives the rule that "data elements that are used within only a single domain shouldn't be within MDM's scope" [23]. On that view a Finance-only credit limit has no business on a master record at all, and putting it there flattens the domain into the centre's model.

The integration world adds the width problem. Gero Vermaas's warning about canonical data models is that their creators "try to boil the ocean and include each and every piece of information used in the organization", and that the model then becomes an endless discussion [24]. Conway's law explains why: a system's structure copies the communication structure of the organisation that designs it [25], so one shared entity implies one shared conversation, and every domain that adds an attribute joins it. In Profisee the width has a physical cost as well. The platform keeps its own copy of the data it masters, which I have called one of the trades it makes for lower complexity (Simple Is a Trade weighs that trade and the rest), so every domain attribute is stored in Profisee's own SQL Server database and carried through every load.

I think those objections are right about the risk and wrong about the conclusion, and the difference is in two parts of the design. The first is that enterprise survivorship never writes a domain attribute. Olesen-Bagneux's real concern is flattening, a domain's meaning reduced to the centre's, and a domain attribute survived only by its owner, by its owner's rule, is not flattened; it is stored beside the enterprise's answer, not replaced by it. Strengholt himself concedes the other half of the design: "Identifying unique data and assigning master identifiers can only be done centrally, not locally within systems" [22]. Central identity is the part both sides accept. The second is that the domain master exists precisely for the population that should not be shared. Where a domain's records are not the enterprise's records, the prefix route keeps them out of the enterprise's model while still giving them Profisee's matching and survivorship.

What the objections do earn is a rule of admission, and here I am extending my answer rather than quoting it. A domain attribute belongs on the core entity when the domain needs it keyed to the enterprise identity: when someone will roll it up the enterprise hierarchy, cross-reference it to another domain or report it beside the shared facts. An attribute that is only ever read inside the domain, about records only the domain cares about, belongs in the domain's own system or in a domain master. That rule gives the hybrid tier something checkable to enforce, and it gives the shared entity a reason to stay narrow. BCG's paper on federated governance puts the balance in a sentence: "Central oversight must be balanced with local autonomy" [26]. The admission rule is where that balance is struck, attribute by attribute.

The mesh advocate's sharpest point survives all of that, and I would rather concede it than argue around it: a shared entity is a shared release. A domain cannot add an attribute to the core entity on its own schedule; the attribute is a model change, it goes through the enterprise tier's naming and documentation standard, and on Profisee it ships through the model-promotion path, which is not where the product is strongest (Simple Is a Trade covers promotion without source control). So the enterprise tier owns the core entity's schema, and the price of a domain band is that the domain waits for a release to change it; on the first route the same holds for a change to the domain's survivorship rule, because its attribute sets live inside the enterprise strategy. The admission rule keeps that price low by keeping the bands few, and the domain master is the way out for a domain that cannot wait.

What Profisee gives you, and what you build

A disclosure, because what follows assesses Profisee. 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 from the vendor, and our services revenue depends on master data management being bought at all. Those interests run toward praise of Profisee, of the category and of Microsoft, inside whose platform Profisee positions itself, so weigh what I say in their favour below what I say against them. One interest runs the other way: the parts of this design that sit around the product, the ownership checks and the export configuration, are paid integration work for us, which gives us a reason to say the product does less of it than it does. Discount that judgement too.

What Profisee gives you, on its own documentation, is enough to carry the model: entities that hold enterprise and domain attributes side by side; more than one strategy per entity, run in sequence; matching confined to a subset of records; survivorship in attribute sets, each with its own filter, criteria and action policy; a golden-record code prefix per strategy; golden records in the same entity as their sources; Connect strategies with import and export filters; a REST interface that filters by attribute or record code [10] [11] [14] [13] [18] [19]. Its Purview integration then publishes the model and matching strategies to the catalogue and brings ownership and glossary back to stewards [2], which is useful governance plumbing, though not the mechanism I described.

Survivorship is not the only thing that writes an attribute, and the ownership map has to reach the other writers too. A steward editing a record, a form in the portal or an inbound integration can change Finance's credit limit as easily as a strategy can, so on my reading the map has to be carried into permissions as well as into survivorship sets, and into which integration is allowed to load which attribute. Profisee says its security model sets "specific data access rights down to the granular level", including "control over which data columns users can access" [27]; I have not tested that against a domain-band design, and my answer did not name permissions as part of the mechanism, so treat it as the place to look rather than a finding.

What it does not give you is the governance. Nothing in the product decides which attributes are the enterprise's, records which domain owns each of the rest, stops two strategies surviving the same attribute, registers a prefix, or decides which export filter serves which domain. Those are the rulebook, and in my mapping, not a procedure from my answer, they fall onto the three tiers. The enterprise tier owns the core attributes, their standard, the naming of strategies and attribute sets, and the prefix registry. The hybrid tier owns the attribute ownership map, the admission rule and a deployment check that every attribute appears in exactly one owner's survivorship sets. The local tier owns each domain's criteria, written down: which sources it trusts, which rule picks the winner, and why.

Read as a build sequence, the design comes to eight steps. It is the same assembly as above, not a procedure from a particular project:

1. Draw the ownership map first. For each core entity, list every attribute and its owner: enterprise or a named domain. Apply the sixteen-name-fields test to every domain attribute; a copy of an enterprise answer is not a domain attribute.
2. Apply the admission rule. Attributes that never leave their domain go to the domain's system or a domain master, not the core entity.
3. Build the enterprise strategy. Match across all sources; survive only the enterprise attributes, by the enterprise's criteria.
4. Give each domain its own survivorship on the enterprise's groups. Its own attribute sets, with filters that admit only the records it trusts, writing only the attributes it owns, inside the enterprise strategy by default; a survivorship-only strategy on the enterprise's existing control attributes only once you have tested it in your release. A domain that needs its own matching is a domain master, not a band.
5. Gate the overlap. Make "each attribute in exactly one owner's survivorship sets" a check that runs before a model change is deployed, not a convention.
6. Register every prefix. Name, owner, purpose, date; within ten characters; the enterprise tier approves it.
7. Configure the export filters against the registry, in Connect or whatever carries your exports, so a domain export selects by registered prefix and nothing else.
8. Watch the width. Count strategies, control attributes and domain attributes per entity at every release, and ask of each new attribute whether it passed the admission rule.

Built, not bought

The question expected a feature. There is none, and I do not think there should be one. A federated model with a centralised core is a statement about who decides what, and no vendor can ship that statement; what a vendor can ship is parts that make it cheap to express. In Profisee those parts are the oldest in the product: an entity that can hold attributes with different owners, and matching strategies that can be told which records to look at and which attributes to write. One record carries the enterprise's identity and the enterprise's facts; beside them sit each domain's own answers, survived by each domain's own rules; and where a domain needs records of its own, a prefix sets them apart, like the code on the CRM 114.

What makes it governance is the rulebook around it: the map of who owns which attribute, the rule for what is allowed onto the shared record, the gate that stops two owners writing the same field, and the registry that keeps every prefix known to more than one person. Build those, and the same two features let you encode centralised, federated and embedded decisions in one model; the federation lives in the rulebook, and the product runs the configuration that encodes it. Skip them, and you have a wide entity, a set of strategies nobody can explain, and a code somebody once chose and nobody remembers.

References

[1] Benjamin Bourgeois, "Master Data Management (MDM) Implementation Styles, Explained," Profisee blog, 12 February 2024 (modified 22 August 2026). Read in full 2026-10-26. Vendor page (the vendor we partner with). https://profisee.com/blog/master-data-management-implementation-styles/

[2] Microsoft, "Microsoft Purview and Profisee Master Data Management (MDM)," Microsoft Learn, last updated 3 April 2025. Read in full 2026-10-26. https://learn.microsoft.com/en-us/purview/data-governance-master-data-management-profisee

[3] Gartner, "Master Data Management: Definition, Process, Framework and Template," gartner.com (the IT Glossary entry for master data management redirects here). Definition read 2026-10-26. https://www.gartner.com/en/data-analytics/topics/master-data-management

[4] Irina Steenbeek, "Data Management vs. Data Governance Operating Models: Are They Different?," Solutions Review, 9 January 2024. Read in full 2026-10-26; a secondary account of DAMA-DMBOK2, which was not read. https://solutionsreview.com/thought-leaders/data-management-vs-data-governance-operating-models-are-they-different/

[5] UK Government, "Data Ownership in Government," Crown copyright 2023 (PDF, published with the Central Digital and Data Office's guidance). Read in full 2026-10-26. https://assets.publishing.service.gov.uk/media/6565b01c1524e6000da101a6/Data_Ownership_in_Government.pdf

[6] Bryan Petzold, Matthias Roggendorf, Kayvaun Rowshankish and Christoph Sporleder, "Designing data governance that delivers value," McKinsey & Company, 26 June 2020. Read in full 2026-10-26. https://www.mckinsey.com/capabilities/quantumblack/our-insights/designing-data-governance-that-delivers-value

[7] Zhamak Dehghani, "Data Mesh Principles and Logical Architecture," martinfowler.com, 3 December 2020. Read in full 2026-10-26. https://martinfowler.com/articles/data-mesh-principles.html

[8] Kimball Group, "Conformed Dimensions," Kimball Dimensional Modeling Techniques. Read in full 2026-10-26. https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/conformed-dimension/

[9] Kimball Group, "Enterprise Data Warehouse Bus Architecture," Kimball Dimensional Modeling Techniques. Read in full 2026-10-26. https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/enterprise-data-warehouse-bus-architecture/

[10] Profisee, "Configure Settings on the Strategy Tab," Profisee Platform Help (stated to apply from 2023 R2), support.profisee.com. Login required; read in full 2026-10-26 with a Profisee Community account. https://support.profisee.com/wikis/profiseeplatform/configure_settings_on_the_strategy_tab

[11] Profisee, "Configure Settings on the Matching Tab," Profisee Platform Help (stated to apply from 2023 R2), support.profisee.com. Login required; read in full 2026-10-26 with a Profisee Community account. https://support.profisee.com/wikis/profiseeplatform/configure_settings_on_the_matching_tab

[12] Profisee, "Promotion," Profisee Platform Help (stated to apply from 2023 R2), support.profisee.com. Login required; read in full 2026-10-26 with a Profisee Community account. https://support.profisee.com/wikis/profiseeplatform/mastering

[13] Profisee, "Matching and Survivorship Overview," Profisee Platform Help (stated to apply from 2023 R2), support.profisee.com. Login required; read in full 2026-10-26 with a Profisee Community account. https://support.profisee.com/wikis/profiseeplatform/matching_and_survivorship_overview

[14] Profisee, "Configuring Settings on the Survivorship Tab," Profisee Platform Help (stated to apply from 2023 R2), support.profisee.com. Login required; read in full 2026-10-26 with a Profisee Community account. https://support.profisee.com/wikis/profiseeplatform/configure_settings_on_the_survivorship_tab

[15] Jim Harris, "The antimatters of MDM (part 2)," SAS Data Roundtable blog, 25 September 2013. Read 2026-10-26. https://blogs.sas.com/content/datamanagement/2013/09/25/the-antimatters-of-mdm-part-2/

[16] Tomi Dahlberg, "The MDM Golden Record is Dead, Rest in Peace – Welcome Interpreted Interoperable Attributes," scientific report, D2I Shock-program project (year not shown on the repository page); deposited in the University of Turku repository. Abstract and record read 2026-10-26; full text not read. https://utupub.fi/handle/10024/163694

[17] Martin Fowler, "Bounded Context," martinfowler.com, 15 January 2014, quoting Eric Evans, Domain-Driven Design (2003). Read in full 2026-10-26; the Evans book was not read. https://martinfowler.com/bliki/BoundedContext.html

[18] Profisee, "Integration Strategies," Profisee Platform Help (Connect), support.profisee.com. Login required; read in full 2026-10-26 with a Profisee Community account. https://support.profisee.com/wikis/profiseeplatform/Strategies_24r2

[19] Microsoft, "Profisee," Microsoft Learn connector reference (Power Automate, Logic Apps and Power Apps), updated 2 December 2025. Filter and RecordCodes parameters read 2026-10-26. https://learn.microsoft.com/en-us/connectors/profisee/

[20] Stuart Blackburn, "Dr. Strangelove" (1964) film study, The Humanities Institute, undated. Read 2026-10-26. https://humanitiesinstitute.org/__static/98c096e306e9d8d43be7a13c59d6d61c/dr-strangelove(3).pdf

[21] Raymond Weschler, "Dr. Strangelove," ESL Notes film guide with the film's dialogue annotated, 2001. Read 2026-10-26; cited for the dialogue that names the CRM 114 and its three-letter code prefix. https://www.eslnotes.com/movies/pdf/dr-strangelove.pdf

[22] Piethein Strengholt, "Master Data Management in Data Mesh," Towards Data Science, 25 February 2022. Read in full 2026-10-26. https://towardsdatascience.com/master-data-management-in-data-mesh-594d21f3ee10/

[23] Ole Olesen-Bagneux, "On the Necessity and Impossibility of Master Data in Data Mesh," presentation slides (Zeenea), 2022, hosted by IRM UK. Read 2026-10-26; the quoted rule is credited on the slide to Piethein Strengholt, Data Management at Scale, chapter 10, which was not read. https://irmuk.co.uk/wp-content/uploads/2024/02/Olsen_Bagneux_On_the_Necessity_and_Impossibility-1.pdf

[24] Gero Vermaas, "Top 10 SOA Pitfalls: #4 - Incorrectly applied Canonical Data Model," Xebia, 2 June 2008 (updated 28 January 2026). Read in full 2026-10-26. https://xebia.com/blog/top-10-soa-pitfalls-4-incorrectly-applied-canonical-data-model/

[25] Melvin E. Conway, "How Do Committees Invent?," Datamation, April 1968; text at melconway.com. Read 2026-10-26. https://www.melconway.com/Home/Committees_Paper.html

[26] Kaj Burchardi, Dwaipayan Nath and Jiaqi Lan, "Federated Data Governance Model," Boston Consulting Group and BCG Platinion, June 2024. Read 2026-10-26. https://media-publications.bcg.com/Federated-Data-Governance-Model.pdf

[27] Profisee, "Data Governance | Profisee Platform," profisee.com, modified 11 September 2026. Security paragraph read 2026-10-26. Vendor page (the vendor we partner with). https://profisee.com/platform/governance