A Distance From Perfect, Owned by Domain

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

One standard, and what it did not survive

Early on, I tried to put the whole enterprise on one standard. The attributes were the ones every department touches — client type, product line, inventory category — and I still think those belong to a single enterprise-wide value. What did not survive was the assumption underneath: that every department would take that value the way I had defined it. The pushback came as requests to make the downstream reports match what each department expected to see, some for backward compatibility, some for reporting only that department needed. It has not stopped. I manage it; I have not finished with it.

That failure is where this argument starts, because it came from the first of two assumptions governance frameworks still carry. Ask how a programme is aligned with business strategy and the usual answer is a diagram: the strategy at the top, the framework underneath, arrows from each goal to a policy, a council, a stewardship role and a quality dimension. Ask how the same programme keeps strong control of master data and the usual answer is a number with a percent sign after it, close to a hundred. The first assumption is that alignment is uniform: one framework, the same definition of good for every domain it touches. The second is that strength means completeness: that a strongly controlled estate is one whose rules catch every defect, so the distance from perfect is a failure to close rather than a quantity to choose.

I held the first of those and gave it up. The second is the harder one to give up, and the rest of this piece is why. Here is the narrow claim I will defend. At enterprise scale, governance is aligned with strategy one domain at a time, and a master data control is strong when three things are true of it: its distance from perfect is stated in advance, every record that falls outside it has a named owner, and someone with enough standing to override a department's convenience enforces it.

What the field already concedes

When I went looking for who agrees with me, the first answer was in the definition of the word everyone uses. Every control is a claim about data quality, and the definition most of the discipline still builds on is thirty years old. Richard Wang and Diane Strong, surveying the people who actually consumed data rather than the people who produced it, defined data quality as data that are fit for use by data consumers, and sorted what those consumers cared about into four families: intrinsic, contextual, representational and accessibility [7]. The definition is relative on purpose. Fit for use is a relation between a record and a use, not a property of the record. A customer address that is perfectly adequate for a marketing segment is unusable for a legal notice, and nothing about the address changed.

The newest pressure on data quality restates that relativity rather than escaping it. Gartner's February 2025 warning that "through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data" is usually read as a demand for cleaner data everywhere [10]. Its own definition says something narrower: the data "must be representative of the use case, of every pattern, errors, outliers and unexpected emergence that is needed to train or run the AI model" [10]. That is fitness for use again, applied to a new consumer, and on that definition it cuts against a uniform bar from the other side: a training set scrubbed of the errors and outliers its use case contains is less representative of that use, not more.

Follow that definition one step and uniformity is already gone. If quality is fitness for a use, and the uses differ by domain, then one enterprise-wide target is a claim that every domain uses its data in the same way, which no enterprise of any size can say with a straight face. The frameworks know this. They mostly write around it by defining the dimensions centrally and leaving the thresholds to "the business", which is honest, and then drawing the thresholds on the diagram as though they were set, which is not.

The research on governance design says the same thing one level up. Kristin Weber, Boris Otto and Hubert Österle ran a community action research project with six international companies and came away with a contingency model rather than a template: the right data governance configuration depends on the company's performance strategy, diversification breadth, organisation structure, competitive strategy, degree of process harmonisation, degree of market regulation and decision-making style [6]. Their sentence for it is flat: "A data governance configuration is specific to a given company" [6]. They also name the pure centralised pole precisely, as the arrangement in which "all decision-making authority resides in a central DQM role, such as the chief steward or the data quality board" [6], and they do not recommend it as a default.

Weber and her colleagues argue contingency between companies. I am going to push it one step further, and that step is my inference rather than their finding: the factors on their list do not only vary between companies, they vary between domains inside one. Market regulation bears on a finance ledger and barely touches a campaign list. Process harmonisation is high in a shared-services function and low in a newly acquired division. If the configuration has to fit those factors, then the configuration of a large enterprise is not one configuration.

The data mesh literature arrives at the same shape from the architecture side. Zhamak Dehghani's account of federated computational governance describes the central problem as deciding what is standardised globally and what is left to the domains, and calls "striking a balance between what shall be standardized globally ... and what shall be left to the domains to decide" an art [8]. Her worked example is useful because it draws the line in a specific place: how a domain models its own data stays with the domain, while how the enterprise identifies an entity that crosses domains is a global concern, because the global layer exists to make the domains interoperate [8]. She would enforce the global part computationally, in the platform, rather than by committee [8].

So a quality definition, an organisational contingency model and a distributed architecture all concede the first assumption: one bar does not fit the enterprise. The second assumption, that the bar should sit at complete, is where the field's evidence and its rhetoric part company.

One of the strictest regimes in the field still writes down a tolerance

A bank supervisor has as good a claim as anyone to insist on completeness, and one of the strongest statements of the completeness position is written into banking supervision. The Basel Committee's principles for risk data aggregation, published in January 2013 and known everywhere by their document number, BCBS 239, say that "Controls surrounding risk data should be as robust as those applicable to accounting data" [1]. They ask a bank to "capture and aggregate all material risk data across the banking group" [1]. The largest banks were given until January 2016 to comply [1]. That is the opposing position at full strength: in the domains that matter most, the bar is set from outside, it is set high, and the enterprise does not get to choose a comfortable distance from it.

Read the next sentence, though, because it is the one the completeness position usually leaves out. "Supervisors expect banks' data to be materially complete, with any exceptions identified and explained" [1]. Material, not total. Exceptions, expected and named. And the principle on report accuracy goes further: supervisors expect "a bank's senior management" to "establish accuracy and precision requirements for both regular and stress/crisis reporting" [1]. One of the strictest data regimes in the field does not abolish the distance from perfect. It requires somebody senior to state it, and it requires every record outside it to carry an explanation. That is very close to my claim, arrived at by a regulator with no interest in agreeing with anybody.

It also answers the strongest objection to what I am arguing. The quality-engineering tradition holds that a stated tolerance becomes a licence: once an enterprise writes down that ninety-something percent is acceptable, it stops working on the rest, and the rest is where the losses concentrate. That is not foolish. A tolerance with nobody accountable for the remainder is exactly what it predicts. The regulator's answer is the one I would give: keep the tolerance, and make every record outside it carry an explanation.

Now look at how far from the stated bar some of the most heavily supervised data programmes in the world actually are. Nearly eight years after that deadline, the Committee's November 2023 progress review reported: "Of the 31 banks assessed, only two banks are fully compliant with all the Principles. Also, there is not a single Principle that has been fully implemented across all banks" [2]. The same executive summary gives a reason, and it is not a technical one. Adoption programmes "were often underfunded, limited in scope and lacking sufficient attention from boards of directors (boards) and senior management" [2]. I will come back to that sentence, because it carries more of this argument than any number in the report.

The record-level picture outside banking is worse. Tadhg Nagle, Thomas Redman and David Sammon had 75 executives each take a hundred records their own department had recently created and mark the obvious errors; the share of error-free records became the department's data quality score [5]. On average, "47% of newly-created data records had at least one critical error", and "only 3% of the DQ scores in our study can be rated 'acceptable' using the loosest-possible standard" [5]. That exercise measures something different from the regulator: records as created, not a bank's aggregation capability against principles. The two measurements agree on only one thing, and it is the thing that matters here. Nobody is near complete, and the organisations with the most reason to be are not near it either.

If completeness were reachable at scale, supervised banks under a published standard are where it would show, and it does not. That does not prove it unreachable, because the regime never asked for it: it asks for materiality [1]. So the ceiling I put on first-pass rules rests on my own record, below, and on nothing public that measures first-pass rule coverage at enterprise scale, because I did not find anything that does.

Against that, the market's vocabulary of perfection is Six Sigma, in the American Society for Quality's words a method for improving "the capability of their business processes", whose numerical goal is "3.4 defects per million opportunities" [4]. I will come back to how far that sits from anything a rule set can reach.

Where rules stop

From here the warrant changes: what follows rests on my own record and is offered as pattern from practice rather than as law.

Asked the flattering question, what I knew from the first day that everyone else learns eventually, I declined it:

I'm not a superhuman with no learning curve. I needed to learn the same lessons as everyone else. The only thing that really distinguishes me, as near as I can tell, is that I tend to think much more in rules, limits and sets than most people. I very much like an 'ordered' world, and carrying that approach into data governance is an easy win.

The person telling you where rules stop should be someone whose instinct is to write more of them, and mine is a rules instinct. Faced with a messy domain, the first thing I reach for is a set: what is in it, what is out of it, where the boundary is and who is allowed to move it. That habit is an easy win in governance and also a specific risk, because left unchecked it produces exactly the two assumptions above. One set of rules for everybody, and rules that are expected to be complete. The one-standard episode cured me of the first. The second is what my next answer is about.

Asked what the genuinely hard part of writing data rules is, as opposed to the part that takes the most hours, my answer was about the ceiling rather than the work:

The hard part is realizing that 'rules' will only get you 95% of the way there. Perfect isn't achievable — it's a goal to strive for, and we need to accept that falling short is okay. Hitting two standard deviations beyond the mean on a first-pass set of data rules is good and three is great, but 100% is unachievable, unless we're shoehorning everything into a box and declaring victory, which is perfectly viable in bounded data sets. I say 'standard deviations' rather than 'sigma' on purpose, to avoid the ambiguity with Six Sigma: that is a great deal more refinement than is practical in master data management or data governance, and I would not claim it. Three standard deviations is about the ceiling I would suggest is achievable — and even one standard deviation of automation is a significant improvement over no MDM implementation at all.

I am making two claims there, and the second is the one people round off. The first is the ceiling: a first pass of rules does not reach every record, and past a point the effort to make it do so stops producing anything but effort. The second is the floor, and it is the more useful of the two for anyone trying to justify a programme. The bar for value is far below the bar for excellence. A rule set that handles only the middle of the distribution is already a large improvement on having no master data management at all, and a programme that waits to be excellent before it counts as useful has confused the two bars.

The scale is a practitioner's, not a measured rate, so here is the plain reading. On a normal distribution, two standard deviations cover 95.45% of a population and three cover 99.73% [3]. Read as the share of records a first pass of rules handles correctly, two is about the 95% a first pass typically reaches, and three, about 99.7%, is the ceiling; I would not claim more. That reading is mine and I have not tested it against a counted rule set. Read any way at all, it leaves no room for a rule set written ahead of unbounded data that calls itself complete.

The exception I allowed for is worth more attention than it usually gets. Completeness is available if everything is shoehorned into a box and the box is declared the answer, and that move is legitimate for bounded data. A closed list of values, a code set that is published and owned somewhere else, a dimension the enterprise defines entirely for itself: in those, the enterprise decides what exists, so a rule can cover all of it by construction. The failure is carrying that move into an unbounded domain, where the box does not describe the world and declaring victory just relocates the defects to whoever has to work around the box. That distinction, bounded or not, is the first thing a per-domain target has to settle, and it is a question about the domain, not about the framework.

Alignment happens one domain at a time

The standard operating-model question is a menu: should governance be centralised, federated, or embedded in the domains? Asked to choose, I would not:

Centralised, federated or embedded in the domains — it should be all three, and federated and embedded are one and the same thing. Centralised is where the consistent, universally applied standard lives: forms of communication, which decisions get documented, what metadata and information is gathered, and clear roles and responsibilities. The federation part is the responsibility of every domain to publish its group's information to those standards while simultaneously establishing the governance model that works for its own domain of data. Finance needs hard numbers; they can't work without them. Marketing doesn't have a single hard number in the department — including pay. Every group needs to be responsible for its own rules and data, but they need to conform to enterprise standards when they create and document those rules.

That is what aligning governance with strategy looks like once it leaves the diagram. The strategy does not ask the same thing of Finance and of Marketing, so a framework that serves the strategy cannot ask the same thing of them either. Finance closes periods and publishes figures that other people rely on; a control target for Finance's master data is a claim about numbers that cannot move after they are signed. Marketing lives on segments, propensities and campaigns that are meant to be revised; a control target set at Finance's level would cost Marketing a great deal and buy it very little. Aligning governance to the strategy means letting those two targets differ, on purpose, and saying so.

What the enterprise keeps is not the content of the rules. It is the form: how decisions are communicated, which decisions are written down, what metadata is captured about a rule, and who holds which role. That is a narrower central layer than most frameworks draw, and it is worth setting beside Dehghani's, because the two do not split the work in the same place. Her global layer holds identity, the handful of entities that cross domains and have to mean the same thing everywhere so that the domains can interoperate [8]. Mine holds procedure. The two are compatible rather than rival, and the single-standard reversal above is where they meet: the attributes I still want held to one enterprise-wide value, the ones that cross every department, are precisely the ones she would put in the global layer. The rest of each domain's rules belong to the domain, and the enterprise's claim on them is only that they be stated in its form.

Here the rules and the domains meet, and the join is my own inference: the control target is a domain rule like any other. A domain decides how far from perfect its master data may sit, because the domain is the one that knows what the data is for. The enterprise decides how that distance is written down. In practice that means a short, fixed record for every domain, kept in the one place the central standard says such records live, stating whether the domain's data is bounded or not, the target distance for its first-pass rules, who owns the records that land outside the target, how an exception is explained, and who has the standing to hold the domain to it. Nothing on that list is a framework. All of it is a decision somebody has to be named against.

A regulated domain adds one line, not a second model. Where a regime like BCBS 239 applies, the target is not the domain's to choose freely; senior management states the accuracy requirement and every exception is identified and explained [1]. That is the same record with a stricter bar and an outside reader. An enterprise that has already written down targets for its other domains should find the regulated one easier, not harder, because the form already exists; I state that as the logic of the design, not as a measured result.

What an unowned exception sounds like

A stated distance from perfect is only as strong as its exceptions path, and the exceptions path is where programmes quietly fail. Asked for the earliest sign that a governance programme is going wrong, I did not name a metric. I named a sound:

The early tell that a governance programme is failing is dodging and evasion. Not my fault, not my group, not my responsibility. You hear 'not' a lot, along with attempts to point the finger at other people or groups. This isn't just data governance, it's every organization. In the absence of a hierarchy, the organization is an amorphous blob of individuals all trying to maximize the appearance of competence and minimize their direct responsibilities. There are some people who are psychologically incapable of not solving problems they encounter — I'm one of them — and those people wind up being the only ones doing any work and, therefore, the ones who shoulder the blame when things go wrong.

Read that against the record described above and the dodge stops looking like a character flaw. It is what a record outside the target sounds like when nobody's name is beside it. A rule set that handles most of a domain leaves a remainder by design, and the remainder has to go somewhere. If the target record names who owns it, the remainder is work with an owner. If it does not, the remainder is a question that gets asked in a meeting, and the answers are the ones in the quotation: not my group, not my responsibility, somebody else's system. None of those answers is a lie. In an organisation that never assigned the remainder, every one of them is technically true.

The formal remedy exists and is well described. Weber and her co-authors build their governance model as a responsibility assignment matrix, roles against decision areas, with the type of responsibility in each cell [6]. The matrix is the right instrument and I would not argue with it. What the dodge tells you is that the matrix has cells that are empty or shared, and that people have noticed. An exceptions path is one row of that matrix that most programmes leave blank, because filling it means writing down, in advance, that there will be exceptions, which is the admission the completeness assumption exists to avoid.

The second half of what I said there is the part I would least like a reader to skip, because it is about who pays for the blank row. I am one of the people who cannot leave a problem alone once it is in front of me, and people like that end up carrying the remainder whether or not anyone assigned it to them. They do the work, and because they are the ones visibly touching it, they are also the ones standing nearest when it goes wrong. An enterprise whose control target has no exceptions owner has not avoided the cost of the remainder. It has handed that cost, unrecorded, to whichever of its people are least able to walk past it, and it has made them the natural recipients of the blame as well. That is not a stewardship model. It is a subsidy, and nobody approved it.

That is also the most practical reason for the second condition above. A name beside every exception is not bureaucracy for its own sake. It is the only way to make visible a cost that otherwise lands on the most conscientious people in the building and is written off as their temperament.

A control the business can ignore is not a control

The third condition is enforcement, and it is the one the frameworks describe least and assume most. Asked whether a master data programme solves the question of who owns the data or only exposes it, I came down hard on one side:

Ownership is revealed by a program, not solved by one — strongly on the revealed side. 'Solving' anything requires buy-in, support, effort and, most importantly, enforcement. You can build as much intelligence into a system as you like, but if the business needs to ignore it to keep operating, they will. Vanishingly few businesses have solved systematizing their own delivery, and for those that have, all a program can do is identify another un-systematized process upstream of the one it's addressing. It's peeling the onion one layer at a time — and to butcher the phrase, it's onion all the way down.

The sentence that matters for a control target is the middle one. Any amount of intelligence can be built into the rules, and if the business has to ignore them to keep operating, it will. That is not a complaint about the business. It is a description of what a control target is up against. A target set at a distance the business cannot live with gets routed around, and the routing is invisible to anyone reading the dashboard, because the dashboard measures the records that went through the rules and not the ones that were keyed somewhere else to avoid them. That is also why the distance has to be set by the domain, as argued above: a target the domain chose is one it has less reason to route around. But less reason is not no reason, and when the target and the quarter-end collide, somebody has to decide which gives way.

That somebody is where I part company with the most persuasive alternative, and I want to be precise about how far. Robert Seiner's non-invasive data governance holds that governance need not arrive as new work carried by new people: steward responsibilities are "identified and recognized, formalized and engaged according to their existing responsibility rather than being assigned or handed to people as more work", and governance is "applied to existing policies, standard operating procedures, practices, and methodologies" [9]. If that is right, my third condition overstates what governance needs; recognition does the work and weight is optional. On ownership, that is close to my own position: a programme reveals who already owns the data; it does not create owners out of nothing. Recognising them is the right first move.

Where we part is on what recognition can hold. The councils, stewardship models, maturity assessments and policy-first approaches the field recommends are, as far as I can see, all correct in principle and all oversold in practice. Each of them works or fails on how it is implemented and, above all, on how strong its champion is, because each of them asks people to spend part of their week on something that does not touch their own department's output. The received wisdom about them quietly assumes an investment of time and authority that most enterprises have not made. That is my quarrel with it, and it is a quarrel about the assumption, not about the methods.

The Basel review is the strongest public support for that quarrel I can offer, and it comes from a setting where the investment should have been guaranteed. Supervised banks, with a published standard, a deadline and a supervisor, built adoption programmes and roadmaps, and those programmes were still "often underfunded, limited in scope and lacking sufficient attention from boards of directors (boards) and senior management" [2]. If a regulated bank under supervision cannot count on the weight arriving by itself, an unregulated domain with a target of its own choosing should not expect it either. If Seiner were right, programmes would routinely hold a target against a department's resistance with nobody senior behind them, and the Basel record points the other way. It is one regime and one kind of institution, so it limits my claim rather than settling it. The third condition survives in a smaller form: recognising stewards staffs a target; it does not hold one when holding it costs a department something.

The last thing I said there is the honest limit on all of this. Every layer a programme settles exposes the one upstream of it that nobody had systematised, and very few enterprises have systematised their own delivery at all. A control target is not a finish line. It is a statement of where the enterprise has decided to stop peeling for now, and who is accountable for the layer it stopped at.

Where the first target gets set: triage or assessment

If the target is a per-domain decision, the practical question is which domain gets one first and how. The orthodox answer is an assessment: establish the current state across the enterprise, score it, and plan the programme from the score. Asked where an engagement actually starts, I described two roads rather than one:

There are usually two courses of action. Triage: stand up what's needed to solve the immediate problem that prompted the project in the first place, and only then work on extending it into a comprehensive programme. Comprehensive: start from the top down with an assessment of where they're at, what they have and what their immediate needs are — which differs from triage only in that they haven't had the emergency yet; they just watched someone else have it and are trying to be proactive. Kudos. Ideally you assess and plan before implementing anything, but when circumstances call for it, having a library of 'basic', industry-neutral approaches or frameworks that can be implemented automatically and quickly beats a poke in the eye with a sharp stick. It stops the bleeding so real governance can be developed over time, with buy-in from the enterprise.

The comprehensive road is the one the frameworks assume, and I do not reject it. It is the ideal, and a client that takes it before its own emergency deserves credit for it. The disagreement is with treating it as the only road. On the triage road the programme exists because something has already gone wrong in one domain, and there the first control target is not an enterprise design exercise. It is whatever stops the damage in the domain that is bleeding, set quickly, from a stock of plain, industry-neutral approaches that do not need to be invented under pressure.

That has a direct consequence for the argument of this piece. Under triage, the first stated distance from perfect is set in one domain, by necessity, before the enterprise standard for stating it exists. The risk is that the emergency's target becomes the enterprise's template by default: the bar that was right for the domain in crisis gets copied to domains that are not in crisis and do not need it. The protection is the order I put them in. Triage stops the bleeding so that real governance can be built afterwards with the enterprise's agreement, which means the triage target is provisional by definition and has to be restated in the enterprise form once that form exists.

The Basel review supplies the cost of getting the other half wrong. Among the reasons banks fell short, it lists that "several banks failed to fully assess the complexity and interdependence of related projects, especially to address IT legacy systems" [2]. That is the case for assessment, made by a regulator, and I accept it. Triage without a later assessment is how an enterprise ends up with one domain's emergency settings running everywhere and nobody able to say why. Assessment without triage, when there is already an emergency, is how a programme spends its first year describing damage it could have stopped. Triage is a tourniquet: provisional by definition, and followed by the assessment it postponed.

What "done well" turns out to mean

Go back to the two assumptions this piece opened with. The first, that alignment is uniform, the field's own literature had already given up: quality is fitness for a use [7], governance configuration is contingent [6], and the architecture that takes domains most seriously leaves each one its own model and centralises only what has to interoperate [8]. What the operating record adds is where the line falls in practice. The enterprise owns the form in which rules are stated, communicated and owned; each domain owns the rules, including how close to perfect its own master data has to be.

The second assumption, that strong means complete, is the one the experience changes most. Strength turns out not to be a level. It is three properties of a target. The distance from perfect is stated before the quarter starts, not discovered at its end. Every record outside that distance has a name beside it, so the remainder is owned work rather than a subsidy from whoever cannot leave it alone. And the target is held by someone with the standing to make a department live with it, because a control the business has to ignore to keep operating will be ignored. One of the strictest regimes in the field asks for the same three things in its own language: materiality rather than totality, exceptions identified and explained, and accuracy requirements set by senior management [1]. It also shows how rarely the third arrives unaided [2].

Two things I could not establish, and they bound everything above. I found no public measurement of how much of an enterprise domain a first pass of rules actually covers, so the ceiling in this piece rests on practice and on nothing I can cite. And the practitioner record here is much stronger on how control targets fail than on how a good one is negotiated: who proposes the distance, who can refuse it, and what happens when two domains want different distances for the same attribute. Those are the mechanics of doing this well, and they are the part of the question that remains open.

What the claim rules out, after all of that, is specific enough to check against any programme. One quality target for the whole enterprise. A target with no exceptions path. A framework, council or maturity score presented as the evidence that governance is aligned with the strategy. If a programme has any of the three, it has the diagram and not the alignment.

Appendix: the arithmetic

The standard-deviation scale in "Where rules stop" reads normal-distribution proportions [3] as a share of records a rule set handles. Figure 2 puts those proportions on one logarithmic axis as records per million left outside the rules, beside the Six Sigma goal as the American Society for Quality states it [4]. Two cautions travel with it. The goal is stated in defects per million opportunities, which is not the same unit as the other three points, so it is plotted as stated and marked apart from them; and it is not the normal-table value for six standard deviations either, because the conventional figure places the process mean 1.5 standard deviations off centre, while a centred six-sigma process corresponds to about 2 defects per billion [12]. And the whole figure is an analogy, not a measurement: no public measurement of first-pass rule coverage at enterprise scale was found. The points are dots rather than bars because a logarithmic axis has no zero, so a bar's length on it would be arbitrary; placing each amount as a position on the scale follows Claus Wilke's treatment of the problem [11].

References

[1] Basel Committee on Banking Supervision, Principles for effective risk data aggregation and risk reporting (BCBS 239), Bank for International Settlements, 9 January 2013, https://www.bis.org/publications/201301-guidelines-principles-effective-risk-data-aggregation-and-risk-reporting — cited for Principle 3 ("Controls surrounding risk data should be as robust as those applicable to accounting data"), Principle 4 ("capture and aggregate all material risk data across the banking group"; "Supervisors expect banks' data to be materially complete, with any exceptions identified and explained"), Principle 7 (senior management to "establish accuracy and precision requirements for both regular and stress/crisis reporting") and the January 2016 compliance date for the banks first designated as global systemically important. Read in part, 2026-09-26: those passages were extracted from the PDF; the document was not read end to end.

[2] Basel Committee on Banking Supervision, Progress in adopting the Principles for effective risk data aggregation and risk reporting, Bank for International Settlements, 28 November 2023, https://www.bis.org/publications/202311-implementation-reports-progress-adopting-principles-effective-risk-data-aggregation-and-risk-reporting — cited for three executive-summary passages: "Of the 31 banks assessed, only two banks are fully compliant with all the Principles. Also, there is not a single Principle that has been fully implemented across all banks"; adoption programmes "were often underfunded, limited in scope and lacking sufficient attention from boards of directors (boards) and senior management"; and "several banks failed to fully assess the complexity and interdependence of related projects, especially to address IT legacy systems." Executive summary read 2026-09-26; the full report was not read end to end.

[3] NIST/SEMATECH, e-Handbook of Statistical Methods, section 6.5.1, "What do we mean by 'Normal' data?", National Institute of Standards and Technology, https://www.itl.nist.gov/div898/handbook/pmc/section5/pmc51.htm — cited for the proportions of a normal population within one, two and three standard deviations of the mean (68.27%, 95.45%, 99.73%). Page read 2026-09-26. Applying these proportions to a rule set is this article's analogy, not the handbook's.

[4] ASQ (American Society for Quality), "Six Sigma Definition - What is Lean Six Sigma?", https://asq.org/quality-resources/six-sigma — cited for "Six Sigma is a method for disciplined quality improvement that provides the tools organizations need to improve the capability of their business processes" and "The numerical goal of a process operating at a 6-sigma level is 3.4 defects per million opportunities". Definition passages read 2026-09-26; the rest of the page was not relied on.

[5] Tadhg Nagle, Thomas C. Redman and David Sammon, "Only 3% of Companies' Data Meets Basic Quality Standards", Harvard Business Review, 11 September 2017, https://hbr.org/2017/09/only-3-of-companies-data-meets-basic-quality-standards — cited for the method (a hundred recently created records per department, error-free share as the data quality score), the 75 executives, "47% of newly-created data records had at least one critical error" and "only 3% of the DQ scores in our study can be rated 'acceptable' using the loosest-possible standard." Read 2026-09-26 through an extraction of the page; the numeric threshold behind "acceptable" was not returned and is not relied on.

[6] Kristin Weber, Boris Otto and Hubert Österle, "One Size Does Not Fit All—A Contingency Approach to Data Governance", Journal of Data and Information Quality 1, no. 1 (June 2009), https://alexandria.unisg.ch/entities/publication/7c65d6a1-835d-4cfa-a655-88425283b055 (full text at https://alexandria.unisg.ch/bitstreams/f631b5f6-9148-4ea2-aa4d-676f899675a9/download) — cited for the six-company community action research design, the responsibility assignment matrix of roles, decision areas and responsibilities, the seven contingency factors, "A data governance configuration is specific to a given company", and the description of strict centralisation. Abstract and those passages read 2026-09-26; not read end to end. The extension of contingency from between companies to between domains is this article's inference, not the authors' finding.

[7] Richard Y. Wang and Diane M. Strong, "Beyond Accuracy: What Data Quality Means to Data Consumers", Journal of Management Information Systems 12, no. 4 (Spring 1996): 5ff., https://web.mit.edu/tdqm/www/tdqmpub/beyondaccuracy_files/beyondaccuracy.html — cited for the definition of data quality as data that are fit for use by data consumers, and for the four categories (intrinsic, contextual, representational, accessibility). Read 2026-09-26 in the MIT Total Data Quality Management archive copy, for those two points only.

[8] Zhamak Dehghani, "Data Mesh Principles and Logical Architecture", martinfowler.com, 3 December 2020, https://martinfowler.com/articles/data-mesh-principles.html — cited for federated computational governance: the balance between what is standardised globally and what is left to domains, the worked example placing a domain's data model with the domain and cross-domain identity in the global layer, and enforcement built computationally into the platform. The governance section was read 2026-09-26; the article was not read end to end.

[9] Robert S. Seiner, "What Is Non-Invasive Data Governance?", DATAVERSITY, 1 April 2016, https://www.dataversity.net/articles/what-is-non-invasive-data-governance/ (the TDAN.com address for the same piece redirects here) — cited as the opposing position on enforcement: steward responsibilities "identified and recognized, formalized and engaged according to their existing responsibility rather than being assigned or handed to people as more work", and governance "applied to existing policies, standard operating procedures, practices, and methodologies". Read 2026-09-26.

[10] Gartner, "Lack of AI-Ready Data Puts AI Projects at Risk", press release, Stamford, Conn., 26 February 2025, https://www.gartner.com/en/newsroom/press-releases/2025-02-26-lack-of-ai-ready-data-puts-ai-projects-at-risk — cited for the prediction, in the release's body sentence "Gartner predicts that through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data" and for the definition that the data "must be representative of the use case, of every pattern, errors, outliers and unexpected emergence that is needed to train or run the AI model." A vendor-analyst press release, cited for what Gartner states, not as an independent measurement; the research note behind it was not read. Release read 2026-09-26.

[11] Claus O. Wilke, Fundamentals of Data Visualization, chapter 17, "The Principle of Proportional Ink", online edition, https://clauswilke.com/dataviz/proportional-ink.html — cited for the observation that on a logarithmic axis "the value 0 would lie infinitely far to the left", so that "we could make our bars arbitrary long", and for the alternative of placing "a dot at the appropriate location along the scale". Wilke also raises the stronger argument that log-scale bar graphs are inherently flawed and then declines to settle it; he is not cited for that. Chapter section on logarithmic axes re-read 2026-09-26; the rest of the book was not relied on.

[12] Pandu R. Tadikamalla, "The Confusion Over Six-Sigma Quality", Quality Progress (American Society for Quality), November 1994, https://asq.org/quality-progress/articles/the-confusion-over-six-sigma-quality?id=5df937bea5a145b6843738990f422464 — cited for the abstract's statements that "six-sigma corresponds to 2 defects per billion parts" for a centred process and that the discrepancy with the 3.4-per-million figure "is caused by Motorola placing the process mean 1.5 standard deviations off center." Abstract only, read 2026-09-26; the article body is behind ASQ's member paywall and was not read.